AH o ESP: la decisión depende de qué debe proteger el paquete

Dos propuestas de IPsec pueden nombrar el mismo algoritmo de integridad basado en SHA y aun así pedir protocolos de protección distintos; AH y ESP no son dos formas de escribir un mismo ajuste de autenticación. Lea primero el protocolo, luego sus algoritmos, luego su modo, y la mayor parte de la ambigüedad desaparece. AH autentica el paquete, incluidos los campos de la cabecera IP que permanecen inalterados en el trayecto, mientras que ESP autentica y cifra lo que encapsula y deja la cabecera exterior tranquila. Esa diferencia decide más despliegues que cualquier nombre de hash.

Qué cubre AH que ESP no

AH aporta integridad, autenticación del origen de los datos y el servicio anti-repetición que define, y ninguna confidencialidad. Su cobertura incluye los datos de la capa superior y los campos de la cabecera IP que sus reglas tratan como inmutables, justo la parte que ESP en modo transporte deja fuera. Cuando un requisito dice que debe autenticarse la propia cabecera IP, AH es el protocolo que responde.

Esa cobertura es también la razón de que AH sea frágil sobre el terreno. Los campos mutables como el TTL, la suma de comprobación de la cabecera y algunas opciones no pueden autenticarse porque los enrutadores pueden reescribirlos, así que el protocolo los pone a cero antes de calcular la comprobación. Por tanto, cualquier cosa que reescriba direcciones rompe el cálculo, no solo la política.

NAT convierte la elección en una restricción

La traducción de direcciones reescribe el origen o el destino en la cabecera IP que AH acaba de autenticar, así que la comprobación de integridad falla en el extremo lejano, y falla como error de protocolo y no como un mensaje que pueda leerse. ESP no autentica la cabecera exterior, y por eso ESP con travesía de NAT funciona y AH detrás de NAT no. Un túnel cuyos dos extremos están detrás de enrutadores corrientes es justo donde esto aparece primero. Por eso la primera pregunta no es qué protocolo es más fuerte, sino si hay un traductor entre los extremos.

Si lo hay, AH queda fuera y la conversación pasa a ESP y a sus opciones de algoritmo. Es una restricción y no una preferencia, y por eso va al principio de la decisión y no al final.

El modo multiplica la pregunta

ESP en modo transporte protege la carga útil de la capa superior y deja la cabecera IP en paz; en modo túnel encapsula todo el paquete interior, incluida la cabecera IP interior, y lo protege. AH tiene los mismos dos modos, así que AH o ESP son en realidad cuatro combinaciones antes de elegir cualquier algoritmo.

Los algoritmos ESP de modo combinado resuelven luego la integridad sin un segundo protocolo. AES-GCM y ChaCha20-Poly1305 autentican y cifran en una sola construcción, así que añadir AH encima no compra nada pero cuesta otra cabecera y otra negociación. La arquitectura permite AH y ESP juntos, y la pregunta práctica es si su puerta de enlace y su versión admiten la combinación y si alguien podrá mantenerla después.

El sustituto honesto para solo AH

La variante ESP de solo integridad conserva el algoritmo y suelta la pretensión de cifrado en lugar de falsificarla, y sobrevive a NAT. Si un diseño heredado usaba AH porque necesitaba autenticación sin confidencialidad, esa variante es la traducción directa, no un túnel cifrado con una nota adjunta.

Ver ESP en una propuesta tampoco es prueba de cifrado. Lea el algoritmo de cifrado: una entrada NULL significa solo integridad, y una entrada de modo combinado significa ambas.

Decida en tres preguntas

Pregunte si se requiere confidencialidad, si hay un traductor en el camino y qué campos de la cabecera deben autenticarse. Esas tres respuestas apuntan a un protocolo y un modo, y escribirlas lleva menos tiempo que volver a leer los RFC más adelante.

Luego verifique lo aceptado y no lo propuesto. ip xfrm state muestra el protocolo, el modo y los algoritmos de la asociación instalada, y una discrepancia no instala nada, lo que es un fallo más limpio que un túnel que sube sin la protección que pretendía.

Mantenga los fallos de autenticación, la cobertura de selectores y los fallos de enrutamiento aparte de esta elección. Producen síntomas distintos, y culpar al protocolo de un problema de selector es una forma segura de pasar un día cambiando hashes sin motivo.