doc: Add RFC documents

1 files changed, 731 insertions, 0 deletions

diff --git a/doc/rfc/rfc3540.txt b/doc/rfc/rfc3540.txt
new file mode 100644
index 0000000..f781c50
--- /dev/null
+++ b/doc/rfc/rfc3540.txt
@@ -0,0 +1,731 @@
+
+
+
+
+
+
+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]
+
+RFC 3540                  Robust ECN Signaling                 June 2003
+
+
+   The keywords MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD,
+   SHOULD NOT, RECOMMENDED, MAY, and OPTIONAL, when they appear in this
+   document, are to be interpreted as described in [RFC2119].
+
+2.  Overview
+
+   The ECN-nonce builds on the existing ECN-Echo and Congestion Window
+   Reduced (CWR) signaling mechanism.  Familiarity with ECN [ECN] is
+   assumed.  For simplicity, we describe the ECN-nonce in one direction
+   only, though it is run in both directions in parallel.
+
+   The ECN protocol for TCP remains unchanged, except for the definition
+   of a new field in the TCP header.  As in [RFC3168], ECT(0) or ECT(1)
+   (ECN-Capable Transport) is set in the ECN field of the IP header on
+   outgoing packets.  Congested routers change this field to CE
+   (Congestion Experienced).  When TCP receivers notice CE, the ECE
+   (ECN-Echo) flag is set in subsequent acknowledgements until receiving
+   a CWR flag.  The CWR flag is sent on new data whenever the sender
+   reacts to congestion.
+
+   The ECN-nonce adds to this protocol, and enables the receiver to
+   demonstrate to the sender that segments being acknowledged were
+   received unmarked.  A random one-bit value (a nonce) is encoded in
+   the two ECT codepoints.  The one-bit sum of these nonces is returned
+   in a TCP header flag, the nonce sum (NS) bit.  Packet marking erases
+   the nonce value in the ECT codepoints because CE overwrites both ECN
+   IP header bits.  Since each nonce is required to calculate the sum,
+   the correct nonce sum implies receipt of only unmarked packets.  Not
+   only are receivers prevented from concealing marked packets, middle-
+   boxes along the network path cannot unmark a packet without
+   successfully guessing the value of the original nonce.
+
+   The sender can verify the nonce sum returned by the receiver to
+   ensure that congestion indications in the form of marked (or dropped)
+   packets are not being concealed.  Because the nonce sum is only one
+   bit long, senders have a 50-50 chance of catching a lying receiver
+   whenever an acknowledgement conceals a mark.  Because each
+   acknowledgement is an independent trial, cheaters will be caught
+   quickly if there are repeated congestion signals.
+
+   The following paragraphs describe aspects of the ECN-nonce protocol
+   in greater detail.
+
+
+
+
+
+
+
+
+
+Spring, et. al.               Experimental                      [Page 3]
+
+RFC 3540                  Robust ECN Signaling                 June 2003
+
+
+   Each acknowledgement carries a nonce sum, which is the one bit sum
+   (exclusive-or, or parity) of nonces over the byte range represented
+   by the acknowledgement.  The sum is used because not every packet is
+   acknowledged individually, nor are packets acknowledged reliably.  If
+   a sum were not used, the nonce in an unmarked packet could be echoed
+   to prove to the sender that the individual packet arrived unmarked.
+   However, since these acks are not reliably delivered, the sender
+   could not distinguish a lost ACK from one that was never sent in
+   order to conceal a marked packet.  The nonce sum prevents the
+   receiver from concealing individual marked packets by not
+   acknowledging them.  Because the nonce and nonce sum are both one bit
+   quantities, the sum is no easier to guess than the individual nonces.
+   We show the nonce sum calculation below in Figure 1.
+
+    Sender             Receiver
+                         initial sum = 1
+      -- 1:4 ECT(0)  --> NS = 1 + 0(1:4) = 1(:4)
+      <- ACK 4, NS=1 ---
+      -- 4:8 ECT(1)  --> NS = 1(:4) + 1(4:8) = 0(:8)
+      <- ACK 8, NS=0 ---
+      -- 8:12 ECT(1)  -> NS = 0(:8) + 1(8:12) = 1(:12)
+      <- ACK 12, NS=1 --
+      -- 12:16 ECT(1) -> NS = 1(:12) + 1(12:16) = 0(:16)
+      <- ACK 16, NS=0 --
+
+   Figure 1: The calculation of nonce sums at the receiver.
+
+   After congestion has occurred and packets have been marked or lost,
+   resynchronization of the sender and receiver nonce sums is needed.
+   When packets are marked, the nonce is cleared, and the sum of the
+   nonces at the receiver will no longer match the sum at the sender.
+   Once nonces have been lost, the difference between sender and
+   receiver nonce sums is constant until there is further loss.  This
+   means that it is possible to resynchronize the sender and receiver
+   after congestion by having the sender set its nonce sum to that of
+   the receiver.  Because congestion indications do not need to be
+   conveyed more frequently than once per round trip, the sender
+   suspends checking while the CWR signal is being delivered and resets
+   its nonce sum to the receiver's when new data is acknowledged.  This
+   has the benefit that the receiver is not explicitly involved in the
+   re-synchronization process.  The resynchronization process is shown
+   in Figure 2 below.  Note that the nonce sum returned in ACK 12 (NS=0)
+   differs from that in the previous example (NS=1), and it continues to
+   differ for ACK 16.
+
+
+
+
+
+
+
+Spring, et. al.               Experimental                      [Page 4]
+
+RFC 3540                  Robust ECN Signaling                 June 2003
+
+
+    Sender              Receiver
+                            initial sum = 1
+      -- 1:4 ECT(0)       -> NS = 1 + 0(1:4) = 1(:4)
+      <- ACK 4, NS=1      --
+      -- 4:8 ECT(1) -> CE -> NS = 1(:4) + ?(4:8) = 1(:8)
+      <- ACK 8, ECE NS=1  --
+      -- 8:12 ECT(1), CWR -> NS = 1(:8) + 1(8:12) = 0(:12)
+      <- ACK 12, NS=0     --
+      -- 12:16 ECT(1)     -> NS = 0(:12) + 1(12:16) = 1(:16)
+      <- ACK 16, NS=1     --
+
+   Figure 2: The calculation of nonce sums at the receiver when a
+      packet (4:8) is marked.  The receiver may calculate the wrong
+      nonce sum when the original nonce information is lost after a
+      packet is marked.
+
+   Third, we need to reconcile that nonces are sent with packets but
+   acknowledgements cover byte ranges.  Acknowledged byte boundaries
+   need not match the transmitted boundaries, and information can be
+   retransmitted in packets with different byte boundaries.  We discuss
+   the first issue, how a receiver sets a nonce when acknowledging part
+   of a segment, in Section 6.1. The second question, what nonce to send
+   when retransmitting smaller segments as a large segment, has a simple
+   answer: ECN is disabled for retransmissions, so can carry no nonce.
+   Because retransmissions are associated with congestion events, nonce
+   checking is suspended until after CWR is acknowledged and the
+   congestion event is over.
+
+   The next sections describe the detailed behavior of senders, routers
+   and receivers, starting with sender transmit behavior, then around
+   the ECN signaling loop, and finish with sender acknowledgement
+   processing.
+
+3.  Sender Behavior (Transmit)
+
+   Senders manage CWR and ECN-Echo as before.  In addition, they must
+   place nonces on packets as they are transmitted and check the
+   validity of the nonce sums in acknowledgments as they are received.
+   This section describes the transmit process.
+
+   To place a one bit nonce value on every ECN-capable IP packet, the
+   sender uses the two ECT codepoints: ECT(0) represents a nonce of 0,
+   and ECT(1) a nonce of 1.  As in ECN, retransmissions are not ECN-
+   capable, so carry no nonce.
+
+   The sender maintains a mapping from each packet's end sequence number
+   to the expected nonce sum (not the nonce placed in the original
+   transmission) in the acknowledgement bearing that sequence number.
+
+
+
+Spring, et. al.               Experimental                      [Page 5]
+
+RFC 3540                  Robust ECN Signaling                 June 2003
+
+
+4.  Router Behavior
+
+   Routers behave as specified in [RFC3168].  By marking packets to
+   signal congestion, the original value of the nonce, in ECT(0) or
+   ECT(1), is removed.  Neither the receiver nor any other party can
+   unmark the packet without successfully guessing the value of the
+   original nonce.
+
+5.  Receiver Behavior (Receive and Transmit)
+
+   ECN-nonce receivers maintain the nonce sum as in-order packets arrive
+   and return the current nonce sum in each acknowledgement.  Receiver
+   behavior is otherwise unchanged from [RFC3168].  Returning the nonce
+   sum is optional, but recommended, as senders are allowed to
+   discontinue sending ECN-capable packets to receivers that do not
+   support the ECN-nonce.
+
+   As packets are removed from the queue of out-of-order packets to be
+   acknowledged, the nonce is recovered from the IP header.  The nonce
+   is added to the current nonce sum as the acknowledgement sequence
+   number is advanced for the recent packet.
+
+   In the case of marked packets, one or more nonce values may be
+   unknown to the receiver.  In this case the missing nonce values are
+   ignored when calculating the sum (or equivalently a value of zero is
+   assumed) and ECN-Echo will be set to signal congestion to the sender.
+
+   Returning the nonce sum corresponding to a given acknowledgement is
+   straightforward.  It is carried in a single "NS" (Nonce Sum) bit in
+   the TCP header.  This bit is adjacent to the CWR and ECN-Echo bits,
+   set as Bit 7 in byte 13 of the TCP header, as shown below:
+
+     0   1   2   3   4   5   6   7   8   9  10  11  12  13  14  15
+   +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
+   |               |           | N | C | E | U | A | P | R | S | F |
+   | Header Length | Reserved  | S | W | C | R | C | S | S | Y | I |
+   |               |           |   | R | E | G | K | H | T | N | N |
+   +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
+
+   Figure 3: The new definition of bytes 13 and 14 of the TCP Header.
+
+   The initial nonce sum is 1, and is included in the SYN/ACK and ACK of
+   the three way TCP handshake.  This allows the other endpoint to infer
+   nonce support, but is not a negotiation, in that the receiver of the
+   SYN/ACK need not check if NS is set to decide whether to set NS in
+   the subsequent ACK.
+
+
+
+
+
+Spring, et. al.               Experimental                      [Page 6]
+
+RFC 3540                  Robust ECN Signaling                 June 2003
+
+
+6.  Sender Behavior (Receive)
+
+   This section completes the description of sender behavior by
+   describing how senders check the validity of the nonce sums.
+
+   The nonce sum is checked when an acknowledgement of new data is
+   received, except during congestion recovery when additional ECN-Echo
+   signals would be ignored.  Checking consists of comparing the correct
+   nonce sum stored in a buffer to that carried in the acknowledgement,
+   with a correction described in the following subsection.
+
+   If ECN-Echo is not set, the receiver claims to have received no
+   marked packets, and can therefore compute and return the correct
+   nonce sum.  To conceal a mark, the receiver must successfully guess
+   the sum of the nonces that it did not receive, because at least one
+   packet was marked and the corresponding nonce was erased.  Provided
+   the individual nonces are equally likely to be 0 or 1, their sum is
+   equally likely to be 0 or 1.  In other words, any guess is equally
+   likely to be wrong and has a 50-50 chance of being caught by the
+   sender.  Because each new acknowledgement is an independent trial, a
+   cheating receiver is likely to be caught after a small number of
+   lies.
+
+   If ECN-Echo is set, the receiver is sending a congestion signal and
+   it is not necessary to check the nonce sum.  The congestion window
+   will be halved, CWR will be set on the next packet with new data
+   sent, and ECN-Echo will be cleared once the CWR signal is received,
+   as in [RFC3168].  During this recovery process, the sum may be
+   incorrect because one or more nonces were not received.  This does
+   not matter during recovery, because TCP invokes congestion mechanisms
+   at most once per RTT, whether there are one or more losses during
+   that period.
+
+6.1.  Resynchronization After Loss or Mark
+
+   After recovery, it is necessary to re-synchronize the sender and
+   receiver nonce sums so that further acknowledgments can be checked.
+   When the receiver's sum is incorrect, it will remain incorrect until
+   further loss.
+
+   This leads to a simple re-synchronization mechanism where the sender
+   resets its nonce sum to that of the receiver when it receives an
+   acknowledgment for new data sent after the congestion window was
+   reduced.  When responding to explicit congestion signals, this will
+   be the first acknowledgement without the ECN-Echo flag set: the
+   acknowledgement of the packet containing the CWR flag.
+
+
+
+
+
+Spring, et. al.               Experimental                      [Page 7]
+
+RFC 3540                  Robust ECN Signaling                 June 2003
+
+
+    Sender              Receiver
+                             initial sum = 1
+      -- 1:4 ECT(0)       -> NS = 1 + 0(1:4) = 1(:4)
+      <- ACK 4, NS=1      --
+      -- 4:8 ECT(1) -> LOST
+      -- 8:12 ECT(1)      -> nonce sum calculation deferred
+                               until in-order data received
+      <- ACK 4, NS=0      --
+      -- 12:16 ECT(1)     -> nonce sum calculation deferred
+      <- ACK 4, NS=0      --
+      -- 4:8 retransmit   -> NS = 1(:4) + ?(4:8) +
+                                  1(8:12) + 1(12:16) = 1(:16)
+      <- ACK 16, NS=1     --
+      -- 16:20 ECT(1) CWR ->
+      <- ACK 20, NS=0     -- NS = 1(:16) + 1(16:20) = 0(:20)
+
+   Figure 4: The calculation of nonce sums at the receiver when a
+      packet is lost, and resynchronization after loss.  The nonce sum
+      is not changed until the cumulative acknowledgement is advanced.
+
+   In practice, resynchronization can be accomplished by storing a bit
+   that has the value one if the expected nonce sum stored by the sender
+   and the received nonce sum in the acknowledgement of CWR differ, and
+   zero otherwise.  This synchronization offset bit can then be used in
+   the comparison between expected nonce sum and received nonce sum.
+
+   The sender should ignore the nonce sum returned on any
+   acknowledgements bearing the ECN-echo flag.
+
+   When an acknowledgment covers only a portion of a segment, such as
+   when a middlebox resegments at the TCP layer instead of fragmenting
+   IP packets, the sender should accept the nonce sum expected at the
+   next segment boundary.  In other words, an acknowledgement covering
+   part of an original segment will include the nonce sum expected when
+   the entire segment is acknowledged.
+
+   Finally, in ECN, senders can choose not to indicate ECN capability on
+   some packets for any reason.  An ECN-nonce sender must resynchronize
+   after sending such ECN-incapable packets, as though a CWR had been
+   sent with the first new data after the ECN-incapable packets.  The
+   sender loses protection for any unacknowledged packets until
+   resynchronization occurs.
+
+
+
+
+
+
+
+
+
+Spring, et. al.               Experimental                      [Page 8]
+
+RFC 3540                  Robust ECN Signaling                 June 2003
+
+
+6.2.  Sender Behavior - Incorrect Nonce Received
+
+   The sender's response to an incorrect nonce is a matter of policy.
+   It is separate from the checking mechanism and does not need to be
+   handled uniformly by senders.  Further, checking received nonce sums
+   at all is optional, and may be disabled.
+
+   If the receiver has never sent a non-zero nonce sum, the sender can
+   infer that the receiver does not understand the nonce, and rate limit
+   the connection, place it in a lower-priority queue, or cease setting
+   ECT in outgoing segments.
+
+   If the received nonce sum has been set in a previous acknowledgement,
+   the sender might infer that a network device has interfered with
+   correct ECN signaling between ECN-nonce supporting endpoints.  The
+   minimum response to an incorrect nonce is the same as the response to
+   a received ECE.  However, to compensate for hidden congestion
+   signals, the sender might reduce the congestion window to one segment
+   and cease setting ECT in outgoing segments.  An incorrect nonce sum
+   is a sign of misbehavior or error between ECN-nonce supporting
+   endpoints.
+
+6.2.1.  Using the ECN-nonce to Protect Against Other Misbehaviors
+
+   The ECN-nonce can provide robustness beyond checking that marked
+   packets are signaled to the sender.  It also ensures that dropped
+   packets cannot be concealed from the sender (because their nonces
+   have been lost).  Drops could potentially be concealed by a faulty
+   TCP implementation, certain attacks, or even a hypothetical TCP
+   accelerator.  Such an accelerator could gamble that it can either
+   successfully "fast start" to a preset bandwidth quickly, retry with
+   another connection, or provide reliability at the application level.
+   If robustness against these faults is also desired, then the ECN-
+   nonce should not be disabled.  Instead, reducing the congestion
+   window to one, or using a low-priority queue, would penalize faulty
+   operation while providing continued checking.
+
+   The ECN-nonce can also detect misbehavior in Eifel [Eifel], a
+   recently proposed mechanism for removing the retransmission ambiguity
+   to improve TCP performance.  A misbehaving receiver might claim to
+   have received only original transmissions to convince the sender to
+   undo congestion actions.  Since retransmissions are sent without ECT,
+   and thus no nonce, returning the correct nonce sum confirms that only
+   original transmissions were received.
+
+
+
+
+
+
+
+Spring, et. al.               Experimental                      [Page 9]
+
+RFC 3540                  Robust ECN Signaling                 June 2003
+
+
+7.  Interactions
+
+7.1.  Path MTU Discovery
+
+   As described in RFC3168, use of the Don't Fragment bit with ECN is
+   recommended.  Receivers that receive unmarked fragments can
+   reconstruct the original nonce to conceal a marked fragment.  The
+   ECN-nonce cannot protect against misbehaving receivers that conceal
+   marked fragments, so some protection is lost in situations where Path
+   MTU discovery is disabled.
+
+   When responding to a small path MTU, the sender will retransmit a
+   smaller frame in place of a larger one.  Since these smaller packets
+   are retransmissions, they will be ECN-incapable and bear no nonce.
+   The sender should resynchronize on the first newly transmitted
+   packet.
+
+7.2.  SACK
+
+   Selective acknowledgements allow receivers to acknowledge out of
+   order segments as an optimization.  It is not necessary to modify the
+   selective acknowledgment option to fit per-range nonce sums, because
+   SACKs cannot be used by a receiver to hide a congestion signal.  The
+   nonce sum corresponds only to the data acknowledged by the cumulative
+   acknowledgement.
+
+7.3.  IPv6
+
+   Although the IPv4 header is protected by a checksum, this is not the
+   case with IPv6, making undetected bit errors in the IPv6 header more
+   likely.  Bit errors that compromise the integrity of the congestion
+   notification fields may cause an incorrect nonce to be received, and
+   an incorrect nonce sum to be returned.
+
+8.  Security Considerations
+
+   The random one-bit nonces need not be from a cryptographic-quality
+   pseudo-random number generator.  A strong random number generator
+   would compromise performance.  Consequently, the sequence of random
+   nonces should not be used for any other purpose.
+
+   Conversely, the pseudo-random bit sequence should not be generated by
+   a linear feedback shift register [Schneier], or similar scheme that
+   would allow an adversary who has seen several previous bits to infer
+   the generation function and thus its future output.
+
+
+
+
+
+
+Spring, et. al.               Experimental                     [Page 10]
+
+RFC 3540                  Robust ECN Signaling                 June 2003
+
+
+   Although the ECN-nonce protects against concealment of congestion
+   signals and optimistic acknowledgement, it provides no additional
+   protection for the integrity of the connection.
+
+9.  IANA Considerations
+
+   The Nonce Sum (NS) is carried in a reserved TCP header bit that must
+   be allocated.  This document describes the use of Bit 7, adjacent to
+   the other header bits used by ECN.
+
+   The codepoint for the NS flag in the TCP header is specified by the
+   Standards Action of this RFC, as is required by RFC 2780.  The IANA
+   has added the following to the registry for "TCP Header Flags":
+
+   RFC 3540 defines bit 7 from the Reserved field to be used for the
+   Nonce Sum, as follows:
+
+     0   1   2   3   4   5   6   7   8   9  10  11  12  13  14  15
+   +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
+   |               |           | N | C | E | U | A | P | R | S | F |
+   | Header Length | Reserved  | S | W | C | R | C | S | S | Y | I |
+   |               |           |   | R | E | G | K | H | T | N | N |
+   +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
+
+   TCP Header Flags
+
+   Bit      Name                                    Reference
+   ---      ----                                    ---------
+    7        NS (Nonce Sum)                         [RFC 3540]
+
+10.  Conclusion
+
+   The ECN-nonce is a simple modification to the ECN signaling mechanism
+   that improves ECN's robustness by preventing receivers from
+   concealing marked (or dropped) packets.  The intent of this work is
+   to help improve the robustness of congestion control in the Internet.
+   The modification retains the character and simplicity of existing ECN
+   signaling.  It is also practical for deployment in the Internet.  It
+   uses the ECT(0) and ECT(1) codepoints and one TCP header flag (as
+   well as CWR and ECN-Echo) and has simple processing rules.
+
+
+
+
+
+
+
+
+
+
+
+Spring, et. al.               Experimental                     [Page 11]
+
+RFC 3540                  Robust ECN Signaling                 June 2003
+
+
+11.  References
+
+   [ECN]      "The ECN Web Page", URL
+              "http://www.icir.org/floyd/ecn.html".
+
+   [RFC3168]  Ramakrishnan, K., Floyd, S. and D. Black, "The addition of
+              explicit congestion notification (ECN) to IP", RFC 3168,
+              September 2001.
+
+   [Eifel]    R. Ludwig and R. Katz. The Eifel Algorithm: Making TCP
+              Robust Against Spurious Retransmissions. Computer
+              Communications Review, January, 2000.
+
+   [B97]      Bradner, S., "Key words for use in RFCs to Indicate
+              Requirement Levels", BCP 14, RFC 2119, March 1997.
+
+   [Savage]   S. Savage, N. Cardwell, D. Wetherall, T. Anderson.  TCP
+              congestion control with a misbehaving receiver. SIGCOMM
+              CCR, October 1999.
+
+   [Schneier] Bruce Schneier. Applied Cryptography, 2nd ed., 1996
+
+12.  Acknowledgements
+
+   This note grew out of research done by Stefan Savage, David Ely,
+   David Wetherall, Tom Anderson and Neil Spring.  We are very grateful
+   for feedback and assistance from Sally Floyd.
+
+13.  Authors' Addresses
+
+   Neil Spring
+   EMail: nspring@cs.washington.edu
+
+
+   David Wetherall
+   Department of Computer Science and Engineering, Box 352350
+   University of Washington
+   Seattle WA 98195-2350
+   EMail: djw@cs.washington.edu
+
+
+   David Ely
+   Computer Science and Engineering, 352350
+   University of Washington
+   Seattle, WA 98195-2350
+   EMail: ely@cs.washington.edu
+
+
+
+
+
+Spring, et. al.               Experimental                     [Page 12]
+
+RFC 3540                  Robust ECN Signaling                 June 2003
+
+
+14.  Full Copyright Statement
+
+   Copyright (C) The Internet Society (2003).  All Rights Reserved.
+
+   This document and translations of it may be copied and furnished to
+   others, and derivative works that comment on or otherwise explain it
+   or assist in its implementation may be prepared, copied, published
+   and distributed, in whole or in part, without restriction of any
+   kind, provided that the above copyright notice and this paragraph are
+   included on all such copies and derivative works.  However, this
+   document itself may not be modified in any way, such as by removing
+   the copyright notice or references to the Internet Society or other
+   Internet organizations, except as needed for the purpose of
+   developing Internet standards in which case the procedures for
+   copyrights defined in the Internet Standards process must be
+   followed, or as required to translate it into languages other than
+   English.
+
+   The limited permissions granted above are perpetual and will not be
+   revoked by the Internet Society or its successors or assigns.
+
+   This document and the information contained herein is provided on an
+   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
+   TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
+   BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
+   HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
+   MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
+
+Acknowledgement
+
+   Funding for the RFC Editor function is currently provided by the
+   Internet Society.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Spring, et. al.               Experimental                     [Page 13]
+