The AH provides data integrity, origin authentication, and optional replay resistance.
The first aspect of AH that surfaces is that it does not provide any form of confidentiality.
As a matter of fact, its primary function is to provide authentication services to the communication. Because AH does not provide confidentiality, there is no need for an encryption algorithm to be defined.
As detailed in Exhibit 8-3, the AH header contains several fields for the creation and maintenance of an SA.
In the IP header, the 8-bit protocol field will be 51. AH is defined as protocol 51 by the IANA. That is, the next header following the outside IP header will be an AH.
Much like ESP, the standard does not directly address the massage authentication code, but merely its utilization. Also, replay resistance is an option and requires the recipient to perform all the functions.
The similarities between ESP and AH tend to dissolve as the inner workings of the AH security protocol are investigated. AH provides authentication out to the outer IP header. It provides authentication services for the upper layer protocols, just like ESP, but ESP cannot authenticate the outer IP header. Once the packet is assembled, the AH process authenticates the entire packet and inserts itself into the packet.
The Next Header field is exactly like it sounds, unlike ESP. It defines the next header in the packet immediately following the authentication data. Of course, for nested operations, the Next Header could an IPSec security protocol.
The Payload Length defines the length, in 32-bit words, the amount of authentication data. The value is determined by subtracting 2 from the 32-bit words. As an example provided in the AH RFC, in the case of a 96-bit authentication value plus the 3 32-bit word fixed portion (equals “6”), this length field will be “4.”
The reserved field is always set to zero. This is followed by the SPI for the SA in which the security protocol is participating. The next value is the 32-bin Sequence Number. The same issues that existed with the ESP Sequence Number and anti-replay protection exist with AH Sequence Numbers.
The authentication data is the message digest, or authenticator used to verify the entire packet. Once again, the size is partially controlled by the message authentication function selected. However, because the value must a multiple of 32 bits, padding may be required.
AH Placement
As discussed above with ESP, the placement of the AH header is dependant on the mode of communication. In transport mode, the header is inserted after the IP header and options, and before any upper layer protocols, including other IPSec headers. In tunnel mode, the original packet is placed behind the header, and the new IP header and options preceed the AH header (see Exhibit 8-4). From the perspective of the outer IP header, AH placement is the same as in transport mode.
Process Execution
There is a sequence of steps required to properly apply the AH. Much like ESP, the procedures are directly related to the direction of the data: outbound or inbound.
Outbound Process. There are four general steps to processing the application of AH to a packet:
Exhibit 8-3. AH header.
Next Header Payload Len. Reserved
Authentication Data (Variable) Sequence Number Field Security Parameters Index (SPI)
0 31
1. Determine the associated SA that calls for AH processing by the available infor-mation in the original packet; for example, IP address (source and destination).
2. Once the communication is determined to have AH applied, the header is inserted after the IP header and the SPI is implemented.
3. Generate a sequence number for application to the header.
4. Calculate and apply the message integrity, pad the digest, and apply to the end of the AH and before the upper layer protocols.
Because the AH is designed for authentication purposes, creating the authentication data that covers the entire packet requires some refined techniques when compared to ESP. During the authentication process, several aspects must be calculated, including:
g Determine IP header fields that are immutable and mutable.
g Set mutable fields to zero.
g Collect AH header information; the authentication data is set to zero.
g Collect the upper layer protocol information, assumed to be immutable.
An immutable field is predictable in that it will not change or be modified in transit. A mutable field is a value that may be changed in transit, and therefore invalidate the message digest that will be checked by the recipient. Mutable fields cannot be included in the authentication process. Therefore, once they are determined, they are set to zero prior to executing the authentication process. The fields are set to zero and not removed from the authentication process to allow proper alignment to be preserved. The follow-ing list defines the mutable and immutable fields of an IP header, also shown in Exhibit 8-5.
g Immutable (to be included in the authentication process):
— version
— IP header length
Exhibit 8-4. AH packet structure within tunnel mode and transport mode.
— total length
— identification
— protocol (will equal 51 for the AH)
— source address
— destination address
g Mutable (to be set to zero prior to authentication calculation):
— type of service
— all flags
— fragment offset
— time to live (TTL)
— header checksum
Inbound Process. As with ESP, if fragmentation occurred in transit, the reassembly is performed prior to IPSec processing the AH. Once the assembly is complete, there are several verification steps to complete. The association of the datagram to the appropriate SA must be executed to determine if the communication received for that SA is valid.
The packet’s data is checked. The verification steps include:
1. The SPI in AH and the destination IP address are used to look up the SA in the SAD. If this process fails, the packet is dropped.
2. Verify the sequence number if anti-replay is enabled.
3. Use the SA determined in the previous step to authenticate the packet.
4. Forward the data to the final destination based on the IP header information.