Resumen

  • RFC 3948 hizo que IKE y ESP encapsulado en UDP usaran la misma asociación NAT; reservó cuatro octetos cero para IKE porque un SPI ESP válido no podía ser cero.
  • El marcador solo resolvía la primera bifurcación. La asociación de seguridad, la protección contra repetición, la criptografía, la política de direcciones internas y el resultado de la aplicación seguían requiriendo comprobaciones propias.

Tres longitudes, una ruta exterior

El atractivo de UDP 4500 estaba en la economía. Si IKE y ESP usaban asociaciones NAT separadas, cada una podía caducar de manera distinta y exigir reglas distintas en el cortafuegos. RFC 3948 eligió compartir: una sola asociación escalaba mejor, reducía mantenimiento duplicado y simplificaba configuración e implementación. RFC 3947 definió la negociación que llevaba el tráfico IKE de travesía NAT a ese puerto.

La captura exterior, sin embargo, ya no podía clasificar por puerto. Había que distinguir control y datos dentro de la carga UDP. El mecanismo fue más pequeño que un encabezado nuevo: reservar un valor que ESP no podía usar.

El cero imposible se convirtió en señal

El primer campo de ESP es el índice de parámetros de seguridad, o SPI. Sirve para buscar en el receptor el estado con el que debe procesarse el paquete. En RFC 2406, el valor cero queda reservado y no se transmite como SPI ESP normal. RFC 3948 exige que el SPI del paquete encapsulado no sea cero.

Los mensajes IKE enviados por UDP 4500 reciben cuatro octetos cero inmediatamente antes de su encabezado. El texto los llama marcador no ESP. Ocupan la misma posición en la que un paquete ESP llevaría el SPI. Así, el primer entero de 32 bits ofrece una decisión rápida: cero significa intentar IKE; cualquier valor no cero puede entrar en el camino ESP.

La palabra “puede” importa. Un valor no cero no demuestra que exista esa asociación ni que el paquete supere su procesamiento. El receptor todavía debe encontrar un SA apropiado, comprobar la secuencia y la ventana contra repetición, verificar la protección criptográfica y aplicar selectores de tráfico. Un SPI desconocido o una integridad fallida siguen siendo rechazo.

Los cuatro ceros tampoco autentican IKE. No son un secreto ni un MAC, no nombran al interlocutor y no autorizan un intercambio. Solo evitan entregar el mismo datagrama a dos intérpretes. La autenticación, cuando corresponde, sucede dentro del protocolo IKE después de que el marcador haya cumplido su tarea modesta.

El byte que no decía “estoy vivo”

RFC 3948 añadió un tercer formato: una carga exacta de un octeto 0xFF, con los mismos puertos que ESP encapsulado. Es un keepalive NAT. Su finalidad exclusiva es provocar tráfico suficiente para que el traductor conserve la asociación, y el receptor debería ignorarlo.

La norma prohíbe usar su recepción para detectar que la conexión está viva. Un traductor puede renovar su temporizador aunque el interlocutor ya no tenga un IKE SA útil, aunque el ESP SA haya desaparecido o aunque la aplicación no reciba nada. El paquete prueba, como máximo y en ese momento, que un datagrama de mantenimiento llegó a una interfaz capaz de recibirlo.

Los intervalos por defecto de la época—veinte segundos sin otro envío antes del mantenimiento necesario y hasta cinco minutos después de que hubiera existido un SA—eran parámetros locales. No establecían una disponibilidad contractual. NAT, IKE, ESP y la aplicación mantenían relojes diferentes.

La envoltura no resolvía la política interior

Encapsular no sustituía ESP. El emisor aplicaba ESP ordinario y añadía UDP; el receptor retiraba UDP y realizaba la decapsulación ESP ordinaria. Después venían decisiones que el primer palabra no podía tomar.

En modo túnel, la implementación debía validar la dirección fuente interior contra el espacio autorizado o la dirección asignada al par, o bien traducirla para la red local. En modo transporte, el cambio de direcciones podía dejar incorrectas las sumas de comprobación TCP o UDP, y RFC 3948 ofrecía rutas limitadas para ajustarlas o recalcularlas. Clasificar un paquete como ESP no autorizaba su dirección interna.

La sección de seguridad muestra por qué. Dos portátiles detrás de NAT diferentes podían tener la misma dirección privada y producir destinos interiores superpuestos en una pasarela. Varios clientes detrás de una única dirección pública podían negociar descripciones de tráfico que también se solapaban. Una búsqueda simple podía no saber qué SA usar para el tráfico de salida. La implementación tenía que asignar direcciones locales únicas, traducir, rechazar el conflicto o resolverlo explícitamente.

La RFC 3715 había descrito estas exigencias de compatibilidad. RFC 3948 las enfrentó con un formato desplegable; no declaró que el puerto exterior se hubiera convertido en identidad única de todo lo que había detrás.

Lo que permaneció en IKEv2

El registro del RFC Editor sitúa RFC 3948 en enero de 2005 y en el Standards Track. El erratum aceptado cambia una referencia de caso en la introducción, no la regla de clasificación.

RFC 7296 conserva la técnica en IKEv2: IKE sobre 4500 empieza con cuatro ceros; ESP empieza directamente con un SPI que no puede ser cero. También permite que un iniciador use 4500 desde el principio, incluso sin haber detectado NAT. Ver el puerto no prueba por sí solo que haya traducción.

La continuidad del diseño no amplió su autoridad. El puerto coordinaba llegada. Los primeros cuatro octetos elegían un candidato de procesamiento. El estado instalado y la criptografía decidían aceptación. La política interior decidía tránsito. La aplicación decidía si el intercambio tuvo valor. RFC 3948 tuvo éxito conceptual al no fingir que una sola señal podía contestar todas esas preguntas.

Fuentes