AH

Integrity Protection Process
The first step of integrity protection is to create a hash by using a keyed hash algorithm, also known as a message authentication code (MAC) algorithm. A standard hash algorithm generates a hash based on a message, while a keyed hash algorithm creates a hash based on both a message and a secret key shared by the two endpoints. The hash is added to the packet, and the packet is sent to the recipient. The recipient can then regenerate the hash using the shared key and confirm that the two hashes match, which provides integrity protection for the packet. IPsec uses hash message authentication code (HMAC) algorithms,18 which perform two keyed hashes. Examples of keyed hash algorithms are HMAC-MD5 and HMAC-SHA-1.19 Another common MAC algorithm is AES Cipher Block Chaining MAC (AES-XCBC-MAC-96).20
Technically, Figures 3-1 and 3-2 are somewhat misleading because it is not possible to protect the integrity of the entire IP header. Certain IP header fields, such as time to live (TTL) and the IP header checksum, are dynamic and may change during routine communications. If the hash is calculated on all the original IP header values, and some of those values legitimately change in transit, the recalculated hash will be different. The destination would conclude that the packet had changed in transit and that its integrity had been violated. To avoid this problem, IP header fields that may legitimately change in transit in an unpredictable manner are excluded from the integrity protection calculations.
This same principle explains why AH is often incompatible with network address translation (NAT) implementations. The IP source and destination address fields are included in the AH integrity protection calculations. If these addresses are altered by a NAT device (e.g., changing the source address from a private to a public address), the AH integrity protection calculation made by the destination will not match. (Section 4.2.1 contains information on techniques for overcoming NAT-related issues.)

Figure 3-5 shows the AH header fields from the first four packets in an AH session between hosts A and B. The fields in the first header have been labeled, and they correspond to the fields identified in Figure 3-3. Items of interest are as follows:
SPI. Host A uses the hex value cdb59934 for the SPI in both its packets, while host B uses the hex value a6b32c00 for the SPI in both packets. This reflects that an AH connection is actually composed of two one-way connections, each with its own SPI.
Sequence Number. Both hosts initially set the sequence number to 1, and both incremented the number to 2 for their second packets.
Authentication Information. The authentication (integrity protection) information, which is a keyed hash based on virtually all the bytes in the packet, is different in each packet. This value should be different even if only one byte in a hashed section of the packet changes.

Figure 3-5. AH Header Fields from Sample Packet

AH Version 3
A new standard for AH, version 3, is currently in development.23 Based on the current standard draft, the functional differences between version 2 and version 3 should be relatively minor to IPsec administrators and users—some modifications to the SPI, and an optional longer sequence number. The version 3 standard draft also points to another standard draft that lists cryptographic algorithm requirements for

AH.24 The draft mandates support for HMAC-SHA1-96, strongly recommends support for AES-XCBC-MAC-96, and also recommends support for HMAC-MD5-96.

The current draft of the proposed standard for AH version 3 is available at http://www.ietf.org/internet-drafts/draft-ietf-ipsec-rfc2402bis-xx.txt. There is also a new proposed standard to replace RFC 2401, which provides an overview of IPsec version 2 (which includes AH version 2 and ESP version 2). The current version of the replacement for RFC 2401 is available at http://www.ietf.org/internet-drafts/draft-ietf-ipsec-rfc2401bis-xx.txt.

 

 3.1.6
3.2.1
AH Summary
AH provides integrity protection for all packet headers and data, with the exception of a few IP header fields that routinely change in transit.
Because AH includes source and destination IP addresses in its integrity protection calculations, AH is often incompatible with NAT. Section 4 describes techniques for overcoming this.
Currently, most IPsec implementations support the second version of IPsec, in which ESP can provide integrity protection services through authentication. The use of AH has significantly declined. In fact, some IPsec implementations no longer support AH.
AH still provides one benefit that ESP does not: integrity protection for the outermost IP header