Summary

  • RFC 2402 computed the Authentication Header Integrity Check Value over a prepared packet view: immutable fields were covered, predictable mutable fields used their expected arrival values, and unpredictable mutable contents were replaced by zero for calculation.
  • A matching ICV did not prove that every observed header bit was unchanged. Fragmentation happened after outbound AH and reassembly before inbound AH; replay checking could be disabled per association, and later policy or application outcomes remained separate.

Suppose a sender authenticates an IPv4 datagram with a Time to Live of 64. A router forwards it and reduces the field. If the receiver authenticated the literal header it observed, the legitimate change would break verification. If the field were simply omitted, its position and length would disappear from the authenticated structure. RFC 2402 chose a third answer: keep the field’s octets in place, but fill them with zero in the input to the Integrity Check Value.

That choice revealed what “packet authentication” meant in the 1998 IP Authentication Header. AH offered connectionless integrity and data-origin authentication, plus optional replay protection selected by the receiver for a Security Association. It did not encrypt. It protected upper-layer data and as much of the IP header as possible, but the RFC itself called header protection piecemeal because some fields necessarily changed in transit.

The AH header carried a Next Header value, a length, reserved bits, a Security Parameters Index, a Sequence Number and variable Authentication Data. The SPI, destination address and AH protocol selected the one-way association. The algorithm and key came from that association. The Sequence Number was always transmitted and incremented even if the receiver chose not to check it for replay.

The ICV input had three kinds of material. Immutable IP fields and upper-layer data were included as themselves. Mutable fields whose arrival value the sender could predict were arranged as they should look at the receiver. Fields liable to unpredictable change were filled with zero. The Authentication Data field itself was also zero during calculation, because it could not contain the result before the result existed.

Zero-fill was not deletion. RFC 2402 explained that leaving the octets in place preserved alignment and authenticated the length of the field even though its contents were outside the check. This produced a prepared view with the same structural footprint as the packet but not the same values in every position. “Canonicalized view” is a useful later description; the RFC spoke of immutable, mutable but predictable, and mutable fields.

IPv4 made the distinction concrete. Version, header length, total length, identification, the AH protocol value, source address and an ordinary destination address entered the ICV unchanged. A destination address affected by loose or strict source routing was mutable but predictable. Type of Service, Flags, Fragment Offset, TTL and Header Checksum were zeroed. The document noted that routers were known to change TOS, might set the Don't Fragment bit, always reduced TTL in normal forwarding, and consequently changed the checksum.

The point was not that those fields did not matter. It was that AH could not honestly promise their original contents at the receiver. A valid ICV therefore could coexist with a lower TTL or another permitted mutable value. It proved agreement over the prepared input, not immobility of the entire wire image.

IPv6 used the same principle with different fields. Class, Flow Label and Hop Limit were zeroed in the 1998 model. A destination address under a routing header could be predicted in its arrival form. Hop-by-Hop and Destination options carried a bit stating whether their Option Data might change en route. Mutable Option Data became zero-valued octets for the ICV, while Option Type and length remained covered. The mechanism depended on later option specifications correctly declaring how new material should be treated.

Padding drew another boundary between calculation and transmission. Explicit padding inside Authentication Data was carried and authenticated. Some algorithms also required implicit zero padding so the calculation input reached a block boundary. Those implicit bytes participated in the ICV but never appeared on the wire. An authentication input could therefore include prepared values and bytes absent from the transmitted datagram.

Fragmentation reinforced that the unit of validation was a reconstructed datagram, not every transport artifact. In transport mode, AH was applied to a whole IP datagram before fragmentation. Routers could later split the protected packet. The receiver had to reassemble those fragments before AH processing; a packet still presented to AH as a fragment was to be discarded and audited. Tunnel mode could, separately, protect an outer packet whose inner payload was already fragmented.

Inbound verification reconstructed the same view. The receiver selected the association, saved the received ICV, zeroed Authentication Data and unpredictable mutable fields, added any required implicit padding, recalculated and compared under the algorithm’s rules. If replay checking was enabled, a candidate sequence number could be screened first, but the receive window advanced only after ICV success. If replay checking was disabled, the present Sequence Number proved no replay decision at all.

RFC 2402 called a matching datagram valid at this AH step. The surrounding RFC 2401 architecture still required inbound policy verification before forwarding or delivery. Application acceptance lay later again. The evidence ladder therefore ran from association and algorithm, through the sender’s prepared view, ICV insertion, possible fragmentation, reassembly, receiver reconstruction and comparison, to optional replay, policy and application receipts.

The specification is historical. It replaced RFC 1826 and was itself replaced by RFC 4302 and RFC 4305. Its mandatory HMAC-MD5 and HMAC-SHA-1 requirements are not current advice. RFC 4302 retained the piecemeal-header principle while revising association lookup, adding extended sequence numbers and moving algorithm requirements elsewhere.

Read through Lu Heng’s later distinction between symbolic authority and running effect, AH’s lesson is austere: an authentication label has force only through the exact executable view that sender and receiver build and compare. That lens is not the RFC’s vocabulary. It simply helps prevent the word “authenticated” from swallowing the fields deliberately excluded, the checks optionally disabled, and the outcomes still waiting downstream.

Sources