IP Authentication Header
obsoleted by
- rfc-4302 — IP Authentication Header
- rfc-4305 — Cryptographic Algorithm Implementation Requirements for Encapsulating Security Payload (ESP) and Authentication Header (AH)
obsoletes
- rfc-1826 — IP Authentication Header
Extracted elements (29)
Mutable fields are set to zero (not omitted) during ICV computation to preserve field alignment and prevent the length of zero-filled fields from being changed in transit, even though their contents are not explicitly covered by the ICV.
The anti-replay sequence number is made an integral, mandatory part of AH (not a transform-defined option as in RFC 1826) to ensure consistent implementation. The default mandatory-to-implement algorithms were changed from keyed MD5 to HMAC-MD5 and HMAC-SHA-1 for security reasons.
The IPv4 TOS, Flags, Fragment Offset, TTL, and Header Checksum fields are excluded from AH ICV computation because: TOS is known to be modified by routers in practice; intermediate routers may set the DF flag; Fragment Offset is always zero (AH applied only to non-fragments); TTL is decremented en route; and Header Checksum changes whenever any of the other excluded fields change.
The IPv6 Routing Header (Type 0) is treated as mutable but predictable: although it rearranges address fields during transit, the final state at the receiver is known to the sender. The sender must reorder the Routing Header fields to their expected received form before ICV computation.
If the IPsec implementation encounters an IPv4 option it does not recognize, it should zero the whole option using the second byte (length) of the option. IPv6 options carry a per-option mutability bit that determines whether the Option Data is zeroed during ICV computation.
On the receive side, if the IP implementation leaves a Fragmentation Extension Header in a reassembled IPv6 packet, AH MUST remove or skip over it and update the previous header's Next Header field before ICV processing. The same applies on the send side if a Fragmentation Extension Header with Offset 0 and More Fragments=0 is passed to IPsec.
The protocol header immediately preceding the AH header MUST contain the value 51 in its Protocol (IPv4) or Next Header (IPv6/Extension) field, as assigned by IANA [STD-2].
Use of the IPv4 Router Alert option (classified immutable) is potentially incompatible with IPsec/AH because routers processing the option may modify the packet. This would require each router on the path to be a member of a multicast-SA defined by the SPI, which requires multicast SA support not currently available.
All AH implementations MUST support the anti-replay service, though its use may be enabled or disabled by the receiver on a per-SA basis. The anti-replay service SHOULD NOT be used in a multi-sender environment that employs a single SA, as there is no mechanism to manage transmitted Sequence Numbers among multiple senders.
All implementations MUST support padding in the Authentication Data field to ensure the AH header is a multiple of 32 bits (IPv4) or 64 bits (IPv6). The authentication algorithm specification MUST also define the ICV length, comparison rules, and processing steps for validation.
Conformant AH implementations MUST support HMAC with MD5 and HMAC with SHA-1 as mandatory-to-implement authentication algorithms. A compliant implementation SHOULD NOT provide the anti-replay service in conjunction with manually-keyed SAs.
For implicit packet padding required by some authentication algorithms, padding octets MUST have a value of zero. This padding is appended before ICV computation but is NOT transmitted with the packet.
If a packet offered to AH for inbound processing appears to be an IP fragment (OFFSET field non-zero or MORE FRAGMENTS flag set), the receiver MUST discard the packet; this is an auditable event. The audit log SHOULD include SPI, date/time, source and destination addresses, and (in IPv6) the Flow ID.
If AH is incorporated into a system that supports auditing, the AH implementation MUST also support auditing and MUST allow a system administrator to enable or disable auditing for AH. There is no requirement for the receiver to transmit any message to the sender in response to an auditable event, to prevent denial of service.
If ICV validation fails, the receiver MUST discard the received IP datagram as invalid; this is an auditable event. The receive window is updated only if ICV verification succeeds.
If no valid Security Association exists for a received packet, the receiver MUST discard it; this is an auditable event. The audit log SHOULD include the SPI value, date/time, source and destination addresses, and (in IPv6) the Flow ID.
The anti-replay sliding receive window MUST support a minimum size of 32; a window size of 64 is preferred and SHOULD be employed as the default. Packets with Sequence Numbers below the left edge of the window are rejected.
The Reserved 16-bit field MUST be set to zero by the sender. Its value is included in the Authentication Data calculation but otherwise ignored by the recipient.
The sender MUST always transmit the Sequence Number field. If anti-replay is enabled, the transmitted Sequence Number must never be allowed to cycle; the sender MUST NOT send a packet that would cause the Sequence Number to overflow. A new SA (and key) must be established before the 2^32nd packet.
The SPI value of zero (0) MUST NOT be sent on the wire; it is reserved for local, implementation-specific use such as signaling 'No Security Association Exists' to key management.
When multiple IPsec headers are required, the order of application MUST be defined by security policy. Each IPsec header SHOULD ignore (not zero or predict) the contents of IPsec headers to be applied later.
In transport mode, AH is inserted after the IP header (and any options) and before the upper-layer protocol. In tunnel mode, AH follows the outer IP header and protects the entire inner IP packet including its header. When AH is implemented in a security gateway protecting transit traffic, tunnel mode MUST be used.
The Authentication Data field is a variable-length field containing the Integrity Check Value (ICV). It must be an integral multiple of 32 bits and may include explicit padding to ensure the AH header is a multiple of 32 bits (IPv4) or 64 bits (IPv6).
The Security Parameters Index (SPI) is an arbitrary 32-bit value that, combined with the destination IP address and security protocol (AH), uniquely identifies the Security Association for a datagram. SPI values 1–255 are reserved by IANA; SPI 0 is reserved for local implementation-specific use.
The Sequence Number is a mandatory, monotonically increasing unsigned 32-bit counter initialized to 0 when an SA is established; the first packet on a given SA has Sequence Number 1. The field is always present even if the receiver does not enable anti-replay.
AH provides connectionless integrity and data origin authentication for IP datagrams, covering as much of the IP header as possible. Fields that may change unpredictably in transit (TOS, TTL, Flags, Header Checksum) are excluded, making AH's IP header protection piecemeal. ESP does not protect any IP header fields unless those fields are encapsulated in tunnel mode.
The anti-replay service is effective only if the receiver actually checks the Sequence Number. Adding or removing IP security labels (BSO, ESO, CIPSO) along a packet's path conflicts with those options' classification as immutable and is incompatible with use of IPsec/AH.
The anti-replay sliding window tracks received Sequence Numbers for a given SA. States: window initialized to zero at SA establishment; packets to the right of the window trigger ICV verification before window advancement; packets within the window are checked against a received-packet bitmask; packets to the left of the window are unconditionally rejected. The window right edge advances only on successful ICV verification.
The AH header consists of: Next Header (8-bit), Payload Len (8-bit, length in 32-bit words minus 2), Reserved (16-bit, zero), SPI (32-bit), Sequence Number (32-bit), and Authentication Data (variable-length, multiple of 32 bits). The IP protocol number immediately preceding AH is 51.