datatracker.ietf.org
Sign in
Version 5.6.3, 2014-09-19
Report a bug

Robust Explicit Congestion Notification (ECN) Signaling with Nonces
RFC 3540

Document type: RFC - Experimental (June 2003; No errata)
Document stream: IETF
Last updated: 2013-03-02
Other versions: plain text, pdf, html

IETF State: (None)
Consensus: Unknown
Document shepherd: No shepherd assigned

IESG State: RFC 3540 (Experimental)
Responsible AD: Allison Mankin
Send notices to: <mankin@psg.com>, <jon.peterson@neustar.biz>

Network Working Group                                          N. Spring
Request for Comments: 3540                                  D. Wetherall
Category: Experimental                                            D. Ely
                                                University of Washington
                                                               June 2003

             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 Notice

   Copyright (C) The Internet Society (2003).  All Rights Reserved.

Abstract

   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.

1.  Introduction

   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
      gained.

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
   impunity.

   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
      processing requirements.

   -  is simple and, to the best of our knowledge, not prone to other
      attacks.

   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]

[include full document text]