Understanding IPSec IKEv2 negotiation on Wireshark

Related Articles:

Understanding IPSec IKEv1 negotiation on Wireshark

1 The Big Picture

There are just 4 messages:

Summary:

• IKE_SA_INIT: negotiate security parameters to protect the next 2 messages (IKE_AUTH)
• Also creates a seed key (known as SKEYSEED) where further keys are produced: 
• SK_e (encryption): computed for each direction (one for outbound and one for inbound) to encrypt IKE_AUTH messages
• SK_a (authentication): computed for each direction (one for outbound and one for inbound) to hash (using HMAC) IKE_AUTH messages
• SK_d (derivation): handed to IPSec to generate encryption and optionally authentication keys for production traffic
• IKE_AUTH: negotiates security parameters to protect production traffic (CHILD_SA)
• More specifically, the IPSec protocol used (ESP or AH - typically ESP as AH doesn't support encryption), the Encryption algorithm (AES128? AES256?) and Authentication algorithm (HMAC_SHA256? HMAC_SHA384?).

2 IKE_SA_INIT

First the Initiator sends a Security Association —> Proposal —> Transform, Transform... payloads which contains the required security settings to protect IKE_AUTH phase as well as to generate the seed key (SK_d) for production traffic (child SA):

In this case here the Initiator only sent one option for Encryption, Integrity, Pseudo-Random Function (PRF) and Diffie Hellman group so there are only 4 corresponding transforms but there could be more. 

Responder picked the 4 available security options also confirmed in Security Association —> Proposal —> Transform, Transform… payloads as seen above.

3 IKE_AUTH

These are immediately applied to next 2 IKE_AUTH messages as seen below:

The above payload is Encrypted using SK_e and Integrity-protected using SK_a (these keys are different for each direction).

The first IKE_AUTH message negotiates the security parameters for production traffic (child SAs), authenticates each side and informs what is the source/destination IP/Port that is supposed to go through IPSec tunnel:

Now, last IKE_AUTH message sent by Responder confirms which security parameters it picked (Security Association message), repeats the same Traffic Selector messages (if correctly configured) and sends hash of message using pre-master key (Authentication message)

Note that I highlighted 2 Notify messages. 

The INITIAL_CONTACT signals to Initiator that this is the only IKE_SA currently active between these peers and if there is any other IKE_SA it should be terminated in favour of this one. 

The SET_WINDOW_SIZE is a flow control mechanism introduced in IKEv2 that allows the other side to send as many outstanding requests as the other peer wants within the window size without receiving any message acknowledging the receipt. 

From now on, if additional CHILD_SAs are needed, a message called CREATE_CHILD_SA can be used to establish additional CHILD_SAs

It can also be used to rekey IKE_SA where Notification payload is sent of type REKEY_SA followed by CREATE_CHILD_SA with new key information so new SA is established and old one is subsequently deleted.