Enhanced Encapsulating Security Payload (EESP)#

Steffen Klassert, Antony Antony (secunet), Christian Hopps (LabN Consulting) — IPSECME WG document

• Why: ESP has no version field and cannot evolve transparently; everything must be IKEv2-negotiated and is invisible to intermediaries. Meanwhile high-speed deployments need an inner-flow identifier for ECMP, CPU pinning, and QoS, and selective exposure of inner headers for middleboxes. This is the network-security wire-format change of the meeting.
• What: EESP is a modernized ESP on a new IP protocol number: a Base Header (version, options length, 16-bit Session ID, SPI) that middleboxes can parse; a Peer Header (full 64-bit sequence number, IV) private to the peers; the ESP trailer eliminated (Next Header/Pad Length moved into a Payload Info Header); IPv6-style TLV options for future extension; and a Crypt Offset option to expose leading bytes of the inner packet for middlebox/telemetry use — covering the PSP (VNI/crypt-offset) use case, anti-replay subspaces, and shared-SA proposals in one mechanism.
• How: The Session ID doubles as a Sub SA ID selecting independent 64-bit anti-replay sequence-number spaces (per core, path, or QoS class), each with keys derived via KDF, creatable "on the fly" in the data plane — including hardware offload deriving per-packet sub-SA keys. Combined-mode (AEAD) algorithms only; replay-disable is negotiated (useful in DCs where upper layers handle replay); an optimized packet format elides the Payload Info Header in IPv4/IPv6 tunnel mode. Negotiable via IKEv2 but portable to other keying protocols; Linux XFRM implementation status is tracked in the draft.
• Where applicable: High-throughput IPsec — datacenter interconnects and large VPN fabrics where per-flow ECMP/QoS under encryption matters. WG document at -04, active; watch for the protocol-number allocation and PSP alignment.