Chapter 2. IKEv2: The Protocol

This chapter takes you through the lifecycle of the Internet Key Exchange version 2. The chapter is structured to provide an overview of IKEv2, then detailed information about each exchange type (SA_INIT, IKE_AUTH, CREATE_CHILD_SA and INFORMATIONAL), so you will have a deep understanding of what is occurring within each.

Understanding the protocol will assist engineers when deploying and troubleshooting the technology, as well as designers making decisions that work when scoping VPN architectures.

This chapter was designed to be accessible, yet also still maintain details from the IKEv2 RFC and minimize output from Cisco-specific technologies to make this relevant if you work in a vendor agnostic environment.

Outputs are taken from packet captures saved in text format. The intent is to show clearly the packet structures along with the data being passed. In some cases the packet was encrypted, and it had to be decrypted to obtain this information.

An RFC is published in the form of a memorandum describing the methods, behaviors, and/or innovations applicable to the working of the Internet and Internet-connected systems. Before an RFC is published, it goes through a process in which it is peer reviewed and analyzed by members of the IETF. Before RFC 7296 was published, the IETF published RFC 4306, which described IKEv2 and was published as an Internet standard in 2005. RFC 4306 has since been updated and replaced by RFC 5996, which was published in 2010. In October 2014, RFC 5996 was updated and replaced by RFC 7296, making RFC 5996 obsolete.

IKEv2 consists of an initial handshake (known as SA_INIT or initial exchange) in which both parties negotiate a set of cryptographic algorithms, exchange Diffie-Hellman public values, and establish a shared session key that can then be used to derive additional key material to protect subsequent IKEv2 exchanges. Randomness is added to the exchange in the form of nonces (‘number used once’).

The second part of the exchange (known as IKE_AUTH or authentication) is secured using cryptographic algorithms and key material obtained from the initial handshake. Each party will exchange identities and provide authentication data to validate their identity, using an integrity check generated from the secret key associated with their identity.

Peers will exchange cryptographic algorithms that will be used to protect one or more IPsec Security Association using Encapsulated Security Payload or Authentication Header.

Should additional pairs of IPsec Security Associations be required, then an additional IKEv2 exchange will occur to create these using a CREATE_CHILD_SA exchange. When IKEv2 is used, these additional IPsec Security Associations are known as Child SAs.

The IKEv2 protocol employs a simple denial of service (DoS) protection mechanism that mitigates blind spoofing attacks that could consume expensive resources.

Every IKEv2 message exchange consists of request/response pairs, with the sender of the request being responsible for retransmitting messages if it does not receive a reply.

On rekey of the IKEv2 SA, a new CREATE_CHILD_SA exchange will occur; this will include exchanging cryptographic algorithms that will be used to protect the new IKEv2 SA. A fresh Diffie-Hellman exchange will occur and be used to generate new key material to protect the subsequent IKEv2 SA that is created.

On rekey of an IPsec Security Association, a new CREATE_CHILD_SA exchange will occur, which consists exchanging cryptographic algorithms that will be used to protect the new IPsec Security Association. Optionally a fresh Diffie-Hellman exchange can occur that will be used in generating new key material to protect the subsequent IPsec Security Association. It should be noted that on a rekey no authentication occurs, RFC 4478, Repeated Authentication in Internet Key Exchange (IKEv2) Protocol, describes how re-authentication can occur in IKEv2.

IKEv2 allows additional control messages to be exchanged once the IKEv2 SA is completed using an INFORMATIONAL exchange. These messages allow for actions such as liveness checking (also known as keepalives) and the deletion of SAs.

The IKEv2 SA is a protected tunnel that allows for subsequent messages to be sent cryptographically protected; this allows the sending of authenticated notification messages, reliable dead-peer detection, and creation of additional child SAs.

IKEv2 uses User Datagram Protocol (UDP) as a transport mechanism and uses ports 500 and 4500. All exchanges should begin with using UDP port 500 as the source and destination address. Although the RFC is not strict on the source port used, most implementations will use the recommended settings. Figure 2-1 illustrates the SA_INIT and IKE_AUTH exchanges with a very high-level explanation of the purpose of each.

The initiating peer will send a proposal of cryptographic algorithms that it supports, which will be used to secure the SA. A Diffie-Hellman public key value is sent, which is used to generate the shared secret. A nonce (number used once) is included in the exchange, which adds randomness into the key generation.

The responder, on receipt of the initial IKE_SA_INIT sent by the initiator, will check that it supports at least one combination of the proposed cryptographic algorithms that are to be used to create the SA. It will select the most preferred algorithms and reply with these.

The responder will check the Diffie-Hellman value received and, assuming that it supports this value, will reply with its own Diffie-Hellman public value.

When the responder has generated and sent the Diffie-Hellman parameters, it will have enough information to generate the secret keys that then protect the rest of the IKEv2 traffic.

When the initiator receives the responder’s reply containing the Diffie-Hellman parameters, it will have enough information to generate the secret keys that then protect the rest of the IKEv2 traffic.

The IKE_SA_INIT packet contains a header consisting of Security Parameter Indexes (SPIs), version number, and flags.

NAT detection can be performed in the IKE_SA_INIT exchange; if this is required a NAT_DETECTION payload will be added in the initial exchange. Figure 2-2 illustrates the IKE SA_INIT exchange.

The following describes each of the parameters of the SA_INIT exchange.

HDR: IKE header

SAi1: Sets of cryptographic algorithms proposed by initiator

SAr1: Specific of cryptographic algorithms chosen by responder

KEi: Initiator key exchange material (uses DH group with highest local priority)

KEr: Responder key exchange material

Ni: Initiator nonce

Nr: Responder nonce

CertReq: Certificate request (optional). The square brackets [ ] surrounding the CertReq payload denotes this as optional.

For modular exponential Diffie-Hellman groups, one party will create its public value using the formula

X = g^x mod p

where

g generates a subgroup of size q (where q is a prime divisor of p-1)

x is a value between 1 and q-1

p is a prime

The peer will generated its own private value y and public value Y, using the formula.

Y = g^y mod p

The value x is generated by the device and this is kept privately. If a intruder was able to retrieve this, then the shared secret could be obtained and hence all encrypted IKEv2 packets could be decrypted. The other values are defined within the RFC for the relevant Diffie-Hellman group, for Modular Exponential groups, see RFC 7296; for groups 1 and 2, RFC 3526; for groups 5, 14, 15, and16, RFC 5903; for groups 19, 20 and 21, RFC 5903; and for group 24 RFC 5114.

The public value exchange is used to create a shared secret using the formula

s = Y^x mod p

Where

s = shared S = secret

x = local private value

Y = peer’s public value

p = prime

It can be seen that Y^x mod p equals g^xy mod p equals g^yx mod p equals X^y mod p. This allows each peer to derive the same shared secret by exchanging only their public values.

Assuming that each peer is using the same Diffie-Hellman group (which is defined within the RFC describing the group used), then each peer will know the values g and p and so can construct s, when the peer’s public value (y) is received.

The initiator will generate a public Diffie-Hellman value and include this in the SA_INIT exchange, within a Key Exchange payload (denoted by KE in all diagrams). The Key Exchange payload consists of the IKE generic payload header followed by the Diffie-Hellman public value itself. The payload indicates which Diffie-Hellman group is used, and the size of the public value will correspond to this group; as a rule of thumb elliptic curve groups are smaller than modulos Diffie-Hellman groups, with some sizes being considerably different. For example, group 16, which uses a 4096-bit modulo Diffie-Hellman value, is sixteen times bigger than group 19, which uses a 256-bit elliptic curve value. However, elliptic curve groups give greater security for the small sizes and small work rate, so their use is recommended where possible.

The following example illustrates a Key Exchange payload that was taken from an SA_INIT exchange. The Diffie-Hellman group can be seen, along with the public value, which is contained within the key exchange data field.

Click here to view code image

Type Payload: Key Exchange (34)
        Next payload: Nonce (40)
        0... .... = Critical Bit: Not Critical
        Payload length: 200
        DH Group #: 1536 bit MODP group (5)
        Key Exchange Data: 973d1a029804cb52720701ce384322686c4f939aa78727e5...

The initiator is really guessing the Diffie-Hellman group that is used on the responder; the value is just sent and not negotiated. For efficiency, the initiator should use a Diffie-Hellman value that it knows that the responder will accept; otherwise expensive cryptographic calculations are performed that can be wasted. On receipt of the initiator’s SA_INIT, the responder will either accept or reject the value, depending on whether the group used by the initiator is configured locally.

Taking all other factors into consideration and assuming that the initiator sent a value that is acceptable to the responder, then the responder will generate its own Diffie-Hellman public value and reply with this. It is common for a number of values to be precalculated so that expensive cryptographic processing doesn’t occur when an initial request is received. It is also common for implementations to reuse values between connections. At this stage the responder will be able to generate the secret key from the initiator’s public Diffie-Hellman value and its own private Diffie-Hellman value.

The initiator will include the Diffie-Hellman groups that it supports within the Security Association payload; this allows the responder to select another group should the initiator’s presented public value not be supported.

If the initiator guessed wrong and the responder didn’t accept the proposed Diffie-Hellman value, the latter will respond with a Notify payload of type INVALID_KE_PAYLOAD, indicating the selected group that it wishes to use.

In this case, the initiator must retry the IKE_SA_INIT with the corrected Diffie-Hellman group (assuming that this group is supported by the initiator). The initiator must again propose its full set of acceptable cryptographic suites, because the rejection message was unauthenticated; otherwise an active attacker could trick the endpoints into negotiating a weaker suite than a stronger one that they both prefer.

Figure 2-3 shows the SA_INIT exchange increasing from two packets to four when an initiator includes a Diffie-Hellman group that the responder does not support. The second request from the Initiator contains a Diffie-Hellman group that the responder has advised that it supports in the INVALID_KE_PAYLOAD.

Additional tests are performed by some implementations (for example, Cisco IOS), when the implementation uses the checks proposed by RFC 6989, Additional Diffie-Hellman Tests for the Internet Key Exchange Protocol Version 2.

If an implementation reuses the same Diffie-Hellman values for multiple connections, then an intruder could send a malformed Diffie-Hellman public key value, which would then allow the attacker to efficiently determine the Diffie-Hellman private value the peers used. RFC 6989 actually proposes that the check be carried out regardless of whether the same Diffie-Hellman private values are reused.

When a device that supports these checks receives an IKE_SA_INIT request containing an elliptic curve public value that it supports, the host will perform a check on the received value to validate that it is not erroneous. Should the received value fail the check, then this public Diffie-Hellman value should not be used, and an INVALID_SYNTAX error notification should be sent to the peer to indicate that the received value was faulty.

The Security Association payload will contain Proposals, which are groups of cryptographic algorithms defined within Transforms; the Transforms support attributes that are negotiated for the protocols used to build an IPsec Security Association, IKE, Authentication Header, and Encapsulation Security Payload.

Table 2-1 displays the types of Transforms along with the method used.

The cryptographic algorithms used for encryption and integrity contained with a transform consist of encryption, integrity, or combined mode ciphers. Combined-mode ciphers support both encryption and integrity within the same cipher method (AES-GCM as described in RFC 4106 or AES-CCM as described in RFC 4301).

A proposal will only contain the same mode of algorithms within the transform, so only encryption and integrity algorithms could coexist within a transform, never with a combined mode algorithm. If an initiator wants to propose both combined mode ciphers and mixed ciphers, then it must include two proposals. RFC 7296 recommends using combined mode ciphers where possible.

If a peer proposes multiple proposals, it must send the preferred algorithms first.

A peer receiving one or more proposals will select the proposal with the transforms that it supports. If there are multiple transforms of the same transform types, for example transform type 1 (encryption algorithms) with transforms of 3DES, AES-CBC-128, AES-CBC-256, the receiving host can select any of these transforms (assuming that it supports them), which equates to a logical OR. If there are multiple transforms with different transform types, the selection is a logical AND of the different transform types. So if the proposal also contained transform type 3 (integrity algorithms) with MD5 and SHA-1, the receiver would select one transform of transform type 1 AND one of transform type 3.

Table 2-2 shows an example of proposed attributes within a transform.

The peer can use any of the algorithms in a mix-and-match basis, so if a peer received a request containing the transforms listed within Table 2-2, it could choose any set of algorithms depending on what is supported locally; for example:

AES-CBC-256 with AUTH_HMAC_SHA1_160 and ESN support

or

3DES with AUTH_HMAC_MD5_96 and no ESN support

or

AES-CBC-256 with AUTH_HMAC_SHA2_384 and ESN support

Note that IKEv2 requires a PRF to be included within the transform, which is used in the generation of the secret key material. IPsec does not require this, so the only time a PRF would be seen within an IKEv2 transform only when the peers are negotiating an IKEv2 SA and not an IPsec Security Association.

The SA_INIT payload will include the Diffie-Hellman public value. In addition, any other Diffie-Hellman groups that are supported by the sending device are included within the Security Association Proposal. This allows for the peer to select another Diffie-Hellman group if the received public value is not supported.

The following example illustrates a security association proposal header that displays the security association payload from an initiator of a SA_INIT exchange; each transform type can be seen, along with the transform ID that denotes the attribute proposed.

Click here to view code image

    Type Payload: Security Association (33)
        Next payload: Key Exchange (34)
        0... .... = Critical Bit: Not Critical
        Payload length: 136
        Type Payload: Proposal (2) # 1
            Next payload: NONE / No Next Payload  (0)
            0... .... = Critical Bit: Not Critical
            Payload length: 132
            Proposal number: 1
            Protocol ID: IKE (1)
            SPI Size: 0
            Proposal transforms: 14
            Type Payload: Transform (3)
                Next payload: Transform (3)
                0... .... = Critical Bit: Not Critical
                Payload length: 12
                Transform Type: Encryption Algorithm (ENCR) (1)
                Transform ID (ENCR): ENCR_AES_CBC (12)
                Transform IKE2 Attribute Type (t=14,l=2) Key-Length : 256
                    1... .... .... .... = Transform IKE2 Format: Type/Value
                    Transform IKE2 Attribute Type: Key-Length (14)
                    Value: 0100
                    Key Length: 256
            Type Payload: Transform (3)
                Next payload: Transform (3)
                0... .... = Critical Bit: Not Critical
                Payload length: 12
                Transform Type: Encryption Algorithm (ENCR) (1)
                Transform ID (ENCR): ENCR_AES_CBC (12)
                Transform IKE2 Attribute Type (t=14,l=2) Key-Length : 192
                    1... .... .... .... = Transform IKE2 Format: Type/Value
                    Transform IKE2 Attribute Type: Key-Length (14)
                    Value: 00c0
                    Key Length: 192
            Type Payload: Transform (3)
                Next payload: Transform (3)
                0... .... = Critical Bit: Not Critical
                Payload length: 12
                Transform Type: Encryption Algorithm (ENCR) (1)
                Transform ID (ENCR): ENCR_AES_CBC (12)
                Transform IKE2 Attribute Type (t=14,l=2) Key-Length : 128
                    1... .... .... .... = Transform IKE2 Format: Type/Value
                    Transform IKE2 Attribute Type: Key-Length (14)
                    Value: 0080
                    Key Length: 128
            Type Payload: Transform (3)
                Next payload: Transform (3)
                0... .... = Critical Bit: Not Critical
                Payload length: 8
                Transform Type: Pseudo-random Function (PRF) (2)
                Transform ID (PRF): PRF_HMAC_SHA2_512 (7)
            Type Payload: Transform (3)
                Next payload: Transform (3)
                0... .... = Critical Bit: Not Critical
                Payload length: 8
                Transform Type: Pseudo-random Function (PRF) (2)
                Transform ID (PRF): PRF_HMAC_SHA2_384 (6)
            Type Payload: Transform (3)
                Next payload: Transform (3)
                0... .... = Critical Bit: Not Critical
                Payload length: 8
                Transform Type: Pseudo-random Function (PRF) (2)
                Transform ID (PRF): PRF_HMAC_SHA2_256 (5)
            Type Payload: Transform (3)
                Next payload: Transform (3)
                0... .... = Critical Bit: Not Critical
                Payload length: 8
                Transform Type: Pseudo-random Function (PRF) (2)
                Transform ID (PRF): PRF_HMAC_SHA1 (2)
            Type Payload: Transform (3)
                Next payload: Transform (3)
                0... .... = Critical Bit: Not Critical
                Payload length: 8
                Transform Type: Pseudo-random Function (PRF) (2)
                Transform ID (PRF): PRF_HMAC_MD5 (1)
            Type Payload: Transform (3)
                Next payload: Transform (3)
                0... .... = Critical Bit: Not Critical
                Payload length: 8
                Transform Type: Integrity Algorithm (INTEG) (3)
                Transform ID (INTEG): AUTH_HMAC_SHA2_512_256 (14)
            Type Payload: Transform (3)
                Next payload: Transform (3)
                0... .... = Critical Bit: Not Critical
                Payload length: 8
                Transform Type: Integrity Algorithm (INTEG) (3)
                Transform ID (INTEG): AUTH_HMAC_SHA2_384_192 (13)
            Type Payload: Transform (3)
                Next payload: Transform (3)
                0... .... = Critical Bit: Not Critical
                Payload length: 8
                Transform Type: Integrity Algorithm (INTEG) (3)
                Transform ID (INTEG): AUTH_HMAC_SHA2_256_128 (12)
            Type Payload: Transform (3)
                Next payload: Transform (3)
                0... .... = Critical Bit: Not Critical
                Payload length: 8
                Transform Type: Integrity Algorithm (INTEG) (3)
                Transform ID (INTEG): AUTH_HMAC_SHA1_96 (2)
            Type Payload: Transform (3)
                Next payload: Transform (3)
                0... .... = Critical Bit: Not Critical
                Payload length: 8
                Transform Type: Integrity Algorithm (INTEG) (3)
                Transform ID (INTEG): AUTH_HMAC_MD5_96 (1)
            Type Payload: Transform (3)
                Next payload: Transform (3)
                0... .... = Critical Bit: Not Critical
                Payload length: 8
                Transform Type: Diffie-Hellman Group (D-H) (4)
                Transform ID (D-H): 1536 bit MODP group (5)
Type Payload: Transform (3)
                Next payload: NONE / No Next Payload  (0)
                0... .... = Critical Bit: Not Critical
                Payload length: 8
                Transform Type: Diffie-Hellman Group (D-H) (4)
                Transform ID (D-H): 1024 bit MODP group (2)

The following illustrates the default IKEv2 proposal from IOS, which shows the parameters that are proposed. (This output was obtained by the show crypto ikev2 proposal command.)

Click here to view code image

IKEv2 proposal: default
     Encryption : AES-CBC-256 AES-CBC-192 AES-CBC-128
     Integrity  : SHA512 SHA384 SHA256 SHA96 MD596
     PRF        : SHA512 SHA384 SHA256 SHA1 MD5
     DH Group   : DH_GROUP_1536_MODP/Group 5 DH_GROUP_1024_MODP/Group 2

The responder will select the preferred algorithm that it supports. It can be seen that the most cryptographically secure algorithms are proposed by the initiator in order, which will result in establishing the most cryptographically secure IKEv2 SA.

Because the SPI is unique, the same value must not be used for multiple connections between hosts, since the SPI is used to match incoming IKEv2 sessions and not any other attribute such as IP address, protocol, or port. Because this value is used to identify the IKEv2 session, it is sent in the IKEv2 header in the clear, even when the session has been encrypted (in the IKE_AUTH and subsequent exchanges). Although this value is sent in the clear, the SPI itself is integrity protected and cannot be tampered with by an intruder.

The value of all zeros is only used by the initiator when setting the responder’s SPI in the initial SA_INIT exchange, for this value will not be known by the initiator. The responder will set the SPI to zero if an issue with the initiator’s initial connection attempt resulted in the responder sending an INFORMATIONAL, INVALID_KE_PAYLOAD, or NO_PROPOSAL_CHOSEN payload in return. If the responder is implementing the anti-DoS cookie mechanism, the responder’s SPI will be set to all zeros.

The following packet output displays the SPI from the initiator in an SA_INIT exchange; note that the responder’s SPI is set to all zeros as the initiator does not yet know the value of this index.

Click here to view code image

Internet Security Association and Key Management Protocol
    Initiator SPI: 7803611e4b2ff28c
    Responder SPI: 0000000000000000
    Next payload: Security Association (33)
    Version: 2.0
        0010 .... = MjVer: 0x02
        .... 0000 = MnVer: 0x00
    Exchange type: IKE_SA_INIT (34)
    Flags: 0x08 (Initiator, No higher version, Request)
        .... 1... = Initiator: Initiator
        ...0 .... = Version: No higher version
        ..0. .... = Response: Request

The following packet output displays the corresponding reply from the responder, which includes both the initiator’s SPI and the responder’s.

Click here to view code image

Internet Security Association and Key Management Protocol
    Initiator SPI: 7803611e4b2ff28c
    Responder SPI: 5d1b50735fe39ffc
    Next payload: Security Association (33)
    Version: 2.0
        0010 .... = MjVer: 0x02
        .... 0000 = MnVer: 0x00
    Exchange type: IKE_SA_INIT (34)
    Flags: 0x20 (Responder, No higher version, Response)
        .... 0... = Initiator: Responder
        ...0 .... = Version: No higher version
        ..1. .... = Response: Response

The nonce must be at a minimum 128 bits in size; it can actually be up to a maximum of 2048 bits in size. The size of the nonce must be at least half the size of the output for the PRF hash function that is negotiated.

As the nonce is sent by the initiator before the PRF is decided on, if It is assumed that multiple PRFs are sent from the initiator, then the size of the nonce must be at least half the size of the largest PRF. For example, if both PRF_HMAC_MD5 and PRF_HMAC_SHA_384 were sent from the initiator, then the smallest nonce would need to be 192 bits, which is half the size of the output of PRF_HMAC_SHA-384 (384 bits).

The following packet output displays a nonce payload taken from an initiator’s request. The initiator sent a number of PRFs, including PRF_HMAC_SHA2_512, which results in a 512 hash. The size of the payload is 36 bytes; however, this size includes 4 bytes for the header, so the nonce data is 32 bytes, or 256 bits, which is half of the number of bits required for the largest PRF being proposed.

The following packet output displays the nonce payload from a SA_INIT exchange.

Click here to view code image

Type Payload: Nonce (40)
        Next payload: Notify (41)
        0... .... = Critical Bit: Not Critical
        Payload length: 36
        Nonce DATA: 559292633baf45cf133f7ceebf963608c2f481bdc715ac67...

This attack is emphasized when an implementation supports RFC 6989 and performs cryptographic checks against the received Diffie-Hellman public value to guarantee that attacks cannot be performed to compromise shared key material. These checks are very computationally expensive, and forcing the VPN headend to perform a large number of these can cause a DoS condition.

To mitigate this DoS attack, IKEv2 has a mechanism to prevent blind spoofing attacks. When a certain amount of half connections are seen, the responder can be configured to reply to any SA_INIT requests with just a notify cookie payload. The initiator will hold no state about the session after sending this cookie, but the cookie will contain information about the state of the request sent from the initiator.

The cookie is constructed as follows:

Click here to view code image

Cookie = <VersionIDofSecret> | Hash (Ni | IPi | SPIi | <secret>)

Here secret is a random value that is stored locally and changed regularly. Because this value is used in the construction of the cookie and could be used by an attacker to exploit the anti-DoS mechanism, it is a closely guarded secret. The value VersionIDofSecret is changed whenever the secret is changed. When the initiator receives the notify cookie payload, it must then reinitiate the SA_INIT to the responder, attaching the notify cookie payload received. On receipt of this payload, the responder can verify that the cookie is legitimate by reconstructing the cookie using the nonce, IP address, and SPI received from the initiator and then substituting the VersionIDofSecret and secret for the values held locally. If these match, then it can be assumed that the initiator sent a SA_INIT that resulted in this cookie being generated.

If an attacker has sent many SA_INIT messages with spoofed source IP addresses, the reply from the responder would be returned to the spoofed source IP address, which would be discarded on receipt because the spoofed host did not send this request. This behavior, therefore, makes the attack useless.

By default Cisco IOS does not have the cookie notification mechanism enabled. This mechanism can be enabled by the crypto ikev2 cookie-challenge number command.

Note that cookie notifications only prevent blind spoofing attacks and do not prevent DoS attacks conducted from hosts that use their real IP addresses. If a host initiates an SA_INIT request that results in the responder generating a cookie notification, then the initiator can simple respond to this (as per the RFC) and so the responder will then perform the expensive cryptographic processing. For this reason care should be taken when designing a VPN solution that allows connections from any IP source address.

Figure 2-4 shows cookie notification in action; the SA_INIT exchanged is increased from two packets to four.

Should the responder reject the Diffie-Hellman group proposed by the initiator and cookie notification is activated, then the exchange will increase from four to six packets, Figure 2-5 shows this occurring. The responder will reply to the initiator with a cookie notification, the initiator will then resend the SA_INIT with the cookie included, and the responder will then reject the Diffie-Hellman group and propose a new group. The initiator will then send the SA_INIT again with the correct Diffie-Hellman group and the cookie.

This behavior is an improvement over that of IKEv1. In IKEv1 the subject name of the CA was included, which could be duplicated. Having an SHA-1 hash removed this limitation.

The following packet output displays the certificate request payload. There are five hashes sent, so this device will trust five CAs.

Click here to view code image

Type Payload: Certificate Request (38)
        Next payload: Notify (41)
        0... .... = Critical Bit: Not Critical
        Payload length: 105
        Certificate Type: Hash and URL of X.509 certificate (12)
        Certificate Authority Data: e27f7bd877d5df9e0a3f9eb4cb0e2ea9efdb6977
        Certificate Authority Data: 3c76492ca10b9f850e2fd6fbae0d362daa2b9c01
        Certificate Authority Data: d0c52226ab4f4660ecae0591c7dc5ad1b047f76c
        Certificate Authority Data: 27f3c8151e6e9a020916ad2ba089605fda7b2faa
        Certificate Authority Data: a6031d7fcabdb29140c6cb82361f6b988fddbc29

This allows the peer to send a 160-bit SHA-1 hash of the certificate along with a URL indicating where the certificate can be obtained. This allows the receiving device to obtain the certificate out of band and does not require potential fragmentation of IKEv2 packets due to large certificates.

The following packet output displays the HTTP_CERT_LOOKUP_SUPPORTED payload. This allows the peer to the send its certificate via a URL.

Click here to view code image

Type Payload: Notify (41)
        Next payload: NONE / No Next Payload  (0)
        0... .... = Critical Bit: Not Critical
        Payload length: 8
        Protocol ID: IKE (1)
        SPI Size: 0
        Notify Message Type: HTTP_CERT_LOOKUP_SUPPORTED (16392)

This method of authentication is not widely used and is not supported by all software clients.

Four cryptographic algorithms are negotiated in the Security Association proposals: an encryption algorithm, an integrity protection algorithm, a Diffie-Hellman group, and a pseudo-random function (PRF).

The two parties must have agreed on the algorithms used, else each party would not be able to generate the key material used to encrypt and decrypt secure communications with the other peer. The initiator would have sent the proposed algorithms, and the responder would have selected the most preferred algorithm that it supports.

A value known as the SKEYSEED is calculated from the nonces exchanged during the IKE_SA_INIT exchange and the Diffie-Hellman shared secret established during that exchange; the calculation is;

SKEYSEED = prf(Ni | Nr, g^ir)

(The | symbol denotes concatenation). Ni and Nr are the nonce from the initiator and responder respectively, and g^ir is the shared secret from the ephemeral Diffie-Hellman exchange.

The PRF is a pseudo-random function that was agreed upon during the IKEv2 exchange; on Cisco IOS MD5 (PRF_HMAC_MD5), SHA-1 (PRF_HMAC_SHA1), SHA256 (PRF_HMAC_SHA2_256), SHA384 (PRF_HMAC_SHA2_2384), or SHA512 (PRF_HMAC_SHA2_512) PRF can be configured. MD5 and SHA-1 are described in RFC 2104, and the SHA-2 variants are covered in RFC 4868. The PRF is actually a keyed-hash message authentication code (HMAC). This involves a cryptographic hash function combined with a secret cryptographic key. This should not be confused with the HMAC used to protect the integrity of IPsec.

RFC 2104 and RFC 4868 define the use of the HMAC in IKEv2. With H as the cryptographic hash function, K the authentication key, and B the block size, ipad and opad are defined as:

ipad = the byte 0x36 repeated B times

opad = the byte 0x5C repeated B times

To compute an HMAC over the data text we perform

H(K XOR opad, H(K XOR ipad, text))

When the SKEYSEED is calculated, the authentication key is generated by concatenating the nonces, Ni and Nr. Although this key would be known to an attacker (as the nonces are exchanged in the SA_INIT exchange in the clear), the data that is used as the text input (g^ir) would not be known, because it is calculated from the Diffie-Hellman exchange and can be assumed to be cryptographically secure; therefore this calculation can be considered secure.

The PRF used for the SKEYSEED generation will produce a fixed-length output, for this is required of the authentication key to be used for the next PRF. This can be seen by the omission of the “+” symbol when this is described in RFC 7296.

The PRF will take a variable-length input and produce a fixed-length output; the output size will vary, depending on the algorithm used.

Table 2-3 defines the PRF algorithms, the block size used, and the output generated.

Once the SKEYSEED has been generated, it is then used as the authentication key input into another PRF that is then used to derive the key material for the IKEv2 SA. The calculation is:

prf+ (SKEYSEED, Ni | Nr | SPIi | SPIr)

This function is used to generate a string of key material that will be used for various cryptographic functions that protect the IKEv2 SA. Because the PRF outputs a fixed-length value, if the length of the key material required is longer than the output of the PRF, multiple PRF’s must be used. The inclusion of the “+” symbol to the PRF denotes that a variable-length output is required.

The calculation is shown below:

prf+ (K,S) = T1 | T2 | T3 | T4 | ...

where:

T1 = prf (K, S | 0x01)

T2 = prf (K, T1 | S | 0×02)

T3 = prf (K, T2 | S | 0×03)

T4 = prf (K, T3 | S | 0×04)

Note that K = SKEYSEED and S = Ni | Nr | SPIi | SPIr

The key material generated is a string that can be split to gain the following values

{SK_d | SK_ai | SK_ar | SK_ei | SK_er | SK_pi | SK_pr }

SK_d is used for deriving new keys for the Child SAs.

SK_ai and SK_ar are used as a key to the integrity protection algorithm for authenticating the component messages of subsequent exchanges.

SK_ei and SK_er are used for encrypting (and of course decrypting) all subsequent IKEv2 payloads.

SK_pi and SK_pr, are used as the key input when authenticating an AUTH payload. The lengths of SK_d, SK_pi and SK_pr must be the preferred key length of the PRF agreed upon.

Once the key material has been generated (after the SA_INIT), all IKEv2 messages (IKE_AUTH, INFORMATION, CREATE_CHILD_SA, etc.) are protected by the cryptographic mechanisms negotiated and key material generated.

This payload will include an initialization vector (IV) that is used as the input to the encryption function. This IV is sent in the clear and must be unique for each payload. The encrypted data will contain the remaining IKEv2 payloads in encrypted format. There is a possibility that padding might be required to allow the encryption to fall on a bit boundary; this padding will be added if required. If a combined mode cipher is not used for encryption, an integrity checksum is added at the end of the header; the length of this checksum corresponds to the integrity algorithm used.

The following example displays an encrypted and authenticated payload. The initialization vector can be seen, along with the encrypted data. At the end of the payload is the integrity checksum, which protects the whole of the IKE payload, including the clear text headers and the encrypted data, from being modified.

Click here to view code image

    Type Payload: Encrypted and Authenticated (46)
        Next payload: Security Association (33)
        0... .... = Critical Bit: Not Critical
        Payload length: 160
        Initialization Vector: 36a1dd71fbeaaa683c2254e8530aa781 (16 bytes)
        Encrypted Data (128 bytes)
            Padding (11 bytes)
            Pad Length: 11
        Integrity Checksum Data: ef3e7c44eff24d09902ebcfc (12 bytes)[correct]

Figure 2-6 shows the IKE_AUTH exchange.

The following describes each of the parameters of the IKE_AUTH exchange.

SK { ... }: Payload between { } is encrypted and integrity protected

IDi: Initiator identity

IDr: Responder identity

Cert: Initiator certificate (optional)

CertReq: Certificate request (optional)

AUTH: Initiator authentication data (not present if initiator authenticates via EAP)

SAi2: Child SA transforms proposed by initiator

SAr2: Child SA transforms chosen by responder

TSi/TSr: Child SA traffic selectors (src/dst proxies)

The following shows an IKE_AUTH message. The headers can be seen with the IKE version, SPI, and flags; however the payload is encrypted, so it cannot be seen by someone who lacks the keys to decrypt it.

Click here to view code image

User Datagram Protocol, Src Port: 500 (500), Dst Port: 500 (500)
Internet Security Association and Key Management Protocol
    Initiator SPI: a3ae32c968f6ccf0
    Responder SPI: fc1c21ef24ef360c
    Next payload: Encrypted and Authenticated (46)
    Version: 2.0
    Exchange type: IKE_AUTH (35)
    Flags: 0x08 (Initiator, No higher version, Request)
    Message ID: 0x00000001
    Length: 572
    Type Payload: Encrypted and Authenticated (46)

This identity will be validated by the peer device when authentication is performed. When preshared keys are used, each peer should have a database of shared keys that relate to an identity. When a device sends its identity along with authentication data, the receiving peer can validate that the peer is who it claims to be by extracting the relevant shared key from the database. When digital signatures are used as a means of authentication, the distinguished name can be extracted from the certificate and sent as the identity in Distinguished Encoding Rules (DER) format. This identity can be checked against the presented certificate and validated when the cryptographic signature checks are performed.

RFC 7296 does not actually stipulate that a device that uses a digital signature algorithm must use an identity taken from the Certificate payload. The identity can be anything: for example, an IP Address, FQDN, or even email address. Likewise, if pre-shared keys are used, an identity of FQDN or email address can be used, or the identity type of IPv4 or IPv6 could be used. However, it does not have to be.

Table 2-4 lists the identities supported by RFC 7296.

Unless the authentication method in use is EAP, the initiator will always reveal its identity before the responder.

Each party must be configured to accept connections from a peer presenting the specified identity.

Although the identity is protected within the IKE_AUTH exchange, it is worth nothing that an inline intruder could reply to an initiator’s SA_INIT request by spoofing the responder’s IP address. As long as the attacker supported the cryptographic algorithms and Diffie-Hellman parameters proposed, the attacker would be able to successfully decode the received IKE_AUTH and so view the initiators identity.

Three methods of authentication are used in IKEv2: signature, pre-shared key, and EAP. Each peer within an exchange can use a local authentication method, so the initiator could use pre-shared key, and the responder could use signature.

It is a rule that if EAP is used, the responder must use signature-based authentication.

Authentication data is included within an Authentication payload. This payload contains the authentication method used along with the authentication data that is used to validate the device sending this data.

The Diffie-Hellman exchange is vulnerable to a man-in-the-middle attack, where an attacker can intercept messages from both parties and reply with its own values. Therefore the authentication exchange includes attributes that uniquely identify the hosts in the session and the attributes relating to this such as the IKE Identity, nonce, and SPI.

Should the initiator use signature-based authentication, then the signed octets can be described as:

Click here to view code image

InitiatorSignedOctets = RealMessage1 | NonceRData | MACedIDForI    GenIKEHDR = [
four octets 0 if using port 4500 ] | RealIKEHDR
RealIKEHDR =  SPIi | SPIr |  . . . | Length
RealMessage1 = RealIKEHDR | RestOfMessage1
NonceRPayload = PayloadHeader | NonceRData
InitiatorIDPayload = PayloadHeader | RestOfInitIDPayload
RestOfInitIDPayload = IDType | RESERVED | InitIDData
MACedIDForI = prf(SK_pi, RestOfInitIDPayload)

Note that SK_pi is generated earlier from the SKEYSEED material.

The initiator signs the first message (the IKE_SA_INIT request), starting with the first octet of the first SPI in the header and ending with the last octet of the last payload. Appended to this (for purposes of computing the signature) are the responder’s nonce Nr, and the value prf(SK_pi, IDi). It is critical to the security of the exchange that each side sign the other side’s nonce to add randomness to the exchange.

When the responder receives these signed octets, it can decrypt these using the related public key that is contained within the certificate presented by the initiator in the certificate payload and can then verify that the holder of the presented certificate is in fact the true owner.

Should the responder use signature-based authentication, then the signed octets can be described as:

Click here to view code image

ResponderSignedOctets = RealMessage2 | NonceIData | MACedIDForR    GenIKEHDR = [
four octets 0 if using port 4500 ] | RealIKEHDR
RealIKEHDR =  SPIi | SPIr |  . . . | Length
RealMessage2 = RealIKEHDR | RestOfMessage2
NonceIPayload = PayloadHeader | NonceIData
ResponderIDPayload = PayloadHeader | RestOfRespIDPayload    RestOfRespIDPayload =
IDType | RESERVED | RespIDData
MACedIDForR = prf(SK_pr, RestOfRespIDPayload)

When the initiator receives these signed octets, it can decrypt these using the related public key that is contained within the certificate presented by the responder and verify that the holder of the presented certificate is in fact the true owner.

The method for a peer to prove authenticity is for it to provide the output of a pseudorandom function (negotiated from the SA_INIT exchange) containing attributes from the SA_INIT and IKE_AUTH exchanges plus the shared secret.

For the initiator:

Click here to view code image

AUTH = prf( prf(Shared Secret, "Key Pad for IKEv2"), <InitiatorSignedOctets>)

where the InitiatorSignedOctets are the same as signature based authentication.

The initiator will send the value generated for AUTH as the authentication data in the authentication payload.

For the responder:

Click here to view code image

AUTH = prf( prf(Shared Secret, "Key Pad for IKEv2"), <ResponderSignedOctets>)

where ResponderSignedOctets are the same as signature-based authentication.

The Initiator will send the value generated for AUTH as the authentication data in the authentication payload.

It is worth noting that when a shared secret is used, if the initiator is tricked into connecting to a rogue VPN headend or to a MITM masquerading as the true responder, when the initiator sends the authentication data an attacker will know all attributes apart from the shared secret. An attacker would be able to capture the AUTH payload and perform an offline brute-force attack, entering the correct (known) data for <ResponderSignedOctets> and the string “Key Pad for IKEv2” while substituting values for the shared secret (for example, using a dictionary attack) until the same value matched. If the shared secret was a weak value that used a dictionary word or a string with little entropy, this would be easily breakable with current computing power.

As IKEv2 can allow asymmetric authentication, it should be noted that one peer could use certificate-based authentication, while the other peer uses shared key, or both parties could use separate shared secrets.

When a host uses shared-key or signature-based authentication, the Authentication payload contains data to authenticate that validity of the host. As EAP is a separate protocol to IKEv2, should a host wish to authenticate using EAP, then it will exclude the Authentication payload from the IKE_AUTH exchange. RFC 7296 states that the initiating host includes an identification payload, which contains the identity that the host is claiming to be. This identity will be proved when using EAP or just used for AAA purposes, EAP will actually use a second Identity.

Figure 2-7 shows the IKE_AUTH exchange when using EAP where the IKE identity is used as the EAP identity.

Cisco IOS allows for the EAP identity to be queried by the responder by using the query-identity command. In this case the identity presented by the initiator will not be used, but instead the identity will be queried within the EAP exchange. This overcomes limitations in cases when clients are required to request an EAP identity request before any other EAP requests. Microsoft Windows 7 is an example of such a client.

Figure 2-8 shows the IKE_AUTH exchange when EAP is used with the query-identity command configured. Rather than using the IKE Identity that is received from the initiator, the responder will reply to the IKE_AUTH with a EAP-Request for the EAP Identity; this allows for separate IKE and EAP identities to exist for a device.

If the responder is willing to use an EAP method, it will include an EAP payload (containing an EAP-Request) in the response of the IKE_AUTH exchange and defer sending the SA and traffic selectors until initiator authentication is complete. These will be sent in a subsequent IKE_AUTH exchange.

It is interesting to note that when EAP is used, although the initiator has revealed its identity but not proven this using the EAP exchange, the responder will reveal its identity.

If we assume a minimal EAP exchange, the next exchange from the initiator will contain the EAP response. Assuming that the initiator provided valid authenticity then the responder will send an EAP Success message. The initiator will then need to include the AUTH payload containing material to authenticate itself. The method used to generate the Authentication data is the same as that used to create a shared secret; however, because there are two types of EAP authentication (key-generating and non-key-generating), the method for authentication changes slightly. For key-generating authentication, the shared secret is substituted with the master session key that was generated from the EAP exchange. For non- key-generating authentication, SK_pi and SK_pr are replaced with the shared secret in the authentication material generation.

The initiator will send the traffic selectors containing traffic that it will look to protect and also traffic selectors of traffic it expects to receive from the peer device. Assuming that the responder accepts these traffic selectors, it would respond with a mirror image of the proposed traffic selectors that it received.

Each traffic selector consists of a traffic selector type that denotes either IPv4 or IPv6, a range of IP addresses (IPv4 or IPv6), a protocol identifier or ID, and a range of ports that will be used to create the unidirectional IPsec Security Association.

The range of IP addresses consists of two addresses, a beginning and an ending address; any other addresses that fall within this range will be included within the SA.

The protocol ID defines the IP protocol number that represents the IP protocol that is being transported, for example, 6 for TCP or 17 for UDP. 0 denotes that all protocols shall be encrypted.

The full list of IP protocol numbers can be found at;

http://www.iana.org/assignments/protocol-numbers/protocol-numbers.xhtml

The range of ports consists of a start and end port number; any ports in between will be included. As ICMP does not, strictly speaking, use port numbers but type and code values, these are treated as a single 16-bit integer port number, with type in the most significant eight bits and code in the least significant eight bits.

The following example displays the traffic selectors from an initiator. In this example, all IPv4 traffic from the 192.168.2.0/24 subnet will be protected going to the peer subnet 192.168.1.0/24. The protocol ID is set to zero, which denotes all protocols, and the port range is set to all ports (any value between 0 and 65535). This configuration on Cisco IOS would only be possible using a crypto map approach.

Click here to view code image

Type Payload: Traffic Selector - Initiator (44) # 1
                    Next payload: Traffic Selector - Responder (45)
                    0... .... = Critical Bit: Not Critical
                    Payload length: 24
                    Number of Traffic Selector: 1
                    Traffic Selector Type: TS_IPV4_ADDR_RANGE (7)
                    Protocol ID: Unused
                    Selector Length: 16
                    Start Port: 0
                    End Port: 65535
                    Starting Addr: 192.168.2.0 (192.168.2.0)
                    Ending Addr: 192.168.2.255 (192.168.2.255)

Type Payload: Traffic Selector - Responder (45) # 1
                    Next payload: NONE / No Next Payload  (0)
                    0... .... = Critical Bit: Not Critical
                    Payload length: 24
                    Number of Traffic Selector: 1
                    Traffic Selector Type: TS_IPV4_ADDR_RANGE (7)
                    Protocol ID: Unused
                    Selector Length: 16
                    Start Port: 0
                    End Port: 65535
                    Starting Addr: 192.168.1.0 (192.168.1.0)
                    Ending Addr: 192.168.1.255 (192.168.1.255)

IKEv2 actually allows the initiator to send a set of traffic selectors and the responder to select a sub-set of these to use. This is not a common case; however, it should be noted.

Note that Cisco does not allow for multiple traffic selectors to exist under an IPsec Security Association. So for every pair of traffic selectors, a separate IPsec Security Association is needed.

When GRE is used to encapsulate IPsec traffic, the GRE traffic will be sourced from the GRE local transport address (also known as the tunnel source address), encapsulated in IPsec, and sent to the tunnel destination. As the traffic selector defines what traffic is to be encrypted, this will contain GRE traffic from the tunnel source to the tunnel destination. The following example displays the traffic selectors used in an IPsec GRE session between two IPv6 peers, 2003::3 and 2007::14.

Click here to view code image

Type Payload: Traffic Selector - Initiator (44) # 1
                    Next payload: Traffic Selector - Responder (45)
                    0... .... = Critical Bit: Not Critical
                    Payload length: 24
                    Number of Traffic Selector: 1
                    Traffic Selector Type: TS_IPV6_ADDR_RANGE (8)
                    Protocol ID: 47
                    Selector Length: 40
                    Start Port: 0
                    End Port: 65535
                    Starting Addr: 2003::3 (2003::3)
                    Ending Addr: 2003::3 (2003::3)

Type Payload: Traffic Selector - Responder (45) # 1
                    Next payload: NONE / No Next Payload  (0)
                    0... .... = Critical Bit: Not Critical
                    Payload length: 24
                    Number of Traffic Selector: 1
                    Traffic Selector Type: TS_IPV6_ADDR_RANGE (8)
                    Protocol ID: 47
                    Selector Length: 40
                    Start Port: 0
                    End Port: 65535
                    Starting Addr: 2007::14 (2007::14)
                    Ending Addr: 2007::14 (2007::14)

This is the prefect remedy if a host crashes and restarts or if it is manually reset for some reason, or in any case in which the host will lose all information about the previous IKEv2 SA. If such cases, there is no point in the peer sending encrypted IKEv2 and Encapsulation Security Payload/Authentication Header traffic to the host that has restarted, because this data will not be correctly decrypted (because no session keys are held) and so traffic will be discarded, wasting network bandwidth and resource. Initial contact is performed when a host sends an INITIAL_CONTACT notification within the IKE_AUTH exchange; on successful authentication, the peer that received the INITIAL_CONTACT payload will remove any existence of any previous IKEv2 SA state along with any IPsec sessions that relate to that peer, asserting that the latest IKEv2 SA is the only IKEv2 SA currently active between both parties.

The following packet output displays the INITIAL_CONTACT payload, notice that this is contained within a Notify payload.

Click here to view code image

Type Payload: Notify (41)
                    Next payload: Identification - Responder (36)
                    0... .... = Critical Bit: Not Critical
                    Payload length: 8
                    Protocol ID: RESERVED (0)
                    SPI Size: 0
                    Notify Message Type: INITIAL_CONTACT (16384)

1. For creating additional IPsec Security Associations in the initial IKEv2 exchange, where the CREATE_CHILD_SA is included directly after the IKE_AUTH exchange if the system requires that more than a single IPsec be built.

2. When the IPsec Security Association is rekeyed where one of more new IPsec Security Association’s are created.

3. If the IKEv2 SA is required to be rekeyed and a new IKEv2 SA is established.

It is worth noting that when new IPsec Security Associations or IKEv2 SAs are created, no authentication material is exchanged. Once the IKEv2 SA is established after it has been successfully authenticated, it will never be authenticated again (unless the IKEv2 SA is cleared and renegotiated using the SA_INIT/IKE_AUTH exchanges).

The exchange of CREATE_CHILD_SA may be initiated by either party after the initial exchanges are completed.

When a IKEv2 SA or IPsec Security Association is required to be rekeyed, the new SA will (or should) become active before the current SA expires. This allows for a transition from the current SA to the new SA.

Keying material for them is generated as follows:

Keymaterial = prf+(SK_d, Ni | Nr)

where Ni and Nr are the nonces from the IKE_SA_INIT exchange if this request is the first Child SA created or the fresh Ni and Nr from the CREATE_CHILD_SA exchange if this is a subsequent creation.

For CREATE_CHILD_SA exchanges that include an optional Diffie-Hellman public key exchange, the keying material is defined as:

Keymaterial = prf+(SK_d, g^ir (new) | Ni | Nr)

where g^ir (new) is the shared secret from the ephemeral Diffie-Hellman exchange.

The “+” appended to the end of the PRF denotes that the output of the PRF can be bit string that is potentially longer than the output of the PRF.

When a rekey occurs, cryptographic algorithms are exchanged using the Security Association payloads. Cisco IOS uses the same algorithms that were used for the parent SA. Nonces are exchanged to add freshness to the generation of key material, and if it is configured, an optional Diffie-Hellman exchange is performed to generate a new shared secret. The traffic that is to be protected by this new SA is exchanged in traffic selector payloads.

When an IPsec Security Association is rekeyed, the same method of generating key material is performed as when a Child SA is created using a CREATE_CHILD_SA exchange. Please refer to the previous description within IPsec Security Association creation for details.

Once the IPsec Security Association has been rekeyed, the previous functioning IPsec Security Association will be deleted by means of an INFORMATIONAL exchange.

Each peer will exchange the cryptographic algorithms within the Security Association payload, nonces for freshness of the generation of key material, and also new Diffie-Hellman public key values to generate a new shared secret.

A new set of initiator and responder SPIs are supplied in the SPI fields in the proposal structures within the SA payloads. Note that the traffic selector payloads are not required when rekeying an IKEv2 SA, for no IPsec Security Associations are created.

The SKEYSEED for the new IKE SA is computed using SK_d from the existing IKEv2 SA as follows:

SKEYSEED = prf(SK_d (old), g^ir (new) | Ni | Nr)

The SKEYSEED can then be used to generate specific key material as needed.

Once both parties have successfully performed the CREATE_CHILD_SA exchange, the new IKEv2 SA can be used.

Any Child SA’s that were created by the old IKEv2 SA will be transferred to the new (recently created) IKEv2 SA.

Once the IKEv2 SA has been rekeyed, the old SA will be deleted by either peer sending an INFORMATIONAL exchange.

Note that no authentication occurs when an IKEv2 SA is rekeyed. RFC 4739, Multiple Authentication Exchanges in the Internet Key Exchange (IKEv2) Protocol, describes a method for reauthentication in IKEv2; however this is not implemented by Cisco IOS.

The IKEv2 header will always begin with the Security Parameter Indexes; this will allow the receiving host to identify the IKEv2 session as the source IP address can be changed via a NAT device, and also multiple IKEv2 sessions can coexist between the same peers using the same 5 tuple (local and remote IP address, protocol and ports), with each session identified by the Security Parameter Index.

After the IKEv2 header will be a number of IKEv2 payloads, and the payload type is defined by the Next Header field. This allows an IKEv2 packet to contain multiple payloads.

The IKEv2 header will contain a major version number which should be set to 2 (being IKEv2), there is also a minor version number which at the time of writing would be set to 0.

The Exchange Type denotes the type of exchange: SA_INIT, IKE_AUTH, CREATE_CHILD, or INFORATIOMAL. The data for these exchange types is contained in the latter part of the packet.

Each packet is numbered, which is denoted by the Message ID field. This is always 0 for the SA_INIT exchange and will increase by 1 for each subsequent exchange. It should be noted that the counter will increase for each exchange, so even if the SA_INIT exchange contains the Cookie payload and increases the number of packets from two to four, the numbering will still be set to 0 in the Message ID field for all packets sent. The counter is used with IKEv2 windowing; the window size will set a fixed number of messages that can be in flight at any given time.

The counter will be reset to 0 when the IKEv2 SA is rekeyed.

The numbering of packets allows each peer to track the request-response nature of IKEv2 and allows for retransmissions to easily be identified.

The following UDP output displays an IKEv2 SA_INIT exchange; this is of course encapsulated in UDP using port 500. The parameters for the IKEv2 header can be seen.

Click here to view code image

User Datagram Protocol, Src Port: 500 (500), Dst Port: 500 (500)
    Source Port: 500 (500)
    Destination Port: 500 (500)
    Length: 408
    Checksum: 0xc089
Internet Security Association and Key Management Protocol
    Initiator SPI: 9ff10b12e411fc0f
    Responder SPI: 0000000000000000
    Next payload: Security Association (33)
    Version: 2.0
        0010 .... = MjVer: 0x02
        .... 0000 = MnVer: 0x00
    Exchange type: IKE_SA_INIT (34)
    Flags: 0x08 (Initiator, No higher version, Request)
        .... 1... = Initiator: Initiator
        ...0 .... = Version: No higher version
        ..0. .... = Response: Request
    Message ID: 0x00000000
    Length: 400

There is actually one case where an INFORMATIONAL exchange will not contain any payloads; in this case it is used as a keepalive packet to check that the peer is up and active.

An INFORMATIONAL exchange that relates to an established IKEv2 SA will be cryptographically protected by the algorithms used to protect the SA, so the exchange will be sent after the IKE_AUTH exchange has occurred.

The exception to all IKEv2 messages being in pairs occurs when an INFORMATIONAL message is sent when IPsec traffic is received from a peer and the receiving peer does not have a matching IPsec Security Association. All other INFORMATIONAL exchanges consist of a pair of messages, with the second acknowledging the first.

http://www.iana.org/assignments/ikev2-parameters/ikev2-parameters.xhtml#ikev2-parameters-14

The INFORMATIONAL exchange containing the Delete payload will also occur should a device have to proactively bring the IKEv2 SA down; for example if an IKEv2 SA is manually cleared on a device or if the corresponding tunnel interface is shut down, this will trigger the INFORMATIONAL exchange containing a Delete payload to notify the peer that the session has been destroyed.

The following packet output displays an INFORMATIONAL exchange being used to delete an IPsec Security Association. The IPsec SPI can be seen as cb989cce.

Click here to view code image

Internet Security Association and Key Management Protocol
    Initiator SPI: 1739c43d75f18743
    Responder SPI: 1f9bde873d9281f5
    Next payload: Encrypted and Authenticated (46)
    Version: 2.0
    Exchange type: INFORMATIONAL (37)
    Flags: 0x08 (Initiator, No higher version, Request)
    Message ID: 0x00000005
    Length: 76
    Type Payload: Encrypted and Authenticated (46)
        Next payload: Delete (42)
        0... .... = Critical Bit: Not Critical
        Payload length: 48
        Initialization Vector: 459cee48eae9966ac0be082687da717f (16 bytes)
        Encrypted Data (16 bytes)
        Decrypted Data (16 bytes)
            Contained Data (12 bytes)
                Type Payload: Delete (42)
                    Next payload: NONE / No Next Payload  (0)
                    0... .... = Critical Bit: Not Critical
                    Payload length: 12
                    Protocol ID: ESP (3)
                    SPI Size: 4
                    Port: 1
                    Delete SPI: cb989cce
            Padding (3 bytes)
            Pad Length: 3
        Integrity Checksum Data: ccb4a8512ff5ef126611b4b3 (12 bytes)[correct]

Similar to Encapsulation Security Payload and Authentication Header SAs, IKE SAs are also deleted by sending an informational exchange. Deleting an IKE SA implicitly closes any remaining Child SAs negotiated under it. The response to a request that deletes the IKE SA is an empty INFORMATIONAL response. The response satisfies the request/response pairing within IKEv2 and ensures that a peer is certain that its peer has deleted the SA.

In IKEv2, deleting a pair of IPsec Security Associations and an IKEv2 SA can take up to six packets: a pair to delete the inbound IPsec Security Association, a pair to delete the outbound IPsec Security Association, and a pair to delete the IKEv2 SA.

IPsec Security Associations are created in pairs, with one SA being formed in each direction. When an IPsec Security Association is to be removed, both SAs in the pair must be deleted. Each endpoint must delete its incoming SAs and allow the other endpoint to close the other SA in each pair. To delete an IPsec Security Association, an INFORMATIONAL exchange with one or more Delete payloads is sent listing the SPIs (as they would be expected in the headers of inbound packets) of the SAs to be deleted. On receipt of this exchange, the peer must close the specified SA(s).

RFC 7296 describes an exchange in which a client can gain an IP address from the headend as if it were on a local network, although the use of configuration payload is not just limited to assigning IP addresses; it also allows a client that has securely established a connection to a headend to then receive configuration parameters via IKEv2, which can be used for remote-access style deployments. The term IPsec Remote Access Client (IRAC) is used to denote the client and IPsec Remote Access Server (IRAS) the head server.

The (IRAC) initiator can request various parameters in the IKE_AUTH exchange by including a Config Request (CFG_REQUEST) payload containing the parameters it wishes to receive. The responder (IRAS) can then provide the requested parameter details in a Config Reply (CFG_REPLY) payload. The structure of Config Reply consists of the requested parameter(s) and the value(s) returned by the responder.

In both cases, the Config Payload is always sent prior to the Security Association payload.

Any IKEv2 device also has the ability to send configuration parameters to the peer, which is achieved using a Config Set (CFG_SET) payload. This payload will contain the type of configuration parameters that the device is sending to the peer and the value of the parameter. Assuming that the peer accepts these parameters, it will reply with a Config Acknowledge (CFG_ACK) payload denoting which parameters it has accepted. Table 2-5 outlines the configuration payload attributes.

Cisco IOS allows for a number of proprietary attributes to be sent within the IKEv2 exchange using the configuration payload. These attributes have a value between 16384 and 32767, being private values.

The use of keepalives allows for failover when designing redundancy into VPN solutions. With regard to the configuration of the keepalive timer, thought should be given to how many IKE sessions the host will have and what overlay protocols are running over these. IKE and IPsec sessions are expensive to create and maintain. When routing protocols and multiple IKE sessions are used, the routing protocol running within the overlay network should have more aggressive keepalive timers than the keepalive mechanism used by IKEv2. This then allows for the routing protocol to reconverge without having to pull down the IKE session should connectivity between hosts fail for a short period of time.

It is always prudent to use IKEv2 keepalives, for without these, if connectivity fails between two peers, the IKE SA and associated IPsec Security Associations would still be consuming resources on both peers; however they would no longer be productively used.

If IKEv2 keepalives are enabled in a remote access architecture, ensure that there is sufficient capacity on the VPN gateway. In situations where many remote access clients use the same VPN gateway hardware, if the keepalive time is set to a very aggressive value, then the queue for this traffic can become congested at peak times. For this reason, timers should be tuned to ensure that there is adequate capacity on the headend and monitored to ensure that IKE control plane traffic can be dispatched without issue.

When Network Address Translation (NAT) is used between two IKEv2 peers, the resulting IPsec Security Association, rather than using the Encapsulation Security Payload protocol, will be encapsulated within the User Datagram Protocol (UDP port 4500). RFC 3715, IPsec-Network Address Translation (NAT) Compatibility Requirements, describes how NAT entries on a gateway will have a finite lifetime. This entry is refreshed when traffic is received on the NAT gateway that matches the NAT entry; for this reason NAT-T keepalives can be sent by peers to keep the corresponding NAT entry refreshed in the NAT gateway. RFC 3948, UDP Encapsulation of IPsec Encapsulation Security Payload Packets, describes the use of encapsulating this traffic. These keepalives are not secured in any way and do not contain any protected data. As these packets are not encrypted, they can be seen with sniffing tools such as Wireshark or even with a verbose debug, the indication being a single byte payload with the value 0xFF.

Figure 2-9 shows the format of a UDP header when the NAT-T keepalive is in use. Note the single byte payload of 0xFF.

The initial exchange usually consists of two request/response pairs. Should DoS protection be required, this will increase the exchange by two pairs. Should the responder not select the Diffie-Hellman group proposed by the initiator, it will be rejected and advised to use another group, resulting in an additional two exchanges.

If the initiator proposed an invalid group and cookie challenge was enabled on the responder, the SA_INIT exchange would increase from two exchanges to six.

The IKE_AUTH exchange in its minimal form can consist of a single request-response pair; however, this can grow to many pairs. If EAP is used, then the IKE_AUTH exchange will minimally be six exchanges. RFC 7296 states that if EAP is used, IKE_AUTH must support at least 10 exchanges. Each additional CHILD_SA created will incur an additional exchange pair.

Nodes that are behind a NAT device have IP addresses that are not globally unique, but rather are assigned from some space that is unique within the network behind the NAT device. These will be commonly allocated RFC 1918 private address in the ranges

10.0.0.0/8

172.16.0.0/12

192.168.0.0/16

Figure 2-10 shows two Encapsulation Security Payload packets, the first being sent by a device, which is described as pre-NAT, and the second packet having the source and destination IP addresses changed via a NAT device.

Creating an IPsec connection through a NAT device introduces a number of problems:

If the IPsec connection should use Encapsulation Security Payload with transport mode, and the internal protected data uses either TCP or UDP, then changing the IP address(s) on packets will cause the TCP or UDP checksums to fail, because these have a dependency on the IP source and destination addresses, which are included within the pseudo-header checksum calculation.

If Authentication Header is used, all parts of the packet are integrity protected; when NAT is used on a Authentication Header packet it will result in the received Authentication Header ICV calculation checksums being changed. This checksum is included in the integrity check, so changing it will break the integrity validation. This will occur for Authentication Header in both transport mode and tunnel mode.

When using Encapsulation Security Payload in tunnel mode, a NAT device can struggle to generate a NAT translation because Encapsulation Security Payload is a stateless protocol. It is common for NAT devices to use the transport protocol and ports in the creation of the NAT cache. As Encapsulation Security Payload does not have the concept of ports, like protocols such as UDP or TCP, some NAT devices cannot create a cache for Encapsulation Security Payload traffic. Some NAT devices will use the SPI in the Encapsulation Security Payload header to maintain state for the connectionless setting; however, not all NAT devices have this ability. It is also common for legacy firewall devices to only allow TCP or UDP traffic and deny any other protocol, including Authentication Header or Encapsulation Security Payload.

To overcome the limitations with NAT devices and the use of Encapsulation Security Payload, Network Address Detection was developed to detect the use of NAT between IPsec peers. If NAT is detected between peers, the IKEv2 and IPsec session would be encapsulated in User Datagram Protocol (IP protocol 17) segments using port 4500, which is denoted in Figure 2-11; this would allow for easy translation by a NAT device.

When NAT-T is used, both IKE and Encapsulation Security Payload are encapsulated within UDP port 4500. For the receiving host to differentiate between both, there is a method to distinguish Encapsulation Security Payload from IKE. For Encapsulation Security Payload traffic, which is encapsulated within UDP, the UDP checksum will commonly be a zero value.

For IKE traffic there is a 4-byte non-Encapsulation Security Payload marker; this sits where the Encapsulation Security Payload SPI would sit if the traffic were Encapsulation Security Payload. The 4-byte non-Encapsulation Security Payload marker is an all zero value, which indicates that the traffic is IKE.

Figure 2-12 shows the UDP encapsulation of Encapsulation Security Payload, with the differencing fields that identify this from a IKE within a UDP header. The size of a UDP header is 8 bytes.

Figure 2-13 illustrates the UDP encapsulation when NAT is detected.

The detection of NAT is also referred as NAT-D, or NAT-Detection, which is described in RFC 3947 and RFC 3948.

For the initiator, the initiator’s SPI will be set and the responder’s SPI will not be known and set to all 0’s.

As the IP address and port are included in the SHA-1 digest, if the relevant IP address or port is changed between the sender and receiver, this can be detected by calculating the SHA-1 digest of the received attributes and comparing this to the SHA-1 digest included in the relevant notify payload.

Should the NAT-T check fail, that is, if the IP address and or port is changed in transit, the initiator will float the IKE_AUTH exchange from UDP port 500 to UDP port 4500. All IKEv2 and subsequence Encapsulation Security Payload traffic is encapsulated within this UDP tunnel. The use of NAT can be detected by viewing the IKEv2 SA or IPsec Security Associations and noting the port numbers used.

It is not mandatory for an IKEv2 device to support the detection of NAT between hosts; however, it is enabled by default on Cisco IOS. To disable the detection of NAT and the subsequent ability to float to UDP port 4500 should NAT be detected, then the following command can be used:

Click here to view code image

no crypto ipsec nat-transparency udp-encapsulation

The sections that follow describe complimentary RFCs to date, although this list will probably grow in the future;

Cisco IOS supports the ability for dual authentication using aggregate authentication, which is described in Chapter 9, “FlexVPN Server.”

You should now be familiar with the various packet exchanges within IKEv2, how the initial SA_INIT exchange is used to negotiate and secure the IKEv2 session, and how authentication then occurs in IKE_AUTH, along with the subsequent creations of IPsec Security Associations.

IKEv2 sessions are maintained using INFORMATIONAL exchanges, which also can be used to remove an IKEv2 SA and to support keepalive functions if required. There will always be an acknowledged reply to any message sent.

The chapter examined what happens when Network Address Translation is used and how IKE detects the presence of NAT within service provider networks and why encapsulating Encapsulation Security Payload within UDP brings a number of benefits.

The packet layout was covered, including how to determine if an IKEv2 packet is from an initiator or receiver, how SPIs can be used to track sessions, and how the packet format is structured.

IKEv2 has a number of complementary RFCs that have been developed, adding additional functionality.

RFC 7296 Internet Key Exchange Protocol Version 2 (IKEv2) http://tools.ietf.org/html/rfc7296

RFC 4739 Multiple Authentication Exchanges in the Internet Key Exchange (IKEv2) Protocol https://tools.ietf.org/html/rfc4739