Resumen

  • RFC 2406 no cifraba el paquete completo. En modo transporte dejaba fuera la cabecera IP original; en modo túnel protegía el datagrama interior, pero añadía una cabecera exterior visible. SPI y Sequence Number también se transmitían sin cifrar.
  • La confidencialidad, la autenticación y la protección contra repeticiones eran decisiones separadas. El contador obligatorio solo se convertía en control antirrepetición cuando el receptor lo verificaba dentro de una SA autenticada.

Un analista puede leer Sequence Number = 417 en una captura y aun así no saber si el paquete fue examinado contra una ventana. Puede observar un SPI y no poseer la asociación que le daba sentido. Puede ver tráfico hacia dos pasarelas sin conocer los interlocutores internos. ESP entregaba piezas para la seguridad; no convertía cada pieza visible en prueba del resultado.

Esa arquitectura apareció en RFC 2406, publicada en noviembre de 1998. El Encapsulating Security Payload ofrecía una mezcla de confidencialidad, autenticación del origen, integridad sin conexión, protección contra repetición y confidencialidad limitada del flujo. La combinación dependía de las opciones de la Security Association y del lugar donde estaba el sistema.

El antecedente de 1995 era más ligero. RFC 1827 establecía un armazón cuyo único campo obligatorio e independiente del transform era el SPI. Los transforms añadían algoritmos y campos propios. RFC 2406 explicó que su crecimiento combinatorio había vuelto necesario reunir el formato y el procesamiento básicos. Así incorporó el número de secuencia, el relleno, Next Header y Authentication Data.

Reunirlos no los volvió una sola garantía. Podía existir confidencialidad sin autenticación ESP. Podía existir autenticación con cifrado NULL, es decir, sin confidencialidad. Al menos una de las dos debía elegirse. La protección contra repetición solo podía operar junto con autenticación y quedaba a criterio del receptor.

El formato empezaba fuera de ESP. Una cabecera IPv4 o IPv6 exterior tenía que dirigir el paquete y anunciar el protocolo 50. Después aparecían el SPI y el número de secuencia, ambos de 32 bits. Luego venían Payload Data, Padding, Pad Length, Next Header y el Authentication Data opcional.

Con algoritmos separados, el cifrado abarcaba Payload Data, relleno, longitud del relleno y Next Header. Quedaban fuera la cabecera IP exterior, SPI, Sequence Number y el ICV final. Un vector de inicialización explícito podía ocupar el principio de Payload Data; RFC 2406 advertía que normalmente no estaba cifrado en sí, aunque se lo llamara parte del ciphertext.

La integridad cubría otra superficie. Si se seleccionaba, el ICV incluía SPI, Sequence Number, Payload Data, Padding, Pad Length y Next Header. Excluía el propio Authentication Data. Como el cifrado se hacía primero, los campos de carga entraban en el cálculo en forma cifrada. La cabecera IP exterior seguía fuera.

El modo transporte mantenía la cabecera IP original. ESP se insertaba entre ella y el protocolo superior, de modo que las direcciones originales continuaban visibles. En IPv6, las extensiones situadas antes de ESP también quedaban fuera; las colocadas después podían entrar en el ámbito protegido. La posición expresaba una propiedad de seguridad, no un mero orden de análisis.

El modo túnel cifraba el datagrama IP original completo. Pero necesitaba una cabecera nueva para llegar entre los extremos del túnel. Quien observaba podía perder las direcciones finales y conservar las de las pasarelas. El secreto del contenido no borraba tamaño, ritmo, volumen ni la existencia de la relación exterior.

Por eso RFC 2406 calificó de limitada la confidencialidad del flujo. El efecto requería modo túnel y mejoraba en una pasarela capaz de agregar muchas comunicaciones. El relleno adicional podía reducir la precisión con que se infería la longitud de la carga, pagando ancho de banda. No ocultaba por sí mismo horarios, cantidad de paquetes ni extremos externos.

El número de secuencia mostraba con especial claridad la diferencia entre campo y control. El emisor debía incrementarlo incluso si el receptor había desactivado antirrepetición. Cuando la protección estaba activa, también debía estar activa la autenticación, porque un contador sin integridad podía manipularse.

El receptor podía hacer una comprobación preliminar para evitar trabajo sobre un número demasiado antiguo. Sin embargo, no avanzaba la ventana hasta validar el ICV. El recibo operativo unía tres hechos: se encontró la SA correcta, el contador quedó autenticado y la ventana local lo aceptó. Una captura mostraba el número, no necesariamente los otros dos.

El orden de procesamiento mantenía separada la política. Antes de aplicar ESP, el sistema debía decidir que el paquete pertenecía a una SA que lo exigía; RFC 2401 describía esa selección. Después venían encapsulado, relleno, cifrado y autenticación opcional. La fragmentación ocurría al final. En recepción, el reensamblado precedía a ESP, y un fragmento que llegara todavía como tal debía descartarse.

La búsqueda de entrada combinaba dirección de destino, protocolo ESP y SPI para hallar una SA unidireccional. La asociación determinaba algoritmos, claves y controles. Sin SA válida, había descarte. Con autenticación seleccionada, el receptor calculaba el ICV antes de liberar datos descifrados. Superar ese paso no sustituía las reglas de entrada ni la decisión de la aplicación.

RFC 2406 también reconocía fallos que podían aparecer más tarde. Con una SA equivocada o corrupción sin autenticación, el resultado descifrado no siempre sería detectado por IPsec; otros protocolos tendrían que rechazarlo. Si descifrado y verificación se ejecutaban en paralelo, la verificación debía terminar antes de entregar el resultado.

Los eventos llamados auditables tampoco garantizaban un registro. Un sistema que ya ofreciera auditoría debía integrar ESP y permitir su activación, pero no todos los sistemas tenían que implementarla. La ausencia de SA, un fragmento inesperado, el desbordamiento de secuencia o un ICV inválido podían generar evidencia; conservarla seguía siendo una decisión local.

RFC 4303 sustituyó a RFC 2406 en 2005. Mantuvo la separación básica entre campos claros, región cifrada, integridad, modos y decisión del receptor, e incorporó secuencias extendidas, algoritmos combinados y relleno TFC explícito. La edición de 1998 es una etapa histórica, no una recomendación criptográfica actual.

La lectura de Lu Heng añade una pregunta de responsabilidad: ¿quién convirtió una capacidad del formato en una decisión ejecutada? El emisor puso el contador; el receptor eligió la ventana; la política eligió la asociación; el operador decidió qué registrar. Decir «ESP protegido» sin nombrar esos actos deja que la etiqueta reclame resultados que no observó.

Fuentes