Editing Internet Key Exchange (section)

==Architecture==
Most IPsec implementations consist of an IKE [[Daemon (computing)|daemon]] that runs in [[user space and kernel space|user space]] and an IPsec stack in the [[Kernel (operating system)|kernel]] that processes the actual [[Internet Protocol|IP]] packets.

User-space daemons have easy access to mass storage containing configuration information, such as the IPsec endpoint addresses, keys and certificates, as required.  Kernel modules, on the other hand, can process packets efficiently and with minimum overhead—which is important for performance reasons.

The IKE protocol uses [[User Datagram Protocol|UDP]] packets, usually on port 500, and generally requires 4–6 packets with 2–3 round trips to create an [[ISAKMP]] [[security association]] (SA) on both sides. The negotiated key material is then given to the IPsec stack.  For instance, this could be an [[Advanced Encryption Standard|AES]] key, information identifying the IP endpoints and ports that are to be protected, as well as what type of IPsec tunnel has been created. The IPsec stack, in turn, intercepts the relevant IP packets if and where appropriate and performs encryption/decryption as required. Implementations vary on how the interception of the packets is done—for example, some use virtual devices, others take a slice out of the firewall, etc.

IKEv1 consists of two phases: phase 1 and phase 2.<ref name="The Internet Key Exchange p. 5">"RFC 2409 The Internet Key Exchange (IKE)", Internet Engineering Task Force (IETF), p. 5</ref>

===IKEv1 phases===

IKE phase one's purpose is to establish a secure authenticated communication channel by using the [[Diffie–Hellman key exchange]] algorithm to generate a shared secret key to encrypt further IKE communications. This negotiation results in one single bi-directional ISAKMP security association.<ref>"RFC 2409 The Internet Key Exchange (IKE)", Internet Engineering Task Force (IETF), p. 6</ref> The authentication can be performed using either [[pre-shared key]] (shared secret), signatures, or public key encryption.<ref>"RFC 2409 The Internet Key Exchange (IKE)", Internet Engineering Task Force (IETF), p. 10-16</ref> Phase 1 operates in either Main Mode or Aggressive Mode. Main Mode protects the identity of the peers and the hash of the shared key by encrypting them; Aggressive Mode does not.<ref name="The Internet Key Exchange p. 5"/>

During IKE phase two, the IKE peers use the secure channel established in Phase 1 to negotiate Security Associations on behalf of other services like [[IPsec]]. The negotiation results in a minimum of two unidirectional security associations (one inbound and one outbound).<ref>"RFC 4306 Internet Key Exchange (IKEv2) Protocol", Internet Engineering Task Force (IETF), p. 11,33</ref> Phase 2 operates only in Quick Mode.<ref name="The Internet Key Exchange p. 5"/>

===Problems with IKE===
Originally, IKE had numerous configuration options but lacked a general facility for automatic negotiation of a well-known default case that is universally implemented. Consequently, both sides of an IKE had to exactly agree on the type of security association they wanted to create{{snd}} option by option{{snd}} or a connection could not be established. Further complications arose from the fact that in many implementations the debug output was difficult to interpret, if there was any facility to produce diagnostic output at all.

The IKE specifications were open to a significant degree of interpretation, bordering on design faults ([[Dead Peer Detection]] being a case in point{{Citation needed|date=June 2015}}), giving rise to different IKE implementations not being able to create an agreed-upon security association at all for many combinations of options, however correctly configured they might appear at either end.

===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.