IPsec Headers in Action

IPsec security services are provided through the AH and ESP Headers in conjunction, of course, with appropriate and relevant key management protocols. The AH protocol is specified in RFC 2402, " IP Authentication Header " ; ESP is specified in RFC 2406, " IP Encapsulating Security Payload (ESP). "

Either security header may be used by itself, or both may be used together in various combinations of transport or tunnel modes. When used together with AH encapsulating ESP, packet authentication can be checked prior to decrypting the ESP Header payload. These headers can also be nested when using IPsec tunneling: An originating node can encrypt and digitally sign a packet, and then send it to the local security gateway. That gateway may then reencrypt and resign the packet as it sends it off to another security gateway.

The ESP and AH authentication services are slightly different: ESP authentication services are ordinarily provided only on the packet payload, whereas AH authenticates almost the entire packet including headers.

The Sequence Number field is mandatory for all AH and ESP Headers and is used to provide antireplay services. Every time a new packet is sent, the Sequence Number is increased by one (the first packet sent with a given SA will have a Sequence Number of 1).

When the receiving host elects to use the antireplay service for a particular SA, the host checks the Sequence Number: If it receives a packet with a Sequence Number value that it has already received, that packet is discarded.

The Authentication Data field contains whatever data is required by the authentication mechanisms specified for that particular SA to authenticate the packet. The ICV may contain a keyed Message Authentication Code (MAC) based on a symmetric encryption algorithm (such as AES or Triple-DES) or a one-way hash function such as MD5 or SHA-1.

The most obvious difference between ESP and AH is that the ESP Header's Next Header field appears at the end of the security payload. Of course, since the header may be encapsulating an encrypted payload, you don't need to know what next header to expect until after you've decrypted the payload-thus, the ESP Next Header field is placed after rather than before the payload.

ESP's authentication service covers only the payload itself, not the IP headers of its own packet as with the Authentication Header. And the confidentiality service covers only the payload itself; obviously, you can't encrypt the IP headers of the packet intended to deliver the payload and still expect any intermediate routers to be able to process the packet. Of course, if you're using tunneling, you can encrypt everything, but only everything in the tunneled packet itself.