Duración de las SA en IKEv2: renovación de claves suave, caducidad dura, reautenticación aparte

Los temporizadores deciden cuándo se reemplazan las claves de un túnel, y los dos umbrales implicados a menudo se leen como uno solo. No lo son. Una vida útil suave pide al par que construya un reemplazo mientras la asociación de seguridad actual todavía transporta tráfico, y una vida útil dura es el plazo tras el cual la asociación antigua desaparece, haya funcionado el reemplazo o no. Entre ambas hay una ventana de solapamiento que existe para que los paquetes no caigan en un hueco.

Qué limita realmente una vida útil

Una asociación de seguridad IPsec es un conjunto de estado criptográfico: claves para una dirección, un índice de parámetros de seguridad, un conjunto de algoritmos y un selector. La vida útil limita cuánto tiempo puede usarse ese estado, lo que limita cuánto tráfico protege una clave. Es una medida de contención para la clave, no una afirmación sobre cuánto debe durar una sesión de usuario.

Las asociaciones de control IKE tienen sus propias claves y sus propias vidas útiles, separadas de las asociaciones hijas que transportan datos. Ese es el primer punto donde la gente confunde dos calendarios.

La suave inicia el reemplazo, la dura termina el estado antiguo

Cuando se acerca el umbral suave, el par inicia un reemplazo. Las implementaciones suelen disparar pronto y aleatorizan el momento para que una cabecera con cientos de túneles no renueve las claves de todos a la vez. En IKEv2 el reemplazo es un intercambio CREATE_CHILD_SA con nonces nuevos, más un intercambio Diffie-Hellman cuando está configurada la confidencialidad directa perfecta. El resultado es un par nuevo de asociaciones con claves nuevas.

El solapamiento importa. Durante un periodo breve el par puede mantener las asociaciones antigua y nueva, y una captura puede mostrar dos conjuntos de identificadores. Eso es el mecanismo funcionando, no una avería.

El umbral duro no perdona. Si el reemplazo no se ha completado para entonces, la asociación antigua debe retirarse y el tráfico protegido solo por ella se detiene. Renovaciones de claves fallidas repetidas que llegan hasta la caducidad dura son la señal operativa para investigar, porque el túnel se sostiene con un plazo en cada ciclo.

Los límites de uso pueden saltar antes que cualquier reloj

El tiempo no es la única frontera. Las implementaciones pueden limitar los bytes o paquetes protegidos por una clave, y un túnel ocupado alcanzará un límite de uso mucho antes que un temporizador de varias horas. strongSwan expone ajustes separados de vida útil y margen para tiempo, bytes y paquetes, lo que significa que el punto efectivo de renovación es el umbral que llegue primero, menos el margen configurado.

Cuando un túnel se renueva mucho más a menudo de lo que sugieren sus horas configuradas, revise los límites de bytes y paquetes antes de culpar al reloj. Un enlace saturado y un enlace inactivo con los mismos ajustes de tiempo tendrán tasas de renovación de claves visiblemente distintas, y solo uno de ellos sigue el temporizador.

Cada par aplica su propia política

IKEv2 no negocia una única vida útil que ambos pares deban mostrar de forma idéntica. Cada lado aplica su política local y puede iniciar el reemplazo cuando se acerca su propio límite, como se describe en RFC 7296 sección 2.8. Por eso una discrepancia entre las horas configuradas de dos pares no es automáticamente un defecto, aunque valores muy distintos pueden provocar agitación si un lado no deja de reemplazar estado que el otro acaba de instalar.

Coordinar significa un comportamiento compatible: ventanas de solapamiento suficientemente largas para el intercambio, márgenes que dejan espacio para reintentos y monitorización que muestra qué lado inició cada renovación.

Renovar claves no es reautenticar

Una renovación de claves refresca las claves bajo la relación autenticada existente. Una reautenticación repite la comprobación de identidad, ya sea un intercambio de certificados o una conversación EAP. Ambas funcionan con calendarios separados y una renovación correcta no dice nada sobre si la cuenta debería seguir teniendo acceso.

Esa distinción importa para la revocación. Desactivar una cuenta, revocar un certificado o terminar una sesión son decisiones de acceso que necesitan una política explícita en la implementación; no se derivan del temporizador de la SA, y una renovación puede continuar tranquilamente para una identidad a la que ya se le han retirado los permisos.

Qué registrar por túnel

Registre qué asociación provocó la renovación, los identificadores antiguo y nuevo, qué umbral saltó y si el reemplazo se completó dentro del solapamiento. Esos cuatro campos hacen visible un problema de renovación antes de que se convierta en una caída y distinguen una política agresiva de una que está fallando.

Mantenga el calendario de retirada de acceso junto a ese registro, no dentro de él. La higiene criptográfica y la política de identidad son controles distintos, y un túnel que rota las claves a tiempo todavía puede mantener una sesión que nadie pretendía conservar.