IKEv2
IKEv2 es la siguiente versión del protocolo Internet Key Exchange que se utiliza para negociar una Asociación de Seguridad al principio de una sesión IPsec.
Sumario
IKEv2 se describe en la RFC 5996 de septiembre de 2010, combinación de la RFC 4306 y la RFC 4718, junto con la RFC 4302 (Security Architecture for the Internet Protocol) y la RFC 4310 (DNS Security Extensions Mapping for the EPP). Fue actualizada en la RFC 7296 de octubre de 2014.
Motivación de IKEv2
La necesidad e intención de una revisión general del protocolo IKE se describe en el apéndice A de la RFC 4306 y se reproduce aquí por conveniencia.
Menos RFCs
Las especificaciones de IKE han sido tratadas en al menos tres RFCs, más si se tiene en cuenta NAT traversal y otras extensiones de uso común. IKEv2 combina estas en una RFC además de realizar mejoras para poder pasar a través de NAT (NAT traversal) y pasar a través de cortafuegos en general.
Soporte estándar de movilidad
Hay una extensión estándar para IKEv2 (llamada MOBIKE) utilizada para soportar movilidad y multiorigen (multihoming en inglés), especialmente para túneles IPsec. Mediante esta extensión IKEv2 e IPsec pueden ser utilizados por usuarios móviles y multiorigen.
Soporte de SCTP
IKEv2 tiene en cuenta el protocolo SCTP que se utiliza en VoIP.
Intercambio de mensajes más sencillo
IKE proporciona ocho mecanismos iniciales de intercambio claramente distintos, cada uno de los cuales tiene ligeras ventajas y desventajas comparado con el resto, lo que provoca agrios debates entre la gente que se dedica a la seguridad. IKEv2 tiene uno, un intercambio de cuatro mensajes.
Menos mecanismos criptográficos
IKEv2 utiliza mecanismos para proteger criptográficamente sus propios paquetes muy similares a los que se emplean para proteger el contenido de los paquetes IP en la pila IPsec (Encapsulating Security Payload - ESP). Esto conduce a implementaciones más simples y también probablemente certificaciones más sencillas.
Fiabilidad y gestión de estado
IKEv2 usa números de secuencia y acuses de recibo (acknowledgements) para proporcionar fiabilidad y autoriza cierta logística de procesado de errores y gestión de estado compartido. Debido a la falta de dichas medidas de fiabilidad, IKE podía terminar en un estado muerto, en el que ambos extremos estaban esperando a que el otro iniciase una acción - lo que nunca ocurría. Dead-Peer-Detection (Detección de Extremo Muerto) fue un parche implementado en IKE para esta condición particular -pero hay y había otras, que los implementadores tendían a sortear de forma no siempre compatible con el resto.
Resistencia a ataques DoS
IKEv2 intenta no hacer mucho procesado hasta determinar que el solicitante realmente existe, lo que debería abordar algunos de los problemas de Ataque de denegación de servicio sufridos por IKE, que puede ser engañado para realizar un montón de (caro) procesado criptográfico desde lugares ficticios (spoofing).
Estado de la implentación
A mayo de 2006 hay una serie de implementaciones de IKEv2 y algunas de las compañías que trabajan con pruebas de interoperabilidad y certificación de IPsec han empezado a organizar talleres de pruebas además de requisitos de certificación actualizados para lidiar con las pruebas de IKEv2. ICSA Labs ha organizado su último taller de interoperabilidad de IKEv2 en Orlando, Florida en marzo de 2007 con 13 fabricantes de todo el mundo.
En noviembre de 2007 están disponibles las siguientes implementaciones de IKEv2 de código abierto: OpenIKEv2, strongSwan 4.1 (uno de los sucesores del proyecto FreeS/WAN), , y Racoon2 del proyecto KAME.
Véase también
Enlaces externos
- RFC 4306
- Proyecto OpenIKEv2
- Proyecto strongSwan 4.1 IKEv2
- racoon2