IPSec (2nd Edition) - page 39

AH Processing

When an outbound packet matches an SPD entry indicating protection with AH, the SADB is queried to see whether a suitable SA exists. If there is no SA, IKE can be used to dynamically create one. If there is an SA, AH is applied to the matched packet in the mode dictated by the SPD entry. If there is an SPD bundle, the order of application depends on the protocols involved. AH always protects ESP, not the other way around.

Output Processing

As mentioned in Chapter 3, when an outbound SA is created—either manually or by IKE—the sequence number counter is initialized to zero. Prior to construction of an AH header using this SA, the counter is incremented. This guarantees that the sequence number in each AH header will be a unique, nonzero, and a monotonically increasing number.

The remaining fields of the AH header are filled in with their appropriate value—the SPI field is assigned the SPI from the SA; the next header field is assigned the value of the type of data following the AH header; and the payload length is assigned the number of 32-bit-words-minus-two value discussed above; and the authentication data field is set to zero.

Unlike ESP, AH extends its protection to immutable or predictable fields of the outer IP header. It is therefore necessary to zero out the mutable fields prior to computation of the Integrity Check Value (ICV). The mutable fields of an IPv4 header that are not included in the authenticating ICV (and are therefore " unprotected ") are the shaded fields in Figure 6.4.

For IPv4 options or IPv6 extension headers, if they are immutable or predictable, they are included in the computation of the ICV. Otherwise, it is necessary to zero them out before computing the ICV.

Padding may be needed depending on the requirements of the authenticator or for alignment reasons. Some MACs—for instance, DES-CBC MAC—require the data over which the MAC is applied be a multiple of the algorithm's block size . In this case padding must be added to properly use the MAC. (Note that neither of the mandatory algorithms have this requirement.) This padding is implicitly added. It must be entirely of the value "zero", and its size is not included in the payload length and is not transmitted with the packet.

The AH header must be a multiple of 32 bits for IPv4 and 64 bits for IPv6. If the output of the MAC is such that this requirement is not met, the AH header must be padded . There is no requirement on the value of the pad, but it must be included in the ICV calculations and the pad size must be reflected in the payload length. The mandatory-to-implement authenticators are properly aligned, so no padding is needed when using HMAC-MD5-96 or HMAC-SHA-96.

The ICV is calculated by passing the key from the SA and the entire IP packet (including the AH header) to the algorithm identified as the authenticator in the SA. Since the mutable fields have been zeroed out the actual values are not included in the ICV. The ICV value is then copied into authentication data field of the AH and the mutable fields in the IP header can be filled in.

AH processing is now complete and the AH-protected IP packet can be transmitted. Depending on the size of the packet, it might be fragmented prior to placing on the wire or it might be fragmented in transit by routers between the two IPSec peers. This is not a problem and is taken care of during input processing.

Input Processing

Reassembly may be required prior to AH input processing if the protected packet was fragmented prior to its receipt. This is a fairly obvious requirement since the ICV check will fail unless it is done on exactly the same data from which the ICV was generated. The Authentication Header document (RFC2402) notes that the current specification of IPv4 does not require the offset field to be zeroed or the more fragments flag to be cleared after reassembly. AH therefore imposes this requirement on reassembly to guarantee that the inbound packet resembles the outbound packet the peer sent. A fully- formed , AH-protected IP packet can then be passed on to AH input processing.

The first thing to do when processing any IPSec packet is to find the SA that was used to protect it, and AH is no different than ESP in this respect. The SA is, again, identified by the destination address of the IP header, the protocol (in this case 51), and the SPI from the AH header. If no SA is found, the packet is discarded.

Once the SA is found, a sequence number check is made. This step is optional but the cost-to-benefit ratio is so low that there is really no reason not to perform an antireplay check. The antireplay check (described in Chapter 3) determines whether this packet is new or received too late. If it fails this check it is discarded.

The ICV must now be checked. First, the ICV value in the authentication data field of the AH header is saved and that field is zeroed. All mutable fields in the IP are also zeroed (these are the same fields, described above, that were zeroed prior to ICV calculation). If the authenticator algorithm and payload length are such that implicit padding is required to bring the size of the data authenticated up to the requirements of the algorithm, implicit padding is added. This implicit padding must contain the value zero. The authenticator algorithm is then applied to the entire packet and the resulting digest is compared to the saved ICV value. If they match, the IP packet has been authenticated; if they do not match the packet must be discarded.

Once the ICV has been verified , the sequence number of the sliding receive window can be advanced if necessary. This concludes AH processing. The saved IP header can then be restored—remember that the mutable fields were zeroed out and this would prevent further processing—and the entire authenticated datagram can be passed to IP processing.