Tunnelling of Explicit Congestion Notification
updated by
- rfc-9601 — Propagating Explicit Congestion Notification across IP Tunnel Headers Separated by a Shim
updates
Extracted elements (25)
A single mode for decapsulation (rather than matching the ingress's two modes) was chosen because the new decapsulation table covers all combinations from any legacy or current ingress correctly. Egress mode complexity was explicitly rejected as unnecessary, even though it would have marginally narrowed the residual covert channel.
For the anomalous combination ECT(1) inner / ECT(0) outer (which no valid protocol produces), the decapsulator corrects the anomaly by forwarding ECT(1) — the inner, more severe value — rather than revealing the anomaly to the transport via ECT(0). This is safe when ECT(1) represents higher congestion severity, and the event is logged for detection.
Pre-congestion notification (PCN) triggered these changes: PCN excess-traffic-marking requires the outer header to reflect congestion accumulated over the entire upstream path, not just since the tunnel ingress. RFC 3168's CE-reset behaviour broke PCN, forcing a choice between PCN and existing Mobile IP/VPN tunnels. Copying CE at ingress solves this cleanly.
Pre-existing decapsulation rules treated ECT(0) and ECT(1) as always equivalent, unnecessarily restricting half a codepoint bit and blocking two-severity-level congestion signalling. The new rules propagate ECT(1) as potentially more severe than ECT(0), enabling PCN's two-level encoding while remaining fully safe for existing single-severity schemes.
RFC 3168 reset CE to ECT(0) on encapsulation to limit the covert channel. RFC 4301 reversed this by simply copying CE, finding a 2-bit covert channel manageable. This specification aligns all IP-in-IP tunnels with RFC 4301 behaviour, eliminating the anomaly where non-IPsec tunnels blocked more of the covert channel than IPsec tunnels, and simplifying encapsulation code.
An RFC 4301 IPsec ingress requires no code change to comply with this specification — its copy-ECN encapsulation is identical to normal mode. Only the RFC 4301 egress needs updating, and only for previously unused inner/outer combinations; all existing combinations produce identical output, making the update fully backward compatible.
IPsec tunnel ingresses compliant with RFC 4301 need not implement compatibility mode because IKEv2 key exchange (which was introduced alongside RFC 4301) guarantees that both tunnel endpoints are RFC 4301 compliant before any packets traverse the tunnel, precluding legacy ECN decapsulators.
Transports have no mechanism to discover whether legacy tunnels on their path support two-severity-level congestion propagation. Schemes requiring two severity levels (e.g., PCN) avoid this open problem by operating within a controlled single-operator domain where all tunnel endpoints can be mandated to comply with this specification.
Updating an RFC 3168 ingress to normal mode (copying rather than resetting CE) is 'black-box backward compatible': any tunnel egress (RFC 4301, any RFC 3168 mode, RFC 2481, RFC 2401, RFC 2003) will produce identical output packets because all variants have always propagated CE through the inner header. CE markings are visible inside the tunnel but output packets are unchanged.
A compliant tunnel egress MUST set the outgoing ECN field to the codepoint at the intersection of the arriving inner (row) and outer (column) per Figure 4. Specifically, if the inner is Not-ECT and the outer is CE, the decapsulator MUST drop the packet.
A decapsulating tunnel egress compliant with this specification MUST agree to any mode request from an ingress (RFC 6040, RFC 4301, RFC 3168 full or limited functionality), since its single decapsulation behaviour is compatible with all of them. If no ECN-related mode is requested, the egress MUST continue without error.
A tunnel ingress MUST at least implement normal mode. Unless it will never be paired with legacy egress nodes (RFC 2003, RFC 2401, RFC 2481, or RFC 3168 limited functionality), an ingress MUST also implement compatibility mode.
Alternate ECN tunnelling schemes SHOULD be avoided whenever possible, as the deployment burden of handling exceptional PHBs across all affected tunnel implementations is significant. A PHB definition need not mention ECN tunnelling if the default behaviour in this specification suffices.
For currently unused (CU) combinations of inner and outer ECN fields (marked '(!!!)' or '(!)' in Figure 4), the decapsulator SHOULD log the event and MAY raise an alarm. Alarms SHOULD be rate-limited, and it MUST be possible to suppress alarms or logging entirely.
If an ingress claims compliance with this specification, it MUST NOT permanently disable ECN processing across the tunnel (i.e., use only compatibility mode exclusively). It SHOULD use normal mode whenever it knows the egress supports ECN propagation.
If the inner ECN field is Not-ECT and the outer ECN field is Not-ECT, ECT(0), or ECT(1), the decapsulator MUST forward the outgoing packet with the ECN field cleared to Not-ECT. The inner Not-ECT marking indicates a transport that relies on drops for congestion signalling and would not understand other ECN codepoints.
In normal mode, an encapsulator MUST construct the outer IP header by copying the two-bit ECN field of the incoming IP header verbatim (including any CE marking). The IPv4 header checksum also changes whenever the ECN field changes.
While a compliant tunnel ingress is dynamically discovering an egress, it MUST send packets in compatibility mode in case the discovered egress is legacy. If the egress denies ECN compliance or returns an error implying non-support, the ingress MUST remain in compatibility mode.
Normal mode encapsulation (Figure 3) copies the full 2-bit ECN field from the incoming IP header into the new outer header, including CE. Compatibility mode clears the outer ECN field to Not-ECT (00). The inner header ECN field is always forwarded unchanged regardless of mode.
The ECN field uses four 2-bit codepoints: Not-ECT (00) for non-ECN-capable transport, ECT(0) (10) and ECT(1) (01) for ECN-capable transport, and CE (11) for Congestion Experienced. Severity ranking from highest to lowest is CE, ECT(1), ECT(0), Not-ECT.
The new decapsulation table (Figure 4) sets the outgoing ECN field to the more severe of inner and outer ECN. Not-ECT inner with CE outer results in packet drop. Not-ECT inner with ECT(0) or ECT(1) outer is forwarded as Not-ECT. ECT(1) inner with ECT(0) outer forwards ECT(1). Previously unused combinations are annotated '(!!!)' or '(!)'.
Because a compliant egress has only one mode regardless of negotiated mode, a man-in-the-middle can still covertly signal CE or ECT(1) in the outer header to the destination even when the ingress uses compatibility mode and sends Not-ECT. This residual channel was accepted to avoid the complexity of a dual-mode egress.
Copying rather than resetting CE on encapsulation expands the ingress covert channel from effectively zero to two bits per datagram (from sender to man-in-the-middle). The IETF Security Area considers this a manageable risk consistent with RFC 4301's existing position. Conversely, dropping congestion notifications is itself a security harm as it impedes congestion enforcement.
The new decapsulation rules improve ECN nonce (RFC 3540) coverage relative to RFC 3168 and RFC 4301, but coverage is not perfect. The compromise on the ECT(1) inner / ECT(0) outer case (Appendix D) — correcting the anomaly rather than forwarding it — trades nonce coverage for safety, since the decapsulator itself can detect the anomaly using the inner header as a reference.
Tunnel ingress mode transitions: initial state is compatibility mode during dynamic endpoint discovery; transitions to normal mode when egress signals compliance with RFC 6040, RFC 4301, or RFC 3168 full functionality; reverts to and stays in compatibility mode if egress denies compliance or returns an error. IPsec (RFC 4301) ingresses are permanently in normal mode by construction.