Network Working Group N. Spring
Request for Comments: 3540 D. Wetherall
Category: Experimental D. Ely
University of Washington
Robust Explicit Congestion Notification (ECN)
Signaling with Nonces
Status of this Memo
This memo defines an Experimental Protocol for the Internet
community. It does not specify an Internet standard of any kind.
Discussion and suggestions for improvement are requested.
Distribution of this memo is unlimited.
Copyright (C) The Internet Society (2003). All Rights Reserved.
This note describes the Explicit Congestion Notification (ECN)-nonce,
an optional addition to ECN that protects against accidental or
malicious concealment of marked packets from the TCP sender. It
improves the robustness of congestion control by preventing receivers
from exploiting ECN to gain an unfair share of network bandwidth.
The ECN-nonce uses the two ECN-Capable Transport (ECT)codepoints in
the ECN field of the IP header, and requires a flag in the TCP
header. It is computationally efficient for both routers and hosts.
Statement of Intent
This specification describes an optional addition to Explicit
Congestion Notification [RFC3168] improving its robustness against
malicious or accidental concealment of marked packets. It has not
been deployed widely. One goal of publication as an Experimental
RFC is to be prudent, and encourage use and deployment prior to
publication in the standards track. Another consideration is to
give time for firewall developers to recognize and accept the
pattern presented by the nonce. It is the intent of the Transport
Area Working Group to re-submit this specification as an IETF
Proposed Standard in the future after more experience has been
Spring, et. al. Experimental [Page 1]RFC 3540 Robust ECN Signaling June 2003
The correct operation of ECN requires the cooperation of the receiver
to return Congestion Experienced signals to the sender, but the
protocol lacks a mechanism to enforce this cooperation. This raises
the possibility that an unscrupulous or poorly implemented receiver
could always clear ECN-Echo and simply not return congestion signals
to the sender. This would give the receiver a performance advantage
at the expense of competing connections that behave properly. More
generally, any device along the path (NAT box, firewall, QOS
bandwidth shapers, and so forth) could remove congestion marks with
The above behaviors may or may not constitute a threat to the
operation of congestion control in the Internet. However, given the
central role of congestion control, it is prudent to design the ECN
signaling loop to be robust against as many threats as possible. In
this way, ECN can provide a clear incentive for improvement over the
prior state-of-the-art without potential incentives for abuse. The
ECN-nonce is a simple, efficient mechanism to eliminate the potential
abuse of ECN.
The ECN-nonce enables the sender to verify the correct behavior of
the ECN receiver and that there is no other interference that
conceals marked (or dropped) packets in the signaling path. The ECN-
nonce protects against both implementation errors and deliberate
abuse. The ECN-nonce:
- catches a misbehaving receiver with a high probability, and never
implicates an innocent receiver.
- does not change other aspects of ECN, nor does it reduce the
benefits of ECN for behaving receivers.
- is cheap in both per-packet overhead (one TCP header flag) and
- is simple and, to the best of our knowledge, not prone to other
We also note that use of the ECN-nonce has two additional benefits,
even when only drop-tail routers are used. First, packet drops
cannot be concealed from the sender. Second, it prevents optimistic
acknowledgements [Savage], in which TCP segments are acknowledged
before they have been received. These benefits also serve to
increase the robustness of congestion control from attacks. We do
not elaborate on these benefits in this document.
The rest of this document describes the ECN-nonce. We present an
overview followed by detailed behavior at senders and receivers.
Spring, et. al. Experimental [Page 2]