11.2. The AH Header

Figure 11.2 shows the format of the AH header. As mentioned earlier, its exact placement in an IP datagram depends on whether we are using transport or tunnel mode. We will show the exact placement in the sections covering these modes.

Figure 11.2. The AH Header

[View full size image]

The next header field is the protocol number of the AH payload. For example, if AH is protecting a TCP segment, the next header field would contain a 6, the protocol number assigned to TCP. AH could be followed by an ESP (Chapter 12) packet or even another AH header, so we shouldn't think that only the TCP or UDP protocol numbers can occur in the next header field.

The payload length field is confusing for two reasons. First, despite its name, it is the length of the AH header, not the length of the payload that AH is protecting. Second, the length is expressed as 2 less than the number of 32-bit words in the header. For example, if the ICV is a 160-bit SHA-1 HMAC (five words), the length of the entire header would be eight 32-bits words, and the header length field would contain a 6.

The "minus 2" is an artifact of AH being an IPv6 protocol. In IPv6, extension header lengths are always expressed as the total length minus 64 bits, or in our case, two 32-bit words. The IPv6 extension header length convention is specified in RFC 2460 [Deering and Hinden 1998].

The security parameter index, along with the destination address and protocol (AH) identifies the SA to which this AH datagram applies. Values 1255 are reserved for future use and are not currently assigned. The value 0 is reserved for local use and is never transmitted to a peer. Thus, the legal values for the SPI are 256 through 2³² - 1. The SPI is always assigned by the destination host, which is why the destination address is needed to uniquely identify the proper SA.

The sequence number field is a counter that increases by 1 for each AH datagram that a host sends for a particular SA. The initial value of the counter is 1. For reasons explained below, the sequence number is never allowed to wrap to 0. A sending host is required to check that the sequence number hasn't wrapped and to negotiate a new SA if it has.

The receiving host uses the sequence number to detect replayed datagrams. The checking on the receiving host's part is optional, and the receiver can inform the sender that it will not be checking sequence numbers, but the sender is always required to increment and send the sequence number. If its peer has informed it that it will not do sequence number checking, the sender can omit checking for sequence number wrapping. We will examine how the receiver checks the sequence numbers in the next section.

The authentication data field contains the result of the ICV calculation. The field is always a multiple of 32-bit words and must be padded in an arbitrary way if the length of the ICV in bytes is not divisible by 4. RFC 2402 allows the use of any MAC that the implementer wishes but requires that all implementations support at least HMAC-MD5-96 [Madson and Glenn 1998a] and HMAC-SHA1-96 [Madson and Glenn 1998b].

When calculating the IVC, the authentication data field is first zeroed and then replaced with the value of the IVC.