IPSec protocol framework using IKEv2

Oracle recently introduced IKEv2 support for IPSec connections. IKEv2 is available for both Commercial and Gov regions:  https://docs.cloud.oracle.com/en-us/iaas/Content/General/Concepts/govinfo.htm.

IKE stands for Internet Key Exchange and in this blog we will discuss about the latest version, IKEv2 which can replace IKEv1 (IKEv1 is still used on many VPN appliances). IKEv2 is explained in depth in the following RFC: https://tools.ietf.org/html/rfc7296.

We will focus on the negotiation part using IKEv2 and the advantages over IKEv1.

IKE is used to create a Security Association between two parties involved in an encrypted transmission. Prior to have the encrypted traffic sent/received IKEv2 will create a secure tunnel, IKE SA that will be used to create in a secure way the CHILD SAs. It can be one CHILD SA or multiple CHILD SAs.

IKEv2 vs IKEv1 packet exchange

When it comes to negotiation, there are slightly differences between the two protocols (IKEv2 is not backward compatible with IKEv1).

IKEv1 has 2 phases, Phase1 (Main Mode) with 6 messages exchanged and Phase2 (Quick Mode) with 3 messages exchanged. For IKEv1 we have up to 9 message exchanged prior to have the traffic sent/received encrypted.

IKEv2 is a Request/Response protocol and can contain only 4 messages exchanged or more. It consists of the following exchanges:

1. IKE_SA_INIT exchanges

2. IKE_AUTH exchanges

3. CREATE_CHILD_SA (if necessary) exchanges

4. INFORMATIONAL exchanges

The first pair of messages (IKE_SA_INIT) negotiate cryptographic algorithms, exchange nonces, and do a Diffie-Hellman exchange. This exchange is similar to IKEv1 Main Mode message 1 to 4. If IKE_SA_INIT is successful, the IKEv2 SA is encrypted but the remote peer is not authenticated.

The second pair of messages (IKE_AUTH) authenticate the previous messages, exchange identities and certificates, and establish the first Child SA. Based on the authentication used: Pre-Shared Key, RSA certificates or EAP the number of messages exchanged in IKE_AUTH can grow.

The first Child SA is created based on the traffic selector that triggered the tunnel creation.

We can say that IKE_AUTH has the same function with IKEv1 Main Mode messages from 5-6 and with the Quick Mode (because IKEv2 established the first Child SA).

However if we have multiple local and remote subnets in the encryption domain (or traffic selectors) CREATE_CHILD_SA is necessary.

CREATE_CHILD_SA will be used also for IKEv2 SA (established at IKE_SA_INIT) or the initial Child SA (established at IKE_AUTH) re-key. We can conclude that CREATE_CHILD_SA completes the IKEv1 Quick Mode phase.

As we can see there is not a 1:1 matching between the two protocols, instead we can approximate and have similarities between the two.

Let's look now at some packet captures explaining the negotiation phase for IKEv2 and IKEv1:

During an IKEv2 SA lifetime, peers may desire to exchange some control messages related to errors or have notifications of certain events.
This function is accomplished by INFORMATIONAL exchange. The INFORMATIONAL exchange must occur only after the initial exchanges in order to be encrypted. There are some informational messages that are not exchanges and can be sent outside of the context of an IKE SA.

IKEv2 vs IKEv1 considerations

- IKEv2 is an enhancement to IKEv1;

- IKEv2 supports EAP 802.1X (https://tools.ietf.org/html/rfc3748), IKEv1 not;

- IKEv2 supports MOBIKE (https://tools.ietf.org/html/rfc4555), IKEv1 not;

- IKEv2 can provide more security adopting the support for more authentic an and encryption algorithms;

- IKEv2 does not consume more bandwidth compared to IKEv1;

- IKEv2 is not backward compatible with IKEv1;