Computer NetworksNetwork Layer Security

Security Associations

LevelAdvanced

Duration75 mins

TopicNetwork Layer Security

4 / 5

IKE Protocol

Automating Security Association Management

The IPSec framework we've explored so far has a significant gap: how do two endpoints agree on SA parameters and, critically, how do they share secret keys securely? If Alice needs to encrypt traffic to Bob using AES-256-GCM, both need the same 256-bit key—but transmitting that key over the network defeats the purpose of encryption.

The Internet Key Exchange (IKE) protocol solves this fundamental problem. IKE enables two parties who have never communicated before to:

Authenticate each other — Verify identities using certificates, pre-shared keys, or EAP
Agree on algorithms — Negotiate mutually-supported cryptographic suites
Derive shared keys — Use Diffie-Hellman key exchange to create keys that no eavesdropper can know
Create IPSec SAs — Establish the Child SAs that protect actual traffic
Manage the lifecycle — Rekey SAs before they expire, delete them when no longer needed

IKE transforms IPSec from a system requiring manual key distribution into a fully automated security infrastructure.

What You Will Learn

By the end of this page, you will understand IKEv2's architecture, message exchanges, authentication methods, and how it creates and manages Security Associations. This knowledge enables you to configure, troubleshoot, and secure IKE deployments.

IKE Evolution: From IKEv1 to IKEv2

IKE has evolved significantly since its introduction. Understanding this evolution helps explain why IKEv2 is structured as it is.

IKEv1 (RFC 2409, 1998):

Original IKE combined ISAKMP (Internet Security Association and Key Management Protocol), Oakley key determination, and SKEME key techniques into a complex protocol with:

Two phases (Phase 1 for IKE SA, Phase 2 for IPSec SA)
Multiple modes (Main Mode, Aggressive Mode, Quick Mode)
Complex state machines
Interoperability issues between implementations
Numerous security vulnerabilities discovered over time

IKEv2 (RFC 7296, 2014):

A complete redesign that addresses IKEv1's shortcomings:

IKEv1 vs IKEv2 Comparison
Aspect	IKEv1	IKEv2
Message Count (Initial)	6-9 messages minimum	4 messages (IKE_SA_INIT + IKE_AUTH)
Complexity	Multiple modes, complex negotiation	Single, streamlined exchange
Authentication	Pre-shared key, signatures, encryption	Same plus EAP, multiple auth
NAT Traversal	Separate extension (NAT-T)	Built into core protocol
DoS Protection	Vulnerable to half-open attacks	Cookie mechanism included
Extensibility	Limited	Designed for extensions
Mobile Support	Poor (IP address changes)	MOBIKE extension
Error Handling	Inconsistent	Standardized NOTIFY payloads

Focus on IKEv2

This page focuses on IKEv2, which is the modern standard. IKEv1 is deprecated for new deployments. However, you may encounter IKEv1 in legacy systems—the core concepts (Diffie-Hellman, authentication, SA negotiation) are similar, but the message formats and state machines differ significantly.

IKEv2 Architecture Overview

IKEv2 uses a request-response model where the initiator sends requests and the responder replies. All exchanges consist of paired messages. The protocol runs over UDP port 500 (or port 4500 when NAT is detected).

Core Concepts:

IKEv2 Fundamental Concepts

•IKE SA — A bidirectional management channel protecting all IKE messages between two peers. Created first, lives longest.
•Child SA — IPSec SAs (ESP or AH) for protecting actual traffic. Created under IKE SA, can be multiple per IKE SA.
•Exchange — A request-response message pair. Four exchange types: IKE_SA_INIT, IKE_AUTH, CREATE_CHILD_SA, INFORMATIONAL.
•Payload — Individual data elements within IKE messages. SA proposals, keys, identities, nonces are all payloads.
•SPI (IKE) — 8-byte identifier for the IKE SA (different from the 4-byte IPSec SPI). Each direction has its own IKE SPI.

Converting Mermaid diagram...

Message Header Structure:

Every IKE message starts with a fixed header:

IKE Header Format
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
// IKEv2 Fixed Header (28 bytes)
 
 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                       IKE SA Initiator's SPI                  |
|                           (8 bytes)                           |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                       IKE SA Responder's SPI                  |
|                           (8 bytes)                           |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|  Next Payload | MjVer | MnVer | Exchange Type |    Flags      |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                          Message ID                           |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                            Length                             |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                         Payloads...                           |
 
Exchange Types:
  34 = IKE_SA_INIT
  35 = IKE_AUTH  
  36 = CREATE_CHILD_SA
  37 = INFORMATIONAL
 
Flags:
  I (Initiator) - Set by initiator, clear by responder
  V (Version)   - Higher version supported
  R (Response)  - Set in response messages

IKE_SA_INIT Exchange

The IKE_SA_INIT exchange is the first step in establishing an IKE session. This exchange is unencrypted—the parties haven't agreed on keys yet! Its purpose is to negotiate cryptographic parameters and perform Diffie-Hellman key exchange.

Initiator's Message (Request):

IKE_SA_INIT Request Payloads
Payload	Content	Purpose
HDR	IKE Header with initiator SPI	Message framing, version, exchange type
SAi1	Proposed cryptographic suites	Offer encryption, integrity, PRF, DH group options
KEi	Initiator's DH public value	Key exchange material for shared secret
Ni	Initiator's nonce (random)	Freshness, prevents replay, used in key derivation

Responder's Message (Response):

IKE_SA_INIT Response Payloads
Payload	Content	Purpose
HDR	IKE Header with responder SPI	Completes SPI pair identification
SAr1	Selected cryptographic suite	Chooses ONE proposal from SAi1
KEr	Responder's DH public value	Complete the DH exchange
Nr	Responder's nonce	Freshness for key derivation
[CERTREQ]	Certificate request (optional)	Request initiator's certificate if using RSA auth

Key Derivation After IKE_SA_INIT:

Once both parties have Ni, Nr, and can compute the DH shared secret (SKEYSEED), they derive all session keys:

IKEv2 Key Derivation
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
// Key Derivation from DH Exchange
 
// Step 1: Compute DH shared secret
// g^ir = (g^i)^r = (g^r)^i (where i = initiator's private, r = responder's private)
SHARED_SECRET = DiffieHellman(KEi.public, private_key)
 
// Step 2: Derive SKEYSEED (initial key material)
SKEYSEED = PRF(Ni | Nr, SHARED_SECRET)
 
// Step 3: Expand into actual keys using PRF+
// PRF+ generates as much key material as needed
{SK_d | SK_ai | SK_ar | SK_ei | SK_er | SK_pi | SK_pr} = 
    PRF+(SKEYSEED, Ni | Nr | SPIi | SPIr)
 
// Key purposes:
// SK_d   = Key for deriving Child SA keys (not used directly)
// SK_ai  = IKE SA integrity key (initiator to responder)
// SK_ar  = IKE SA integrity key (responder to initiator)
// SK_ei  = IKE SA encryption key (initiator to responder)
// SK_er  = IKE SA encryption key (responder to initiator)
// SK_pi  = Used in AUTH payload computation (initiator)
// SK_pr  = Used in AUTH payload computation (responder)
 
// Example with AES-256 and SHA-256:
// SK_d:  256 bits (for Child SA derivation)
// SK_ai: 256 bits (HMAC-SHA-256 key)
// SK_ar: 256 bits
// SK_ei: 256 bits (AES-256 key)
// SK_er: 256 bits
// SK_pi: 256 bits
// SK_pr: 256 bits
// Total: 1792 bits (224 bytes) of key material

DoS Protection: Cookies

An attacker can flood responders with IKE_SA_INIT requests from spoofed IPs, consuming memory and CPU. IKEv2 includes cookie-based DoS protection: under load, the responder replies with a COOKIE notification. The initiator must retry with this cookie, proving it can receive at the claimed IP. This stateless challenge prevents resource exhaustion.

IKE_AUTH Exchange

The IKE_AUTH exchange performs mutual authentication and creates the first Child SA. Unlike IKE_SA_INIT, this exchange is encrypted and integrity-protected using the keys derived in the previous step.

Authentication Methods:

IKEv2 supports multiple authentication methods:

RSA Digital Signature Authentication is the most common method for site-to-site VPNs and enterprise deployments.

How it works:

Each party has an X.509 certificate signed by a trusted CA
The AUTH payload contains a signature over specific message data
The peer verifies the signature using the certificate's public key
Certificate chain is verified against trusted CAs

AUTH Payload Computation:

InitiatorSignedOctets = RealMessage1 | Nr | PRF(SK_pi, IDi')
AUTH = SIGNATURE(InitiatorSignedOctets, InitiatorPrivateKey)

ResponderSignedOctets = RealMessage2 | Ni | PRF(SK_pr, IDr')
AUTH = SIGNATURE(ResponderSignedOctets, ResponderPrivateKey)

Advantages: Strong security, no shared secrets to distribute, certificate revocation possible.

Disadvantages: Requires PKI infrastructure, certificate management overhead.

IKE_AUTH and Child SA Creation:

The IKE_AUTH exchange also creates the first Child SA. The initiator includes SA proposals, Traffic Selectors (TSi, TSr) specifying what traffic the SA will protect. The responder selects parameters and may narrow the traffic selectors.

IKE_AUTH Payloads
Payload	Initiator	Responder	Purpose
IDi/IDr	Required	Required	Identity of each party
CERT	Optional	Optional	X.509 certificate for signature auth
CERTREQ	Optional	Optional	Request peer's certificate
AUTH	Required	Required	Authentication proof (signature or MAC)
SAi2/SAr2	Required	Required	Child SA cryptographic proposals/selection
TSi	Required	Required	Traffic Selectors - initiator side
TSr	Required	Required	Traffic Selectors - responder side
CP	Optional	Optional	Configuration Payload (IP assignment for remote access)

Traffic Selector Narrowing

The initiator proposes traffic selectors describing what traffic to protect (e.g., 10.1.0.0/16 ↔ 10.2.0.0/16). The responder can NARROW these (e.g., to 10.1.1.0/24 ↔ 10.2.1.0/24) but cannot expand them. This allows policy negotiation while respecting security constraints.

CREATE_CHILD_SA Exchange

After the initial IKE_AUTH completes, additional Child SAs can be created using the CREATE_CHILD_SA exchange. This exchange is also used to rekey existing Child SAs and to rekey the IKE SA itself.

Use Cases for CREATE_CHILD_SA:

•New Child SA — Create additional IPSec SAs for different traffic patterns or policies
•Child SA Rekey — Replace an expiring Child SA with a fresh one
•IKE SA Rekey — Replace the IKE SA itself (keeps Child SAs, just refreshes management channel)

Creating a New Child SA:

CREATE_CHILD_SA Exchange
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
// CREATE_CHILD_SA for New Child SA
 
Initiator → Responder:
  HDR, SK {
    SA,       // Cryptographic proposals for Child SA
    Ni,       // Nonce (fresh randomness)
    [KEi],    // Optional: DH public value for PFS
    TSi,      // Traffic selectors (initiator side)
    TSr       // Traffic selectors (responder side)
  }
 
Responder → Initiator:
  HDR, SK {
    SA,       // Selected cryptographic parameters
    Nr,       // Responder nonce
    [KEr],    // DH public value if KEi was included
    TSi,      // Possibly narrowed traffic selectors
    TSr
  }
 
// Key derivation for new Child SA:
KEYMAT = PRF+(SK_d, Ni | Nr)
 
// If PFS (KEi/KEr included):
KEYMAT = PRF+(SK_d, DH_SHARED_SECRET | Ni | Nr)
 
// KEYMAT is split into:
// - Encryption key (initiator → responder)
// - Encryption key (responder → initiator)  
// - Integrity key (initiator → responder), if needed
// - Integrity key (responder → initiator), if needed

Rekeying Child SAs:

When a Child SA approaches its lifetime limit, a new CREATE_CHILD_SA exchange creates the replacement. The process includes a REKEY_SA notification identifying which SA is being replaced:

Child SA Rekeying
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
// Rekeying a Child SA
 
Initiator → Responder:
  HDR, SK {
    N(REKEY_SA, <Protocol, SPI>),  // Identify SA being replaced
    SA,                             // Proposals for new SA
    Ni,
    [KEi],
    TSi,
    TSr
  }
 
Responder → Initiator:
  HDR, SK {
    SA,
    Nr,
    [KEr],
    TSi,
    TSr
  }
 
// After successful exchange:
// 1. Both install new Child SA
// 2. Traffic transitions to new SA
// 3. Old SA is deleted after brief overlap period
// 4. DELETE notification may be sent to explicitly remove old SA

Perfect Forward Secrecy (PFS)

Including KEi/KEr in CREATE_CHILD_SA provides PFS. Each Child SA gets unique key material from a fresh DH exchange. If an attacker later compromises SK_d (from the IKE SA), they still can't derive Child SA keys without the per-SA DH exchange. PFS adds computational cost but significantly limits damage from key compromise.

INFORMATIONAL Exchange

The INFORMATIONAL exchange is a general-purpose mechanism for sending control messages. Unlike IKE_AUTH or CREATE_CHILD_SA, it doesn't always create or modify SAs—it handles maintenance, notifications, and teardown.

Common INFORMATIONAL Uses:

INFORMATIONAL Exchange Payloads
Payload	Purpose	Examples
N (Notify)	Send notifications/errors	INVALID_SYNTAX, AUTHENTICATION_FAILED, REKEY_SA
D (Delete)	Request SA deletion	Delete specific Child SA or IKE SA
CP (Config)	Configuration changes	Request new IP address in remote access

Deleting Security Associations:

When an SA is no longer needed (or has expired), a DELETE payload requests its removal:

SA Deletion
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
// Deleting a Child SA
 
Initiator → Responder:
  HDR, SK {
    D(ESP, <SPI_of_SA_to_delete>)  // Specify protocol and SPI
  }
 
Responder → Initiator:
  HDR, SK {
    D(ESP, <corresponding_SPI>)    // Acknowledge with its SPI for same SA
  }
 
// Note: SPIs are different in each direction!
// Initiator sends the SPI it assigned (for traffic it receives)
// Responder replies with the SPI it assigned
 
// Deleting the IKE SA itself:
Initiator → Responder:
  HDR, SK {
    D(IKE, <no SPI needed>)        // IKE SA identified by header SPIs
  }
 
Responder → Initiator:
  HDR, SK {
    D(IKE, <no SPI needed>)
  }
 
// After IKE SA deletion, all Child SAs under it are also deleted

Dead Peer Detection (DPD):

IKEv2 uses empty INFORMATIONAL exchanges to verify peer liveness. If a peer doesn't respond to several probes, the IKE SA and all Child SAs are considered dead and deleted locally.

Dead Peer Detection
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
// Dead Peer Detection (Liveness Check)
 
// Empty INFORMATIONAL exchange acts as heartbeat
Initiator → Responder:
  HDR, SK {}   // No payloads inside SK
 
Responder → Initiator:  
  HDR, SK {}   // Empty response confirms peer is alive
 
// Typical DPD behavior:
// - Send probe if no traffic received for X seconds (e.g., 30s)
// - Retry Y times with increasing intervals
// - If no response after all retries, declare peer dead
// - Delete all SAs associated with that peer
 
// DPD Configuration Example:
dpd_delay = 30      // Seconds of inactivity before probe
dpd_timeout = 120   // Total seconds before declaring dead
dpd_action = CLEAR  // Action on timeout: clear, hold, restart

INFORMATIONAL Exchange Reliability

All IKEv2 exchanges use request-response pairs with retransmission. If a request times out, it's retransmitted. Only the original initiator of an exchange retransmits—the responder just replies when it receives requests. This prevents amplification and ensures reliable delivery.

NAT Traversal in IKEv2

Network Address Translation (NAT) presents a significant challenge for IPSec. NAT modifies IP headers, which can break IPSec in several ways:

AH failure — AH authenticates the IP header, including addresses. NAT changes addresses, invalidating the authentication.
ESP over IP failure — Standard ESP (protocol 50) doesn't include port numbers. NAT can't distinguish multiple ESP connections from the same public IP.
IKE detection — NAT on port 500 requires special handling.

IKEv2 Built-in NAT-T:

IKEv2 includes NAT Traversal (NAT-T) as a core feature, not an extension:

NAT-T Mechanism

•NAT Detection — During IKE_SA_INIT, both parties include NAT_DETECTION_SOURCE_IP and NAT_DETECTION_DESTINATION_IP payloads containing hashes of their addresses and ports.
•Hash Comparison — Each side computes what the hash SHOULD be. If it doesn't match, NAT is present.
•Port Switch — If NAT is detected, subsequent IKE and ESP traffic switches from port 500 to port 4500.
•UDP Encapsulation — ESP packets are encapsulated in UDP (port 4500). NAT translates the UDP header, ESP inside is untouched.

NAT Detection Payloads
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
// NAT Detection in IKE_SA_INIT
 
// Initiator sends:
N(NAT_DETECTION_SOURCE_IP) = SHA-1(SPIi | SPIr | Initiator_IP | Initiator_Port)
N(NAT_DETECTION_DESTINATION_IP) = SHA-1(SPIi | SPIr | Responder_IP | Responder_Port)
 
// Responder computes expected hashes from received packet
// If received SOURCE hash ≠ computed (using packet source IP/port):
//   → NAT exists between initiator and responder
 
// If received DESTINATION hash ≠ computed (using packet dest IP/port):
//   → NAT exists between responder and initiator
 
// After NAT detection, ESP is encapsulated in UDP:
 
Original ESP packet:
+----------+------------+------------------+
| IP Header| ESP Header |   ESP Payload    |
| Proto=50 |    SPI     |   (encrypted)    |
+----------+------------+------------------+
 
UDP-Encapsulated ESP (NAT-T):
+----------+------------+------------+------------------+
| IP Header| UDP Header | ESP Header |   ESP Payload    |
| Proto=17 | Src: 4500  |    SPI     |   (encrypted)    |
|          | Dst: 4500  |            |                  |
+----------+------------+------------+------------------+
 
// NAT modifies IP and UDP headers, ESP inside is protected
// Keepalives: empty UDP packets (just 0xFF) maintain NAT mappings

NAT Keepalives

NAT devices timeout inactive mappings (often 60-120 seconds). To keep the NAT mapping alive, the peer behind NAT must periodically send keepalive packets. These are 1-byte UDP packets (containing 0xFF) sent on port 4500. Without keepalives, the NAT mapping expires and the VPN breaks.

Summary: IKE Protocol

We've explored IKE—the engine that powers automated IPSec security. IKE transforms manual key distribution into a scalable, secure protocol.

Key Takeaways

•IKEv2 is the modern standard — Simpler, faster, and more secure than IKEv1.
•Four exchange types — IKE_SA_INIT (unauthenticated DH), IKE_AUTH (mutual auth + first Child SA), CREATE_CHILD_SA (additional SAs, rekeying), INFORMATIONAL (maintenance).
•Multiple authentication methods — RSA signatures for enterprise, PSK for simple setups, EAP for remote access.
•Diffie-Hellman provides shared secrets — Keys are derived, never transmitted, defeating eavesdroppers.
•NAT-T is built in — Automatic detection and UDP encapsulation for NAT traversal.
•PFS is optional but recommended — Fresh DH exchange per Child SA limits compromise damage.

What's Next:

The final page in this module covers Key Management—the broader practices and protocols for managing cryptographic keys throughout their lifecycle. We'll explore key generation, distribution, storage, rotation, and destruction, completing our understanding of how Security Associations are secured.

Page Complete

You now understand IKE—the protocol that bootstraps all IPSec security. This knowledge is essential for configuring VPNs, debugging connectivity issues, and understanding the security properties of your IPSec deployments.

4 / 5

Loading learning content...

Computer NetworksNetwork Layer Security

Security Associations

LevelAdvanced

Duration75 mins

TopicNetwork Layer Security

4 / 5

IKE Protocol

Automating Security Association Management

The Internet Key Exchange (IKE) protocol solves this fundamental problem. IKE enables two parties who have never communicated before to:

Authenticate each other — Verify identities using certificates, pre-shared keys, or EAP
Agree on algorithms — Negotiate mutually-supported cryptographic suites
Derive shared keys — Use Diffie-Hellman key exchange to create keys that no eavesdropper can know
Create IPSec SAs — Establish the Child SAs that protect actual traffic
Manage the lifecycle — Rekey SAs before they expire, delete them when no longer needed

IKE transforms IPSec from a system requiring manual key distribution into a fully automated security infrastructure.

What You Will Learn

IKE Evolution: From IKEv1 to IKEv2

IKE has evolved significantly since its introduction. Understanding this evolution helps explain why IKEv2 is structured as it is.

IKEv1 (RFC 2409, 1998):

Original IKE combined ISAKMP (Internet Security Association and Key Management Protocol), Oakley key determination, and SKEME key techniques into a complex protocol with:

Two phases (Phase 1 for IKE SA, Phase 2 for IPSec SA)
Multiple modes (Main Mode, Aggressive Mode, Quick Mode)
Complex state machines
Interoperability issues between implementations
Numerous security vulnerabilities discovered over time

IKEv2 (RFC 7296, 2014):

A complete redesign that addresses IKEv1's shortcomings:

IKEv1 vs IKEv2 Comparison
Aspect	IKEv1	IKEv2
Message Count (Initial)	6-9 messages minimum	4 messages (IKE_SA_INIT + IKE_AUTH)
Complexity	Multiple modes, complex negotiation	Single, streamlined exchange
Authentication	Pre-shared key, signatures, encryption	Same plus EAP, multiple auth
NAT Traversal	Separate extension (NAT-T)	Built into core protocol
DoS Protection	Vulnerable to half-open attacks	Cookie mechanism included
Extensibility	Limited	Designed for extensions
Mobile Support	Poor (IP address changes)	MOBIKE extension
Error Handling	Inconsistent	Standardized NOTIFY payloads

Focus on IKEv2

IKEv2 Architecture Overview

Core Concepts:

IKEv2 Fundamental Concepts

•IKE SA — A bidirectional management channel protecting all IKE messages between two peers. Created first, lives longest.
•Child SA — IPSec SAs (ESP or AH) for protecting actual traffic. Created under IKE SA, can be multiple per IKE SA.
•Exchange — A request-response message pair. Four exchange types: IKE_SA_INIT, IKE_AUTH, CREATE_CHILD_SA, INFORMATIONAL.
•Payload — Individual data elements within IKE messages. SA proposals, keys, identities, nonces are all payloads.
•SPI (IKE) — 8-byte identifier for the IKE SA (different from the 4-byte IPSec SPI). Each direction has its own IKE SPI.

Converting Mermaid diagram...

Message Header Structure:

Every IKE message starts with a fixed header:

IKE Header Format
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
// IKEv2 Fixed Header (28 bytes)
 
 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                       IKE SA Initiator's SPI                  |
|                           (8 bytes)                           |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                       IKE SA Responder's SPI                  |
|                           (8 bytes)                           |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|  Next Payload | MjVer | MnVer | Exchange Type |    Flags      |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                          Message ID                           |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                            Length                             |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                         Payloads...                           |
 
Exchange Types:
  34 = IKE_SA_INIT
  35 = IKE_AUTH  
  36 = CREATE_CHILD_SA
  37 = INFORMATIONAL
 
Flags:
  I (Initiator) - Set by initiator, clear by responder
  V (Version)   - Higher version supported
  R (Response)  - Set in response messages

IKE_SA_INIT Exchange

Initiator's Message (Request):

IKE_SA_INIT Request Payloads
Payload	Content	Purpose
HDR	IKE Header with initiator SPI	Message framing, version, exchange type
SAi1	Proposed cryptographic suites	Offer encryption, integrity, PRF, DH group options
KEi	Initiator's DH public value	Key exchange material for shared secret
Ni	Initiator's nonce (random)	Freshness, prevents replay, used in key derivation

Responder's Message (Response):

IKE_SA_INIT Response Payloads
Payload	Content	Purpose
HDR	IKE Header with responder SPI	Completes SPI pair identification
SAr1	Selected cryptographic suite	Chooses ONE proposal from SAi1
KEr	Responder's DH public value	Complete the DH exchange
Nr	Responder's nonce	Freshness for key derivation
[CERTREQ]	Certificate request (optional)	Request initiator's certificate if using RSA auth

Key Derivation After IKE_SA_INIT:

Once both parties have Ni, Nr, and can compute the DH shared secret (SKEYSEED), they derive all session keys:

IKEv2 Key Derivation
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
// Key Derivation from DH Exchange
 
// Step 1: Compute DH shared secret
// g^ir = (g^i)^r = (g^r)^i (where i = initiator's private, r = responder's private)
SHARED_SECRET = DiffieHellman(KEi.public, private_key)
 
// Step 2: Derive SKEYSEED (initial key material)
SKEYSEED = PRF(Ni | Nr, SHARED_SECRET)
 
// Step 3: Expand into actual keys using PRF+
// PRF+ generates as much key material as needed
{SK_d | SK_ai | SK_ar | SK_ei | SK_er | SK_pi | SK_pr} = 
    PRF+(SKEYSEED, Ni | Nr | SPIi | SPIr)
 
// Key purposes:
// SK_d   = Key for deriving Child SA keys (not used directly)
// SK_ai  = IKE SA integrity key (initiator to responder)
// SK_ar  = IKE SA integrity key (responder to initiator)
// SK_ei  = IKE SA encryption key (initiator to responder)
// SK_er  = IKE SA encryption key (responder to initiator)
// SK_pi  = Used in AUTH payload computation (initiator)
// SK_pr  = Used in AUTH payload computation (responder)
 
// Example with AES-256 and SHA-256:
// SK_d:  256 bits (for Child SA derivation)
// SK_ai: 256 bits (HMAC-SHA-256 key)
// SK_ar: 256 bits
// SK_ei: 256 bits (AES-256 key)
// SK_er: 256 bits
// SK_pi: 256 bits
// SK_pr: 256 bits
// Total: 1792 bits (224 bytes) of key material

DoS Protection: Cookies

IKE_AUTH Exchange

Authentication Methods:

IKEv2 supports multiple authentication methods:

RSA Digital Signature Authentication is the most common method for site-to-site VPNs and enterprise deployments.

How it works:

Each party has an X.509 certificate signed by a trusted CA
The AUTH payload contains a signature over specific message data
The peer verifies the signature using the certificate's public key
Certificate chain is verified against trusted CAs

AUTH Payload Computation:

InitiatorSignedOctets = RealMessage1 | Nr | PRF(SK_pi, IDi')
AUTH = SIGNATURE(InitiatorSignedOctets, InitiatorPrivateKey)

ResponderSignedOctets = RealMessage2 | Ni | PRF(SK_pr, IDr')
AUTH = SIGNATURE(ResponderSignedOctets, ResponderPrivateKey)

Advantages: Strong security, no shared secrets to distribute, certificate revocation possible.

Disadvantages: Requires PKI infrastructure, certificate management overhead.

IKE_AUTH and Child SA Creation:

IKE_AUTH Payloads
Payload	Initiator	Responder	Purpose
IDi/IDr	Required	Required	Identity of each party
CERT	Optional	Optional	X.509 certificate for signature auth
CERTREQ	Optional	Optional	Request peer's certificate
AUTH	Required	Required	Authentication proof (signature or MAC)
SAi2/SAr2	Required	Required	Child SA cryptographic proposals/selection
TSi	Required	Required	Traffic Selectors - initiator side
TSr	Required	Required	Traffic Selectors - responder side
CP	Optional	Optional	Configuration Payload (IP assignment for remote access)

Traffic Selector Narrowing

CREATE_CHILD_SA Exchange

After the initial IKE_AUTH completes, additional Child SAs can be created using the CREATE_CHILD_SA exchange. This exchange is also used to rekey existing Child SAs and to rekey the IKE SA itself.

Use Cases for CREATE_CHILD_SA:

•New Child SA — Create additional IPSec SAs for different traffic patterns or policies
•Child SA Rekey — Replace an expiring Child SA with a fresh one
•IKE SA Rekey — Replace the IKE SA itself (keeps Child SAs, just refreshes management channel)

Creating a New Child SA:

CREATE_CHILD_SA Exchange
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
// CREATE_CHILD_SA for New Child SA
 
Initiator → Responder:
  HDR, SK {
    SA,       // Cryptographic proposals for Child SA
    Ni,       // Nonce (fresh randomness)
    [KEi],    // Optional: DH public value for PFS
    TSi,      // Traffic selectors (initiator side)
    TSr       // Traffic selectors (responder side)
  }
 
Responder → Initiator:
  HDR, SK {
    SA,       // Selected cryptographic parameters
    Nr,       // Responder nonce
    [KEr],    // DH public value if KEi was included
    TSi,      // Possibly narrowed traffic selectors
    TSr
  }
 
// Key derivation for new Child SA:
KEYMAT = PRF+(SK_d, Ni | Nr)
 
// If PFS (KEi/KEr included):
KEYMAT = PRF+(SK_d, DH_SHARED_SECRET | Ni | Nr)
 
// KEYMAT is split into:
// - Encryption key (initiator → responder)
// - Encryption key (responder → initiator)  
// - Integrity key (initiator → responder), if needed
// - Integrity key (responder → initiator), if needed

Rekeying Child SAs:

When a Child SA approaches its lifetime limit, a new CREATE_CHILD_SA exchange creates the replacement. The process includes a REKEY_SA notification identifying which SA is being replaced:

Child SA Rekeying
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
// Rekeying a Child SA
 
Initiator → Responder:
  HDR, SK {
    N(REKEY_SA, <Protocol, SPI>),  // Identify SA being replaced
    SA,                             // Proposals for new SA
    Ni,
    [KEi],
    TSi,
    TSr
  }
 
Responder → Initiator:
  HDR, SK {
    SA,
    Nr,
    [KEr],
    TSi,
    TSr
  }
 
// After successful exchange:
// 1. Both install new Child SA
// 2. Traffic transitions to new SA
// 3. Old SA is deleted after brief overlap period
// 4. DELETE notification may be sent to explicitly remove old SA

Perfect Forward Secrecy (PFS)

INFORMATIONAL Exchange

Common INFORMATIONAL Uses:

INFORMATIONAL Exchange Payloads
Payload	Purpose	Examples
N (Notify)	Send notifications/errors	INVALID_SYNTAX, AUTHENTICATION_FAILED, REKEY_SA
D (Delete)	Request SA deletion	Delete specific Child SA or IKE SA
CP (Config)	Configuration changes	Request new IP address in remote access

Deleting Security Associations:

When an SA is no longer needed (or has expired), a DELETE payload requests its removal:

SA Deletion
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
// Deleting a Child SA
 
Initiator → Responder:
  HDR, SK {
    D(ESP, <SPI_of_SA_to_delete>)  // Specify protocol and SPI
  }
 
Responder → Initiator:
  HDR, SK {
    D(ESP, <corresponding_SPI>)    // Acknowledge with its SPI for same SA
  }
 
// Note: SPIs are different in each direction!
// Initiator sends the SPI it assigned (for traffic it receives)
// Responder replies with the SPI it assigned
 
// Deleting the IKE SA itself:
Initiator → Responder:
  HDR, SK {
    D(IKE, <no SPI needed>)        // IKE SA identified by header SPIs
  }
 
Responder → Initiator:
  HDR, SK {
    D(IKE, <no SPI needed>)
  }
 
// After IKE SA deletion, all Child SAs under it are also deleted

Dead Peer Detection (DPD):

IKEv2 uses empty INFORMATIONAL exchanges to verify peer liveness. If a peer doesn't respond to several probes, the IKE SA and all Child SAs are considered dead and deleted locally.

Dead Peer Detection
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
// Dead Peer Detection (Liveness Check)
 
// Empty INFORMATIONAL exchange acts as heartbeat
Initiator → Responder:
  HDR, SK {}   // No payloads inside SK
 
Responder → Initiator:  
  HDR, SK {}   // Empty response confirms peer is alive
 
// Typical DPD behavior:
// - Send probe if no traffic received for X seconds (e.g., 30s)
// - Retry Y times with increasing intervals
// - If no response after all retries, declare peer dead
// - Delete all SAs associated with that peer
 
// DPD Configuration Example:
dpd_delay = 30      // Seconds of inactivity before probe
dpd_timeout = 120   // Total seconds before declaring dead
dpd_action = CLEAR  // Action on timeout: clear, hold, restart

INFORMATIONAL Exchange Reliability

NAT Traversal in IKEv2

Network Address Translation (NAT) presents a significant challenge for IPSec. NAT modifies IP headers, which can break IPSec in several ways:

AH failure — AH authenticates the IP header, including addresses. NAT changes addresses, invalidating the authentication.
ESP over IP failure — Standard ESP (protocol 50) doesn't include port numbers. NAT can't distinguish multiple ESP connections from the same public IP.
IKE detection — NAT on port 500 requires special handling.

IKEv2 Built-in NAT-T:

IKEv2 includes NAT Traversal (NAT-T) as a core feature, not an extension:

NAT-T Mechanism

•NAT Detection — During IKE_SA_INIT, both parties include NAT_DETECTION_SOURCE_IP and NAT_DETECTION_DESTINATION_IP payloads containing hashes of their addresses and ports.
•Hash Comparison — Each side computes what the hash SHOULD be. If it doesn't match, NAT is present.
•Port Switch — If NAT is detected, subsequent IKE and ESP traffic switches from port 500 to port 4500.
•UDP Encapsulation — ESP packets are encapsulated in UDP (port 4500). NAT translates the UDP header, ESP inside is untouched.

NAT Detection Payloads
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
// NAT Detection in IKE_SA_INIT
 
// Initiator sends:
N(NAT_DETECTION_SOURCE_IP) = SHA-1(SPIi | SPIr | Initiator_IP | Initiator_Port)
N(NAT_DETECTION_DESTINATION_IP) = SHA-1(SPIi | SPIr | Responder_IP | Responder_Port)
 
// Responder computes expected hashes from received packet
// If received SOURCE hash ≠ computed (using packet source IP/port):
//   → NAT exists between initiator and responder
 
// If received DESTINATION hash ≠ computed (using packet dest IP/port):
//   → NAT exists between responder and initiator
 
// After NAT detection, ESP is encapsulated in UDP:
 
Original ESP packet:
+----------+------------+------------------+
| IP Header| ESP Header |   ESP Payload    |
| Proto=50 |    SPI     |   (encrypted)    |
+----------+------------+------------------+
 
UDP-Encapsulated ESP (NAT-T):
+----------+------------+------------+------------------+
| IP Header| UDP Header | ESP Header |   ESP Payload    |
| Proto=17 | Src: 4500  |    SPI     |   (encrypted)    |
|          | Dst: 4500  |            |                  |
+----------+------------+------------+------------------+
 
// NAT modifies IP and UDP headers, ESP inside is protected
// Keepalives: empty UDP packets (just 0xFF) maintain NAT mappings

NAT Keepalives

Summary: IKE Protocol

We've explored IKE—the engine that powers automated IPSec security. IKE transforms manual key distribution into a scalable, secure protocol.

Key Takeaways

•IKEv2 is the modern standard — Simpler, faster, and more secure than IKEv1.
•Four exchange types — IKE_SA_INIT (unauthenticated DH), IKE_AUTH (mutual auth + first Child SA), CREATE_CHILD_SA (additional SAs, rekeying), INFORMATIONAL (maintenance).
•Multiple authentication methods — RSA signatures for enterprise, PSK for simple setups, EAP for remote access.
•Diffie-Hellman provides shared secrets — Keys are derived, never transmitted, defeating eavesdroppers.
•NAT-T is built in — Automatic detection and UDP encapsulation for NAT traversal.
•PFS is optional but recommended — Fresh DH exchange per Child SA limits compromise damage.

What's Next:

Page Complete

4 / 5