IKEv2

IKEv2 is the next version of the Internet Key Exchange protocol which is used to negotiate a Security Association at the outset of an IPsec session.

Overview

IKEv2 is described in RFC 4306 - although there are other related RFCs that are important. RFC 4301 (Security Architecture for the Internet Protocol) through RFC 4310 (DNS Security Extensions Mapping for the EPP) and more are being added all the time as the need arises to add new security features and protocols.

Motivation for IKEv2

The need and intent of an overhaul of the IKE protocol is described in Appendix A of RFC 4306 and paraphrased in part here for convenience.

Fewer RFCs

The specifications for IKE were covered in at least three RFCs, more if one takes into account NAT traversal and other extensions that are in common use. IKEv2 combines these in one RFC as well as making improvements to support for NAT traversal and firewall traversal in general.

Standard Mobility support

There is a standard extension for IKEv2(named MOBIKE) used to support mobility and multihoming for it and esp. for IPsec tunnels. By use of this extension IKEv2 and IPsec can be used by mobile and multihomed users.

SCTP support

IKEv2 allows for the SCTP protocol as used in Internet Telephony VoIP.

Simpler message exchange

IKE provides eight distinctly different initial exchange mechanisms, each one of which has slight advantages and disadvantages when compared to the others giving rise to fierce debates amongst security folk. IKEv2 has one, four-message exchange.

Fewer cryptographic mechanisms

IKEv2 uses very similar mechanisms to protect its own packets cryptographically to what is used to ultimately protect the IP payloads in the IPsec stack (Encapsulating Security Payload - ESP). Leading to simpler implementations and also probably easier certifications (Common Criteria, FIPS 140-2) which require each cryptographic implementation to be separately validated.

Reliability and State management

IKEv2 uses sequence numbers and acknowledgments to provide reliability and mandates some error processing logistics and shared state management. IKE could end up in a dead state due to the lack of such reliability measures, where both parties were expecting the other to initiate an action - which never eventuated. Dead-Peer-Detection was a work-around implemented in IKE for this particular condition - but there are and were others, which implementors tended to get around via means that were not always compatible with everybody else.

DoS attack resilience

IKEv2 tries to not do much processing until it can determine the requester actually exists, which should address some of the Denial of Service problems suffered by IKE which can be tricked into doing a lot of cryptographic (expensive) processing from bogus locations (spoofing).

Implementation Status

As of May-2006 there are a number of implementations of IKEv2 and some of the companies dealing in IPsec certification and interoperability testing are starting to hold work-shops for testing as well as updated certification requirements to deal with IKEv2 testing. [http://www.icsalabs.com ICSA Labs] held its latest IKEv2 Interoperability Workshop in Orlando, FL in March 2007 with 13 vendors from around the world.

The following Open Source implementations of IKEv2 are currently available: [http://sourceforge.net/projects/openikev2 OpenIKEv2] , strongSwan 4.1 (one of the successors of the FreeS/WAN project), [http://sourceforge.net/projects/ikev2 IKEv2] , and [http://www.racoon2.wide.ad.jp/w/ Racoon2] from the KAME project.

See also

* Internet key exchange
* IPsec

External links

* RFC 4306
* [http://sourceforge.net/projects/openikev2 OpenIKEv2 project]
* [http://www.strongswan.org/ strongSwan 4.1 IKEv2 project]
* [http://sourceforge.net/projects/ikev2 IKEv2 project]
* [http://www.racoon2.wide.ad.jp/w/ racoon2 ]