IP Encapsulating Security Payload (ESP)
obsoleted by
- rfc-2406 — IP Encapsulating Security Payload (ESP)
Extracted elements (26)
In Tunnel-mode with strict red/black separation, the addressing and other information in cleartext IP headers MAY differ from the values in the encrypted original datagram. This permits concealment of true source and destination addressing from passive observers.
Key management is intentionally decoupled from the ESP security protocol. The only coupling between key management and ESP is through the SPI, permitting multiple key management mechanisms and allowing key management protocols to be changed or corrected without impacting ESP implementations.
The encrypted IP datagram normally carries no explicit Security Label because the SPI implicitly indicates the sensitivity level, improving over IPv4 practice where explicit Sensitivity Labels were required for Compartmented Mode Workstations. This reduces overhead while maintaining security classification.
The ESP format uses 'transforms' to specify encryption and authentication algorithms along with the Opaque Transform Data format, rather than baking a fixed algorithm into the header. This design supports new transforms and cryptographic algorithms in the future without changing the core ESP format.
The receiver is advised not to immediately notify the sender of an SA failure because of the strong potential for easy-to-exploit denial of service attacks. Silent discard with local logging is preferred over ICMP error responses.
ESP works with both IPv4 and IPv6. In IPv6, the Authentication Header and other end-to-end headers precede the ESP header; in Transport-mode the ESP header sits immediately before the transport-layer header. The mechanism is the same for both IP versions.
When AH is present both in the cleartext IP header and inside a Tunnel-mode ESP header of the same packet, the outer cleartext AH protects the unencrypted IP headers while the inner encrypted AH provides authentication only for the encrypted IP packet. These serve distinct purposes.
Conforming implementations MUST fully implement the ESP header, MUST support manual key distribution, MUST comply with all requirements of the IP Security Architecture (RFC 1825), and MUST support DES CBC as specified in the companion ESP DES-CBC Transform document (RFC 1829).
If an Authentication Header encapsulated within a Tunnel-mode ESP header has a different security classification level than the ESP header, an error has occurred and SHOULD be recorded in the system log or audit log.
If no valid Security Association exists for a session (e.g., the receiver has no key), the receiver MUST discard the encrypted ESP and the failure MUST be recorded in the system log or audit log.
Implementations of ESP in systems claiming to provide multi-level security MUST support implicit security labels (where the SPI identifies the sensitivity level), though implementations MAY additionally support explicit labels.
Implementations SHOULD support user-oriented keying as described in the IP Security Architecture, to preclude Chosen Plaintext attacks and make cryptanalysis more difficult.
In systems claiming to provide multilevel security (e.g., B1 or Compartmented Mode Workstation), additional appropriate mandatory access controls MUST be applied based on the security level of the receiving process and the security level associated with the Security Association after successful Tunnel-mode decryption.
In Transport-mode ESP, if no key exists for the session or the decryption attempt fails, the encrypted ESP MUST be discarded and the failure MUST be recorded in the system log or audit log.
In Transport-mode ESP, systems claiming to provide multilevel security MUST apply additional Mandatory Access Controls based on the security level of the receiving process and the security level of the received packet's Security Association.
The system or audit log entry for a failed ESP decryption or missing SA SHOULD include the SPI value, date/time, cleartext Sending Address, cleartext Destination Address, and the cleartext Flow ID. The log entry MAY also include other identifying data.
ESP is assigned IP Protocol Number 50. The header immediately preceding an ESP header always contains the value 50 in its Next Header (IPv6) or Protocol (IPv4) field. ESP may appear anywhere after the IP header and before the final transport-layer protocol.
ESP processing is ordered relative to IP fragmentation: ESP processing occurs prior to IP fragmentation on output and after IP reassembly on input. This ensures the ESP header is not split across IP fragments.
ESP supports two operational modes: Tunnel-mode, which encapsulates an entire IP datagram inside ESP within a new cleartext IP header; and Transport-mode, which encapsulates only the transport-layer frame (e.g., TCP, UDP, ICMP) and inserts the ESP header immediately before the transport-layer header.
The Authentication Header (AH) may be combined with ESP in two ways: AH outside ESP authenticates the entire datagram including encrypted portions; or AH inside Tunnel-mode ESP authenticates only the encrypted inner datagram. The placement of AH unambiguously identifies what is being authenticated.
Cryptographic transforms for ESP that use a block-chaining algorithm and lack a strong integrity mechanism are vulnerable to a cut-and-paste attack (Bellovin) and SHOULD NOT be used unless the Authentication Header is always present with packets using that ESP transform.
ESP does not provide protection from traffic analysis. Users seeking traffic analysis protection should consider appropriate link encryption, which is outside the scope of this specification.
If user-oriented keying is not in use, the algorithm must not be vulnerable to any kind of Chosen Plaintext attack. DES is known to be susceptible to differential and linear cryptanalysis; user-oriented keying is recommended to preclude such attacks and complicate cryptanalysis.
The security quality provided by ESP depends entirely on the strength of the chosen encryption algorithm, correctness of its implementation, security of the key management mechanism and implementation, and strength of the key. Failure in any of these dimensions provides little or no real security.
The ESP header consists of two components: an unencrypted Security Parameter Index (SPI) field of 32 bits, followed by variable-length Opaque Transform Data that is encrypted. The SPI is the only mandatory transform-independent field.
The SPI is a 32-bit pseudo-random value identifying the security association for the datagram. If no security association has been established, the SPI field value SHALL be 0x00000000. SPI values 0x00000001 through 0x000000FF are reserved for IANA.