IP Encapsulating Security Payload (ESP)
obsoleted by
- rfc-4303 — IP Encapsulating Security Payload (ESP)
- rfc-4305 — Cryptographic Algorithm Implementation Requirements for Encapsulating Security Payload (ESP) and Authentication Header (AH)
obsoletes
- rfc-1827 — IP Encapsulating Security Payload (ESP)
Extracted elements (30)
Additional padding beyond algorithm and alignment requirements MAY be used to conceal the actual payload length in support of partial traffic flow confidentiality. However, such padding has adverse bandwidth implications and should be used with care.
ESP was reformulated from RFC 1827's 'shell' approach (completed via transform documents) into a complete specification with integrated options for security services. The combinatorial growth of transforms motivated this change; fields for authentication, anti-replay, padding, and next-protocol identification are now defined in the base ESP specification.
The default padding scheme (sequential integers 1, 2, 3, ...) was chosen for its relative simplicity, ease of implementation in hardware, and because it offers limited protection against 'cut and paste' attacks in the absence of other integrity measures when the receiver checks padding values upon decryption.
When authentication is selected, encryption is performed first before authentication, and encryption does not encompass the Authentication Data field. This order facilitates rapid detection and rejection of replayed or bogus packets prior to decryption, reducing the impact of denial of service attacks, and also allows parallel processing of decryption and authentication at the receiver.
For bump-in-the-stack and bump-in-the-wire IPv4 transport mode implementations, inbound and outbound IP fragments may require the IPsec implementation to perform extra IP reassembly/fragmentation to conform to this specification while providing transparent IPsec support.
In IPv6, ESP is viewed as an end-to-end payload and should appear after hop-by-hop, routing, and fragmentation extension headers. Destination options extension headers may appear either before or after the ESP header; placing them after ESP generally is preferable since ESP only protects fields after the ESP header.
The protocol header immediately preceding the ESP header (IPv4, IPv6, or Extension) must contain the value 50 in its Protocol (IPv4) or Next Header (IPv6, Extension) field to identify the ESP payload.
A minimum anti-replay window size of 32 MUST be supported; a window size of 64 is preferred and SHOULD be employed as the default. The receiver does NOT notify the sender of the window size.
All ESP implementations MUST support the anti-replay service, though its use may be enabled or disabled by the receiver on a per-SA basis. The anti-replay service MUST NOT be enabled unless the authentication service is also enabled for the SA, since otherwise the Sequence Number field is not integrity-protected.
All implementations MUST support generation and consumption of padding (0-255 bytes). If padding bytes are needed and the encryption algorithm does not specify content, the default padding MUST be used: bytes initialized to sequential integers 1, 2, 3, ... When this scheme is used, the receiver SHOULD inspect the Padding field.
Although both confidentiality and authentication are individually optional, at least one of them MUST be selected; both encryption and authentication algorithms MUST NOT simultaneously be NULL.
Conformant implementations MUST implement DES in CBC mode, HMAC with MD5, HMAC with SHA-1, NULL Authentication algorithm, and NULL Encryption algorithm as mandatory-to-implement algorithms. Support for the two NULL algorithms is required to maintain consistency with service negotiation.
For ICV computation, if the byte string length does not match the blocksize requirements of the authentication algorithm, implicit zero-filled padding MUST be appended to the end of the ESP packet after the Next Header field prior to ICV computation; this padding is not transmitted with the packet.
Fragmentation is performed after ESP processing; transport mode ESP is applied only to whole IP datagrams. If a packet offered to ESP appears to be an IP fragment (OFFSET field non-zero or MORE FRAGMENTS flag set), the receiver MUST discard the packet; this is an auditable event.
If anti-replay is enabled, the sender MUST NOT send a packet on an SA if doing so would cause the Sequence Number to cycle. An attempt to transmit a packet that would result in Sequence Number overflow is an auditable event.
If ICV validation fails, the receiver MUST discard the received IP datagram as invalid; this is an auditable event. The receiver MUST authenticate a packet before updating the Sequence Number window data when the packet is either inside the window and new, or outside the window on the right side.
If no valid Security Association exists for a received packet (e.g., the receiver has no key), the receiver MUST discard the packet; this is an auditable event. The audit log entry SHOULD include SPI value, date/time, Source Address, Destination Address, Sequence Number, and (in IPv6) the cleartext Flow ID.
If verification and decryption are performed serially, ICV verification SHOULD be performed first. If performed in parallel, verification MUST be completed before the decrypted packet is passed on for further processing, to facilitate rapid rejection of bogus packets and reduce DoS impact.
The sender MUST always transmit the Sequence Number field. If anti-replay is enabled, the sender's counter and the receiver's counter MUST be reset (by establishing a new SA and key) prior to transmission of the 2^32nd packet on an SA to prevent counter cycling.
The SPI value of zero MUST NOT be sent on the wire; it is reserved for local implementation-specific use such as indicating 'No Security Association Exists' during SA establishment.
The Authentication Data is an optional variable-length field containing an Integrity Check Value (ICV) computed over the ESP packet minus the Authentication Data field. It is present only if the authentication service has been selected for the SA; the authentication algorithm specification MUST specify the ICV length, comparison rules, and processing steps.
The Payload Data is a mandatory variable-length field containing data described by the Next Header field. If the encryption algorithm requires cryptographic synchronization data such as an IV, this data MAY be carried explicitly in the Payload field; any such algorithm MUST specify the length, structure, and location of this data in an RFC.
The Security Parameters Index (SPI) is a mandatory 32-bit value that, combined with the destination IP address and security protocol (ESP), uniquely identifies the Security Association for the datagram. SPI values 1-255 are reserved by IANA; SPI value zero is reserved for local implementation-specific use.
The Sequence Number is a mandatory, monotonically increasing unsigned 32-bit counter that is always present even if the receiver does not enable anti-replay. Both sender and receiver counters are initialized to 0 when an SA is established; the first packet has Sequence Number 1.
A compliant implementation SHOULD NOT provide the anti-replay service in conjunction with SAs that are manually keyed, because correct provision of anti-replay with manual keys would require correct maintenance of counter state at the sender until key replacement, with no automated recovery if counter overflow were imminent.
The anti-replay service SHOULD NOT be used in a multi-sender environment that employs a single SA, since there are no provisions for managing transmitted Sequence Number values among multiple senders directing traffic to a single SA, regardless of whether the destination address is unicast, broadcast, or multicast.
There is no requirement for the receiver to transmit any message to the purported sender in response to the detection of an auditable event, because of the potential to induce denial of service via such action.
Use of confidentiality without integrity/authentication (either in ESP or separately in AH) may subject traffic to certain forms of active attacks that could undermine the confidentiality service, as described in [Bel96]. Implementations should carefully consider the security implications of selecting confidentiality alone.
The anti-replay sliding window mechanism: the right edge represents the highest validated Sequence Number received. Packets with Sequence Numbers below the left edge are rejected. Packets within or to the right of the window proceed to ICV verification; the receive window is updated only if ICV verification succeeds. A minimum window size of 32 MUST be supported; a window size of 64 SHOULD be the default.
The ESP packet consists of: SPI (32-bit), Sequence Number (32-bit), Payload Data (variable), Padding (0-255 bytes), Pad Length (8-bit), Next Header (8-bit), and optional Authentication Data (variable). The SPI and Sequence Number are covered by authentication; Payload Data through Next Header are covered by both authentication and encryption.