[Docs] [txt|pdf] [Tracker] [WG] [Email] [Nits]

Versions: 00

Internet Engineering Task Force                              Sally Floyd
INTERNET DRAFT                                                     ACIRI
draft-ietf-tsvwg-tcp-ecn-00.txt                       K. K. Ramakrishnan
                                                      TeraOptic Networks
                                                           November 2000
                                                      Expires:  May 2001



       TCP with ECN: The Treatment of Retransmitted Data Packets




                          Status of this Memo


   This document is an Internet-Draft and is in full conformance with
   all provisions of Section 10 of RFC2026.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups.  Note that
   other groups may also distribute working documents as Internet-
   Drafts.

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

   The list of current Internet-Drafts can be accessed at
   http://www.ietf.org/ietf/1id-abstracts.txt

   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html.

Abstract

   This document makes recommendations for the use of ECN with
   retransmitted data packets, for an ECN-capable TCP connection.  This
   document supplements RFC 2481 [RFC2481], which did not address the
   issue of retransmitted data packets.  This document recommends that
   for ECN-capable TCP implementations, the ECT bit (ECN-Capable
   Transport) in the IP header SHOULD NOT be set on retransmitted data
   packets, and that the TCP data receiver SHOULD ignore the ECN field
   on arriving data packets that are outside of the receiver's current
   window.  This is for greater security against denial-of-service
   attacks.



Floyd and Ramakrishnan        Experimental                      [Page 1]


draft-tsvwg-tcp-ecn-00        TCP with ECN                 November 2000


   In addition, this document recommends that the CWR bit (Congestion
   Window Reduced) in the TCP header SHOULD NOT be set on retransmitted
   packets.  When the TCP data sender is ready to set the CWR bit after
   reducing the congestion window, it SHOULD set the CWR bit on the
   first new data packet that it transmits.

1. Introduction

   RFC 2481, which describes both the TCP and IP semantics for ECN, does
   not make any special mention of retransmitted TCP packets.  It is
   important to make special mention of the use of ECN with
   retransmitted packets, especially the setting of the ECT bit on
   retransmitted packets.  If TCP is allowed to set the ECT bit on
   retransmitted data packets, this could open the door for denial-of-
   service attacks.

   In particular, an attacker capable of spoofing the IP source address
   could send data packets with arbitrary sequence numbers, with both
   the ECT and CE bits set in the IP header.  On receiving this spoofed
   data packet, the TCP data receiver would determine that the data does
   not lie in the current receive window, and return a duplicate
   acknowledgement.  We define an out-of-window packet at the TCP data
   receiver as a data packet that lies outside the receiver's current
   window.  On receiving an out-of-window packet, the TCP data receiver
   has to decide whether or not to treat the CE bit in the packet header
   as a valid indication of congestion, and therefore whether to return
   ECN-Echo indications to the TCP data sender.  If the TCP data
   receiver ignored the CE bit in an out-of-window packet, then the TCP
   data sender would not receive this possibly-legitimate indication of
   congestion, resulting in a violation of end-to-end congestion
   control.  On the other hand, if the TCP data receiver honors the CE
   indication in the out-of-window packet, and reports the indication of
   congestion to the TCP data sender, then the malicious node that
   created the spoofed, out-of-window packet has successfully
   ``attacked'' the TCP connection by forcing the data sender to
   unnecessarily reduce (halve) its congestion window.  To prevent such
   a denial-of-service attack, Section 2 of this document recommends
   that a legitimate TCP data sender SHOULD NOT set the ECT bit on
   retransmitted data packets, and that the TCP data receiver SHOULD
   ignore the CE bit on out-of-window packets.

2.  ECN and Retransmitted Data Packets

   In this document we assume an environment where it is possible for a
   malicious host to spoof the legitimate IP source address of a TCP
   connection, and to send a data packet with the spoofed source address
   along with the ECT and CE bits set.  In order to protect itself
   against a denial-of-service attack, the TCP connection has to refrain



Floyd and Ramakrishnan        Experimental                      [Page 2]


draft-tsvwg-tcp-ecn-00        TCP with ECN                 November 2000


   from halving its congestion window in response to such a spoofed data
   packet.

   There are several possible ways that a TCP connection could protect
   itself from such a denial-of-service attack:

      (1) Not using ECN on retransmits: The TCP receiver could ignore
      the CE bit on out-of-window packets, knowing that a conformant
      sender would not set the ECT bit on retransmitted packets.

      (2) Ignoring ECN on out-of-window packets: The TCP receiver could
      ignore the CE bit on out-of-window packets, knowing that a
      conformant sender would not set the ECT bit on retransmitted
      packets.

      (3) Ignoring ECN on significantly out-of-window packets: The TCP
      receiver could ignore the CE bit on packets far outside the
      current window, while a conformant sender could be allowed to set
      the ECT bit on retransmitted packets.

      (4) Verifying out-of-window ECN packets: The TCP receiver could
      report to the sender the sequence numbers of an out-of-window data
      packet with the CE bit set, and the sender could halve its
      congestion window only if it had in fact recently sent this
      packet.

   In this document we discuss each of these four proposals, and explain
   why we follow the first proposal, to not use ECN on retransmitted
   data packets (by not setting the ECT bit on these packets), for ECN-
   Capable TCP implementations.

2.1.   Option 1:  Not Using ECN on Retransmits.

   This document recommends Option 1, not using ECN on retransmitted
   packets.  This approach is simple, straightforward, and protects
   against ECN-based denial-of-service attacks.  (This assumes that the
   attacker is unable to guess the initial sequence number (ISN) of a
   TCP connection, and therefore is unlikely to guess a sequence number
   for a spoofed packet that is within the current window.)

   The drawback of Option 1 is that it denies ECN protection for
   retransmitted packets.  However, for an ECN-capable TCP connection in
   a fully-ECN-capable environment with mild congestion, packets should
   rarely be dropped due to congestion in the first place, and so
   instances of retransmitted packets should rarely arise.  If packets
   are being retransmitted, then there are already packet losses (from
   corruption or from congestion) that ECN has been unable to prevent.




Floyd and Ramakrishnan        Experimental                      [Page 3]


draft-tsvwg-tcp-ecn-00        TCP with ECN                 November 2000


   We note that, with Option 1, if the router sets the CE bit for an
   ECN-capable data packet within a TCP connection, then the TCP
   connection is guaranteed to receive that indication of congestion, or
   to receive some other indication of congestion within the same window
   of data, even if this packet is dropped or reordered in the network.
   We consider two cases, when the packet is later retransmitted, and
   when the packet is not later retransmitted.

   In the first case, if the packet is either dropped or delayed, and at
   some point retransmitted by the data sender, then the retransmission
   is a result of a Fast Retransmit or a Retransmit Timeout for either
   that packet or for some prior packet in the same window of data.  In
   this case, because the data sender already has retransmitted this
   packet, we know that the data sender has already responded to an
   indication of congestion for some packet within the same window of
   data as the original packet.  Thus, even if this retransmitted packet
   is dropped in the network, or is delayed, with the CE bit set, and is
   later ignored by the data receiver as an out-of-window packet, this
   is not a problem, because the sender has already responded to an
   indication of congestion for that window of data. Communicating the
   indication of congestion with the CE bit for this retransmitted
   packet (if that indication is provided to the sender within the same
   window of data as a previously dropped packet) would not have
   resulted in any further reduction of the window by the sender.

   In the second case, if the packet is never retransmitted by the data
   sender, then this data packet is the only copy of this data received
   by the data receiver, and therefore arrives at the data receiver as
   an in-window packet, regardless of how much the packet might be
   delayed or reordered.  In this case, if the CE bit is set on the
   packet within the network, this will be treated by the data receiver
   as a valid indication of congestion.

2.2.   Option 2:  Ignoring ECN on Out-of-window Packets?

   A second option for protecting against ECN-based denial-of-service
   attacks would be for the TCP data sender to be allowed to set the CE
   bit on retransmitted packets, but for the TCP data receiver to ignore
   the CE bit on out-of-window data packets.  However, this would have
   the unfortunate consequence of weakening the effectiveness of ECN-
   based end-to-end congestion control (by carrying over to ECN some of
   the existing weaknesses of packet drops as indications of
   congestion).

   We will say that a retransmitted TCP packet is ``necessarily-
   retransmitted'' if the retransmission is the only copy of this data
   received at the TCP receiver, and ``unnecessarily-retransmitted''
   otherwise.  For TCP, drops of unnecessarily-retransmitted data



Floyd and Ramakrishnan        Experimental                      [Page 4]


draft-tsvwg-tcp-ecn-00        TCP with ECN                 November 2000


   packets are not detected as indications of congestion by the TCP end
   nodes.  That is, if a necessarily-retransmitted TCP packet is
   dropped, then the packet loss is detected by the TCP receiver, and
   TCP reduces its sending rate.  In contrast, if an unnecessarily-
   retransmitted TCP packet is dropped, then that loss is not detected
   by the TCP receiver, and TCP does not reduce its sending rate.

   Option 2, of ignoring ECN on out-of-window packets, would effectively
   prevent ECN-based denial-of-service attacks using retransmitted
   packets.  At the same time, allowing the data receiver to ignore ECN
   information on out-of-window packets would carry over to ECN the
   weaknesses of packet drops as indications of congestion: that packet
   drops of unnecessarily-retransmitted packets are not detected as
   indications of congestion by the TCP end hosts.  With Option 2, a
   necessarily-retransmitted TCP packet would be in-window when received
   at the TCP receiver, and ECN indications in the packet header would
   be treated normally by the TCP receiver.  However, an unnecessarily-
   retransmitted TCP packet would most likely be out-of-window when
   received at the TCP receiver, and therefore, with Option 2, any ECN
   information in the packet header would be ignored.  Setting the ECT
   bit on unnecessarily-retransmitted TCP packets has the potential that
   routers would mark rather than drop such packets. A receiver ignoring
   the CE bit on such a packet would result in not communicating the
   congestion indication to the TCP sender, making the ECN information
   as unreliable as packet drops for unnecessarily-retransmitted
   packets.  However, it is not sufficient for ECN to be merely as
   reliable as packet losses as indications of congestion.  An attempt
   by a congested router to avoid dropping the unnecessarily-
   retransmitted packet and provide an indication of congestion via ECN
   would be negated by Option 2.  With Option 2, a transport would
   communicate that it is ECN-capable by setting the ECT bit, but would
   ignore the CE bit.  In addition to violating the semantics of ECN,
   this could also have an impact on other flows, both in terms of
   fairness and the possible congestion experienced by such other flows.

   The principle has already been established for TCP that the ECT bit
   should not be set on a packet if there will be no viable congestion-
   control response by the transport to a router setting the CE bit in
   the packet header.  Consider the example of pure acknowledgement
   (ACK) packets.  TCP does not have effective, loss-based end-to-end
   congestion control for ACK packets, that is, packets that don't
   contain any data.  If a pure ACK packet in a TCP connection is
   dropped, the TCP connection does not respond by reducing its sending
   rate along that path.  Because current TCP receivers have no
   mechanisms for reducing traffic on the ACK-path in response to
   congestion notification, RFC 2481 specifies that the ECT bit should
   not be set on pure ACK packets.




Floyd and Ramakrishnan        Experimental                      [Page 5]


draft-tsvwg-tcp-ecn-00        TCP with ECN                 November 2000


   Therefore, our view is that Option 2 is not a viable option for
   preventing ECN-based denial-of-service attacks on a connection.

2.3.   Option 3: Ignoring ECN on significantly out-of-window packets:

   With Option 3, the TCP data sender would be allowed to set the CE bit
   on retransmitted packets, and the TCP connection would protect itself
   from ECN on spoofed packets by checking the sequence numbers of out-
   of-window packets that arrive with the CE bit set.  Consider a data
   receiver that has acknowledged data up to and including sequence
   number N, and has a window of W bytes.  If the out-of-window data is
   contained within the sequence number range (N-W, N] (modulo the
   proper amount), then the CE bit on the out-of-window packet is
   treated as a valid indication of congestion, and otherwise the CE bit
   on the out-of-window packet is ignored.  This is based on the view
   that the receiver considers the range (N-W, N] to represent a range
   of data that could plausibly result from retransmissions from the
   legitimate data source.

   Option 3 would make it somewhat easier for a malicious host to guess
   a sequence-number range for which a CE bit would be treated as a
   valid indication of congestion, and therefore would make an ECN-based
   denial-of-service attack somewhat more likely to be successful.
   However, Option 3 would still offer a significant protection against
   denial-of-service attacks because the malicious host has to guess the
   appropriate sequence number range.

   However, Option 3 introduces some additional complexity at the TCP
   data receiver, and would not necessarily result in the CE bit being
   respected on all data packets actually sent by the legitimate data
   sender.  While Option 3 has the benefit over Option 1 of allowing the
   sender to set the ECT bit on retransmitted packets, the benefit does
   not seem worth the additional cost at the data receiver.

2.4.   Option 4:  Verifying out-of-window ECN packets?

   With Option 4, the TCP data sender would be allowed to set the CE bit
   on retransmitted packets, and the TCP connection would protect itself
   from ECN on spoofed packets by having the data receiver report to the
   data sender the sequence numbers of the data in out-of-window packets
   with the CE bit set.  Using this sequence-number information, the
   data sender could verify that it had actually sent this retransmitted
   packet before honoring the ECN indication of congestion.  If the data
   sender determined that this packet was in fact from another host that
   had spoofed its IP address, then the data sender could ignore this
   indication of congestion.

   At first glance this seems simple, but Option 4 would actually turn



Floyd and Ramakrishnan        Experimental                      [Page 6]


draft-tsvwg-tcp-ecn-00        TCP with ECN                 November 2000


   into something rather complicated.  The ECN-Echo information is
   carried from the data receiver to the data sender not just in one ACK
   packet, but possibly in a number of successive ACK packets.  In
   addition, the data receiver could receive multiple data packets with
   the CE bit set, which are treated by the data sender as a single
   instance of congestion.  The benefits of Option 4 do not seem likely
   to be worth the extra complexity that would be entailed.  In
   addition, this would require significant additional changes to the
   header and to the standardization process for such use.

   In summary, this document recommends Option 1, that the ECT bit
   SHOULD NOT be set on retransmitted data packets, and that the TCP
   data receiver SHOULD ignore the ECN field on out-of-window data
   packets.

3.  Setting the CWR bit.

   RFC 2481 says the following regarding the setting of the CWR bit:
   ``When an ECN-Capable TCP reduces its congestion window for any
   reason (because of a retransmit timeout, a Fast Retransmit, or in
   response to an ECN Notification), the TCP sets the CWR flag in the
   TCP header of the first data packet sent after the window reduction.
   If that data packet is dropped in the network, then the sending TCP
   will have to reduce the congestion window again and retransmit the
   dropped packet.  Thus, the Congestion Window Reduced message is
   reliably delivered to the data receiver."

   However, as noted earlier in this document, if a retransmitted data
   packet is dropped in the network, the sending TCP does not
   necessarily respond by reducing its congestion window.  Therefore,
   the CWR bit SHOULD NOT be set on retransmitted packets.  Instead,
   when the TCP data sender is ready to set the CWR bit after reducing
   the congestion window, it SHOULD set the CWR bit on the first *new*
   data packet that it subsequently transmits.

4.  ECN and window probes.

   When the TCP data receiver advertises a zero window, the TCP data
   sender sends window probes to determine if the receiver's window has
   increased.  Window probe packets do not contain any user data except
   for the sequence number, which is a byte.  Because window probes use
   the exact sequence numbers, they cannot be easily spoofed in denial-
   of-service attacks.  Therefore, if a window probe arrives with ECT
   and CE set, then the receiver SHOULD respond to the ECN indications.

   At the same time, if a window probe packet is dropped in the network,
   this loss is not detected by the receiver.  Therefore, the TCP data
   sender SHOULD NOT set either the ECT or CWR bits on window probe



Floyd and Ramakrishnan        Experimental                      [Page 7]


draft-tsvwg-tcp-ecn-00        TCP with ECN                 November 2000


   packets.

5.  Conclusions

   This document recommends that for ECN-capable TCP implementations,
   the ECT bit SHOULD NOT be set on retransmitted data packets, and that
   the TCP data receiver SHOULD ignore the ECN field on out-of-window
   data packets.  This is for greater security against denial-of-service
   attacks.

   In addition, this document recommends that the CWR bit (Congestion
   Window Reduced) in the TCP header SHOULD NOT be set on retransmitted
   packets.  When the TCP data sender is ready to set the CWR bit after
   reducing the congestion window, it SHOULD set the CWR bit on the
   first *new* data packet that it transmits.

   Finally, this document recommends that a TCP data sender SHOULD NOT
   set either the ECT or CWR bits on window probe packets.

6. Acknowledgements

   This note resulted from email discussions with a number of people,
   including Alexey Kuznetsov, Jamal Hadi-Salim, and Venkat Venkatsubra.




























Floyd and Ramakrishnan        Experimental                      [Page 8]


draft-tsvwg-tcp-ecn-00        TCP with ECN                 November 2000


7. References


   [RFC2481] K. Ramakrishnan, S. Floyd, A Proposal to add Explicit
   Congestion Notification (ECN) to IP, RFC 2481, January 1999.

8. Security Considerations

   Security considerations have been addressed in the main body of the
   document.

AUTHORS' ADDRESSES


   K. K. Ramakrishnan
   TeraOptic Networks
   Phone: +1 (408) 666-8650
   Email: kk@teraoptic.com

   Sally Floyd
   Phone: +1 (510) 666-2989
   ACIRI
   Email: floyd@aciri.org
   URL: http://www.aciri.org/floyd/


   This draft was created in November 2000.
   It expires May 2001.























Floyd and Ramakrishnan        Experimental                      [Page 9]


Html markup produced by rfcmarkup 1.127, available from https://tools.ietf.org/tools/rfcmarkup/