Resumen

  • El borrador de trabajo IPSECME fechado el 1 de octubre especifica que un mensaje IKE protegido recibido por una nueva conexión TCP, con otra IP de origen y/o puerto, solo actualiza el uso de esa conexión para la asociación IKE. No autoriza a cambiar la IP ni el puerto de las asociaciones ESP hijas.
  • La versión 08 también admite que, si se espera tráfico en ambos sentidos, la falta de paquetes ESP entrantes apunta a un posible problema de conectividad. La prueba ESP cifrada sigue siendo otra opción; el silencio no demuestra por sí mismo una caída.

Que el plano de control responda no significa que haya un túnel de datos utilizable. IKEv2 negocia las asociaciones de seguridad. ESP lleva los paquetes protegidos. La propuesta para usar TCP de forma fiable en IKE sin obligar a ESP a circular por TCP es atractiva cuando los intercambios de claves son voluminosos, pero crea dos rutas que las redes intermedias pueden tratar de manera diferente. Por eso un intercambio IKE satisfactorio y la llegada efectiva de ESP son hechos que necesitan pruebas distintas.

La comparación con la versión 07 muestra dónde está la noticia. Antes, el apartado sobre NAT hablaba de un mensaje IKE protegido procedente de otra dirección o puerto. Ahora delimita el caso de una conexión TCP nueva con IP de origen y/o puerto diferentes. El equipo que recibe el mensaje utiliza esa conexión únicamente para su asociación IKE y no debe alterar los extremos de origen guardados para ninguna asociación ESP creada bajo ella. Un paquete ESP cuya integridad se verifica desde otra dirección se rige por una actualización separada de ESP. La conexión de control no puede convertirse en una instrucción implícita para redirigir datos.

La separación de transportes no nació en esta revisión. El documento ya contemplaba la notificación SEPARATE_TRANSPORTS: IKE puede empezar por UDP 4500 y pasar a TCP para los intercambios siguientes si el par confirma el soporte. También puede empezar directamente por TCP cuando el primer intercambio es grande. En ese modo, ESP va por IP directo o encapsulado en UDP cuando sea posible. Si un par al que se contactó primero por TCP no confirma la notificación, tanto IKE como ESP deben usar TCP conforme a RFC 9329. Atribuir toda esta arquitectura a la versión 08 exageraría el cambio real.

Otra modificación se refiere a cómo se sospecha que la ruta de datos falla. Si el tráfico normal es bidireccional, la ausencia de ESP de entrada es un indicio de posible problema. El borrador conserva la posibilidad de emplear un ping ESP cifrado. Pero una aplicación inactiva también puede producir silencio, igual que una política que no espera respuestas o una observación colocada en el punto equivocado. La frase no permite culpar automáticamente a un cortafuegos o a NAT.

El texto ya exigía tratar por separado el estado NAT de TCP e IP/UDP. La conexión TCP de IKE no mantiene abierta la asignación UDP usada por ESP; se necesitan los keepalives de su propio camino. Cuando IKE comienza por TCP, completar la negociación tampoco verifica que ESP llegue al destino. Tras establecer la asociación hija, el iniciador debería confirmar el alcance de ESP salvo que disponga de otra prueba. Si no puede confirmarlo, debe borrar la asociación IKE y establecerla de nuevo por TCP sin proponer la ruta ESP separada. El retorno a un modo común depende de esa comprobación, no de una etiqueta global «conectado».

Datatracker muestra un Internet-Draft activo del grupo IPSECME enviado a publicación y con publicación solicitada. No es una RFC publicada. El valor de la nueva notificación sigue pendiente de asignación en el borrador y no hay evidencia aquí de un despliegue comercial ni de un incidente. La conclusión útil es más limitada y más importante: cada plano conserva su propio estado y su propia carga de prueba.

Fuentes