Resumen

  • RFC 3193 exigió ESP para proteger control y datos de L2TP, pero la asociación IPsec sólo servía si sus selectores seguían la dirección y los puertos que el túnel iba eligiendo durante el establecimiento.
  • La verificación por paquete heredaba la identidad de IKE, no la identidad que PPP hubiese autenticado; en una máquina con varios usuarios hacía falta una política local separada para aislar el tráfico.

La seguridad de un túnel no empezaba cuando aparecía el icono de conexión. Para RFC 3193 empezaba antes del primer mensaje que intentaba abrirlo.

El mensaje SCCRQ creaba la conexión de control L2TP. Si salía antes de que existiera una asociación IPsec capaz de protegerlo, la operación fundacional quedaba fuera del perímetro que pretendía crear. Por eso el filtro inicial debía estar instalado de antemano. El envío del SCCRQ podía activar IKE; si la SA no llegaba a establecerse, el paquete debía descartarse.

Esta exigencia temporal respondía a una diferencia entre protocolos. L2TP conocía su socket y podía escoger un puerto fuente dinámico. El respondedor podía contestar desde otro puerto. La especificación L2TP incluso permitía elegir otra dirección IP. IKE, en cambio, negociaba en Quick Mode un conjunto de tráfico expresado mediante direcciones, protocolo y puertos. No podía proteger con precisión un dato que la aplicación aún no había decidido.

RFC 3193 introdujo una cooperación explícita. Cuando L2TP conocía el puerto del iniciador, lo inyectaba en la base de filtros IPsec. IKE terminaba la negociación y asociaba un filtro concreto a la SA. Mientras se resolvía el establecimiento, algunas reglas aceptaban el posible puerto nuevo; cuando el túnel quedaba fijado, podían eliminarse las asociaciones y reglas residuales.

Cambiar de dirección no era una continuidad implícita. El respondedor debía enviar por la ruta original protegida un StopCCN con “Try Another” y la nueva dirección. El iniciador comprobaba el formato, instalaba nueva política, negociaba nuevas Phase 1 y Phase 2 y sólo entonces enviaba otro SCCRQ. La dirección nueva requería una relación criptográfica nueva, aunque el propósito operativo fuese el mismo.

El cambio de puerto tenía otro recorrido. Debía decidirse antes del SCCRP. L2TP añadía los filtros y el respondedor iniciaba una nueva Phase 2. La amplitud temporal necesaria para descubrir el puerto no se convertía en permiso perpetuo. El filtro final debía describir el socket que realmente había ganado la negociación.

De ahí que “usa UDP 1701” fuese una observación insuficiente. El 1701 podía ser sólo el lugar inicial de encuentro. La identidad del túnel residía también en las direcciones, puertos finalmente elegidos, asociación IPsec y estado L2TP. Un número de puerto no era una credencial.

La recepción de paquetes conservaba la misma disciplina. L2TP debía comprobar primero que IPsec había autenticado o descifrado el paquete. Así sabía que no había llegado en claro y que pertenecía a la SA esperada. Después debía comparar direcciones y puertos con el socket usado para crear aquel túnel. Un par criptográficamente confiable podía enviar un paquete al contexto L2TP equivocado; superar la primera prueba no eliminaba la segunda.

Tampoco había una única máquina de estados. La conexión L2TP, IKE Phase 1, las SA Phase 2 y los filtros vivían en almacenes distintos. Cuando terminaba el túnel, las SA creadas para él debían eliminarse y enviarse las notificaciones correspondientes. Cuando IKE recibía un borrado, debía avisar a L2TP. Sólo tras los reconocimientos pertinentes era seguro retirar el estado y los filtros asociados.

Un registro “VPN desconectada” no demuestra ese cierre compuesto. Puede haber desaparecido el túnel y sobrevivir una SA, o haberse borrado la SA mientras la aplicación conserva un túnel aparentemente activo. RFC 3193 coordinaba ambos mundos; no fingía que fuesen una sola fila transaccional.

La encapsulación también modificaba la realidad física del enlace. PPP solía trabajar con 1.500 bytes, pero L2TP e IPsec añadían cabeceras. El documento recomendaba calcular el MTU disponible después de esa sobrecarga y entregarlo a PPP antes de LCP. Si IPsec descubría después un PMTU menor, debía guardarlo en la SA y notificar a L2TP. Un hallazgo en la capa IP no cambiaba PPP hasta cruzar esa interfaz.

La compresión con estado mostraba otro peligro. Aunque L2TP fuese orientado a conexión, sobre IP no imponía orden de entrega. La pérdida de un paquete podía desincronizar toda una secuencia comprimida o cifrada con historia. El RFC prefería mecanismos sin estado. La forma lógica de túnel no convertía la red subyacente en un canal ordenado.

Sin embargo, la separación decisiva era la de identidad.

PPP podía autenticar a un usuario una vez, al establecer la sesión. Esa identidad no se volvía a comprobar con cada paquete. IKE autenticaba una identidad —con frecuencia la máquina— y derivaba claves con las que IPsec protegía cada paquete contra modificación y repetición. La prueba repetida era fuerte, pero repetía la afirmación de IKE.

En un equipo compartido, esto abría una brecha. Si PPP había identificado a Alicia pero IKE había certificado el portátil, ESP probaba que el paquete venía de quien poseía las claves del portátil. No probaba que Alicia fuese el proceso o usuario local que lo originó. Sin separación de tráfico, otro usuario del mismo equipo podía aprovechar el túnel abierto.

Autenticar al usuario dentro de IKE podía cerrar parte de la brecha, pero no sustituía la aplicación de política. El cliente tenía que garantizar que sólo el tráfico de ese usuario entraba en el túnel. La identidad declarada y el aislamiento efectivo seguían siendo hechos diferentes.

Los certificados trasladaban la pregunta al enrolamiento. Un LNS podía confiar en varias autoridades y aplicar prácticas distintas de revocación. Un certificado de máquina valía lo que valiese el proceso que impedía obtenerlo bajo una identidad falsa. Una tarjeta inteligente protegía mejor algunas claves de usuario, pero podía permitir mover una credencial que una organización quería ligar a hardware aprobado. El soporte criptográfico no definía por sí mismo la autoridad administrativa.

Las claves precompartidas de grupo eran más frágiles. En acceso remoto, la dirección del cliente solía ser dinámica. En Main Mode, el servidor podía necesitar escoger la clave antes de recibir la identidad. Compartir una clave entre todos resolvía la selección, pero destruía la individualidad: quien conociera el secreto podía demostrar pertenencia al grupo, no ser un par concreto. En el modelo descrito podía hacerse pasar por el LNS y atacar después contraseñas de métodos PPP heredados. El RFC desaconsejó usar una clave grupal para autenticar el LNS.

Aggressive Mode permitía escoger la clave usando una identidad temprana, pero exponía esa identidad. Los certificados escalaban mejor, pero exigían autoridades, enrolamiento y revocación. No existía una opción que eliminase todos los costes. La etiqueta “autenticado” ocultaba qué intercambio se había elegido.

El lugar donde comenzaba L2TP cambiaba además quién podía observar la protección. En el túnel obligatorio, el cliente entregaba PPP al LAC y quizá ni supiera que el tramo LAC–LNS iba por L2TP/IPsec. El LNS podía consultar las propiedades de la SA; el cliente no podía usarla como prueba de su enlace hasta el LAC. Había conocimiento asimétrico.

En el túnel voluntario, el cliente originaba L2TP y podía conocer la SA hasta el LNS. Cliente y LNS podían ajustar mejor el cifrado o la compresión PPP y evitar alguna duplicación. Pero el segmento posterior al LNS no entraba en esa prueba. El propio RFC declaró que no normalizaba seguridad de extremo a extremo.

Ésa fue su aportación más perdurable. No puso simplemente IPsec “debajo” de L2TP. Definió qué hechos debía entregar L2TP a la política de seguridad, qué resultado debía devolver IKE a la aplicación y qué identidades quedaban fuera. La interoperabilidad dependía de coordinar pruebas limitadas, no de elevar una de ellas a verdad total.