In the past I had published a few blog posts regarding IKEv2, which can be found here, here and here.

A quick refresh of the IKEv2 establishment can be summarised in the following figure: 

To perform IPsec related tests, of course we need to establish our own lab. The simplest way is to set-up a virtual lab by using Linux systems.

In my case I used VirtualBox, and Fedora.

Fedora provides in its own repositories two options: Racoon2 and strongSwan.

Racoon2 provides an implementation of key management system for IPsec. It supports IKEv1, IKEv2, and KINK protocols. It works on FreeBSD, NetBSD, Linux, and Mac OS X.

StrongSwan is an openSource IPsec-based VPN Solution that runs on Linux 2.6, 3.x and 4.x kernels, Android, FreeBSD, OS X, iOS and Windows. It implements both the IKEv1 and IKEv2 (RFC 7296) key exchange protocols. It has been fully tested support of IPv6 IPsec tunnel and transport connections.

 In my example I will use strongSwan (for no particular reason) to establish a site-to-site VPN connectivity.

As discussed in my previous blogpost, during IKEv2 Establishment the first two exchanges are the "IKE SA Init" and the "IKE Auth". The first one is the only exchange that is unauthenticated and unencrypted, and therefore is of a special interest.     

The "IKE SA Init" exchange includes by default the IKEv2 header, the Security Association payload, the Key Exchange payload and the Nonce payload. Except of the IKEv2 header, of a special interest is the Security Association payload, for two main reasons: First, it is the one used for the various negotiations that need to take place in order to establish the Security Association, and secondly, ti will give us some room for testing IKEv2 implementations. Therefore, in this second part of the IKEv2 blogpost these two structures, the IKEv2 header and the Security Association payload, as well as their usage, are examined. 

Internet Key Exchange (IKE) is the protocol used to establish Security Associations in IPsec. IP Security (IPsec) is a family of network protocols providing confidentiality, data integrity, access control, and data source authentication to IP datagrams [1]. These services are provided by maintaining shared states between the source and the sink of an IP datagram called Security Associations (SAs).

IKE is a component of IPsec used for performing mutual authentication, establishing and maintaining the SAs dynamically and in an automated way. Its latest version is IKE version 2 (IKEv2), defined in [2].

Given that (a small part of) IKE is the only part of IPsec which is still unauthentiticated and unencrypted ,it introduces a special interest from a security perspective, because it constitutes one of the very few attack surfaces of IPsec. The objective of this series of blog post is to examine the latest version of IKE, IKEv2, in order to a) to help us understand i to full a extent, and b) to identify potential attacking vectors.