Concepto
Protocolo desarrollado por Cisco, a diferencia del PPTP el protocolo L2F no depende de IP con lo cual es capaz de trabajar directamente bajo otros protocolos.
Utiliza PPP para la autenticación de usuarios remotos. Los túneles que crea pueden soportar más de una conexión.
Trabaja con un servicio de enlace llamado Virtual Dial-Up (VDU), que nos permite acceder a la utilización de toda la infraestructura de Internet, no solo para conectar a través de diferentes protocolos al IP sino también cuando las direcciones IP no son reconocidas.
El protocolo L2F es capaz de encapsular payloads PPP o payloads SLIP que serán enviados a sus destinos.
Protocolos utilizados por L2F
PAP
Protocolo de autenticación de password. Cuando se establece la conexión entre el servidor y el cliente este último envía el par formado por el nombre de usuario y la contraseña, luego se verificará la identidad del usuario y se autentificara o rechazará la petición con lo cual la conexión será finalizada.
CHAP
Protocolo de autentificación periódica del cliente. Luego de que la fase de conexión ese completada el autenticador envía un mensaje de recusación al par usuario/password, el par responde con un valor calculado usando una función hash; este valor es comparado con el que calcula el autenticador y si coinciden la comunicación continua, caso contrario se cancela.
En intervalos aleatorios se repetirá esta tarea.
Para esto se requiere que ambos extremos cuenten con la clave secreta.
Funcionamiento del L2F (Cisco's Layer Two Forwarding)
Definición del protocolo
El protocolo L2F requiere dos puntos a estandarizar:
- Encapsulamiento de los paquetes dentro del L2F. El ISP y los extremos deben negociar sobre que paquetes se encapsulará el protocolo.
- Administrador de conexión de L2F y MID.
Formato del paquete
Formato general
El paquete L2F encapsulado tiene esta forma básica:
| Encabezado L2F |
| Payload PPP/SLIP |
| CRC L2F |
Formato detallado
| 0 | 1 | 2 | 3 | ||||||||||||||||||||||||||||
| 0 | 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 0 | 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 0 | 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 0 | 1 |
| K | P | K | S | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | C | Version | Protocol | Sequence (opt) | ||||||||||||||||
| Multiplex ID | Client id (opt) | ||||||||||||||||||||||||||||||
| Length | Offset (opt) | ||||||||||||||||||||||||||||||
| Key (opt) | |||||||||||||||||||||||||||||||
| Payload | |||||||||||||||||||||||||||||||
| L2F checksum | |||||||||||||||||||||||||||||||
Version: Indica la versión de L2F con la que fue creado el paquete. Debe contener el valor 001.
Protocol: Indica el protocolo que transporta el paquete.
Valor |
Mensaje |
Descripción |
|---|---|---|
| 0x00 | L2F_ILLEGAL | Ilegal |
| 0x01 | L2F_PROTO | Paquete de administración |
| 0x02 | L2F_PPP | PPP dentro de L2F |
| 0x03 | L2F_SLIP | SLIP dentro de L2F |
Sequence: Contendrá un valor si el bit 3 del encabezado es seteado en 1. El valor se incrementará automáticamente empezando desde 0.
Multiplex ID: Identifica una conexión particular en el túnel. Cada conexión tiene un MID único.
Client ID: Cliente a quien deben enviarse los paquetes.
Length: Longitud del paquete L2F.
Offset: Esta presente solo si el bit 1 esta seteado en 1. Especifica el bit a partir del cual comienza el payload.
Key: Si el bit K esta seteado en 1 esta presente este campo el cual contendrá el valor que envíe el extremo del túnel. Esto se utiliza para evitar el Spoofing.
L2F cheksum: Campo opcional calculado para la detección de posibles errores.
Mensajes de L2F
Valor Hexadecimal |
Mensaje |
Descripción |
|---|---|---|
| 0x00 | Invalid | Mensaje invalido |
| 0x01 | L2F_CONF | Mensaje utilizado para el establecimiento de la conexión entre el NAS y el destino. |
| 0x02 | L2F_CONF_NAME | Mensaje que indica el nombre del transmisor del mensaje |
| 0x03 | L2F_CONF_CHAL | Mensaje que indica el número aleatorio de recuse. |
| 0x04 | L2F_CONF_CLID | Mensaje que indica CLID asignado para uso del par. |
| 0x02 | L2F_OPEN | Mensaje de configuración aceptada. |
| 0x01 | L2F_OPEN_NAME | Nombre recibido del cliente. |
| 0x02 | L2F_OPEN_CHAL | Mensaje que indica la recepción del recuse del cliente. |
| 0x03 | L2F_OPEN_RESP | Mensaje de respuesta del recuse del cliente |
| 0x04 | L2F_ACK_LCP1 LCP CONFACK | Mensaje que indica la aceptación del cliente |
| 0x05 | L2F_ACK_LCP2 LCP CONFACK | Mensaje de envío para el cliente |
| 0x06 | L2F_OPEN_TYPE | Mensaje que indica el tipo de autenticación usado. |
| 0x07 | L2F_OPEN_ID | Mensaje que indica la ID asociada con la autenticación |
| 0x03 | L2F_CLOSE | Mensaje que indica que se realiza un pedido de desconexión |
| 0x01 | L2F_CLOSE_WHY | Mensaje que indica la causa de la desconexión. |
| 0x02 | L2F_CLOSE_STR | Mensaje con la descripción ASCII de la desconexión. |
| 0x04 | L2F_ECHO | Mensaje utilizado para la verificación de presencia del par. |
| 0x05 | L2F_ECHO_RESP | Mensaje de respuesta al L2F_ECHO. |
Forma de creación y trabajo del túnel
El usuario remoto inicia la conexión PPP por medio de un ISP vía un acceso PSTN o ISDN. El servidor de Acceso a la Red (NAS) acepta la conexión y el enlace PPP es establecido. El ISP realiza los controles correspondientes de usuario por el protocolo CHAP o PAP.
Solo el campo nombre de usuario es utilizado para determinar si se requiere un servicio de VDU por medio de los protocolos CHAP o PAP. El ISP debe mantener una base de datos con los usuarios que utilicen el servicio.
En caso de requerir el servicio se designara un punto final del túnel. Si en cambio el servicio no debe ser dado se creará una conexión normal a Internet.
Si el túnel no existe en el extremo indicado, este debe ser inicializado, se le asigna un Multiplex ID (MID) y un indicador de conexión es enviado al destino de la nueva VDU. En el caso de que el túnel ya exista un MID no utilizado es asignado a la comunicación. El destino puede aceptar o rechazar este pedido, en este último caso se puede incluir en la respuesta la causa del rechazo.
Una vez creada la conexión se crea el túnel virtual para SLIP o PPP y se empieza a transmitir en ambas direcciones. Por medio del protocolo CHAP en forma periódica se verificará que el par en la conexión este activo.
En la figura 13 podemos observar como se crea el enlace y como se trata a los paquetes que circulan por el enlace.
Figura 13