101
0/228
Loading content...
A Security Association is more than just an abstract security contract—it's a precisely defined set of parameters that govern every aspect of how traffic is protected. When an IPSec implementation processes a packet, it doesn't rely on guesswork; it consults the SA's parameters to know exactly which algorithm to use, which key to apply, and how to handle sequence numbers.
Think of SA parameters as the detailed specifications in a construction blueprint. While the conceptual design says "build a secure wall," the parameters specify exactly: "Use AES-256-GCM with this 256-bit key, authenticate using this 256-bit integrity key, increment this sequence number, and expire after 3600 seconds or 1GB of data, whichever comes first."
This page dissects every parameter that comprises a fully-specified Security Association, explaining not just what each parameter is, but why it exists and how it affects security.
By the end of this page, you will understand every parameter that defines an SA—from cryptographic algorithms and keys to operational parameters like sequence numbers and lifetimes. You'll be able to read and understand SA configurations in any IPSec implementation.
Security Association parameters can be organized into logical categories based on their function. Understanding these categories helps conceptualize how an SA is constructed and configured.
The Four Parameter Categories:
Now let's examine each category in detail, understanding every parameter and its role in securing communications.
Identification parameters enable the receiving host to locate the correct SA for processing incoming packets. Without proper identification, the receiver couldn't determine which decryption key or integrity algorithm to use.
Complete Identification Parameter Set:
| Parameter | Size/Type | Description | Example |
|---|---|---|---|
| Security Parameters Index (SPI) | 32-bit unsigned integer | Unique identifier assigned by receiver; carried in AH/ESP header | 0x3A7B9C01 |
| Destination IP Address | 32-bit (IPv4) or 128-bit (IPv6) | IP address of the SA's receiving endpoint | 192.168.1.100 or 2001:db8::1 |
| Security Protocol | 8-bit protocol number | Either AH (51) or ESP (50) | 50 (ESP) |
| Source IP Address | 32-bit or 128-bit (optional) | Used in some implementations for additional specificity | 10.0.0.50 |
The Three-Tuple Requirement:
The minimum identification requirement is the triple (SPI, Destination Address, Protocol). This combination must be unique for all active SAs at a given receiver:
SA_ID = (SPI, Destination_IP, Protocol)
Because the receiver assigns the SPI, it can guarantee uniqueness within its own SA namespace. Two different sending hosts might use the same SPI value when communicating with the same receiver, but as long as the receiver assigned different SPIs to each sending host, there's no collision.
SPI Assignment Strategies:
If a receiver detects that a newly proposed SPI would collide with an existing SA's SPI (for the same destination and protocol), it must reject the SA negotiation and request a different SPI. Implementations typically retry with a new random SPI.
For ESP SAs providing confidentiality, encryption parameters define how data is transformed into ciphertext. These parameters must be identical at both endpoints—any mismatch causes decryption failure.
Core Encryption Parameters:
| Parameter | Description | Common Values |
|---|---|---|
| Encryption Algorithm | The symmetric cipher used for confidentiality | AES-GCM, AES-CBC, ChaCha20-Poly1305, AES-CTR, NULL |
| Encryption Key | Secret key material for the cipher | 128, 192, or 256 bits depending on algorithm |
| Encryption Key Length | Size of the encryption key in bits | 128, 192, 256, or algorithm-specific |
| Initialization Vector (IV) Mode | How IVs are generated for each packet | Explicit IV, implicit IV, counter-based |
| IV Length | Size of IV/nonce in bits | 64, 96, or 128 bits algorithm-dependent |
Algorithm Selection Deep Dive:
The choice of encryption algorithm has profound implications for security, performance, and compatibility:
AES-GCM (Galois/Counter Mode) is the modern standard for IPSec encryption, providing authenticated encryption—both confidentiality and integrity in a single operation.
Key Properties:
Configuration:
Algorithm: ENCR_AES_GCM_16 (RFC 4106)
Key Length: 128, 192, or 256 bits
ICV Length: 8, 12, or 16 bytes (16 recommended)
Salt: 4 bytes (part of the nonce construction)
Security Consideration: Never reuse a nonce with the same key. For high-volume traffic, ensure sufficient nonce space or rekey before nonce exhaustion.
For new deployments, use AES-256-GCM as the primary algorithm with ChaCha20-Poly1305 as a fallback. Avoid AES-CBC unless required for legacy compatibility. The AEAD ciphers (GCM, Poly1305) provide both encryption and authentication in a single, verified operation—reducing implementation complexity and attack surface.
Authentication parameters ensure data integrity and origin verification. For AH SAs, these are the primary security service. For ESP SAs using non-AEAD ciphers, authentication must be configured separately.
Authentication Algorithm Parameters:
| Parameter | Description | Common Values |
|---|---|---|
| Authentication Algorithm | The MAC/hash algorithm for integrity verification | HMAC-SHA-256, HMAC-SHA-384, HMAC-SHA-512, AES-XCBC-MAC |
| Authentication Key | Secret key for the MAC algorithm | 256, 384, or 512 bits depending on algorithm |
| ICV Truncation Length | Size of the Integrity Check Value included in packet | 96, 128, 192, or 256 bits |
| Extended Sequence Numbers (ESN) | Whether 64-bit sequence numbers are used for auth | Enabled/Disabled |
Integrity Check Value (ICV) Mechanics:
The ICV is computed over specific portions of the packet and appended to verify integrity. What's covered differs between AH and ESP:
AH ICV Coverage:
ESP ICV Coverage:
123456789101112131415161718192021222324252627282930313233
// Simplified ICV Computation for ESP// Using HMAC-SHA-256 with truncation to 128 bits function computeESP_ICV(packet, authKey) { // Construct authenticated data const authenticatedData = Buffer.concat([ packet.espHeader, // SPI (4 bytes) + SeqNum (4 bytes) packet.encryptedPayload, // Ciphertext packet.espTrailer // Padding + Pad Length + Next Header ]); // For ESN (Extended Sequence Numbers), include high-order 32 bits if (useESN) { const seqHi = getHighOrderSequenceNumber(); authenticatedData = Buffer.concat([authenticatedData, seqHi]); } // Compute HMAC-SHA-256 const fullHMAC = crypto.createHmac('sha256', authKey) .update(authenticatedData) .digest(); // Truncate to 128 bits (16 bytes) for ICV const ICV = fullHMAC.slice(0, 16); return ICV;} // Verification at receiver:// 1. Extract ICV from received packet// 2. Compute ICV over received data using SA's auth key// 3. Compare computed ICV with received ICV (constant-time!)// 4. If mismatch: silently discard packet (security best practice)The authentication key MUST be cryptographically independent from the encryption key, even when derived from the same master secret. IKE's PRF+ derivation function ensures this separation. Never use the same key material for both encryption and authentication—this can lead to subtle cryptographic attacks.
Key material is the most sensitive component of an SA. The security of the entire system depends on keys being:
Key Material Components:
| Parameter | Purpose | Derivation Source |
|---|---|---|
| Encryption Key (SK_e) | Symmetric key for cipher algorithm | IKE PRF+ or manual configuration |
| Integrity Key (SK_a) | Key for HMAC/MAC computation | IKE PRF+ (independent from SK_e) |
| Salt (for GCM/CCM) | Fixed value combined with IV for nonce | IKE PRF+ (4 bytes for AES-GCM) |
| IV/Nonce Generator State | Counter or random state for IV generation | Initialized from IKE, incremented per packet |
Key Derivation from IKE:
When IKE establishes a Child SA, it derives key material using a Pseudo-Random Function (PRF) in a deterministic expansion called PRF+:
KEYMAT = PRF+(SK_d, Ni | Nr | SPIi | SPIr)
Where:
SK_d = Secret key derived from IKE SA
Ni = Initiator's nonce
Nr = Responder's nonce
SPIi = Initiator's SPI for this Child SA
SPIr = Responder's SPI for this Child SA
The KEYMAT is then partitioned into the needed keys for both directions:
123456789101112131415161718192021
// Key Material Derivation (IKEv2 RFC 7296) // PRF+ produces as much key material as neededKEYMAT = PRF+(SK_d, Ni | Nr | SPIi | SPIr) // For ESP with AES-256-GCM (256-bit key, 4-byte salt) in both directions: // Initiator → Responder direction:SK_ei = KEYMAT[0:31] // Encryption key (32 bytes = 256 bits)Salt_i = KEYMAT[32:35] // Salt for GCM nonce (4 bytes) // Responder → Initiator direction: SK_er = KEYMAT[36:67] // Encryption key (32 bytes = 256 bits)Salt_r = KEYMAT[68:71] // Salt for GCM nonce (4 bytes) // If separate integrity keys needed (e.g., AES-CBC + HMAC-SHA-256):SK_ai = KEYMAT[72:103] // Integrity key initiator→responderSK_ar = KEYMAT[104:135] // Integrity key responder→initiator // Note: Each direction has INDEPENDENT keys// Compromising one direction doesn't compromise the otherWhen PFS is enabled, each Child SA rekeying includes a new Diffie-Hellman exchange. This means compromising a Child SA's keys doesn't help decrypt past or future SAs, even if the IKE SA's long-term keys are later compromised. PFS adds computational cost but significantly limits the damage from key compromise.
Operational parameters control the runtime behavior of an SA—how packets are processed, how state is maintained, and what mode of operation is used.
Complete Operational Parameter Set:
| Parameter | Type | Description | Typical Value |
|---|---|---|---|
| Sequence Number Counter | 64-bit integer | Monotonically increasing counter for each packet sent | Starts at 1 |
| Sequence Number Overflow Flag | Boolean | Whether to allow sequence number to wrap | Usually prohibited |
| Anti-Replay Window | Bitmap + size | Sliding window to detect replayed packets | 64 or 128 packets |
| Extended Sequence Numbers (ESN) | Boolean | Use 64-bit vs 32-bit sequence numbers | Enabled for high-volume |
| SA Mode | Enum | Transport or Tunnel mode | Tunnel for VPN |
| Path MTU | 16-bit integer | Maximum transmission unit for this SA | 1400-1500 bytes |
| DF Bit Policy | Enum | How to handle Don't Fragment bit | Copy, Set, or Clear |
| DSCP Policy | Enum | How to handle Differentiated Services field | Copy or Map |
Sequence Number Mechanics:
The sequence number is critical for anti-replay protection. Each outbound packet gets the next sequence number, and the counter is incremented. The receiver maintains a sliding window of recently received sequence numbers:
With 32-bit sequence numbers, overflow occurs after ~4 billion packets. At 10 Gbps with small packets, this can happen in under an hour! Extended Sequence Numbers (ESN) use 64 bits—only the low 32 bits are transmitted (saving header space), while the high 32 bits are tracked locally and included in authentication computation.
Security Associations have finite lifetimes to limit the exposure from potential key compromise and to ensure cryptographic limits aren't exceeded. Lifetime parameters control when SAs are rekeyed and when they're forcibly deleted.
Lifetime Parameter Types:
| Parameter | Measurement | Purpose | Typical Values |
|---|---|---|---|
| Time-Based Lifetime | Seconds since SA establishment | Limit key exposure duration | 3600-86400 seconds |
| Traffic-Based Lifetime (Bytes) | Total bytes protected | Prevent cryptographic limits | 1-100 GB |
| Traffic-Based Lifetime (Packets) | Total packets protected | Alternative to byte limit | 1M-1B packets |
| Soft Lifetime Threshold | Percentage of hard limit | When to initiate rekeying | 70-80% of hard limit |
| Hard Lifetime | Absolute maximum | When SA is deleted regardless | 120% of soft or absolute value |
Soft vs Hard Lifetime Deep Dive:
The distinction between soft and hard lifetimes is crucial for seamless SA transitions:
Cryptographic Limits:
Lifetime limits aren't arbitrary—they're derived from cryptographic security requirements. Each algorithm has practical limits:
| Algorithm | Recommended Limit | Reason |
|---|---|---|
| AES-GCM-128 | 2^32 packets (4B) | Nonce collision probability threshold |
| AES-GCM-256 | 2^32 packets (4B) | Same nonce limit regardless of key size |
| AES-CBC + HMAC | 2^64 bytes | Birthday bound on block cipher |
| ChaCha20-Poly1305 | 2^64 bytes | Nonce size allows high volume |
Both endpoints should have matching lifetime configurations, but clock drift means they won't expire simultaneously. To prevent both sides racing to rekey: only the ORIGINAL initiator should initiate rekeying. The responder should have a slightly longer lifetime to avoid simultaneous rekey attempts.
We've thoroughly examined every parameter category that defines a complete Security Association. Let's consolidate this knowledge:
What's Next:
Now that we understand individual SA parameters, the next page explores how SAs are organized and managed through the Security Association Database (SAD) and the Security Policy Database (SPD). These databases determine which traffic gets protected and how SA lookups are performed.
You now have detailed knowledge of every parameter that comprises a Security Association. This understanding is essential for configuring IPSec implementations, debugging VPN issues, and understanding security audit reports.