RFC 4302

Q: What does the Introduction section cover in RFC 4302 — AH?

The Introduction section provides detailed technical specifications, security considerations, and implementation guidance as documented in RFC 4302 — AH. This content is part of the BLACKLABS RFC Reference Library.

Q: What does the AH Header Format section cover in RFC 4302 — AH?

The AH Header Format section provides detailed technical specifications, security considerations, and implementation guidance as documented in RFC 4302 — AH. This content is part of the BLACKLABS RFC Reference Library.

Q: What does the AH vs ESP Comparison section cover in RFC 4302 — AH?

The AH vs ESP Comparison section provides detailed technical specifications, security considerations, and implementation guidance as documented in RFC 4302 — AH. This content is part of the BLACKLABS RFC Reference Library.

Q: What does the Security Considerations section cover in RFC 4302 — AH?

The Security Considerations section provides detailed technical specifications, security considerations, and implementation guidance as documented in RFC 4302 — AH. This content is part of the BLACKLABS RFC Reference Library.

BLACKLABS

IP Authentication Header

Standards Track Obsoletes: RFC 2402

December 2005

Abstract: This document describes the IP Authentication Header (AH), which provides connectionless integrity, data origin authentication, and optional anti-replay protection for IP datagrams. AH does NOT provide confidentiality (encryption).

Canonical source: https://www.rfc-editor.org/rfc/rfc4302 | IETF Datatracker

1. Introduction

▶

AH provides data integrity and authentication for the entire IP packet including the header (unlike ESP which only protects the payload). However, AH does NOT provide encryption.

AH is defined for completeness in the IPsec architecture but is NOT used in 3GPP NDS/IP. TS 33.210 exclusively uses ESP (RFC 4303) for both confidentiality and integrity.

3GPP Note: AH is NOT used in 3GPP NDS/IP implementations. ESP with authentication provides equivalent integrity plus confidentiality. This RFC is referenced for IPsec architecture completeness.

2. AH Header Format

▶

AH is IP protocol number 51. The ICV covers the entire IP packet with mutable fields (TTL, header checksum) set to zero before computation.

  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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|  Next Header  |  Payload Len  |           RESERVED          |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                 Security Parameters Index (SPI)             |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                    Sequence Number Field                    |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                                                             |
+                Integrity Check Value (ICV)                  +
|                         (variable)                          |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

3. AH vs ESP Comparison

▶

Feature	AH (RFC 4302)	ESP (RFC 4303)
Confidentiality	No	Yes
Payload authentication	Yes	Yes
IP header authentication	Yes (immutable fields)	No (outer header)
Anti-replay	Yes	Yes
NAT traversal	No (breaks checksum)	Yes (UDP encapsulation)
3GPP NDS/IP usage	NOT used	MANDATORY

4. Security Considerations

▶

AH cannot traverse NAT devices because the authentication covers IP addresses which NAT modifies
AH provides no confidentiality — payload is transmitted in plaintext
ESP with authentication provides superset functionality and is universally preferred
AH remains in specifications for backward compatibility and niche use cases requiring IP header integrity