11.1. Introduction

An unprotected IP datagram is subject to arbitrary manipulation by an attacker. The header is covered by the usual Internet checksum, but this provides protection only against corruption; an attacker can modify any of the header fields and be undetected by merely recalculating the checksum. The same principle applies to the data portion. Datagrams carrying TCP segments or UDP datagrams have their data protected by another Internet checksum, but again, the data is easily manipulated by an attacker, who needs only modify the data and recalculate the checksum.

Some situations require that hosts or networks be able to verify that IP datagrams are from whom they purport to be and that their payloads have not been tampered with in transit. As we shall see in Chapter 12, ESP can provide these services along with the confidentiality afforded by encryption. In some instances, however, confidentiality is not required, and in those cases, it makes sense to forgo the unneeded and expensive encryption step. The Authentication Header (AH) protocol provides endpoint authentication and data integrity without the overhead of encryption, thereby supplying exactly what's required in these situations.

In Chapter 12, we will see that ESP can also provide authentication and integrity functions without encryption. The IPsec working group consensus is that AH is still useful because its authentication function is subtly different from that of ESP. Not everyone agrees; see [Ferguson and Schneier 1999], for example.

The AH protocol is specified in RFC 2402 [Kent and Atkinson 1998a]. AH provides its protection by calculating a keyed MAC, called an integrity check value (ICV), over parts of the IP header and the entire payload data. The results of the ICV are placed in the AH header, and the header is added to the IP datagram. The exact placement of the AH header in the datagram depends on whether it is being used in transport or tunnel mode.

A moment's thought makes it clear that AH can't authenticate the entire IP header, because some of its fields are changed by intermediate routers. Figure 11.1 shows the fields of the IP header that AH does and does not authenticate.

Figure 11.1. IP Header Fields Authenticated by AH

[View full size image]

The shaded fields are mutable, are not covered by the authentication, and are zeroed before calculating the ICV. In addition, the destination address is specified as being mutable but predictable, meaning that it can be changed by intermediate routers but that the final value is known. The destination address is mutable but predictable when source routing is used. In this case, the predictable value is the final destination address, which is what the end host will see, so that value is filled in before the ICV is calculated.

Figure 11.1 doesn't show any IP options, but like the fields in the header itself, some options are mutable and must be zeroed before calculating the ICV. RFC 2402 has a complete list, but the common mutable IP options are the loose and strict source route, the timestamp, and the record route.

AH is an IP protocol and as such has its own IP protocol number: 51. As we'll see, the AH header always immediately follows an IP header, and the protocol field of that header will contain a 51, indicating that the datagram is carrying AH protocol data.