Resumen

  • draft-ietf-ipsecme-ikev2-reliable-transport-07 desacopla IKE sobre TCP de ESP directo o encapsulado en UDP; una Child SA válida acredita negociación y protección, no tránsito efectivo de los datos.
  • El operador necesita recibos distintos para capacidad acordada, mapeo NAT, respuesta ESP cifrada, tráfico de aplicación y repliegue; la autenticidad puede seguir intacta mientras falla la disponibilidad.

Hay una avería que parece un éxito durante demasiado tiempo. El intercambio IKE termina, las identidades están autenticadas, las claves existen y el sistema instala una Child SA. El panel marca verde. Sin embargo, ninguna aplicación logra cruzar el túnel.

La causa puede estar fuera del diálogo que acaba de funcionar. TCP pasó por el cortafuegos, pero ESP nativo no. El NAT recuerda la sesión TCP, pero nunca abrió un mapeo UDP 4500 para ESP. La organización ha demostrado que dos pares pudieron negociar; aún no ha demostrado que el servicio pueda circular.

Ese es el límite central de Separate Transports for IKE and ESP. La revisión 07 es un Internet-Draft activo del grupo IPsecME, en el IETF stream, con intención Standards Track y estado congelado “WG Consensus: Waiting for Write-Up”. No es un RFC ni evidencia de adopción operativa. Es una propuesta que vuelve explícita una separación que la práctica suele ocultar.

IKEv2 nació sobre UDP. RFC 9329 permite encapsular IKE y ESP en TCP cuando UDP está bloqueado. A la vez, los intercambios post-cuánticos aumentan el volumen del material de clave: TCP resulta útil para llevar mensajes grandes, pero no necesariamente conviene someter todo el flujo ESP a sus efectos de rendimiento. La revisión 07 propone conservar TCP para el control y buscar otro camino para ESP.

La señal SEPARATE_TRANSPORTS comunica esa capacidad. Si ambos extremos la aceptan, los intercambios IKE posteriores continúan por TCP y ESP sale directamente sobre IP o encapsulado en UDP cuando hay NAT. Si el respondedor no devuelve la señal, IKE y ESP permanecen juntos sobre TCP conforme a RFC 9329.

Aceptar la señal no prueba el camino. Solo autoriza el intento.

El modo de inicio cambia la evidencia disponible. Si IKE_SA_INIT utilizó UDP, la respuesta demuestra al menos que UDP fue alcanzable en ese momento. Si empezó directamente por TCP, no existe prueba implícita para ESP. Por eso, después de crear la Child SA, el iniciador debería verificar ESP salvo que ya observe tráfico entrante protegido.

La revisión también evita un diagnóstico cómodo pero incorrecto. No confirmar ESP no debilita por sí solo la autenticación IKEv2 ni la protección criptográfica de la Child SA. La asociación puede ser auténtica y estar bien construida, pero no entregar un solo paquete útil. La seguridad de identidad y la disponibilidad de transporte son juicios diferentes.

El NAT tiene memoria por protocolo. Mantener viva la conexión TCP de IKE no conserva el mapeo UDP que ESP necesita. Los extremos deben enviar keepalives para ESP de manera independiente. Un paquete ESP válido recibido desde otro puerto puede actualizar las SA ESP relacionadas, sin cambiar el destino usado por IKE. Un mensaje IKE protegido puede actualizar el control, sin declarar válida la dirección de ESP.

No hay una única “dirección del túnel”. Hay estados que comparten relación criptográfica pero no comparten necesariamente camino.

Para IKE iniciado en TCP, la revisión 07 define una comprobación práctica. Con NAT detectado, se prueba ESP encapsulado en UDP 4500. Sin NAT, se intenta primero ESP directo; si no contesta tras una espera breve, se prueba también UDP porque algunos equipos intermedios solo admiten paquetes con cabecera UDP o TCP. Gana el primer transporte que responde, una estrategia comparable a Happy Eyeballs.

El Echo ESP cifrado es una opción para obtener esa respuesta. Su alcance debe quedar escrito con precisión. Demuestra que una solicitud y una respuesta protegidas recorrieron una ruta bajo una SA. No garantiza todos los tamaños, todos los selectores de tráfico, la salud del servicio remoto ni el resultado que esperaba el usuario. Después del sondeo todavía hace falta una prueba de aplicación.

Cuando no puede confirmarse ESP, el iniciador debe borrar la IKE SA actual y restablecerla por TCP sin proponer transporte separado. El sistema vuelve así al modelo acoplado de RFC 9329. La política local decide si acepta ESP por TCP o si cancela el establecimiento. La primera opción prioriza continuidad y puede degradar rendimiento; la segunda protege un requisito operativo y asume indisponibilidad.

Esa elección pertenece al propietario del servicio, no a un valor predeterminado invisible. Un acceso administrativo de emergencia puede tolerar el repliegue. Una transferencia intensiva puede no tolerarlo. Un entorno auditado puede exigir que la ruta haya producido un recibo cifrado y una transacción representativa antes de admitir carga.

MOBIKE obliga a renovar el juicio. Cuando cambia la dirección, cambian también los cortafuegos y los mapeos. La IKE SA puede seguir por TCP, pero el camino ESP anterior no se traslada mágicamente. El nuevo entorno requiere su propia comprobación. La reanudación de sesión sigue el mismo principio: el ticket no debe guardar la elección de transportes, porque el cliente pudo despertar en otra red.

El diseño coincide con la idea de Heng Lu de especificación inicial mínima y decisión futura localizada. Los pares comparten una capacidad pequeña e interoperable. El extremo que observa las condiciones actuales decide después entre ESP directo, UDP, repliegue TCP o aborto. La etiqueta simbólica “SA establecida” no sustituye al hecho operativo de paquetes protegidos en movimiento. Running code significa tránsito observado, no solo estado configurado.

Un registro útil debería conservar: transporte de cada fase IKE, oferta y aceptación de SEPARATE_TRANSPORTS, detección NAT, método ESP ensayado, mapeo y keepalive propios, primera respuesta protegida, tráfico real posterior, autoridad que aceptó el repliegue y revalidación tras movilidad o reanudación. Reducirlo todo a “VPN activa” borra precisamente la frontera que la revisión intenta proteger.

Fuentes