Internet Key Exchange (IKEv2) Protocol

IKE is the protocol used to set up a security association (SA) in the IPsec protocol suite. IKEv2 is the
second and latest version of the IKE protocol. Adoption for this protocol started as early as 2006.

IKE builds upon the Oakley protocol and ISAKMP. IKE uses X.509 certificates for authentication - either
pre-shared or distributed using DNS (preferably with DNSSEC) and a DiffieHellman key exchange - to
set up a shared session secret from which cryptographic keys are derived.

History
The Internet Engineering Task Force (IETF) originally defined IKE in November 1998 in a series of
publications (Request for Comments) known as RFC 2407, RFC 2408 and RFC 2409:

1. RFC 2407 defined The Internet IP Security Domain of Interpretation for ISAKMP.
2. RFC 2408 Internet Security Association and Key Management Protocol (ISAKMP).
3. RFC 2409 defined The Internet Key Exchange (IKE).

IKE was updated to version two (IKEv2) in December 2005 by RFC 4306. Some open details were clarified
in October 2006 by RFC 4718. These two documents plus additional clarifications were combined into
the updated IKEv2 RFC 5996 which was published in September 2010. A later update upgraded the
document from Proposed Standard to Internet Standard, and was published as RFC 7296 in October
2014.

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 option by option
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 debug routine 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), 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

The need and intent of an overhaul of the IKE protocol was described in Appendix A of RFC 4306. The
following issues were addressed:

1. 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
 Internet Key Exchange (IKEv2) Protocol

one RFC as well as making improvements to support for NAT traversal and firewall traversal in
general.
2. Standard Mobility support: There is a standard extension for IKEv2 (named MOBIKE) used to
support mobility and multihoming for it and ESP. By use of this extension IKEv2 and IPsec can be
used by mobile and multihomed users.
3. NAT traversal: The encapsulation of IKE and ESP in UDP port 4500 enables these protocols to
pass through a device or firewall performing NAT.
4. SCTP support: IKEv2 allows for the SCTP protocol as used in Internet Telephony VoIP.
5. 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.
6. Fewer cryptographic mechanisms: IKEv2 uses cryptographic mechanisms to protect its packets
that are very similar to what IPsec Encapsulating Security Payload (ESP) uses to protect the IPsec
packets. This led to simpler implementations and certifications for Common Criteria and FIPS
140-2, which require each cryptographic implementation to be separately validated.
7. 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) were developed but not standardized. This meant that different
implementations of work-arounds were not always compatible.
8. 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 spoofed locations.

Vulnerabilities
Leaked NSA presentations released by 'Der Spiegel' indicate that IKE is being exploited in an unknown
manner to decrypt IPSec traffic.

Initial Phases in IKEv2 Exchange

In effect, IKEv2 has only two initial phases of negotiation:

IKE_SA_INIT Exchange
IKE_AUTH Exchange

IKE_SA_INIT Exchange
IKE_SA_INIT is the initial exchange in which the peers establish a secure channel. After it completes the
initial exchange, all further exchanges are encrypted. The exchanges contain only two packets because it
combines all the information usually exchanged in MM1-4 in IKEv1. As a result, the responder is
 Internet Key Exchange (IKEv2) Protocol

computationally expensive to process the IKE_SA_INIT packet and can leave to process the first packet;
it leaves the protocol open to a DOS attack from spoofed addresses.

In order to protect from this kind of attack, IKEv2 has an optional exchange within IKE_SA_INIT to
prevent against spoofing attacks. If a certain threshold of incomplete sessions is reached, the responder
does not process the packet further, but instead sends a response to the Initiator with a cookie. For the
session to continue, the Initiator must resend the IKE_SA_INIT packet and include the cookie it received.

The Initiator resends the initial packet along with the Notify payload from the responder that proves the
original exchange was not spoofed. Here is a diagram of IKE_SA_INIT exchange with cookie challenge:

Figure 1 IKE_SA_INIT Exchange

IKE_AUTH Exchange
After the IKE_SA_INIT exchange is complete, the IKEv2 SA is encrypted; however, the remote peer has
not been authenticated. The IKE_AUTH exchange is used to authenticate the remote peer and create
the first IPsec SA.

The exchange contains the Internet Security Association and Key Management Protocol (ISAKMP) ID
along with an authentication payload. The contents of the authentication payload is dependent on the
method of authentication, which can be Pre-Shared Key (PSK), RSA certificates (RSA-SIG), Elliptic Curve
Digital Signature Algorithm certificates (ECDSA-SIG), or EAP. In addition to the authentication payloads,
the exchange includes the SA and Traffic Selector payloads that describe the IPsec SA to be created.
 Internet Key Exchange (IKEv2) Protocol

Later IKEv2 Exchanges

CREATE_CHILD_SA Exchange

If additional child SAs are required, or if the IKE SA or one of the child SAs needs to be re-keyed, it serves
the same function that the Quick mode exchange does in IKEv1. As shown in the this diagram, there are
only two packets in this exchange; however, the exchange repeats for every rekey or new SA:

Figure 2 Child_SA Exchange

INFORMATIONAL Exchange

As it is in all IKEv2 exchanges, each INFORMATIONAL Exchange request expects a response. Three types
of payloads can be included in an INFORMATIONAL exchange. Any number of any combination of
payloads can be included, as shown in the this diagram:

Figure 3 Informational Exchange

1. The Notify payload (N) has already been seen in conjunction with cookies. There are several
other types as well. They carry error and status information, as they do in IKEv1.
 Internet Key Exchange (IKEv2) Protocol

2. The Delete payload (D) informs the peer that the sender has deleted one or more of its incoming
SAs. The responder is expected to delete those SAs and usually includes Delete payloads for the
SAs that correspond in the other direction in its response message.
3. The Configuration payload (CP) is used to negotiate configuration data between the peers. One
important use of the CP is to request (request) and assign (response) an address on a network
protected by a security gateway. In the typical case, a mobile host establishes a Virtual Private
Network (VPN) with a security gateway on its home network and requests that it be given an IP
address on the home network.

(Note: This eliminates one of the problems that the combined use of Layer 2 Tunneling Protocol (L2TP)
and IPsec is intended to solve.)

Differences between IKEv1 and IKEv2

Figure 4 Difference b/w IKEv1 & IKEv2

 Internet Key Exchange (IKEv2) Protocol

IKEv1 IKEv2
IPsec SA Child SA (Changed)
Exchange modes: Only one exchange procedure is defined.
1. Main mode Exchange modes were obsoleted.
2. Aggressive mode
Exchanged messages to establish VPN. Only 4 messages.
1. Main mode: 9 messages
2. Aggressive mode: 6 messages
Authentication methods ( 4 methods ): Only 2 methods:
1. Pre-Shared Key (PSK) 1. Pre-Shared Key (PSK)
2. Digital Signature (RSA-Sig) 2. Digital Signature (RSA-Sig)
3. Public Key Encryption
4. Revised Mode of Public key Encryption
Both peers must use the same authentication Each peer can use a different authentication
method. method (Asymmetrical authentication).
(e.g. Initiator: PSK and Responder: RSA-Sig)
Traffic selector: 1. Multiple combinations of a source IP range,
1. Only a combination of a source IP range, a a destination IP range, a source port range
destination IP range, a source port and a and a destination port range are allowed
destination port is allowed per IPsec SA. per Child SA. Of course, IPv4 and IPv6
2. Exact agreement of the traffic selector addresses can be configured for the same
between peers is required. Child SA.
2. Narrowing traffic selectors between peers
is allowed.
Lifetime for SAs: NOT negotiated. Each peer can delete SAs anytime
Agreement between peers is required. by exchanging DELETE payloads.
Multi-hosting: Supported by using multiple IDs on a single IP
Basically, NOT supported. address and port pair.
Rekeying: Defined.
NOT defined.
NAT Traversal: Supported by default.
Defined as an extension.
Dead Peer Detection / Keep-alive for SAs: Supported by default.
Defined as an extension.
Remote Access VPN: Supported by default:
NOT defined. Supported by vender-specific Extensible Authentication Protocol (EAP)
implementations: User authentication over EAP is associated
Mode config with IKE's authentication.
XAUTH Configuration payload (CP)
Multi-homing: Supported by MOBIKE (IKEv2 Mobility and
Basically, NOT supported. Multihoming Protocol: RFC 4555).
Mobile Clients: Supported by MOBIKE (IKEv2 Mobility and
Basically, NOT supported. Multihoming Protocol: RFC 4555).
DoS protections: 1. Anti-replay function is supported.
Basically, NOT supported. 2. 'Cookies' is supported for mitigating
 Internet Key Exchange (IKEv2) Protocol
Less reliable than IKEv2.
Extensions are very poor.
flooding attacks.
3. Many vulnerabilities in IKEv1 were fixed.
More reliable.
1. All message types are defined as Request
and Response pairs.
2. A procedure to delete SAs is defined.
3. A procedure to retransmit a message is
defined.
Useful extentions in actual network environment.
1. "Redirect Mechanism for IKEv2 (RFC5685)"
2. "IKEv2 Session Resumption (RFC5723)"
3. "An Extension for EAP-Only Authentication
in IKEv2 (RFC5998)"
4. "Protocol Support for High Availability of
IKEv2/IPsec (RFC6311)"
5. "A Quick Crash Detection Method for the
Internet Key Exchange Protocol (IKE)
(RFC6290)"
 Internet Key Exchange (IKEv2) Protocol

Example S2S VPN using IKEv2

Figure 5 Topology

Peer1 (Router)

crypto ikev2 proposal 10

encryption aes-cbc-256
integrity sha256
group 5
exit
 Internet Key Exchange (IKEv2) Protocol

crypto ikev2 policy 1

proposal 10
exit

crypto ikev2 keyring KEY1

peer peer2
address 102.1.1.100
pre-shared-key cisco
exit
exit

crypto ikev2 profile IKEV2

match identity remote add 102.1.1.100
identity local add 101.1.1.100
keyring local KEY1
authentication local pre-share
authentication remote pre-share
exit

ip access-list extended VPN

permit ip host 192.168.1.100 host 192.168.2.100
exit

crypto ipsec transform-set esp-aes esp-sha-hmac

exit

crypto map CMAP 10 ipsec-isakmp

set transform-set tset
set ikev2-profile IKEV2
match address VPN
set peer 102.1.1.100
exit

int f0/0
crypto map CMAP
exit
 Internet Key Exchange (IKEv2) Protocol

Peer2 (ASA)

crypto ikev2 policy 10

encryption aes-256
integrity sha256
prf sha256
group 5
exit

tunnel-group 101.1.1.100 type ipsec-l2l

tunnel-group 101.1.1.100 ipsec-attributes
ikev2 local-authentication pre-share-key cisco
ikev2 remote-authentication pre-share-key cisco
exit

crypto ipsec ikev2 ipsec-proposal Prop1

protocol esp encryption aes
protocol esp integrity sha-1
exit

access-list VPN permit ip host 192.168.2.100 host 192.168.1.100

crypto map CMAP 10 set ikev2 ipsec-proposal Prop1

crypto map CMAP 10 set peer 101.1.1.100
crypto map CMAP 10 match address VPN
crypto map CMAP interface outside
crypto ikev2 enable outside