Duración das SA en IKEv2: renovación de chaves suave, caducidade dura, reautenticación aparte

Os temporizadores deciden cando se substitúen as chaves dun túnel, e os dous limiares implicados a miúdo len como un só. Non o son. Unha vida útil suave pide ao par que constrúa un substituto mentres a asociación de seguridade actual aínda transporta tráfico, e unha vida útil dura é o prazo tras o cal a asociación antiga desaparece, funcione ou non o substituto. Entre ambas hai unha xanela de solapamento que existe para que os paquetes non caian nun oco.

Que limita realmente unha vida útil

Unha asociación de seguridade IPsec é un conxunto de estado criptográfico: chaves para unha dirección, un índice de parámetros de seguridade, un conxunto de algoritmos e un selector. A vida útil limita canto tempo se pode usar ese estado, o que limita canto tráfico protexe unha chave. É unha medida de contención para a chave, non unha afirmación sobre canto debe durar unha sesión de usuario.

As asociacións de control IKE teñen as súas propias chaves e as súas propias vidas útiles, separadas das asociacións fillas que transportan datos. Ese é o primeiro punto onde a xente confunde dous calendarios.

A suave inicia o substituto, a dura remata o estado antigo

Cando se achega o limiar suave, o par inicia un substituto. As implementacións adoitan disparar cedo e aleatorizan o momento para que unha cabeceira con centos de túneles non renove as chaves de todos á vez. En IKEv2 o substituto é un intercambio CREATE_CHILD_SA con nonces novos, máis un intercambio Diffie-Hellman cando está configurada a confidencialidade directa perfecta. O resultado é un novo par de asociacións con chaves novas.

O solapamento importa. Durante un período breve o par pode manter as asociacións antiga e nova, e unha captura pode mostrar dous conxuntos de identificadores. Eso é o mecanismo funcionando, non unha avaría.

O limiar duro non perdoa. Se o substituto non está completado para entón, a asociación antiga debe retirarse e o tráfico protexido só por ela detense. Renovacións de chaves fallidas repetidas que chegan ata a caducidade dura son o sinal operativo para investigar, porque o túnel sostense cun prazo en cada ciclo.

Os límites de uso poden saltar antes que calquera reloxo

O tempo non é a única fronteira. As implementacións poden limitar os bytes ou paquetes protexidos por unha chave, e un túnel ocupado alcanzará un límite de uso moito antes que un temporizador de varias horas. strongSwan expón axustes separados de vida útil e marxe para tempo, bytes e paquetes, o que significa que o punto efectivo de renovación é o limiar que chegue primeiro, menos a marxe configurada.

Cando un túnel se renova moito máis a miúdo do que suxiren as súas horas configuradas, revise os límites de bytes e paquetes antes de culpar o reloxo. Unha ligazón saturada e unha ligazón inactiva cos mesmos axustes de tempo terán taxas de renovación de chaves visiblemente distintas, e só unha delas segue o temporizador.

Cada par aplica a súa propia política

IKEv2 non negocia unha única vida útil que ambos pares deban mostrar de forma idéntica. Cada lado aplica a súa política local e pode iniciar o substituto cando se achega o seu propio límite, como se describe en RFC 7296 sección 2.8. Así que unha discrepancia entre as horas configuradas de dous pares non é automaticamente un defecto, aínda que valores moi distintos poden provocar axitación se un lado non deixa de substituír estado que o outro acaba de instalar.

Coordinar significa un comportamento compatible: xanelas de solapamento abondo longas para o intercambio, marxes que deixan espazo para reintentos e monitorización que mostra que lado iniciou cada renovación.

Renovar chaves non é reautenticar

Unha renovación de chaves refresca as chaves baixo a relación autenticada existente. Unha reautenticación repite a comprobación de identidade, xa sexa un intercambio de certificados ou unha conversa EAP. Ambas funcionan con calendarios separados e unha renovación correcta non di nada sobre se a conta debería seguir tendo acceso.

Esa distinción importa para a revocación. Desactivar unha conta, revogar un certificado ou rematar unha sesión son decisións de acceso que necesitan unha política explícita na implementación; non se derivan do temporizador da SA, e unha renovación pode continuar tranquilamente para unha identidade á que xa se lle retiraron os permisos.

Que rexistrar por túnel

Rexiste que asociación provocou a renovación, os identificadores antigo e novo, que limiar saltou e se o substituto se completou dentro do solapamento. Esos catro campos fan visible un problema de renovación antes de que se converta nunha caída e distinguen unha política agresiva dunha que está fallando.

Manteña o calendario de retirada de acceso xunto a ese rexistro, non dentro del. A hixiene criptográfica e a política de identidade son controis distintos, e un túnel que rota as chaves a tempo aínda pode manter unha sesión que ninguén pretendía conservar.