Some thoughts and tools from an IT Security enthusiast.

Yet another web site regarding IT security from an IT security enthusiast.

I created this web site to share my thoughts, my work and my tools with you.

Your comments and questions are more than welcome.






Site-to-Site VPN Using strongSwan (and a few Observations for Supported Capabilities)

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.

Installing and Configuring strongSwan

In order to install strongSwan in our systems, we simply run (as root): dnf install strongswan.

Let’s assume that the IP of Site A is and of Site B is In order to keep things as simple as possible (i.e. using the minimum capabilities), I will establish the IPsec connections without certificates, but by using a pre-shared key.

The ipsec.conf configuration files(located at /etc/strongswan) look as follows:


Site A

Site B

config setup




conn %default

conn tunnel #















config setup




conn %default

conn tunnel #
















If my pre-shared key is 'test12345', then ipsec.secrets file (located also at (located at /etc/strongswan) should look like as follows:


Site A

Site B : PSK 'test12345' : PSK 'test12345'


Then, at both sites we need to start the corresponding service: systemctl start strongswan

(of course, you also need to configure the host firewalls to allow UDP port 500.


If everything went well, we should see something like the following:

A Few Observations on SA Establishment Negotiated by strongSwan

The Security Association establishment (and the IKE_SA_Init and IKE_Auth exchanges) should be familiar by now to us. If not. Please refer to my previous blogposts here and here. However, we have a closer look at them, and specifically to IKE_SA_Init, we may be surprised (with respect to what we have seen so far in the aforementioned blogposts):


As we can see, in addition to the standard payloads (Security Association, Key Exchange, Nonce) encountered and examined so far, we now have payload, the Notify payload.


The Notify Payload

The Notify payload is used to transmit informational data, such as error conditions and state transitions, to specifying why a request was rejected (in a response message), or to indicate sender capabilities or to modify the meaning of the request.


The payload type for the Notify payload is forty-one (41).

- Protocol ID indicates the type of the SA. For notifications concerning Child SAs, this field MUST contain either (2) to indicate AH or (3) to indicate ESP.


- SPI Size is the length in octets of the SPI as defined by the IPsec protocol ID or zero if no SPI is applicable. For a notification concerning the IKE SA, the SPI Size MUST be zero and the field must be empty.


- Notify Message Type specifies the type of notification message.


- SPI (of a variable length) is the Security Parameter Index.


- Notification Data (also of a variable length) defines the status or error data transmitted in addition to the Notify Message Type.


For more information, the reader should refer to RFC 7296.


Notifications for Supported Capabilities

In the wireshark snapshot presented above, the Notify payload advertises the following capabilities:

  • NAT Detection (source IP and Destination IP). IPsec faces some uses when used through NAT. To manage NAT traversal, IKEv2 can use UDP encapsulation of IKE and ESP packets, as described in paragraph 2.23 of RFC 7296.

  • IKEv2 Fragmentation support (RFC 7383). IKEv2 uses UDP as a transport for its messages. Most IKEv2 messages are relatively small, usually below several hundred bytes. A notable exception is the IKE_AUTH exchange, which requires fairly large messages, up to several KB, especially when certificates are transferred. When the IKE message size exceeds the path MTU, it gets fragmented at the IP level. The problem is that some network devices, specifically some NAT boxes, do not allow IP fragments to pass through. This apparently blocks IKE communication and, therefore, prevents peers from establishing an IPsec SA. Especially as far as IPv6 is concerned, several attack vectors that rely on IP fragmentation have been found. Therefore, many network operators filter all IPv6 fragments. Moreover, the default behavior of many currently deployed firewalls is to discard IPv6 fragments. To avoid such cases, the implementation of RFC 7383 allows the fragmentation of IKEv2 exchanges without relying on the IP protocol.

  • Signature Hash Algorithms negotiation support, as described in RFC 7427.

  • Multiple Authentication supported (not depicted in this wireshark snapshot), an experimental protocol defined in RFC 4739 which allows the use of multiple authentication exchanges, using either different mechanisms or the same mechanism.

  • Redirect Mechanism support, defined in RFC 5685, that allows an overloaded VPN gateway or a VPN gateway that is being shut down for maintenance to redirect the VPN client to attach to another gateway. The proposed mechanism can also be used in Mobile IPv6 to enable the home agent to redirect the mobile node to another home agent.


From the above capabilities, of a special interest are the support of IKEv2 fragmentation, and especially the Redirect capability.

In general, as it becomes clear from the above wireshark snapshot, in IKEv2 Exchanges we can add a set of Notify payloads advertising various capabilities. Their use (and potential abuse) needs to be tested.






The IKEv2 Header and the Security Association Payload

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. 

The IKEv2 Header

The IKE header is depicted in the next figure:

The IKE Header Format (figure obtained from ref. [2]).

 In the above figure:

  • SPIs (Security Parameter Indexes) are connection unique identifiers chosen by the endpoint (initiator and responder) themselves. Incoming IKE packets are mapped to an IKE SA only using the packet's SPI. Multiple sessions per peer are possible. In the first message of an initial IKE exchange, the initiator will set the responder's SPI value to zero.

  • Next Payload indicates the type of payload that immediately follows the header.

  • Exchange Type indicates the type of exchange being used. The reader should refer to for the possible values. The most typical values are the following:










IKE_SESSION_RESUME (defined in [4])

  • Flags indicate specific options that are set for the message. The bits are as follows:

| X | X | R | V | I | X | X | X |

    • R (Response) indicates that this message is a response to a message containing the same Message ID. This bit MUST be cleared in all request messages and MUST be set in all responses.

    • V (Version) - Implementations of IKEv2 MUST clear this bit when sending and MUST ignore it in incoming messages.

    • I (Initiator) MUST be set in messages sent by the original initiator of the IKE SA and MUST be cleared in messages sent by the original responder. It is used by the recipient to determine which eight octets of the SPI were generated by the recipient. This bit changes to reflect who initiated the last rekey of the IKE SA.

    • 'X' bits MUST be set to zero (0) when sending and MUST be ignored on receipt.

  • Message ID is used to control retransmission of lost packets and matching of requests and responses, as well as to prevent message replay attacks.

  • Length indicates the length of the total message (including the header and all the payloads).

 A wireshark capture of IKEv2 header is presented below:

An IKEv2 header (as captured by Wireshark)

(screenshot obtained thanks to the pcap files published by by Johannes Weber at


In the above figure we can see: a) the initiator’s and responder’s SPIs (the responder’s one is set to 0 since this is the very first message of the initial exchange), b) the Next Payload (which, in this case, points to a Security Association payload, the IKE Version 2.0), c) the flags (which depict that this is a message sent by the Initiator of the exchange, and that it is a Request, and d) the Message ID and the length of the header plus the payloads.


For more information the fields of the IKE header, the reader can refer to section 3.1 of [2].

Generic Payload Header

Each IKE payload begins with a generic payload header, shown in the next figure. This is the first part of all IKE payloads, and hence, it is described in this subsection to avoid repeating information.

Generic Payload Header (figure obtained from ref. [2]).


  • Next Payload is an identifier for the type of the next payload in the message. If the current payload is the last in the message, then this field will be 0. An Encrypted payload, which must always be the last payload of a message, is an exception. The currently defined payloads are the following:


    Security Association



    Key Exchange



    Identification - Initiator



    Identification - Responder






    Certificate Request







    Ni, Nr








    Vendor ID



    Traffic Selector - Initiator



    Traffic Selector - Responder



    Encrypted and Authenticated






    Extensible Authentication



    Generic Secure Password Method

    GSPM [RFC6467]


    Encrypted and Authenticated Fragment

    SKF     [RFC7383]


    Puzzle Solution

    PS       [RFC8019]

    The reader should refer to for the latest update.

  • Critical MUST be set to zero if the sender wants the recipient to skip this payload if it does not understand the payload type code in the Next Payload field of the previous payload. It MUST be set to one if the sender wants the recipient to reject this entire message if it does not understand the payload type. It MUST be ignored by the recipient if the recipient understands the payload type code. Note that the critical bit applies to the current payload rather than the "next" payload whose type code appears in the first octet.

  • Payload Length is the length in octets of the current payload, including the generic payload header.

Security Association Payload

The Security Association payload is probably the most complicated IKEv2 one.


In a nutshell, eech Security Association (SA) payload MAY contain one or more Proposals, each one of which MAY contain one or more Transforms, each one of which MAY contain one or more Attribute information. Proposals, Transforms, and Attributes each have their own variable-length encodings. They are nested such that the Payload Length of an SA payload includes the combined contents of the SA, Proposal, Transform, and Attribute information.


An example of a Security Association payload with one Proposal and several nested Transforms is depicted below:


As said, the length of a Proposal includes the lengths of all Transforms and Attributes it contains. The length of a Transform includes the lengths of all Attributes it contains.


The Security Association payload format is depicted in the figure below:

Security Association Payload (figure obtained from ref. [2]).


The first 32 bits are the ones of the Generic Payload header described in the previous subsection.


As already mentioned, a Security Association Payload may contain one or more payload. A Proposal contains a Proposal Num and an IPsec Protocol ID. The Proposals substructure is depicted in the next figure:

 Proposal Substructure (figure obtained from ref. [2]).


  • Last Substruc specifies whether or not this is the last Proposal Substructure in the SA. This field has a value of 0 if this was the last Proposal Substructure, and a value of 2 if there are more Proposal Substructures.

  • Proposal Length is the length of this proposal, including all transforms and attributes that follow.

  • Proposal Num. When a proposal is made, the first proposal in an SA payload MUST be 1, and subsequent proposals MUST be one more than the previous proposal (indicating an OR of the two proposals). When a proposal is accepted, the proposal number in the SA payload MUST match the number on the proposal sent that was accepted.

  • Protocol ID specifies the IPsec protocol identifier for the current negotiation. The most common defined values are the following (more can be found in

Protocol Protocol ID

IKE          1

AH           2

ESP         3

  • SPI Size. For an initial IKE SA negotiation, this field MUST be zero; the SPI is obtained from the outer header. During subsequent negotiations, it is equal to the size, in octets, of the SPI of the corresponding protocol (8 for IKE, 4 for ESP and AH).

  • Num Transforms specifies the number of transforms in this proposal.

  • SPI (variable) - The sending entity's SPI. Even if the SPI Size is not a multiple of 4 octets, there is no padding applied to the payload. When the SPI Size field is zero, this field is not present in the Security Association payload.


If there is more than one Proposal, they MUST be ordered from most preferred to least preferred. Each Proposal contains a single IPsec protocol, each protocol MAY contain multiple transforms, and each transform MAY contain multiple attributes.


Each Proposal structure is followed by one or more transform structures. The number of different Transforms is generally determined by the Protocol, as follows:

  • AH generally has two transforms: Extended Sequence Numbers (ESNs) and an integrity check algorithm.

  • ESP generally has three transforms: ESN, an encryption algorithm, and an integrity check algorithm.

  • IKE generally has four transforms: a Diffie-Hellman group, an integrity check algorithm, a PRF (Pseudo-Random Function) algorithm, and an encryption algorithm.

The Transforms substructure is depicted in the next figure:

Transform Substructure (figure obtained from ref. [2]).


  • Last Substruc specifies whether or not this is the last Transform Substructure in the Proposal. This field has a value of 0 if this was the last Transform Substructure, and a value of 3 if there are more Transform Substructures.

  • Transform Length gives the length (in octets) of the Transform Substructure including Header and Attributes.

  • Transform Type. Different protocols support different Transform Types. For some protocols, some of the transforms may be optional. If a transform is optional and the initiator wishes to propose that the transform be omitted, no transform of the given type is included in the proposal. If the initiator wishes to make use of the transform optional to the responder, it includes a transform substructure with Transform ID = 0 as one of the options. The Transform Type values are listed below (the reader should refer to for the latest update).


   Description                     Trans.  Used In
   Encryption Algorithm (ENCR)     1       IKE and ESP
   Pseudorandom Function (PRF)     2       IKE
   Integrity Algorithm (INTEG)     3       IKE, AH, optional in ESP
   Diffie-Hellman Group (D-H)      4       IKE, optional in AH & ESP
   Extended Sequence Numbers (ESN) 5       AH and ESP



If there are multiple transforms with the same Transform Type, the proposal is an OR of those transforms. If there are multiple transforms with different Transform Types, the proposal is an AND of the different groups.


Attributes are necessary when the transform can be used in more than one way, as when an encryption algorithm has a variable key size. The transform would specify the algorithm and the attribute would specify the key size.


Most transforms do not have Attributes though. A transform MUST NOT have multiple attributes of the same type.


The Attributes are type/value pairs. Attributes can have a value with a fixed two-octet length or a variable-length value. For the latter, the attribute is encoded as type/length/value.


The Attributes Substructure is depicted in the figure below:

Attributes Substructure (figure obtained from ref. [2]).

  • Attribute Format (AF) indicates whether the data attribute follows the Type/Length/Value (TLV) format or a shortened Type/Value (TV) format. If the AF bit is zero (0), then the attribute uses TLV format; if the AF bit is one (1), the TV format (with two-byte value) is used.

  • Attribute Type is a Unique identifier for each type of attribute.

  • Attribute Value (variable length) is the value of the attribute associated with the attribute type. If the AF bit is a zero (0), this field has a variable length defined by the Attribute Length field. If the AF bit is a one (1), the Attribute Value has a length of 2 octets.


The only currently defined Attribute type (Key Length) is fixed length (the variable-length encoding specification is included only for future extensions). This is defined as follows:


  Attribute Type         Value         Attribute Format
       Key Length (in bits)   14            TV

An example of a set of Transforms (as a part of a Proposal), with one of them incorporating an Attribute, is depicted on the following Wireshark output:

A Wireshark output of some Transforms and an Attribute as part of the Security Association Payload.


 In the above example, the Attribute of the first transform (which proposes the use of AES as an encryption algorithm) is the key length of the AES algorithm (256 bits).


The Key Exchange Payload

The Key Exchange payload is used to exchange Diffie-Hellman public numbers as part of a Diffie-Hellman key exchange. The Key Exchange payload consists of the IKE generic payload header followed by the Diffie-Hellman public value itself.



The Key Exchange Payload (figure obtained from ref. [2]).


A Key Exchange payload is constructed by copying one’s Diffie-Hellman public value into the "Key Exchange Data" portion of the payload. T

he Diffie-Hellman Group Num identifies the Diffie-Hellman group in which the Key Exchange Data was computed. This Diffie-Hellman Group Num MUST match a Diffie-Hellman group specified in a proposal in the SA payload that is sent in the same message, and SHOULD match the Diffie-Hellman group in the first group in the first proposal, if such exists. If none of the proposals in that SA payload specifies a Diffie-Hellman group, the KE payload MUST NOT be present. If the selected proposal uses a different Diffie-Hellman group (other than NONE), the message MUST be rejected with a Notify payload of type INVALID_KE_PAYLOAD.


The Nonce Payload

The Nonce payload, denoted as Ni and Nr in this document for the initiator’s and responder’s nonce, respectively, contains random data used to guarantee liveness during an exchange and protect against replay attacks.

The Nonce Payload (figure obtained from ref. [2]).



Nonce Data (which is of a variable length) contains the random data generated by the transmitting entity.


The payload type for the Nonce payload is forty (40).


The size of the Nonce Data MUST be between 16 and 256 octets,inclusive. Nonce values MUST NOT be reused.


A wireshark screenshot of the Key Exchange and of the Nonce payload is presented below:


A Wireshark screenshot of a Key Exhange and a Nonce Payload


Conclusions of the IKEv2 Establishment

In these first two blogposts we examine how an IKEv2 Security Association(SA) is established. We saw that in order to achieve this we need two pairs of exchanges, IKE_SA_Init and IKE_Auth exchanges. From them, only the first one is unencrypted. Therefore, during the SA establishment, IKE_SA_init is the only attack surface available to an unauthenticated attacker.

During IKE_SA_Init, at a minimum one header (the IKEv2 header) and three payloads are used: The Security Association payload, the Key Exchange payload and the Nonce payload 9in some cases some more are used, but this will be examined in another blog post).


From the aforementioned IKEv2 payloads used during the SA establishment, of a special interest seems to be the Security Association payload. That is because it can encapsulate several nested substructures, of a different levels (Proposals, Transformations, Attributes) and numbers of substructure per parent structure.


In the next blog post I shall explain how we can easily set up a virtual IKEv2 lab and we will start testing it.

Until then, Merry Christmas to all!


[1] Kent, S. and K. Seo, "Security Architecture for the Internet Protocol", RFC 4301, DOI 10.17487/RFC4301, December 2005, <>.

[2] Kaufman, C., Hoffman, P., Nir, Y., Eronen, P., and T. Kivinen, "Internet Key Exchange Protocol Version 2 (IKEv2)", STD 79, RFC 7296, DOI 10.17487/RFC7296, October 2014, <>.

[3] Diffie, W. and M. Hellman, "New Directions in Cryptography", IEEE Transactions on Information Theory, V.IT-22 n. 6, June 1977.

[4] Sheffer, Y. and H. Tschofenig, "Internet Key Exchange Protocol Version 2 (IKEv2) Session Resumption", RFC 5723, DOI 10.17487/RFC5723, January 2010, <>.