Wrapped Encapsulating Security Payload (ESP) for Traffic Visibility
Extracted elements (25)
ESP is preferred over AH in enterprise environments because AH does not work in NAT environments. Integrity-only ESP (ESP-NULL or AES-GMAC) provides authentication without encryption, enabling network monitoring, but standard ESP provides no deterministic way to distinguish encrypted from unencrypted payloads.
Heuristics-based parsing to distinguish encrypted from integrity-only ESP is expensive, requires numerous protocol-specific rules, and is not robust when encrypted packet fields resemble protocol heuristics. WESP replaces this with a deterministic, single-bit indicator that works for both stateful and stateless devices (ACLs, NetFlow exporters).
The Reserved bits are constrained so future assignments MUST NOT affect the distinction between encrypted and unencrypted packets or the semantics of HdrLen, ensuring old implementations can still locate the encapsulated packet correctly even when new bits are defined.
The WESP header is designed to minimally extend ESP by prepending only 4 octets (IPv4) or 8 octets (IPv6), preserving the ESP body unchanged so compliant implementations only need to add the new header without restructuring the existing ESP packet.
WESP is wholly compatible with NAT Traversal (NAT-T) as defined in RFC 3948 and can be used without modification in NAT environments. Negotiation of WESP via IKEv2 preserves all other negotiation parameters including NAT-T.
WESP requires modification of ESP endpoints, unlike the heuristics approach which inspects unchanged ESP traffic. Both approaches are expected to coexist for years; intermediate nodes SHOULD support both during transition, as heuristics are needed for endpoints not yet upgraded to WESP.
When WESP is used with UDP encapsulation and IPv6, the 4-octet Protocol Identifier (0x00000002) already achieves 8-octet alignment, so the IPv6 padding (P bit) is not needed and need not be set.
If the responder declines the USE_WESP_MODE request, the CHILD_SA is established using standard ESP. If this is unacceptable to the initiator, the initiator MUST delete the SA.
The Padding Present (P) bit MUST be used with IPv6 to preserve 8-octet alignment. This padding MUST NOT be used with IPv4, as 4-octet IPv4 alignment is already satisfied without it.
The receiver MUST ensure HdrLen matches the header offset computed from the negotiated SA and MUST drop the packet if it does not match. This prevents deliberate misconfiguration to hide payload from trusted intermediary devices.
The receiver MUST only accept the packet if TrailerLen matches the ICV size computed from the negotiated SA, preventing a sender from deliberately obfuscating part of the payload from inspection by a trusted intermediary.
The recipient MUST ensure the Encrypted Payload (E) flag is consistent with the negotiated SA policy and MUST drop the incoming packet if inconsistent. E=1 means the ESP payload is encrypted; E=0 means integrity-only ESP.
The Version field (V, 2 bits) MUST be sent as 0 and checked by the receiver. If the version differs from the expected version, the packet MUST be dropped. Future modifications require a new version number.
For UDP encapsulation (NAT-T), a Protocol Identifier field with value 0x00000002 immediately follows the UDP header to demultiplex between IKE, standard ESP (RFC 3948), and WESP. This reuses the reserved SPI value range (1–255) from RFC 4303 Section 2.1.
IKEv2 negotiation of WESP mode uses the USE_WESP_MODE notification (value 16415). It MUST be included in a request containing an SA payload for a CHILD_SA using ESP. If accepted, the response MUST also include USE_WESP_MODE; if declined, the CHILD_SA uses standard ESP per RFC 4303.
WESP uses IP protocol number 141. The outer protocol header (IPv4, IPv6, or Extension) immediately preceding the WESP header SHALL contain value 141 in its Protocol or Next Header field.
IANA assigned IP Protocol Number 141 to the WESP protocol. IANA assigned USE_WESP_MODE notification value 16415 from the IKEv2 Notify Message Types - Status Types registry (16384–40959, Expert Review range). IANA assigned SPI value 2 from the reserved SPI range for WESP within UDP-encapsulated NAT-T environments.
IANA created a new 'WESP Flags' registry. The first 2 bits (Version Number) have value 0 assigned to this specification; further assignments require Standards Action. The remaining 4 undefined bits are managed via IETF Review policy per RFC 5226.
Because ESP is end-to-end, intermediate devices cannot verify correctness of WESP header fields. An attacker could modify the WESP header to cause a packet to sneak past a firewall by setting fields to values the firewall allows. Endpoints MUST verify WESP header sanity before accepting packets.
WESP allows intermediate device visibility into ESP-encapsulated frames. Care should be taken not to send sensitive data over WESP connections in network domains where this visibility is not appropriate. A strong key agreement protocol (e.g., IKEv2) and a strong policy engine should govern where WESP is employed.
Flags (8 bits), MSB first: Version (V, 2 bits), Encrypted Payload (E, 1 bit), Padding Present (P, 1 bit), and Reserved (Rsvd, 4 bits). Version MUST be sent as 0; E=1 indicates encrypted payload; P=1 indicates 4-octet padding is present; Reserved bits MUST be sent as 0.
HdrLen (8 bits): Byte offset from the start of the WESP header to the Rest of Payload Data within the encapsulated ESP header. MUST be zero when using ESP with encryption. For integrity-only ESP, invalid values include any value less than 12, any non-multiple of 4, and any non-multiple of 8 when using IPv6.
Next Header (8 bits): In integrity-only mode, MUST equal the ESP trailer Next Header field. In encrypted mode, this field loses its semantics and MUST be initialized to all zeros. The receiver MUST drop the packet if the two Next Header values do not match in integrity-only mode.
The WESP header consists of four fixed 8-bit fields: Next Header, HdrLen, TrailerLen, and Flags, totaling 4 octets for IPv4. For IPv6, an optional 4-octet padding field follows, making the header 8 octets when the P flag is set.
TrailerLen (8 bits): Size in octets of the Integrity Check Value (ICV) as negotiated in the IPsec SA. MUST be set to zero when using ESP with encryption. The receiver MUST accept the packet only if this field matches the value computed from the negotiated SA.