Networking / Beginners

---

Encapsulating Security Payload (ESP)

Specified in RFC 2406, " IP Encapsulating Security Payload (ESP), " the ESP Header allows IP nodes to exchange datagrams whose payloads are encrypted. The ESP Header is designed to provide several different services (some overlapping with the Authentication Header), including the following.

• Confidentiality of datagrams through encryption
• Authentication of data origin through the use of public key encryption
• Antireplay services through the same sequence number mechanism as provided by the Authentication Header
• Limited traffic flow confidentiality through the use of security gateways

The ESP Header can be used in conjunction with an Authentication Header. In fact, unless the ESP Header uses some mechanism for authentication, it is recommended that the Authentication Header be used with the ESP Header.

The ESP Header must follow any headers that need to be processed by nodes intermediate to the destination node-all data that follows the ESP Header will be encrypted, with the encrypted payload beginning directly after the last ESP Header field (see following).

ESP can be used in tunnel or transport mode, similar to the Authentication Header. In transport mode, the IP Header and any Hop-by-Hop, Routing, or Fragmentation Extension Headers precede the Authentication Header (if present), followed by the ESP Header. Any Destination Options Headers can either precedeor follow the ESP Header, or even both; any Headers that follow the ESP Header are encrypted.

The result appears, in many respects, to simply be a regular IP datagram transmitted from source to destination, with an encrypted payload. This use of ESP in transport mode is appropriate in some cases, but it allows attackers to study traffic between the two nodes, noting which nodes are communicating, how much data they exchange, when they exchange it, and so forth. All this information may potentially provide the attacker with some information that helps defeat the communicating parties.

An alternative is to use a security gateway, much as just described for the Authentication Header. A security gateway can operate directly with a node or can link to another security gateway. A single node can use ESP in tunnel mode by encrypting all outbound packets and encapsulating them in a separate stream of IP datagrams that are sent to the security gateway. That gateway then can decrypt the traffic and resend the original datagrams to their destinations.

When tunneling, the ESP Header encapsulates the entire tunneled IP datagram and is an extension to the IP Header directing that datagram to a security gateway. It is also possible to combine ESP Headers with Authentication Headers in several different ways; for example, the tunneled datagram may have a Transport-Mode Authentication Header.

The following ESP Header format (taken from RFC 2406) includes the Next Header fi eld, which appears near the end of the ESP Header and indicates the presence (and identity) of any other headers (such as AH) that may follow. The rest of the ESP Header consists of the following.

Security Parameter Index (SPI) This is the same 32-bit value referred to in the section on the Authentication Header. This value is used by the communicating nodes to refer to a security association, which can be used to determine how the data should be encrypted.

Sequence Number This 32-bit value is set to zero to start and is incremented by one with each datagram sent. As just described for the Authentication Header, the sequence number can be used to protect against replay attacks, and a new security association must be set up before this value cycles through all 2 32 values.

Payload Data This is a variable-length fi eld and actually contains the encrypted portion of the datagram, along with any supplementary data necessary for the encryption algorithm (e.g., initialization data). The payload begins with an initialization vector , a value that must be sent in plaintext; encryption algorithms need this value to decrypt the protected data.

Padding The encrypted portion of the header (the payload) must end on the appropriate boundary, so padding may be necessary.

Padding Length This field indicates how much padding has been added to the payload data.

Next Header This field operates as it normally does with other IPv6 extension headers; it just appears near the end of the header (where it can be given confidentiality protection) rather than at the beginning so that the next layer protocol can be hidden from any unauthorized third parties.

Authentication Data This is an Integrity Check Value ( ICV ) calculated on the entire ESP Header (except for the authentication data). This authentication calculation is optional. The ICV is discussed at greater length following.