¿Qué incluye una propuesta IPsec? Campos de IKE y ESP

IKE arranca, ambos pares anuncian AES y el túnel sigue fallando con NO_PROPOSAL_CHOSEN. El registro nombra la propuesta pero no el campo que no coincidió. Una propuesta es una oferta completa, y un solo campo incompatible invalida toda la combinación en lugar de solo esa línea. Leerla como un saco de elecciones independientes de algoritmos es la razón habitual por la que el desajuste permanece invisible.

Dos negociaciones con listas de propuestas separadas

IKEv2 construye dos asociaciones de seguridad. La primera es la IKE SA, que protege el propio intercambio de control, y la segunda es la CHILD SA, que transporta su tráfico por ESP. Cada una tiene su propia lista de propuestas, y un par puede aceptar una y rechazar la otra.

Esa división explica una confusión habitual: una IKE SA que funciona solo demuestra que los algoritmos del canal de control coincidieron. Si la propuesta CHILD falla, el túnel no transporta ni un paquete aunque la primera fase se haya completado y los registros se vean sanos en la parte superior.

El orden dentro de cada lista también importa. El respondedor elige entre las ofertas ordenadas del iniciador, así que mover una entrada ampliamente compatible por encima de una estrecha cambia qué conjunto se instala sin cambiar ningún nombre de algoritmo. Fije ese orden en la configuración en lugar de confiar en los valores predeterminados. Un orden estable también hace que la comparación de registros entre sitios tenga sentido.

Qué campos pertenecen a qué propuesta

El conjunto de campos es pequeño, pero no es idéntico en las dos negociaciones. Lea la tabla fila por fila, porque un campo de una columna puede faltar en la otra. La sintaxis varía según la implementación; la documentación de propuestas de strongSwan es una referencia concreta.

El campo de cifrado nombra el cifrador y, en la mayoría de las sintaxis, su longitud de clave. El campo de integridad nombra el hash usado para autenticar el texto cifrado, y el PRF nombra la función que deriva material de clave para la IKE SA. El grupo DH establece material secreto compartido nuevo, por eso aparece en ambos lados pero con fines distintos.

Los números de secuencia extendidos pertenecen solo a la ruta de datos. Amplían el espacio de secuencia y se negocian como parte de la propuesta CHILD, así que un desajuste allí rechaza una oferta CHILD mientras deja intacta la IKE SA.

Cómo se selecciona una oferta completa

Cada propuesta es un conjunto, y el respondedor busca un conjunto donde cada campo obligatorio sea aceptable. Dos listas pueden contener ambas AES y SHA-256 y aun así no tener ninguna entrada compatible, porque la longitud de clave, el PRF o el grupo DH difieren. La comparación se hace por propuesta, no por algoritmo.

Cuando nada coincide, el respondedor envía NO_PROPOSAL_CHOSEN con el tipo de SA que falló. Lea a qué lista de propuestas se refiere el aviso antes de editar la configuración; cambiar los algoritmos de ESP cuando se rechazó la propuesta IKE desperdicia un ciclo de depuración.

Vale la pena conocer el comportamiento de selección cuando ajusta un perfil. Algunas implementaciones prefieren el orden del iniciador, otras reordenan según la política local, así que un conjunto que funciona entre dos proveedores puede desaparecer cuando invierte qué lado inicia la conexión.

AEAD elimina un campo en lugar de añadir uno

AES-GCM y ChaCha20-Poly1305 autentican y cifran en una sola operación. Cuando se selecciona cualquiera de ellos para ESP, el algoritmo de integridad no se negocia por separado, porque la construcción AEAD ya lo cubre. Por tanto, una propuesta que combina AES-GCM con SHA-256 es redundante en el mejor caso y rechazada en el peor.

El PRF sigue siendo independiente en el lado de IKE, ya que deriva claves para el canal de control en lugar de proteger las cargas útiles. Por eso una propuesta IKE puede combinar legítimamente un cifrador AEAD con un PRF y un grupo DH, mientras que la propuesta ESP correspondiente solo enumera el cifrador AEAD y el grupo PFS opcional.

La longitud de clave forma parte del token de cifrado, así que AES-128-GCM y AES-256-GCM son ofertas distintas. Un perfil copiado de una guía que asumía claves de 256-bit no coincidirá con un extremo configurado para 128-bit, aunque ambas líneas digan AES-GCM. Dos pares pueden acordar la familia de cifradores y aun así rechazarse por el número que sigue al guion.

Lea la SA instalada, no la configuración

La lista de propuestas configurada es una oferta; la SA instalada es el resultado. En strongSwan y un núcleo Linux, ambas vistas están disponibles:

sudo swanctl --list-sas
sudo ip xfrm state
sudo ip xfrm policy

swanctl --list-sas imprime los algoritmos negociados por SA, incluido si el CHILD usa AEAD. ip xfrm state muestra lo que el núcleo instaló realmente, y es el lugar para confirmar que una renovación de claves no recayó en un conjunto distinto del que documentó.

Guarde esa salida junto a la configuración después de una corrección. Cuando una actualización del cliente cambia sus valores predeterminados, el conjunto registrado le da una línea base para comparar, y la comparación señala el campo que se movió en lugar de reiniciar la investigación desde el principio.