"Introducción IKEv2@ como se describe en [RFC5996] y su predecesor RFC 4306@ tiene un método para recuperarse de un reinicio de un par. Siempre que el tráfico fluya en ambas direcciones@ el par reiniciado debe restablecer los túneles inmediatamente. Sin embargo@ en muchos casos@ el par reiniciado es una puerta de enlace VPN que protege solo servidores@ por lo que todo el tráfico es entrante. En otros casos@ el par no reiniciado tiene una dirección IP dinámica@ por lo que el par reiniciado no puede iniciar IKE porque su dirección IP actual es desconocido. En tales casos@ el par reiniciado no podrá restablecer los túneles. La Sección 2 describe cómo funciona la recuperación bajo RFC 5996@ y explica por qué puede tardar varios minutos. El método propuesto aquí es enviar una cadena de octetos@ llamado ""token QCD""@ en el intercambio IKE_AUTH que establece el túnel. Ese token se puede almacenar en el par como parte de IKE SA. Después de un reinicio@, la implementación reiniciada puede volver a generar el token y enviarlo a el peer@ para eliminar IKE SA. Eliminar IKE SA da como resultado un establecimiento rápido de nuevos túneles IPsec. Esto se describe en la Sección 3. Convenciones utilizadas en este documento Las palabras clave ""DEBE""@ ""NO DEBE""@ ""REQUERIDO""@ ""DEBE""@ ""NO DEBE""@ ""DEBE ""@ ""NO DEBE""@ ""RECOMENDADO""@ ""MAYO""@ y ""OPCIONAL"" en este documento deben interpretarse como se describe en [RFC2119]. El término "token" se refiere a una cadena de octetos que una implementación puede generar utilizando solo las propiedades de un mensaje IKE protegido (como los índices de parámetros de seguridad (SPI) de IKE) como entrada. Una implementación conforme DEBE poder generar el mismo token a partir de la misma entrada incluso después de reiniciar. El término "creador de tokens" se refiere a una implementación que genera un token y lo envía al par como se especifica en este documento. El término "tomador de token" se refiere a una implementación que almacena dicho token o un resumen del mismo para verificar que un nuevo token que recibe es idéntico al antiguo que ha almacenado. El término "almacenamiento no volátil" en este documento se refiere a un módulo de almacenamiento de datos que persiste durante los reinicios del fabricante del token. Ejemplos de dicho módulo de almacenamiento incluyen un disco interno@ un módulo de memoria flash interno@ un disco externo@ y una base de datos externa. Se requiere un pequeño módulo de almacenamiento no volátil para un fabricante de tokens, pero se puede usar uno más grande para mejorar el rendimiento, como se describe en la Sección 8.2.
RFC 6290-2011 Historia
2011RFC 6290-2011 Un método rápido de detección de fallos para el Protocolo de intercambio de claves de Internet (IKE)