The Authentication Header carries all the information necessary for a receiving system to validate a packet's integrity and origin. Unlike many complex protocol headers with numerous optional fields, AH is remarkably straightforward—a design that reflects its focused purpose and enables efficient processing.

Every bit in the AH header serves a specific function. Understanding this structure is essential for:

• Implementing IPSec solutions at the system level
• Debugging authentication failures in production networks
• Analyzing packet captures during security investigations
• Understanding overhead implications for network capacity planning
• Configuring security policies that interact with AH-protected traffic

The Authentication Header consists of a fixed portion (12 bytes) followed by a variable-length Integrity Check Value (ICV). The total header size must be a multiple of 32 bits (4 bytes) for IPv4 or 64 bits (8 bytes) for IPv6 to maintain proper alignment.

Complete AH Header Structure:

Minimum Header Size:

• Fixed portion: 12 bytes
• Minimum ICV (HMAC-MD5-96, HMAC-SHA1-96): 12 bytes (96 bits truncated)
• Minimum total AH header: 24 bytes

Typical Header Sizes:

The header size directly impacts network overhead. For small packets (e.g., 64-byte minimum Ethernet frames), AH can represent 30%+ additional data.

The Next Header field (8 bits) identifies the type of header or protocol that immediately follows the Authentication Header. This field uses the same protocol number space as the IPv4 Protocol field and IPv6 Next Header field, maintained by IANA.

Common Values:

Operational Significance:

The Next Header field is critical for proper packet processing. After validating the AH ICV, the receiver uses this field to determine how to handle the rest of the packet:

1. Transport Mode: Next Header typically indicates the upper-layer protocol (TCP=6, UDP=17, etc.)
2. Tunnel Mode: Next Header indicates IP (4 for IPv4, 41 for IPv6), signifying an encapsulated packet
3. Nested Security: When AH protects ESP, Next Header is 50—the receiver knows to process ESP next

IPv4 Integration:

In IPv4 packets, AH is identified by protocol number 51 in the IP header's Protocol field. The IP header's Protocol field points to AH, and AH's Next Header field points to the next layer.

IPv6 Integration:

In IPv6, AH is an extension header (protocol 51). It chains with other extension headers using the Next Header mechanism. IPv6's streamlined design makes AH integration particularly elegant—it fits naturally into the extension header chain.

The Payload Length field (8 bits) specifies the length of the AH header in 32-bit (4-byte) units, minus 2. This unusual encoding requires careful interpretation.

Formula:

Payload Length Value = (AH Header Length in bytes / 4) - 2

Why "Minus 2"?

The original IPSec specification used a length encoding that counts 32-bit words. Subtracting 2 accounts for the minimum data before the ICV (Next Header + Payload Length + Reserved = 4 bytes, plus SPI = 4 bytes = 8 bytes = 2 words).

Calculation Examples:

Decoding the Field:

To calculate the actual AH header length from the Payload Length field:

AH Header Length (bytes) = (Payload Length + 2) × 4

Example Decode:

• Payload Length field value: 4
• AH Header Length = (4 + 2) × 4 = 24 bytes

Practical Implications:

1. Maximum Value: 8 bits allow values 0-255, theoretically supporting headers up to (255 + 2) × 4 = 1028 bytes
2. Minimum Value: Value of 4 corresponds to 24-byte header (12-byte fixed + 12-byte minimum ICV)
3. Value 0: Invalid for standard AH—would indicate an 8-byte header with no ICV, which defeats the purpose

Implementation Consideration:

When implementing AH processing, always validate the Payload Length makes sense:

• Verify the calculated length doesn't exceed packet size
• Ensure the length matches expected ICV size for the negotiated algorithm
• Reject packets with inconsistent length values to prevent buffer overflow attacks

The Reserved field is 16 bits (2 bytes) set aside for future use. Per RFC 4302:

• Senders MUST set this field to zero
• Receivers MUST ignore this field

Purpose:

Reserved fields allow protocol evolution without changing header structure. If future requirements emerge—such as new flags, quality-of-service indicators, or extended capabilities—this field provides space for expansion while maintaining backward compatibility with existing implementations.

Current Usage:

Despite being defined in 1998 (RFC 2402) and formalized in 2005 (RFC 4302), the Reserved field remains unused. No RFCs have allocated bits from this field for any purpose.

Implementation Requirements:

Why 16 Bits?

The Reserved field size maintains 32-bit alignment for the first row of the header (Next Header + Payload Length + Reserved = 32 bits). This alignment optimizes processing on most CPU architectures, where 32-bit aligned reads are most efficient.

Comparison with ESP:

Interestingly, ESP has no equivalent reserved field—its header is more tightly packed. AH's reserved field reflects the original design philosophy of allowing future enhancement without protocol revision.

The Security Parameters Index (SPI) is a 32-bit field that, combined with the destination IP address and the security protocol (AH or ESP), uniquely identifies the Security Association for this packet.

Fundamental Concept:

The SPI is the key that unlocks SA lookup. When a packet arrives, the receiver uses:

(Destination IP Address + Protocol + SPI) → Security Association

This triplet maps to a unique SA in the receiver's Security Association Database (SAD), which contains all parameters needed to authenticate the packet.

SPI Value Ranges:

SPI Assignment:

The SPI is selected by the receiving host during SA establishment. This is critical for understanding who "owns" an SPI:

• Host A initiates communication with Host B
• SA from A→B: SPI chosen by B (B will receive these packets)
• SA from B→A: SPI chosen by A (A will receive these packets)
• Each direction has its own SA with its own SPI

IKE and SPI Negotiation:

During IKE negotiation:

1. Initiator proposes an SA with algorithms and parameters
2. Responder accepts and provides the SPI for the SA in that direction
3. For bidirectional communication, this happens twice (once per direction)
4. Each party stores the SPI it assigned for incoming packets

Uniqueness Requirements:

SPIs must be unique for:

• A given destination IP address
• A given protocol (AH or ESP)

Different destination IPs can use the same SPI value. Different protocols (AH and ESP) for the same destination can use the same SPI value. This scoping minimizes the risk of SPI exhaustion in large-scale deployments.

The Sequence Number field is a 32-bit unsigned integer that provides anti-replay protection. Each packet transmitted using a particular SA has a unique, monotonically increasing sequence number.

Sender Behavior:

1. Maintain a 32-bit counter for each SA, initialized to 0 when SA is established
2. Before transmitting, increment the counter by 1
3. Insert the counter value into the Sequence Number field
4. The counter MUST NOT cycle—when it reaches 2³² - 1, a new SA must be established

Receiver Behavior:

1. Maintain a counter and anti-replay window for each SA
2. When a packet arrives, check if sequence number falls within the acceptable window
3. If sequence number is valid, verify ICV; if ICV valid, update window to include this sequence number
4. Reject packets with sequence numbers below window or already received

Counter Lifecycle:

Sequence Number Window:

Receivers maintain a sliding window (typically 32 or 64 packets wide) to accommodate out-of-order packet delivery:

Window of size W, right edge at R
Acceptable range: [R - W + 1, R]

Example (W=32, R=100):
Acceptable: 69-100
Packet 70 arriving after 71-100: Accepted (in window, not yet seen)
Packet 68: Rejected (below window)
Packet 73: Rejected (already seen—replay attempt)

Extended Sequence Numbers (ESN):

RFC 4302 supports 64-bit Extended Sequence Numbers for high-bandwidth connections. With ESN:

• Full 64-bit counter maintained internally
• Only lower 32 bits transmitted in packet (to preserve header format)
• Upper 32 bits reconstructed at receiver using window logic
• Enables 2⁶⁴ packets per SA—sufficient for decades at high rates

Why This Matters:

Without sequence numbers, an attacker could:

• Capture a legitimate "transfer $1000" packet
• Replay it 1000 times
• Trigger $1,000,000 in unauthorized transfers

The sequence number ensures each packet is processed exactly once.

The Integrity Check Value (ICV) is the cryptographic heart of the Authentication Header. It's a variable-length field containing the output of the authentication algorithm applied to protected portions of the packet.

ICV Computation:

The ICV is computed over:

1. IP header fields that don't change in transit (immutable)
2. Mutable-but-predictable fields (set to predicted value or zero)
3. The complete AH header (with ICV field temporarily set to zero)
4. The entire upper-layer payload

Algorithm Selection:

The authentication algorithm is specified in the SA. Common choices include:

ICV Computation Process:

Handling Mutable Fields:

Certain IP header fields change as packets traverse the network. For ICV computation, these are handled specially:

Truncation:

Many algorithms specify truncated ICVs (e.g., "96" in HMAC-SHA1-96). Truncation:

• Reduces overhead (full SHA-1 is 160 bits; 96 bits is transmitted)
• Maintains security margin (96 bits provides sufficient collision resistance)
• Ensures alignment (96 bits = 12 bytes, maintaining 32-bit alignment)

Let's examine how AH headers integrate with complete IP packets in both transport and tunnel modes.

Example 1: IPv4 Transport Mode (TCP Traffic)

Original packet: 192.168.1.10 → 192.168.1.20, TCP port 443 (HTTPS)

Example 2: IPv4 Tunnel Mode (Site-to-Site)

Internal hosts (10.0.1.0/24) communicating through VPN gateways:

We've thoroughly examined every component of the Authentication Header. Let's consolidate the essential knowledge:

What's Next:

With a complete understanding of AH's format, we're ready to explore how it provides integrity protection. The next page examines the cryptographic mechanisms—how ICVs are computed, which fields are protected, and how receivers validate authenticity at the packet level.