IKE e IPsec, fases y parámetros aceptables

IPsec negocia el túnel en dos pasos. Primero las pasarelas se identifican entre sí y acuerdan cómo protegerán su propia conversación de control; después, dentro de ese canal, acuerdan cómo protegerán el tráfico de los usuarios.

En IKEv1 esos pasos se llaman fase 1 y fase 2. En IKEv2 la idea es la misma, pero los nombres cambian: el primer paso crea la IKE SA (el canal de control) y el segundo crea la Child SA (la asociación que lleva el tráfico). Muchos equipos siguen hablando de «fases» aunque usen IKEv2; lo que importa es saber a cuál de los dos pasos se refiere cada parámetro.

Cada paso tiene su propia propuesta (cifrado, integridad, grupo Diffie-Hellman y duración) y las dos pasarelas deben tener al menos una combinación en común en cada paso.

El grupo Diffie-Hellman determina con qué tipo y tamaño de números se calcula la clave compartida. Los grupos pequeños son los primeros que se quedan atrás. La RFC 8247 clasifica cada uno con las palabras de la RFC 2119: DEBE (MUST), DEBERÍA (SHOULD), PUEDE (MAY), NO DEBERÍA (SHOULD NOT) y NO DEBE (MUST NOT).

Abre la tabla referencia_rfc8247 para ver cómo clasifica cada grupo y busca en propuestas qué túnel usa uno de los que no debe usarse. Un túnel con un grupo «no debería» es una deuda; uno con un grupo «no debe» es un hallazgo.

La RFC 8247 es una guía de algoritmos para IKEv2. Un túnel que todavía negocia con IKEv1 queda fuera de lo que esa guía cubre y, por eso, es el primer candidato a migración: no basta con cambiar un algoritmo, hay que cambiar de protocolo con el otro extremo.

Cuenta en propuestas los túneles cuya versión de IKE es la 1.

El PFS (secreto perfecto hacia adelante, perfect forward secrecy) hace que cada Child SA derive su clave con un intercambio Diffie-Hellman nuevo. Sin él, quien lograra la clave del canal de control podría reconstruir las de todo el tráfico posterior; con él, cada renovación de clave es independiente de la anterior.

La columna pfs de propuestas dice si cada túnel lo usa. No es una cuestión de «uno u otro»: un túnel puede tener un buen cifrado y aun así no tener PFS.

Los parámetros de un túnel se acuerdan, no se imponen: si una pasarela cambia su propuesta y la otra no, no queda ninguna combinación en común y el túnel cae. Corregir un túnel con un tercero es, por tanto, una gestión con fecha, una propuesta nueva acordada con el otro extremo y una ventana para el cambio.