Resumen

  • L2F abre primero un túnel con MID=0 y después negocia por separado cada conexión cliente con un MID no nulo.
  • CLID, MID y Key seleccionan y protegen contextos de protocolo; por sí solos no prueban identidad humana, autorización vigente ni sesión de aplicación.
  • RFC 2341 deja la fiabilidad del tráfico de datos al protocolo transportado, de modo que un control confirmado no es recibo de entrega para cada trama.

La llamada y el punto de terminación no son el mismo hecho

En la arquitectura de marcación virtual de RFC 2341, el usuario llama por PSTN o ISDN a un Network Access Server del proveedor de Internet. El NAS recibe el acceso físico, pero una Home Gateway remota termina la sesión PPP o SLIP. L2F encapsula las tramas de enlace que deben cruzar entre ambos equipos.

La arquitectura distribuye la responsabilidad. El NAS necesita interpretar apenas lo suficiente para descubrir una identidad aparente y decidir qué Home Gateway corresponde. La gateway conserva la decisión de aceptar o rechazar la conexión y puede realizar autenticación adicional. La red de transporte mueve las tramas. PPP configura el enlace y sus protocolos de red. La aplicación todavía debe abrir su propia sesión y producir una respuesta útil.

Por eso, el primer intercambio L2F_CONF/L2F_OPEN no termina el trabajo. Ese intercambio usa MID=0, negocia nombres, challenges y CLID asignados, y deja el túnel disponible para establecer clientes. «Disponible» es la palabra operacional: crea capacidad, no evidencia de que una persona ya esté autorizada.

Cada cliente emplea luego un MID distinto de cero. El NAS envía otro L2F_OPEN, con el tipo de autenticación y, cuando corresponda, datos de CHAP, PAP o LCP. Solo la respuesta OPEN de la Home Gateway registra la aceptación de esa conexión cliente. Después comienza el reenvío de tramas PPP o SLIP. Un túnel puede estar abierto y no contener ningún cliente aceptado; además, el resultado de un MID no se hereda por los demás.

CLID y MID contestan «dónde», no «quién»

CLID permite separar túneles entremezclados cuando el medio inferior no los distingue de forma fiable. MID separa clientes dentro de un túnel. El valor cero pertenece al estado del túnel; los valores no nulos pertenecen al estado cliente. Si un MID cerrado vuelve a utilizarse, debe empezar como una conexión nueva.

Esas reglas evitan confundir tablas de estado. No convierten el identificador en credencial personal. Saber qué contexto procesó un paquete no demuestra quién controlaba el terminal, qué derecho tenía esa persona en ese momento, ni qué identidad reconoció una aplicación posterior.

El propio RFC llama «apparent identity» a lo que el ISP intenta obtener. La Home Gateway decide después y aún puede existir una tercera fase de autenticación PPP o SLIP fuera del alcance de L2F. RFC 1994, para CHAP, define su challenge-response como un límite separado. Recoger un nombre, enviarlo, validar un secreto, autorizar un protocolo y aceptar una operación de negocio son eventos relacionados, pero no equivalentes.

La asimetría entre control y datos

L2F exige retransmitir los mensajes de control. Para el tráfico de datos, la especificación dice otra cosa: no ofrece control de flujo ni entrega fiable y deja los reintentos al protocolo encapsulado. El campo de secuencia normalmente ni siquiera se usa en los paquetes de datos ordinarios.

Así, el éxito de un OPEN, un ECHO o una comprobación de Key muestra que ocurrió una interacción de control. No informa del destino de cada trama. Dos contadores pueden discrepar aunque el túnel permanezca sano, y un contador ascendente demuestra una observación local, no una entrega de extremo a extremo.

En el caso de PPP, L2F transporta la trama después de retirar el framing físico, la transparencia y el FCS. ECHO de PPP, negociación NCP y TERMREQ pasan como tramas HDLC-like que L2F no interpreta como resultados de aplicación. De hecho, L2F no detecta directamente un TERMREQ; el endpoint PPP debe provocar la transición de cierre correspondiente.

PPP añade sus propios estados: establecimiento y configuración por LCP, autenticación opcional y configuración de protocolos de red por NCP. Incluso entonces, una aplicación debe autenticar, abrir una sesión, procesar una solicitud y devolver un resultado. La palabra «abierto» en una capa no adelanta las conclusiones de las siguientes.

Una protección contra spoofing no es seguridad integral

Durante la creación del túnel, NAS y Home Gateway usan un secreto compartido y un challenge-response. Los paquetes posteriores pueden incluir una Key de 32 bits derivada de la respuesta; un CLID desconocido, una Key incorrecta o un paquete inválido deben descartarse. La protección se refiere al contexto configurado entre esos dos equipos.

No demuestra confidencialidad de la carga, autorización del usuario final, identidad de la aplicación ni resultado de negocio. Años después, RFC 3193 separó para L2TP la autenticación del túnel, la integridad por paquete, la protección contra repetición, la confidencialidad y la seguridad de extremo a extremo. No corresponde proyectar esas propiedades hacia atrás. Sí corresponde conservar la distinción entre reconocer al par del túnel y completar con seguridad una acción del usuario.

Leer un RFC histórico sin convertirlo en mito

RFC 2341 figura como Historic. Su aviso declara que no especifica un estándar de Internet, y el Datatracker lo ubica en el flujo Legacy, sin respaldo del IETF ni posición formal en el proceso de estándares. El documento prueba qué protocolo se describió; no prueba volumen de despliegue, interoperabilidad real, uso presente ni éxito comercial.

Su mejor legado es una disciplina de evidencia. Deben existir recibos separados para la llamada, LCP, elección de gateway, túnel por CLID, cliente por MID, autenticación posterior, salida y entrada de tramas, NCP, sesión de aplicación y resultado visible. Los extremos necesitan contadores propios y cierres propios. Solo entonces «conectado» deja de ser una etiqueta y se convierte en una afirmación verificable.

Fuentes