Resumen

  • RFC 2402 calculaba el ICV de AH sobre una vista preparada: conservaba campos inmutables, colocaba los mutables previsibles en su valor esperado de llegada y sustituía por cero el contenido mutable imprevisible.
  • Un ICV válido no demostraba que todos los bits vistos en la red permanecieran iguales. La fragmentación iba después de AH y el reensamblado antes de la verificación; la comprobación contra repetición podía estar desactivada y la política o la aplicación decidían más tarde.

El valor de Time to Live cuenta una paradoja útil. Debe cambiar para que IP funcione, pero ese cambio impediría comparar literalmente el encabezado enviado con el recibido. RFC 2402 resolvió la paradoja sin fingir que el campo era estable: el TTL real seguía en el paquete, mientras su posición se llenaba con cero en la entrada del Integrity Check Value.

El IP Authentication Header de noviembre de 1998 ofrecía integridad sin conexión y autenticación del origen, con protección opcional contra repetición elegida por el receptor para cada asociación. No proporcionaba confidencialidad. Cubría los datos superiores y la mayor parte posible del encabezado IP, aunque el propio texto calificaba esa cobertura de parcial porque algunos campos cambiaban en tránsito.

AH incluía Next Header, longitud, bits reservados, SPI, Sequence Number y Authentication Data. SPI, destino y protocolo AH seleccionaban la asociación unidireccional, de la que procedían algoritmo y clave. El número de secuencia se enviaba siempre y el emisor lo incrementaba incluso si el receptor no lo usaba para detectar repeticiones.

La entrada del ICV tenía tres clases. Los campos inmutables y los datos de capas superiores entraban con sus valores. Los campos mutables cuyo estado final podía predecirse se ordenaban como aparecerían al llegar. El contenido mutable de forma imprevisible se reemplazaba por cero. Authentication Data también se ponía a cero mientras se calculaba el valor que después ocuparía ese espacio.

Poner a cero no significaba eliminar. Los octetos conservaban posición y alineación, de modo que la longitud del campo seguía dentro de la estructura autenticada aunque su contenido quedara fuera. La vista preparada compartía el esqueleto del paquete, no todos sus valores. “Canonicalización” es una explicación posterior; RFC 2402 hablaba de inmutable, mutable pero previsible y mutable.

IPv4 mostraba la clasificación. Version, IHL, Total Length, Identification, el valor de protocolo AH, Source Address y un Destination Address ordinario se incluían. Un destino bajo source routing era mutable pero previsible. TOS, Flags, Fragment Offset, TTL y Header Checksum se llenaban con cero. El RFC reconocía que routers reales cambiaban TOS, podían marcar DF, reducían TTL y actualizaban la suma.

Así, un ICV correcto podía acompañar a un TTL menor. No probaba inmovilidad de toda la imagen transmitida, sino coincidencia de la vista preparada bajo una asociación, una clave y un algoritmo. Los campos excluidos no desaparecían del paquete; desaparecía la pretensión de que AH certificara sus valores concretos.

IPv6 trasladaba el método a Class, Flow Label y Hop Limit, que se ponían a cero en el modelo de 1998. Un destino afectado por Routing Header podía predecirse. Las opciones Hop-by-Hop y Destination llevaban un bit de mutabilidad: Option Data mutable se trataba como octetos cero, mientras Option Type y longitud quedaban cubiertos. La extensión futura del protocolo dependía de que cada nueva opción declarase su tratamiento.

El padding separaba aún más cálculo y transmisión. El relleno explícito dentro de Authentication Data se enviaba y se autenticaba. Algunos algoritmos exigían además relleno implícito con ceros hasta un límite de bloque; participaba en el cálculo, pero nunca viajaba. La entrada autenticada podía contener octetos que no habían estado en la red.

La fragmentación definía otra frontera. En modo transporte, AH se aplicaba al datagrama completo y la fragmentación ocurría después. Los routers podían dividirlo, pero el receptor debía reensamblar antes de AH. Si el objeto entregado al proceso aún parecía un fragmento, se descartaba y auditaba. En modo túnel, el paquete exterior protegido podía contener como carga un paquete interior ya fragmentado: eran niveles distintos.

Al recibir, la implementación reconstruía la vista: elegía la asociación, guardaba el ICV recibido, ponía a cero Authentication Data y campos imprevisibles, añadía relleno implícito y comparaba el nuevo resultado. Con anti-replay activo podía filtrar primero el número candidato, pero solo actualizaba la ventana después de validar el ICV. Con anti-replay inactivo, el número presente no era evidencia de una decisión contra repetición.

RFC 2402 llamaba válido al datagrama en esa etapa de AH. RFC 2401 todavía exigía comprobar política de entrada antes de entregar o reenviar; la aplicación tenía su propia decisión. La cadena completa separaba asociación, vista del emisor, ICV, fragmentos, reensamblado, vista del receptor, comparación, replay opcional, política y resultado aplicativo.

La especificación es histórica. Sustituyó a RFC 1826 y fue sustituida por RFC 4302 y RFC 4305. HMAC-MD5 y HMAC-SHA-1 no son recomendaciones actuales. RFC 4302 mantuvo la cobertura parcial, pero revisó búsqueda de asociaciones, secuencias extendidas y gestión de algoritmos.

Las reflexiones posteriores de Lu Heng sobre código en ejecución y capas de realidad ofrecen una lente, no palabras del RFC. Una etiqueta de autenticación adquiere efecto solo mediante la vista exacta que dos sistemas construyen y comparan. No puede autorizar por sí sola los campos excluidos, los controles opcionales ni los resultados posteriores.

Fuentes