Editing Internet Key Exchange (section)

===Improvements with IKEv2===
{{Confusing section|date=February 2009}}
The IKEv2 protocol was described in Appendix A of RFC 4306 in 2005. The following issues were addressed:

* Fewer [[Requests for Comments]] (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]] ([[Network Address Translation]] (NAT)) and [[firewall (networking)|firewall]] traversal in general.
* Standard Mobility support: There is a standard extension for IKEv2 named [rfc:4555 Mobility and Multihoming Protocol] (MOBIKE) (see also, [[IPsec#IETF_documentation|IPsec]]) used to support mobility and multihoming for it and [[IPsec#Encapsulating_Security_Payload|Encapsulating Security Payload]] (ESP). By use of this extension IKEv2 and [[IPsec]] can be used by mobile and multihomed users.
* [[NAT traversal]]: The encapsulation of IKE and [[IPsec#Encapsulating_Security_Payload|ESP]] in [[User Datagram Protocol]] (UDP port 4500) enables these protocols to pass through a device or firewall performing [[Network Address Translation|NAT]].<ref>"RFC 4306: Internet Key Exchange (IKEv2) Protocol", Internet Engineering Task Force (IETF), p 38-40</ref>
* [[Stream Control Transmission Protocol]] (SCTP) support: IKEv2 allows for the [[Stream Control Transmission Protocol|SCTP]] protocol as used in Internet telephony protocol, [[Voice over IP]] (VoIP).
* Simple message exchange: IKEv2 has one four-message initial exchange mechanism where IKE provided eight distinctly different initial exchange mechanisms, each one of which had slight advantages and disadvantages.
* Fewer cryptographic mechanisms: IKEv2 uses cryptographic mechanisms to protect its packets that are very similar to what IPsec ESP uses to protect the IPsec packets.  This led to simpler implementations and certifications for [[Common Criteria]] and [[FIPS 140-2]] ([[Federal Information Processing Standard]] (FIPS), 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. Work arounds (such as [[Dead Peer Detection|Dead-Peer-Detection]]) were developed but not standardized.  This meant that different implementations of work-arounds were not always compatible.
* [[Denial of Service]] (DoS) attack resilience: IKEv2 does not perform much processing until it determines if the requester actually exists.  This addressed some of the DoS problems suffered by IKE which would perform a lot of expensive cryptographic processing from [[IP address spoofing|spoofed]] locations.

: Supposing '''HostA''' has a [[Security Parameter Index]] (SPI) of <code>A</code> and '''HostB''' has an [[Security Parameter Index|SPI]] of <code>B</code>, the scenario would look like this:

<pre>
HostA -------------------------------------------------- HostB
     |HDR(A,0),sai1,kei,Ni-------------------------->   |
     |   <----------------------------HDR(A,0),N(cookie)|
     |HDR(A,0),N(cookie),sai1,kei,Ni---------------->   |
     |   <--------------------------HDR(A,B),SAr1,ker,Nr|
</pre>

: If '''HostB''' (the responder) is experiencing large amounts of half-open IKE connections, it will send an unencrypted reply message of <code>IKE_SA_INIT</code> to '''HostA''' (the initiator) with a notify message of type <code>COOKIE</code>, and will expect '''HostA''' to send an <code>IKE_SA_INIT</code> request with that cookie value in a notify payload to '''HostB'''. This is to ensure that the initiator is really capable of handling an IKE response from the responder.