ESP, Encapsulating Security Payload
Description Glossary RFCs Publications Obsolete RFCs

Description:

Protocol suite: TCP/IP, IPSec.
Protocol type:Transport layer protocol.
IP Protocol:50.
MIME subtype:
SNMP MIBs:
Working groups: ipsec, IP Security Protocol.
ipsecme, IP Security Maintenance and Extensions.
Links:

ESP will function with both the IPv4 and IPv6 protocols.

ESP supports two modes of operation, tunnel mode and transport mode.

RFC 4303:

The ESP header is designed to provide a mix of security services in IPv4 and IPv6. ESP may be applied alone, in combination with AH, or in a nested fashion.

Security services can be provided between a pair of communicating hosts, between a pair of communicating security gateways, or between a security gateway and a host. The ESP header is inserted after the IP header and before the next layer protocol header (transport mode) or before an encapsulated IP header (tunnel mode). ESP can be used to provide confidentiality, data origin authentication, connectionless integrity, an anti-replay service (a form of partial sequence integrity), and (limited) traffic flow confidentiality. The set of services provided depends on options selected at the time of Security Association (SA) establishment and on the location of the implementation in a network topology.

MAC header IPv4 | IPv6 header ESP header Data :::

ESP header:

0001020304050607 0809101112131415 1617181920212223 2425262728293031
Security Parameters Index
Sequence number
Payload data :::
Padding ::: Pad length Next header
Authentication data :::

SPI, Security Parameters Index. 32 bits.
An arbitrary value that, in combination with the destination IP address and security protocol (ESP), uniquely identifies the SA for this datagram. The set of SPI values in the range 1 through 255 are reserved for future use. A reserved SPI value will not normally be assigned by IANA unless the use of the assigned SPI value is specified in an RFC. It is ordinarily selected by the destination system upon establishment of an SA. This field is mandatory. The value of zero is reserved for local, implementation- specific use and MUST NOT be sent on the wire. For example, a key management implementation MAY use the zero SPI value to mean "No Security Association Exists" during the period when the IPsec implementation has requested that its key management entity establish a new SA, but the SA has not yet been established.

Sequence number. 32 bits, unsigned.
This field contains a monotonically increasing counter value. It is mandatory and is always present even if the receiver does not elect to enable the anti-replay service for a specific SA. Processing of this field is at the discretion of the receiver. The sender MUST always transmit this field, but the receiver need not act upon it. The sender's counter and the receiver's counter are initialized to 0 when an SA is established. The first packet sent using a given SA will have a Sequence number of 1. If anti-replay is enabled (the default), the transmitted Sequence number must never be allowed to cycle. Thus, the sender's counter and the receiver's counter MUST be reset (by establishing a new SA and thus a new key) prior to the transmission of the 2^32nd packet on an SA.

Payload data. Variable length.
Contains the data described by the Next header field. This field is mandatory and is an integral number of bytes in length. If the algorithm used to encrypt the payload requires cryptographic synchronization data, e.g., an Initialization Vector (IV), then this data MAY be carried explicitly in the Payload data field. Any encryption algorithm that requires such explicit, per-packet synchronization data MUST indicate the length, any structure for such data, and the location of this data as part of an RFC specifying how the algorithm is used with ESP. If such synchronization data is implicit, the algorithm for deriving the data MUST be part of the RFC.

Padding. Variable length, 0 to 255 bytes.
Padding may be required, irrespective of encryption algorithm requirements, to ensure that the resulting ciphertext terminates on a 4 byte boundary. Specifically, the Pad length and Next header fields must be right aligned within a 4 byte word to ensure that the Authentication data field, if present, is aligned on a 4 byte boundary.

Pad length. 8 bits.
Specifies the size of the Padding field in bytes.

Next header. 8 bits.
An IPv4/IPv6 protocol number describing the format of the Payload data field.

Authentication data. Variable length.
Contains an ICV computed over the ESP packet minus the Authentication data. The length of the field is specified by the authentication function selected. This field is optional and is included only if the authentication service has been selected for the SA in question. The authentication algorithm specification MUST specify the length of the ICV and the comparison rules and processing steps for validation.

Glossary:

ICV, Integrity Check Value.

SA, Security Association.

RFCs:

[RFC 1829] The ESP DES-CBC Transform.

[RFC 1851] The ESP Triple DES Transform.

[RFC 2403] The Use of HMAC-MD5-96 within ESP and AH.

[RFC 2405] The ESP DES-CBC Cipher Algorithm With Explicit IV.

[RFC 2410] The NULL Encryption Algorithm and Its Use With IPsec.

[RFC 2411] IP Security Document Roadmap.

[RFC 2451] The ESP CBC-Mode Cipher Algorithms.

[RFC 2857] The Use of HMAC-RIPEMD-160-96 within ESP and AH.

[RFC 3095] RObust Header Compression (ROHC): Framework and four profiles: RTP, UDP, ESP, and uncompressed.

[RFC 3686] Using Advanced Encryption Standard (AES) Counter Mode With IPsec Encapsulating Security Payload (ESP).

[RFC 4106] The Use of Galois/Counter Mode (GCM) in IPsec Encapsulating Security Payload (ESP).

[RFC 4196] The SEED Cipher Algorithm and Its Use with IPsec.

[RFC 4301] Security Architecture for the Internet Protocol.

[RFC 4303] IP Encapsulating Security Payload (ESP).

[RFC 4305] Cryptographic Algorithm Implementation Requirements for Encapsulating Security Payload (ESP) and Authentication Header (AH).

[RFC 4309] Using Advanced Encryption Standard (AES) CCM Mode with IPsec Encapsulating Security Payload (ESP).

[RFC 4312] The Camellia Cipher Algorithm and Its Use With IPsec.

[RFC 4359] The Use of RSA/SHA-1 Signatures within Encapsulating Security Payload (ESP) and Authentication Header (AH).

[RFC 4543] The Use of Galois Message Authentication Code (GMAC) in IPsec ESP and AH.

Publications:

Obsolete RFCs:

[RFC 1825] Security Architecture for the Internet Protocol.

[RFC 1827] IP Encapsulating Security Payload (ESP).

[RFC 2401] Security Architecture for the Internet Protocol.

[RFC 2404] The Use of HMAC-SHA-1-96 within ESP and AH.

[RFC 2406] IP Encapsulating Security Payload (ESP).

Description Glossary RFCs Publications Obsolete RFCs