| Internet-Draft | ESP Entropy Header | June 2026 |
| Yang, et al. | Expires 24 December 2026 | [Page] |
When IPsec Encapsulating Security Payload (ESP) is used in tunnel mode, an intermediate node cannot inspect the encrypted inner headers to derive entropy for Equal-Cost Multipath (ECMP) or Link Aggregation Group (LAG) path selection. Path selection is then driven by outer header fields that are identical for every packet of a given tunnel, so all packets of the tunnel are placed on a single path regardless of the number of inner flows.¶
This document defines the ESP Entropy Header, an IP protocol header that is placed immediately ahead of ESP and carries an entropy value in a fixed position that transit nodes can use for path selection. It also defines an Internet Key Exchange Protocol Version 2 (IKEv2) extension with which peers negotiate the use of the header on a per-Child-SA basis. The mechanism applies to both IPv4 and IPv6.¶
This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.¶
Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at https://datatracker.ietf.org/drafts/current/.¶
Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."¶
This Internet-Draft will expire on 24 December 2026.¶
Copyright (c) 2026 IETF Trust and the persons identified as the document authors. All rights reserved.¶
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License.¶
IPsec [RFC4301] provides security services for IP traffic at the network layer. ESP [RFC4303] is the most widely deployed IPsec protocol and provides confidentiality, integrity, and anti-replay protection. In tunnel mode the original packet is encrypted and encapsulated in a new outer IP header.¶
Intermediate nodes along the tunnel path perform ECMP and LAG path selection by computing a hash over selected packet header fields. For an ESP tunnel-mode packet, only the outer IP header is available to such a node. When a single tunnel carries multiple inner flows, the outer source and destination addresses are the same for every packet, so the hash yields the same result at each hop and all packets of the tunnel are assigned to the same path. The available paths are therefore not used evenly. This behavior is a recognized operational limitation of IPsec deployments.¶
Comparable problems have been addressed in other encapsulations. MPLS uses entropy labels [RFC6790]. IPv6 tunnels can use the flow label for the same purpose [RFC6438]. For IPsec there is at present no header within the IP protocol stack, common to IPv4 and IPv6, that carries entropy in a fixed location for a transit node to use.¶
This document defines an IP protocol header, the ESP Entropy Header, that immediately precedes the ESP header. The header carries a 16-bit Entropy field that is set by the IPsec sender and is available for inspection by transit nodes. A transit node that recognizes the assigned protocol number MAY include the Entropy field in its ECMP and LAG path-selection input.¶
Use of the ESP Entropy Header is negotiated between IPsec peers using an IKEv2 [RFC7296] Notify exchange, so that a peer includes the header only when its peer is prepared to process packets that carry it.¶
Improving the entropy available for path selection, as this document does, is complementary to making the path-selection decision itself load-aware. The latter approach is described in [I-D.yang-rtgwg-ecmp-adaptive-load-balance]; the two mechanisms operate at different points and may be combined. The relationship is discussed in Section 1.3.¶
Entropy for encrypted tunnel traffic can be provided in more than one way. This section records the trade-offs that apply to the alternatives, so that the choice made in this document is documented rather than assumed.¶
UDP encapsulation: [I-D.xu-ipsecme-esp-in-udp-lb] and [I-D.acharya-ipsecme-esp-ecmp] encapsulate ESP in UDP and use the UDP source port to carry entropy. This suits environments in which transit nodes already hash on the UDP five-tuple. It adds an 8-octet UDP header, requires a UDP checksum in IPv6 [RFC8200], and shares the UDP port space with NAT traversal [RFC3948], which can interact with the use of the source port for entropy.¶
IPv6 flow label: [RFC6438] uses the IPv6 flow label for ECMP and LAG in tunnels. It is native to IPv6 and adds no header, but is not available in IPv4 and provides a 20-bit field whose use for load balancing depends on transit support.¶
Multiple Security Associations: distinct SPI values across several SAs can provide differentiation at the ESP layer. This increases IKE signaling and keying state and requires a transit node to inspect fields beyond the IP header.¶
The ESP Entropy Header is defined as an IP protocol type and so applies to both IPv4 and IPv6. The Entropy field is at a fixed octet offset from the start of the header, which allows a transit node to locate it without parsing variable-length structures. This approach follows the precedent of Wrapped ESP [RFC5840], which defined an IP-protocol-numbered header that wraps ESP for a different purpose (traffic visibility); that precedent shows that an IP-protocol-numbered header adjacent to ESP is an established mechanism in the IPsec architecture.¶
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.¶
This document uses the following terms.¶
The ESP Entropy Header is 8 octets in length. It is identified by its own IP protocol number (see Section 9). In the IP header that precedes it, the Protocol field (IPv4) or the Next Header field (IPv6) carries this protocol number.¶
0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Next Header | Hdr Len | Entropy | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Reserved (MBZ) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
A 16-bit value. A transit node MAY use this field as input to ECMP and LAG path selection.¶
The value is set by the IPsec sender. The means by which the sender selects the value is a local matter and is outside the scope of this document. To be useful for load distribution, the Entropy field has the following properties:¶
The ESP Entropy Header is placed between the outer IP header (and any IPv6 extension headers) and the ESP header. The following diagrams show the resulting packet structure.¶
+-------------------+ | Outer IPv4 | Protocol = EEH (TBD1) | Header | +-------------------+ | ESP Entropy Hdr | Next Header = 50 (ESP) | (8 octets) | +-------------------+ | ESP Header | SPI, Sequence Number +-------------------+ | | Original IP Packet | Encrypted Payload | (encrypted by ESP) | | +-------------------+ | ESP Trailer | Padding, Pad Length, NH +-------------------+ | ESP ICV | +-------------------+
+-------------------+ | Outer IPv6 | Next Header = EEH (TBD1) | Header | or extension header chain +-------------------+ | (Extension Hdrs) | (if any; last NH = TBD1) +-------------------+ | ESP Entropy Hdr | Next Header = 50 (ESP) | (8 octets) | +-------------------+ | ESP Header | SPI, Sequence Number +-------------------+ | | Original IP Packet | Encrypted Payload | (encrypted by ESP) | | +-------------------+ | ESP Trailer | Padding, Pad Length, NH +-------------------+ | ESP ICV | +-------------------+
The ESP Entropy Header is not covered by ESP encryption or integrity protection. It is visible in the clear to nodes on the path. The security consequences are discussed in Section 7.¶
When the ESP Entropy Header has been negotiated for a Child SA (see Section 5), the IPsec sender that chooses to include the header in an outbound packet on that SA does so subject to the following requirements.¶
The IPsec sender MAY omit the ESP Entropy Header on some packets of an SA for which it has been negotiated, for example when no useful entropy can be derived for a packet. When the header is omitted, the outer IP Protocol or Next Header field MUST be set to the ESP value (50) and no ESP Entropy Header is present. A receiver MUST accept packets both with and without the header on an SA for which the header has been negotiated.¶
A transit node that recognizes the ESP Entropy Header protocol number MAY include the Entropy field in the fields it uses for ECMP or LAG path selection. The Entropy field is at octets 2 and 3 of the header.¶
A transit node MUST NOT modify any field of the ESP Entropy Header.¶
A transit node that does not recognize the protocol number forwards the packet according to its existing behavior for the outer IP header; an unrecognized protocol number does not prevent forwarding. The mechanism is therefore incrementally deployable: a node that recognizes the header obtains improved path selection, and a node that does not continues to forward the traffic.¶
When the IPsec receiver has negotiated the ESP Entropy Header for a Child SA, it MUST accept and process an incoming packet whose outer IP Protocol or Next Header value indicates the ESP Entropy Header.¶
Because the SPI that identifies the Child SA is carried in the ESP header, which follows the ESP Entropy Header, a receiver cannot determine the SA before it has parsed the ESP Entropy Header. A receiver that implements this specification therefore MUST process the ESP Entropy Header whenever the outer IP Protocol or Next Header value indicates it, and then continue to inbound ESP processing where the SA is resolved. Per-Child-SA negotiation (Section 5) governs whether a sender is permitted to emit the header; it does not gate the receiver's ability to parse it. A node that does not implement this specification does not recognize the protocol number and handles the packet according to its existing behavior for an unknown IP protocol number, as described for transit nodes in Section 4.2.¶
Use of the ESP Entropy Header MUST be negotiated between peers before the header is sent. This document defines an IKEv2 [RFC7296] Notify Message of type Status, ESP_ENTROPY_HEADER_SUPPORTED, for this purpose.¶
The initiator includes the ESP_ENTROPY_HEADER_SUPPORTED notification in the IKE_AUTH or CREATE_CHILD_SA exchange that establishes or rekeys the Child SA.¶
If the responder is willing to receive packets that carry the ESP Entropy Header on the Child SA, it includes the same notification in its response.¶
The ESP Entropy Header is negotiated successfully when both the request and the response carry the ESP_ENTROPY_HEADER_SUPPORTED notification. If the response does not carry it, the initiator MUST NOT send packets that carry the ESP Entropy Header on the Child SA.¶
Successful negotiation means that each peer is prepared to receive the header. Each peer decides independently whether to include the header in its own outbound packets; the notification does not require a peer to include the header in every packet.¶
1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Next Payload |C| RESERVED | Payload Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Protocol ID | SPI Size | Notify Message Type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
This notification carries no data.¶
The ESP Entropy Header adds 8 octets to each packet that carries it. An implementation that uses the header MUST account for the additional 8 octets when it performs Path MTU Discovery [RFC1191] [RFC8201] or when it determines the effective MTU for inner packets.¶
The effective inner MTU when the header is in use is reduced by 8 octets. An implementation SHOULD use PMTUD and adjust the tunnel MTU accordingly. When PMTUD is not available, the implementation MUST use a conservative MTU estimate that accounts for the 8-octet header.¶
The ESP Entropy Header is outside the ESP encryption and integrity boundaries, so the Entropy field is visible to observers on the path.¶
The Entropy field does not directly carry inner packet content. Because its value is typically associated with an inner flow, an observer can infer that packets with the same Entropy value belong to the same flow, and over time the number of distinct Entropy values in a tunnel gives an estimate of the number of concurrent flows. This is a form of traffic analysis.¶
An operator whose threat model includes flow-level traffic analysis by an on-path observer SHOULD weigh the benefit of improved load distribution against this exposure. Periodically changing the Entropy value of a long-lived flow reduces the duration over which packets can be correlated, at the cost of moving the flow between paths when the value changes.¶
The ESP Entropy Header is not integrity-protected by ESP. An on-path attacker that can modify packets could alter the Entropy field and influence transit path selection, for example to concentrate traffic on a subset of paths or to direct traffic onto a path the attacker observes.¶
These risks are the same in kind as those from modification of other unprotected outer header fields such as the DSCP or the IPv6 flow label. An operator that requires integrity protection of the outer header chain MAY apply AH [RFC4302] around the ESP Entropy Header.¶
The 16-bit Entropy field provides 65,536 values. When a tunnel carries many concurrent flows, two or more flows may share an Entropy value. A collision does not affect correctness; it reduces the granularity of load distribution for the affected flows.¶
A transit node that does not recognize the assigned protocol number forwards packets using its existing outer-header path selection, so the presence of the header on a path with non-supporting nodes does not cause packet loss. A benefit is obtained at each transit node that recognizes the header, independently of the other nodes on the path.¶
When IPsec traffic is already encapsulated in UDP, for example for NAT traversal [RFC3948], the UDP source port can serve as entropy if the implementation varies it per flow. In that case the ESP Entropy Header adds no benefit and SHOULD NOT be negotiated.¶
The ESP Entropy Header improves the entropy that a transit node can use as input to a static path-selection hash. It does not change how a node reacts to load after a flow has been placed on a path. Load-aware path selection, such as the procedures of [I-D.yang-rtgwg-ecmp-adaptive-load-balance], adjusts placement in response to measured load and is complementary: better entropy improves the initial distribution, and load-aware selection corrects skew that develops afterward. The two mechanisms do not conflict.¶
IANA is requested to assign a value from the "Assigned Internet Protocol Numbers" registry. Allocation of an IP protocol number requires IESG approval per [RFC5237].¶
| Decimal | Keyword | Protocol | Reference |
|---|---|---|---|
| TBD1 | EEH | ESP Entropy Header | [This document] |
IANA is requested to assign a value from the "IKEv2 Notify Message Types - Status Types" registry.¶
| Value | Notify Message Type | Reference |
|---|---|---|
| TBD2 | ESP_ENTROPY_HEADER_SUPPORTED | [This document] |
The use of an entropy value to distribute load for encapsulated traffic is established in the MPLS architecture through entropy labels [RFC6790] and in IPv6 through the flow label [RFC6438]. This document applies the same idea within the IPsec protocol stack.¶