diff options
Diffstat (limited to 'doc/rfc/rfc3168.txt')
| -rw-r--r-- | doc/rfc/rfc3168.txt | 3531 |
1 files changed, 3531 insertions, 0 deletions
diff --git a/doc/rfc/rfc3168.txt b/doc/rfc/rfc3168.txt new file mode 100644 index 0000000..30b05f7 --- /dev/null +++ b/doc/rfc/rfc3168.txt @@ -0,0 +1,3531 @@ + + + + + + +Network Working Group K. Ramakrishnan +Request for Comments: 3168 TeraOptic Networks +Updates: 2474, 2401, 793 S. Floyd +Obsoletes: 2481 ACIRI +Category: Standards Track D. Black + EMC + September 2001 + + + The Addition of Explicit Congestion Notification (ECN) to IP + +Status of this Memo + + This document specifies an Internet standards track protocol for the + Internet community, and requests discussion and suggestions for + improvements. Please refer to the current edition of the "Internet + Official Protocol Standards" (STD 1) for the standardization state + and status of this protocol. Distribution of this memo is unlimited. + +Copyright Notice + + Copyright (C) The Internet Society (2001). All Rights Reserved. + +Abstract + + This memo specifies the incorporation of ECN (Explicit Congestion + Notification) to TCP and IP, including ECN's use of two bits in the + IP header. + +Table of Contents + + 1. Introduction.................................................. 3 + 2. Conventions and Acronyms...................................... 5 + 3. Assumptions and General Principles............................ 5 + 4. Active Queue Management (AQM)................................. 6 + 5. Explicit Congestion Notification in IP........................ 6 + 5.1. ECN as an Indication of Persistent Congestion............... 10 + 5.2. Dropped or Corrupted Packets................................ 11 + 5.3. Fragmentation............................................... 11 + 6. Support from the Transport Protocol........................... 12 + 6.1. TCP......................................................... 13 + 6.1.1 TCP Initialization......................................... 14 + 6.1.1.1. Middlebox Issues........................................ 16 + 6.1.1.2. Robust TCP Initialization with an Echoed Reserved Field. 17 + 6.1.2. The TCP Sender............................................ 18 + 6.1.3. The TCP Receiver.......................................... 19 + 6.1.4. Congestion on the ACK-path................................ 20 + 6.1.5. Retransmitted TCP packets................................. 20 + + + +Ramakrishnan, et al. Standards Track [Page 1] + +RFC 3168 The Addition of ECN to IP September 2001 + + + 6.1.6. TCP Window Probes......................................... 22 + 7. Non-compliance by the End Nodes............................... 22 + 8. Non-compliance in the Network................................. 24 + 8.1. Complications Introduced by Split Paths..................... 25 + 9. Encapsulated Packets.......................................... 25 + 9.1. IP packets encapsulated in IP............................... 25 + 9.1.1. The Limited-functionality and Full-functionality Options.. 27 + 9.1.2. Changes to the ECN Field within an IP Tunnel.............. 28 + 9.2. IPsec Tunnels............................................... 29 + 9.2.1. Negotiation between Tunnel Endpoints...................... 31 + 9.2.1.1. ECN Tunnel Security Association Database Field.......... 32 + 9.2.1.2. ECN Tunnel Security Association Attribute............... 32 + 9.2.1.3. Changes to IPsec Tunnel Header Processing............... 33 + 9.2.2. Changes to the ECN Field within an IPsec Tunnel........... 35 + 9.2.3. Comments for IPsec Support................................ 35 + 9.3. IP packets encapsulated in non-IP Packet Headers............ 36 + 10. Issues Raised by Monitoring and Policing Devices............. 36 + 11. Evaluations of ECN........................................... 37 + 11.1. Related Work Evaluating ECN................................ 37 + 11.2. A Discussion of the ECN nonce.............................. 37 + 11.2.1. The Incremental Deployment of ECT(1) in Routers.......... 38 + 12. Summary of changes required in IP and TCP.................... 38 + 13. Conclusions.................................................. 40 + 14. Acknowledgements............................................. 41 + 15. References................................................... 41 + 16. Security Considerations...................................... 45 + 17. IPv4 Header Checksum Recalculation........................... 45 + 18. Possible Changes to the ECN Field in the Network............. 45 + 18.1. Possible Changes to the IP Header.......................... 46 + 18.1.1. Erasing the Congestion Indication........................ 46 + 18.1.2. Falsely Reporting Congestion............................. 47 + 18.1.3. Disabling ECN-Capability................................. 47 + 18.1.4. Falsely Indicating ECN-Capability........................ 47 + 18.2. Information carried in the Transport Header................ 48 + 18.3. Split Paths................................................ 49 + 19. Implications of Subverting End-to-End Congestion Control..... 50 + 19.1. Implications for the Network and for Competing Flows....... 50 + 19.2. Implications for the Subverted Flow........................ 53 + 19.3. Non-ECN-Based Methods of Subverting End-to-end Congestion + Control.................................................... 54 + 20. The Motivation for the ECT Codepoints........................ 54 + 20.1. The Motivation for an ECT Codepoint........................ 54 + 20.2. The Motivation for two ECT Codepoints...................... 55 + 21. Why use Two Bits in the IP Header?........................... 57 + 22. Historical Definitions for the IPv4 TOS Octet................ 58 + 23. IANA Considerations.......................................... 60 + 23.1. IPv4 TOS Byte and IPv6 Traffic Class Octet................. 60 + 23.2. TCP Header Flags........................................... 61 + + + +Ramakrishnan, et al. Standards Track [Page 2] + +RFC 3168 The Addition of ECN to IP September 2001 + + + 23.3. IPSEC Security Association Attributes....................... 62 + 24. Authors' Addresses........................................... 62 + 25. Full Copyright Statement..................................... 63 + +1. Introduction + + We begin by describing TCP's use of packet drops as an indication of + congestion. Next we explain that with the addition of active queue + management (e.g., RED) to the Internet infrastructure, where routers + detect congestion before the queue overflows, routers are no longer + limited to packet drops as an indication of congestion. Routers can + instead set the Congestion Experienced (CE) codepoint in the IP + header of packets from ECN-capable transports. We describe when the + CE codepoint is to be set in routers, and describe modifications + needed to TCP to make it ECN-capable. Modifications to other + transport protocols (e.g., unreliable unicast or multicast, reliable + multicast, other reliable unicast transport protocols) could be + considered as those protocols are developed and advance through the + standards process. We also describe in this document the issues + involving the use of ECN within IP tunnels, and within IPsec tunnels + in particular. + + One of the guiding principles for this document is that, to the + extent possible, the mechanisms specified here be incrementally + deployable. One challenge to the principle of incremental deployment + has been the prior existence of some IP tunnels that were not + compatible with the use of ECN. As ECN becomes deployed, non- + compatible IP tunnels will have to be upgraded to conform to this + document. + + This document obsoletes RFC 2481, "A Proposal to add Explicit + Congestion Notification (ECN) to IP", which defined ECN as an + Experimental Protocol for the Internet Community. This document also + updates RFC 2474, "Definition of the Differentiated Services Field + (DS Field) in the IPv4 and IPv6 Headers", in defining the ECN field + in the IP header, RFC 2401, "Security Architecture for the Internet + Protocol" to change the handling of IPv4 TOS Byte and IPv6 Traffic + Class Octet in tunnel mode header construction to be compatible with + the use of ECN, and RFC 793, "Transmission Control Protocol", in + defining two new flags in the TCP header. + + TCP's congestion control and avoidance algorithms are based on the + notion that the network is a black-box [Jacobson88, Jacobson90]. The + network's state of congestion or otherwise is determined by end- + systems probing for the network state, by gradually increasing the + load on the network (by increasing the window of packets that are + outstanding in the network) until the network becomes congested and a + packet is lost. Treating the network as a "black-box" and treating + + + +Ramakrishnan, et al. Standards Track [Page 3] + +RFC 3168 The Addition of ECN to IP September 2001 + + + loss as an indication of congestion in the network is appropriate for + pure best-effort data carried by TCP, with little or no sensitivity + to delay or loss of individual packets. In addition, TCP's + congestion management algorithms have techniques built-in (such as + Fast Retransmit and Fast Recovery) to minimize the impact of losses, + from a throughput perspective. However, these mechanisms are not + intended to help applications that are in fact sensitive to the delay + or loss of one or more individual packets. Interactive traffic such + as telnet, web-browsing, and transfer of audio and video data can be + sensitive to packet losses (especially when using an unreliable data + delivery transport such as UDP) or to the increased latency of the + packet caused by the need to retransmit the packet after a loss (with + the reliable data delivery semantics provided by TCP). + + Since TCP determines the appropriate congestion window to use by + gradually increasing the window size until it experiences a dropped + packet, this causes the queues at the bottleneck router to build up. + With most packet drop policies at the router that are not sensitive + to the load placed by each individual flow (e.g., tail-drop on queue + overflow), this means that some of the packets of latency-sensitive + flows may be dropped. In addition, such drop policies lead to + synchronization of loss across multiple flows. + + Active queue management mechanisms detect congestion before the queue + overflows, and provide an indication of this congestion to the end + nodes. Thus, active queue management can reduce unnecessary queuing + delay for all traffic sharing that queue. The advantages of active + queue management are discussed in RFC 2309 [RFC2309]. Active queue + management avoids some of the bad properties of dropping on queue + overflow, including the undesirable synchronization of loss across + multiple flows. More importantly, active queue management means that + transport protocols with mechanisms for congestion control (e.g., + TCP) do not have to rely on buffer overflow as the only indication of + congestion. + + Active queue management mechanisms may use one of several methods for + indicating congestion to end-nodes. One is to use packet drops, as is + currently done. However, active queue management allows the router to + separate policies of queuing or dropping packets from the policies + for indicating congestion. Thus, active queue management allows + routers to use the Congestion Experienced (CE) codepoint in a packet + header as an indication of congestion, instead of relying solely on + packet drops. This has the potential of reducing the impact of loss + on latency-sensitive flows. + + + + + + + +Ramakrishnan, et al. Standards Track [Page 4] + +RFC 3168 The Addition of ECN to IP September 2001 + + + There exist some middleboxes (firewalls, load balancers, or intrusion + detection systems) in the Internet that either drop a TCP SYN packet + configured to negotiate ECN, or respond with a RST. This document + specifies procedures that TCP implementations may use to provide + robust connectivity even in the presence of such equipment. + +2. Conventions and Acronyms + + 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]. + +3. Assumptions and General Principles + + In this section, we describe some of the important design principles + and assumptions that guided the design choices in this proposal. + + * Because ECN is likely to be adopted gradually, accommodating + migration is essential. Some routers may still only drop packets + to indicate congestion, and some end-systems may not be ECN- + capable. The most viable strategy is one that accommodates + incremental deployment without having to resort to "islands" of + ECN-capable and non-ECN-capable environments. + + * New mechanisms for congestion control and avoidance need to co- + exist and cooperate with existing mechanisms for congestion + control. In particular, new mechanisms have to co-exist with + TCP's current methods of adapting to congestion and with + routers' current practice of dropping packets in periods of + congestion. + + * Congestion may persist over different time-scales. The time + scales that we are concerned with are congestion events that may + last longer than a round-trip time. + + * The number of packets in an individual flow (e.g., TCP + connection or an exchange using UDP) may range from a small + number of packets to quite a large number. We are interested in + managing the congestion caused by flows that send enough packets + so that they are still active when network feedback reaches + them. + + * Asymmetric routing is likely to be a normal occurrence in the + Internet. The path (sequence of links and routers) followed by + data packets may be different from the path followed by the + acknowledgment packets in the reverse direction. + + + + + +Ramakrishnan, et al. Standards Track [Page 5] + +RFC 3168 The Addition of ECN to IP September 2001 + + + * Many routers process the "regular" headers in IP packets more + efficiently than they process the header information in IP + options. This suggests keeping congestion experienced + information in the regular headers of an IP packet. + + * It must be recognized that not all end-systems will cooperate in + mechanisms for congestion control. However, new mechanisms + shouldn't make it easier for TCP applications to disable TCP + congestion control. The benefit of lying about participating in + new mechanisms such as ECN-capability should be small. + +4. Active Queue Management (AQM) + + Random Early Detection (RED) is one mechanism for Active Queue + Management (AQM) that has been proposed to detect incipient + congestion [FJ93], and is currently being deployed in the Internet + [RFC2309]. AQM is meant to be a general mechanism using one of + several alternatives for congestion indication, but in the absence of + ECN, AQM is restricted to using packet drops as a mechanism for + congestion indication. AQM drops packets based on the average queue + length exceeding a threshold, rather than only when the queue + overflows. However, because AQM may drop packets before the queue + actually overflows, AQM is not always forced by memory limitations to + discard the packet. + + AQM can set a Congestion Experienced (CE) codepoint in the packet + header instead of dropping the packet, when such a field is provided + in the IP header and understood by the transport protocol. The use + of the CE codepoint with ECN allows the receiver(s) to receive the + packet, avoiding the potential for excessive delays due to + retransmissions after packet losses. We use the term 'CE packet' to + denote a packet that has the CE codepoint set. + +5. Explicit Congestion Notification in IP + + This document specifies that the Internet provide a congestion + indication for incipient congestion (as in RED and earlier work + [RJ90]) where the notification can sometimes be through marking + packets rather than dropping them. This uses an ECN field in the IP + header with two bits, making four ECN codepoints, '00' to '11'. The + ECN-Capable Transport (ECT) codepoints '10' and '01' are set by the + data sender to indicate that the end-points of the transport protocol + are ECN-capable; we call them ECT(0) and ECT(1) respectively. The + phrase "the ECT codepoint" in this documents refers to either of the + two ECT codepoints. Routers treat the ECT(0) and ECT(1) codepoints + as equivalent. Senders are free to use either the ECT(0) or the + ECT(1) codepoint to indicate ECT, on a packet-by-packet basis. + + + + +Ramakrishnan, et al. Standards Track [Page 6] + +RFC 3168 The Addition of ECN to IP September 2001 + + + The use of both the two codepoints for ECT, ECT(0) and ECT(1), is + motivated primarily by the desire to allow mechanisms for the data + sender to verify that network elements are not erasing the CE + codepoint, and that data receivers are properly reporting to the + sender the receipt of packets with the CE codepoint set, as required + by the transport protocol. Guidelines for the senders and receivers + to differentiate between the ECT(0) and ECT(1) codepoints will be + addressed in separate documents, for each transport protocol. In + particular, this document does not address mechanisms for TCP end- + nodes to differentiate between the ECT(0) and ECT(1) codepoints. + Protocols and senders that only require a single ECT codepoint SHOULD + use ECT(0). + + The not-ECT codepoint '00' indicates a packet that is not using ECN. + The CE codepoint '11' is set by a router to indicate congestion to + the end nodes. Routers that have a packet arriving at a full queue + drop the packet, just as they do in the absence of ECN. + + +-----+-----+ + | ECN FIELD | + +-----+-----+ + ECT CE [Obsolete] RFC 2481 names for the ECN bits. + 0 0 Not-ECT + 0 1 ECT(1) + 1 0 ECT(0) + 1 1 CE + + Figure 1: The ECN Field in IP. + + The use of two ECT codepoints essentially gives a one-bit ECN nonce + in packet headers, and routers necessarily "erase" the nonce when + they set the CE codepoint [SCWA99]. For example, routers that erased + the CE codepoint would face additional difficulty in reconstructing + the original nonce, and thus repeated erasure of the CE codepoint + would be more likely to be detected by the end-nodes. The ECN nonce + also can address the problem of misbehaving transport receivers lying + to the transport sender about whether or not the CE codepoint was set + in a packet. The motivations for the use of two ECT codepoints is + discussed in more detail in Section 20, along with some discussion of + alternate possibilities for the fourth ECT codepoint (that is, the + codepoint '01'). Backwards compatibility with earlier ECN + implementations that do not understand the ECT(1) codepoint is + discussed in Section 11. + + In RFC 2481 [RFC2481], the ECN field was divided into the ECN-Capable + Transport (ECT) bit and the CE bit. The ECN field with only the + ECN-Capable Transport (ECT) bit set in RFC 2481 corresponds to the + ECT(0) codepoint in this document, and the ECN field with both the + + + +Ramakrishnan, et al. Standards Track [Page 7] + +RFC 3168 The Addition of ECN to IP September 2001 + + + ECT and CE bit in RFC 2481 corresponds to the CE codepoint in this + document. The '01' codepoint was left undefined in RFC 2481, and + this is the reason for recommending the use of ECT(0) when only a + single ECT codepoint is needed. + + 0 1 2 3 4 5 6 7 + +-----+-----+-----+-----+-----+-----+-----+-----+ + | DS FIELD, DSCP | ECN FIELD | + +-----+-----+-----+-----+-----+-----+-----+-----+ + + DSCP: differentiated services codepoint + ECN: Explicit Congestion Notification + + Figure 2: The Differentiated Services and ECN Fields in IP. + + Bits 6 and 7 in the IPv4 TOS octet are designated as the ECN field. + The IPv4 TOS octet corresponds to the Traffic Class octet in IPv6, + and the ECN field is defined identically in both cases. The + definitions for the IPv4 TOS octet [RFC791] and the IPv6 Traffic + Class octet have been superseded by the six-bit DS (Differentiated + Services) Field [RFC2474, RFC2780]. Bits 6 and 7 are listed in + [RFC2474] as Currently Unused, and are specified in RFC 2780 as + approved for experimental use for ECN. Section 22 gives a brief + history of the TOS octet. + + Because of the unstable history of the TOS octet, the use of the ECN + field as specified in this document cannot be guaranteed to be + backwards compatible with those past uses of these two bits that + pre-date ECN. The potential dangers of this lack of backwards + compatibility are discussed in Section 22. + + Upon the receipt by an ECN-Capable transport of a single CE packet, + the congestion control algorithms followed at the end-systems MUST be + essentially the same as the congestion control response to a *single* + dropped packet. For example, for ECN-Capable TCP the source TCP is + required to halve its congestion window for any window of data + containing either a packet drop or an ECN indication. + + One reason for requiring that the congestion-control response to the + CE packet be essentially the same as the response to a dropped packet + is to accommodate the incremental deployment of ECN in both end- + systems and in routers. Some routers may drop ECN-Capable packets + (e.g., using the same AQM policies for congestion detection) while + other routers set the CE codepoint, for equivalent levels of + congestion. Similarly, a router might drop a non-ECN-Capable packet + but set the CE codepoint in an ECN-Capable packet, for equivalent + + + + + +Ramakrishnan, et al. Standards Track [Page 8] + +RFC 3168 The Addition of ECN to IP September 2001 + + + levels of congestion. If there were different congestion control + responses to a CE codepoint than to a packet drop, this could result + in unfair treatment for different flows. + + An additional goal is that the end-systems should react to congestion + at most once per window of data (i.e., at most once per round-trip + time), to avoid reacting multiple times to multiple indications of + congestion within a round-trip time. + + For a router, the CE codepoint of an ECN-Capable packet SHOULD only + be set if the router would otherwise have dropped the packet as an + indication of congestion to the end nodes. When the router's buffer + is not yet full and the router is prepared to drop a packet to inform + end nodes of incipient congestion, the router should first check to + see if the ECT codepoint is set in that packet's IP header. If so, + then instead of dropping the packet, the router MAY instead set the + CE codepoint in the IP header. + + An environment where all end nodes were ECN-Capable could allow new + criteria to be developed for setting the CE codepoint, and new + congestion control mechanisms for end-node reaction to CE packets. + However, this is a research issue, and as such is not addressed in + this document. + + When a CE packet (i.e., a packet that has the CE codepoint set) is + received by a router, the CE codepoint is left unchanged, and the + packet is transmitted as usual. When severe congestion has occurred + and the router's queue is full, then the router has no choice but to + drop some packet when a new packet arrives. We anticipate that such + packet losses will become relatively infrequent when a majority of + end-systems become ECN-Capable and participate in TCP or other + compatible congestion control mechanisms. In an ECN-Capable + environment that is adequately-provisioned, packet losses should + occur primarily during transients or in the presence of non- + cooperating sources. + + The above discussion of when CE may be set instead of dropping a + packet applies by default to all Differentiated Services Per-Hop + Behaviors (PHBs) [RFC 2475]. Specifications for PHBs MAY provide + more specifics on how a compliant implementation is to choose between + setting CE and dropping a packet, but this is NOT REQUIRED. A router + MUST NOT set CE instead of dropping a packet when the drop that would + occur is caused by reasons other than congestion or the desire to + indicate incipient congestion to end nodes (e.g., a diffserv edge + node may be configured to unconditionally drop certain classes of + traffic to prevent them from entering its diffserv domain). + + + + + +Ramakrishnan, et al. Standards Track [Page 9] + +RFC 3168 The Addition of ECN to IP September 2001 + + + We expect that routers will set the CE codepoint in response to + incipient congestion as indicated by the average queue size, using + the RED algorithms suggested in [FJ93, RFC2309]. To the best of our + knowledge, this is the only proposal currently under discussion in + the IETF for routers to drop packets proactively, before the buffer + overflows. However, this document does not attempt to specify a + particular mechanism for active queue management, leaving that + endeavor, if needed, to other areas of the IETF. While ECN is + inextricably tied up with the need to have a reasonable active queue + management mechanism at the router, the reverse does not hold; active + queue management mechanisms have been developed and deployed + independent of ECN, using packet drops as indications of congestion + in the absence of ECN in the IP architecture. + +5.1. ECN as an Indication of Persistent Congestion + + We emphasize that a *single* packet with the CE codepoint set in an + IP packet causes the transport layer to respond, in terms of + congestion control, as it would to a packet drop. The instantaneous + queue size is likely to see considerable variations even when the + router does not experience persistent congestion. As such, it is + important that transient congestion at a router, reflected by the + instantaneous queue size reaching a threshold much smaller than the + capacity of the queue, not trigger a reaction at the transport layer. + Therefore, the CE codepoint should not be set by a router based on + the instantaneous queue size. + + For example, since the ATM and Frame Relay mechanisms for congestion + indication have typically been defined without an associated notion + of average queue size as the basis for determining that an + intermediate node is congested, we believe that they provide a very + noisy signal. The TCP-sender reaction specified in this document for + ECN is NOT the appropriate reaction for such a noisy signal of + congestion notification. However, if the routers that interface to + the ATM network have a way of maintaining the average queue at the + interface, and use it to come to a reliable determination that the + ATM subnet is congested, they may use the ECN notification that is + defined here. + + We continue to encourage experiments in techniques at layer 2 (e.g., + in ATM switches or Frame Relay switches) to take advantage of ECN. + For example, using a scheme such as RED (where packet marking is + based on the average queue length exceeding a threshold), layer 2 + devices could provide a reasonably reliable indication of congestion. + When all the layer 2 devices in a path set that layer's own + Congestion Experienced codepoint (e.g., the EFCI bit for ATM, the + FECN bit in Frame Relay) in this reliable manner, then the interface + router to the layer 2 network could copy the state of that layer 2 + + + +Ramakrishnan, et al. Standards Track [Page 10] + +RFC 3168 The Addition of ECN to IP September 2001 + + + Congestion Experienced codepoint into the CE codepoint in the IP + header. We recognize that this is not the current practice, nor is + it in current standards. However, encouraging experimentation in this + manner may provide the information needed to enable evolution of + existing layer 2 mechanisms to provide a more reliable means of + congestion indication, when they use a single bit for indicating + congestion. + +5.2. Dropped or Corrupted Packets + + For the proposed use for ECN in this document (that is, for a + transport protocol such as TCP for which a dropped data packet is an + indication of congestion), end nodes detect dropped data packets, and + the congestion response of the end nodes to a dropped data packet is + at least as strong as the congestion response to a received CE + packet. To ensure the reliable delivery of the congestion indication + of the CE codepoint, an ECT codepoint MUST NOT be set in a packet + unless the loss of that packet in the network would be detected by + the end nodes and interpreted as an indication of congestion. + + Transport protocols such as TCP do not necessarily detect all packet + drops, such as the drop of a "pure" ACK packet; for example, TCP does + not reduce the arrival rate of subsequent ACK packets in response to + an earlier dropped ACK packet. Any proposal for extending ECN- + Capability to such packets would have to address issues such as the + case of an ACK packet that was marked with the CE codepoint but was + later dropped in the network. We believe that this aspect is still + the subject of research, so this document specifies that at this + time, "pure" ACK packets MUST NOT indicate ECN-Capability. + + Similarly, if a CE packet is dropped later in the network due to + corruption (bit errors), the end nodes should still invoke congestion + control, just as TCP would today in response to a dropped data + packet. This issue of corrupted CE packets would have to be + considered in any proposal for the network to distinguish between + packets dropped due to corruption, and packets dropped due to + congestion or buffer overflow. In particular, the ubiquitous + deployment of ECN would not, in and of itself, be a sufficient + development to allow end-nodes to interpret packet drops as + indications of corruption rather than congestion. + +5.3. Fragmentation + + ECN-capable packets MAY have the DF (Don't Fragment) bit set. + Reassembly of a fragmented packet MUST NOT lose indications of + congestion. In other words, if any fragment of an IP packet to be + reassembled has the CE codepoint set, then one of two actions MUST be + taken: + + + +Ramakrishnan, et al. Standards Track [Page 11] + +RFC 3168 The Addition of ECN to IP September 2001 + + + * Set the CE codepoint on the reassembled packet. However, this + MUST NOT occur if any of the other fragments contributing to + this reassembly carries the Not-ECT codepoint. + + * The packet is dropped, instead of being reassembled, for any + other reason. + + If both actions are applicable, either MAY be chosen. Reassembly of + a fragmented packet MUST NOT change the ECN codepoint when all of the + fragments carry the same codepoint. + + We would note that because RFC 2481 did not specify reassembly + behavior, older ECN implementations conformant with that Experimental + RFC do not necessarily perform reassembly correctly, in terms of + preserving the CE codepoint in a fragment. The sender could avoid + the consequences of this behavior by setting the DF bit in ECN- + Capable packets. + + Situations may arise in which the above reassembly specification is + insufficiently precise. For example, if there is a malicious or + broken entity in the path at or after the fragmentation point, packet + fragments could carry a mixture of ECT(0), ECT(1), and/or Not-ECT + codepoints. The reassembly specification above does not place + requirements on reassembly of fragments in this case. In situations + where more precise reassembly behavior would be required, protocol + specifications SHOULD instead specify that DF MUST be set in all + ECN-capable packets sent by the protocol. + +6. Support from the Transport Protocol + + ECN requires support from the transport protocol, in addition to the + functionality given by the ECN field in the IP packet header. The + transport protocol might require negotiation between the endpoints + during setup to determine that all of the endpoints are ECN-capable, + so that the sender can set the ECT codepoint in transmitted packets. + Second, the transport protocol must be capable of reacting + appropriately to the receipt of CE packets. This reaction could be + in the form of the data receiver informing the data sender of the + received CE packet (e.g., TCP), of the data receiver unsubscribing to + a layered multicast group (e.g., RLM [MJV96]), or of some other + action that ultimately reduces the arrival rate of that flow on that + congested link. CE packets indicate persistent rather than transient + congestion (see Section 5.1), and hence reactions to the receipt of + CE packets should be those appropriate for persistent congestion. + + This document only addresses the addition of ECN Capability to TCP, + leaving issues of ECN in other transport protocols to further + research. For TCP, ECN requires three new pieces of functionality: + + + +Ramakrishnan, et al. Standards Track [Page 12] + +RFC 3168 The Addition of ECN to IP September 2001 + + + negotiation between the endpoints during connection setup to + determine if they are both ECN-capable; an ECN-Echo (ECE) flag in the + TCP header so that the data receiver can inform the data sender when + a CE packet has been received; and a Congestion Window Reduced (CWR) + flag in the TCP header so that the data sender can inform the data + receiver that the congestion window has been reduced. The support + required from other transport protocols is likely to be different, + particularly for unreliable or reliable multicast transport + protocols, and will have to be determined as other transport + protocols are brought to the IETF for standardization. + + In a mild abuse of terminology, in this document we refer to `TCP + packets' instead of `TCP segments'. + +6.1. TCP + + The following sections describe in detail the proposed use of ECN in + TCP. This proposal is described in essentially the same form in + [Floyd94]. We assume that the source TCP uses the standard congestion + control algorithms of Slow-start, Fast Retransmit and Fast Recovery + [RFC2581]. + + This proposal specifies two new flags in the Reserved field of the + TCP header. The TCP mechanism for negotiating ECN-Capability uses + the ECN-Echo (ECE) flag in the TCP header. Bit 9 in the Reserved + field of the TCP header is designated as the ECN-Echo flag. The + location of the 6-bit Reserved field in the TCP header is shown in + Figure 4 of RFC 793 [RFC793] (and is reproduced below for + completeness). This specification of the ECN Field leaves the + Reserved field as a 4-bit field using bits 4-7. + + To enable the TCP receiver to determine when to stop setting the + ECN-Echo flag, we introduce a second new flag in the TCP header, the + CWR flag. The CWR flag is assigned to Bit 8 in the Reserved field of + the TCP header. + + 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 + +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ + | | | U | A | P | R | S | F | + | Header Length | Reserved | R | C | S | S | Y | I | + | | | G | K | H | T | N | N | + +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ + + Figure 3: The old definition of bytes 13 and 14 of the TCP + header. + + + + + + +Ramakrishnan, et al. Standards Track [Page 13] + +RFC 3168 The Addition of ECN to IP September 2001 + + + 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 + +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ + | | | C | E | U | A | P | R | S | F | + | Header Length | Reserved | W | C | R | C | S | S | Y | I | + | | | R | E | G | K | H | T | N | N | + +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ + + Figure 4: The new definition of bytes 13 and 14 of the TCP + Header. + + Thus, ECN uses the ECT and CE flags in the IP header (as shown in + Figure 1) for signaling between routers and connection endpoints, and + uses the ECN-Echo and CWR flags in the TCP header (as shown in Figure + 4) for TCP-endpoint to TCP-endpoint signaling. For a TCP connection, + a typical sequence of events in an ECN-based reaction to congestion + is as follows: + + * An ECT codepoint is set in packets transmitted by the sender to + indicate that ECN is supported by the transport entities for + these packets. + + * An ECN-capable router detects impending congestion and detects + that an ECT codepoint is set in the packet it is about to drop. + Instead of dropping the packet, the router chooses to set the CE + codepoint in the IP header and forwards the packet. + + * The receiver receives the packet with the CE codepoint set, and + sets the ECN-Echo flag in its next TCP ACK sent to the sender. + + * The sender receives the TCP ACK with ECN-Echo set, and reacts to + the congestion as if a packet had been dropped. + + * The sender sets the CWR flag in the TCP header of the next + packet sent to the receiver to acknowledge its receipt of and + reaction to the ECN-Echo flag. + + The negotiation for using ECN by the TCP transport entities and the + use of the ECN-Echo and CWR flags is described in more detail in the + sections below. + +6.1.1 TCP Initialization + + In the TCP connection setup phase, the source and destination TCPs + exchange information about their willingness to use ECN. Subsequent + to the completion of this negotiation, the TCP sender sets an ECT + codepoint in the IP header of data packets to indicate to the network + that the transport is capable and willing to participate in ECN for + this packet. This indicates to the routers that they may mark this + + + +Ramakrishnan, et al. Standards Track [Page 14] + +RFC 3168 The Addition of ECN to IP September 2001 + + + packet with the CE codepoint, if they would like to use that as a + method of congestion notification. If the TCP connection does not + wish to use ECN notification for a particular packet, the sending TCP + sets the ECN codepoint to not-ECT, and the TCP receiver ignores the + CE codepoint in the received packet. + + For this discussion, we designate the initiating host as Host A and + the responding host as Host B. We call a SYN packet with the ECE and + CWR flags set an "ECN-setup SYN packet", and we call a SYN packet + with at least one of the ECE and CWR flags not set a "non-ECN-setup + SYN packet". Similarly, we call a SYN-ACK packet with only the ECE + flag set but the CWR flag not set an "ECN-setup SYN-ACK packet", and + we call a SYN-ACK packet with any other configuration of the ECE and + CWR flags a "non-ECN-setup SYN-ACK packet". + + Before a TCP connection can use ECN, Host A sends an ECN-setup SYN + packet, and Host B sends an ECN-setup SYN-ACK packet. For a SYN + packet, the setting of both ECE and CWR in the ECN-setup SYN packet + is defined as an indication that the sending TCP is ECN-Capable, + rather than as an indication of congestion or of response to + congestion. More precisely, an ECN-setup SYN packet indicates that + the TCP implementation transmitting the SYN packet will participate + in ECN as both a sender and receiver. Specifically, as a receiver, + it will respond to incoming data packets that have the CE codepoint + set in the IP header by setting ECE in outgoing TCP Acknowledgement + (ACK) packets. As a sender, it will respond to incoming packets that + have ECE set by reducing the congestion window and setting CWR when + appropriate. An ECN-setup SYN packet does not commit the TCP sender + to setting the ECT codepoint in any or all of the packets it may + transmit. However, the commitment to respond appropriately to + incoming packets with the CE codepoint set remains even if the TCP + sender in a later transmission, within this TCP connection, sends a + SYN packet without ECE and CWR set. + + When Host B sends an ECN-setup SYN-ACK packet, it sets the ECE flag + but not the CWR flag. An ECN-setup SYN-ACK packet is defined as an + indication that the TCP transmitting the SYN-ACK packet is ECN- + Capable. As with the SYN packet, an ECN-setup SYN-ACK packet does + not commit the TCP host to setting the ECT codepoint in transmitted + packets. + + The following rules apply to the sending of ECN-setup packets within + a TCP connection, where a TCP connection is defined by the standard + rules for TCP connection establishment and termination. + + * If a host has received an ECN-setup SYN packet, then it MAY send + an ECN-setup SYN-ACK packet. Otherwise, it MUST NOT send an + ECN-setup SYN-ACK packet. + + + +Ramakrishnan, et al. Standards Track [Page 15] + +RFC 3168 The Addition of ECN to IP September 2001 + + + * A host MUST NOT set ECT on data packets unless it has sent at + least one ECN-setup SYN or ECN-setup SYN-ACK packet, and has + received at least one ECN-setup SYN or ECN-setup SYN-ACK packet, + and has sent no non-ECN-setup SYN or non-ECN-setup SYN-ACK + packet. If a host has received at least one non-ECN-setup SYN + or non-ECN-setup SYN-ACK packet, then it SHOULD NOT set ECT on + data packets. + + * If a host ever sets the ECT codepoint on a data packet, then + that host MUST correctly set/clear the CWR TCP bit on all + subsequent packets in the connection. + + * If a host has sent at least one ECN-setup SYN or ECN-setup SYN- + ACK packet, and has received no non-ECN-setup SYN or non-ECN- + setup SYN-ACK packet, then if that host receives TCP data + packets with ECT and CE codepoints set in the IP header, then + that host MUST process these packets as specified for an ECN- + capable connection. + + * A host that is not willing to use ECN on a TCP connection SHOULD + clear both the ECE and CWR flags in all non-ECN-setup SYN and/or + SYN-ACK packets that it sends to indicate this unwillingness. + Receivers MUST correctly handle all forms of the non-ECN-setup + SYN and SYN-ACK packets. + + * A host MUST NOT set ECT on SYN or SYN-ACK packets. + + A TCP client enters TIME-WAIT state after receiving a FIN-ACK, and + transitions to CLOSED state after a timeout. Many TCP + implementations create a new TCP connection if they receive an in- + window SYN packet during TIME-WAIT state. When a TCP host enters + TIME-WAIT or CLOSED state, it should ignore any previous state about + the negotiation of ECN for that connection. + +6.1.1.1. Middlebox Issues + + ECN introduces the use of the ECN-Echo and CWR flags in the TCP + header (as shown in Figure 3) for initialization. There exist some + faulty firewalls, load balancers, and intrusion detection systems in + the Internet that either drop an ECN-setup SYN packet or respond with + a RST, in the belief that such a packet (with these bits set) is a + signature for a port-scanning tool that could be used in a denial- + of-service attack. Some of the offending equipment has been + identified, and a web page [FIXES] contains a list of non-compliant + products and the fixes posted by the vendors, where these are + available. The TBIT web page [TBIT] lists some of the web servers + affected by this faulty equipment. We mention this in this document + as a warning to the community of this problem. + + + +Ramakrishnan, et al. Standards Track [Page 16] + +RFC 3168 The Addition of ECN to IP September 2001 + + + To provide robust connectivity even in the presence of such faulty + equipment, a host that receives a RST in response to the transmission + of an ECN-setup SYN packet MAY resend a SYN with CWR and ECE cleared. + This could result in a TCP connection being established without using + ECN. + + A host that receives no reply to an ECN-setup SYN within the normal + SYN retransmission timeout interval MAY resend the SYN and any + subsequent SYN retransmissions with CWR and ECE cleared. To overcome + normal packet loss that results in the original SYN being lost, the + originating host may retransmit one or more ECN-setup SYN packets + before giving up and retransmitting the SYN with the CWR and ECE bits + cleared. + + We note that in this case, the following example scenario is + possible: + + (1) Host A: Sends an ECN-setup SYN. + (2) Host B: Sends an ECN-setup SYN/ACK, packet is dropped or delayed. + (3) Host A: Sends a non-ECN-setup SYN. + (4) Host B: Sends a non-ECN-setup SYN/ACK. + + We note that in this case, following the procedures above, neither + Host A nor Host B may set the ECT bit on data packets. Further, an + important consequence of the rules for ECN setup and usage in Section + 6.1.1 is that a host is forbidden from using the reception of ECT + data packets as an implicit signal that the other host is ECN- + capable. + +6.1.1.2. Robust TCP Initialization with an Echoed Reserved Field + + There is the question of why we chose to have the TCP sending the SYN + set two ECN-related flags in the Reserved field of the TCP header for + the SYN packet, while the responding TCP sending the SYN-ACK sets + only one ECN-related flag in the SYN-ACK packet. This asymmetry is + necessary for the robust negotiation of ECN-capability with some + deployed TCP implementations. There exists at least one faulty TCP + implementation in which TCP receivers set the Reserved field of the + TCP header in ACK packets (and hence the SYN-ACK) simply to reflect + the Reserved field of the TCP header in the received data packet. + Because the TCP SYN packet sets the ECN-Echo and CWR flags to + indicate ECN-capability, while the SYN-ACK packet sets only the ECN- + Echo flag, the sending TCP correctly interprets a receiver's + reflection of its own flags in the Reserved field as an indication + that the receiver is not ECN-capable. The sending TCP is not mislead + by a faulty TCP implementation sending a SYN-ACK packet that simply + reflects the Reserved field of the incoming SYN packet. + + + + +Ramakrishnan, et al. Standards Track [Page 17] + +RFC 3168 The Addition of ECN to IP September 2001 + + +6.1.2. The TCP Sender + + For a TCP connection using ECN, new data packets are transmitted with + an ECT codepoint set in the IP header. When only one ECT codepoint + is needed by a sender for all packets sent on a TCP connection, + ECT(0) SHOULD be used. If the sender receives an ECN-Echo (ECE) ACK + packet (that is, an ACK packet with the ECN-Echo flag set in the TCP + header), then the sender knows that congestion was encountered in the + network on the path from the sender to the receiver. The indication + of congestion should be treated just as a congestion loss in non- + ECN-Capable TCP. That is, the TCP source halves the congestion window + "cwnd" and reduces the slow start threshold "ssthresh". The sending + TCP SHOULD NOT increase the congestion window in response to the + receipt of an ECN-Echo ACK packet. + + TCP should not react to congestion indications more than once every + window of data (or more loosely, more than once every round-trip + time). That is, the TCP sender's congestion window should be reduced + only once in response to a series of dropped and/or CE packets from a + single window of data. In addition, the TCP source should not + decrease the slow-start threshold, ssthresh, if it has been decreased + within the last round trip time. However, if any retransmitted + packets are dropped, then this is interpreted by the source TCP as a + new instance of congestion. + + After the source TCP reduces its congestion window in response to a + CE packet, incoming acknowledgments that continue to arrive can + "clock out" outgoing packets as allowed by the reduced congestion + window. If the congestion window consists of only one MSS (maximum + segment size), and the sending TCP receives an ECN-Echo ACK packet, + then the sending TCP should in principle still reduce its congestion + window in half. However, the value of the congestion window is + bounded below by a value of one MSS. If the sending TCP were to + continue to send, using a congestion window of 1 MSS, this results in + the transmission of one packet per round-trip time. It is necessary + to still reduce the sending rate of the TCP sender even further, on + receipt of an ECN-Echo packet when the congestion window is one. We + use the retransmit timer as a means of reducing the rate further in + this circumstance. Therefore, the sending TCP MUST reset the + retransmit timer on receiving the ECN-Echo packet when the congestion + window is one. The sending TCP will then be able to send a new + packet only when the retransmit timer expires. + + When an ECN-Capable TCP sender reduces its congestion window for any + reason (because of a retransmit timeout, a Fast Retransmit, or in + response to an ECN Notification), the TCP sender sets the CWR flag in + the TCP header of the first new data packet sent after the window + reduction. If that data packet is dropped in the network, then the + + + +Ramakrishnan, et al. Standards Track [Page 18] + +RFC 3168 The Addition of ECN to IP September 2001 + + + sending TCP will have to reduce the congestion window again and + retransmit the dropped packet. + + We ensure that the "Congestion Window Reduced" information is + reliably delivered to the TCP receiver. This comes about from the + fact that if the new data packet carrying the CWR flag is dropped, + then the TCP sender will have to again reduce its congestion window, + and send another new data packet with the CWR flag set. Thus, the + CWR bit 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 only on the first + new data packet that it transmits. + + [Floyd94] discusses TCP's response to ECN in more detail. [Floyd98] + discusses the validation test in the ns simulator, which illustrates + a wide range of ECN scenarios. These scenarios include the following: + an ECN followed by another ECN, a Fast Retransmit, or a Retransmit + Timeout; a Retransmit Timeout or a Fast Retransmit followed by an + ECN; and a congestion window of one packet followed by an ECN. + + TCP follows existing algorithms for sending data packets in response + to incoming ACKs, multiple duplicate acknowledgments, or retransmit + timeouts [RFC2581]. TCP also follows the normal procedures for + increasing the congestion window when it receives ACK packets without + the ECN-Echo bit set [RFC2581]. + +6.1.3. The TCP Receiver + + When TCP receives a CE data packet at the destination end-system, the + TCP data receiver sets the ECN-Echo flag in the TCP header of the + subsequent ACK packet. If there is any ACK withholding implemented, + as in current "delayed-ACK" TCP implementations where the TCP + receiver can send an ACK for two arriving data packets, then the + ECN-Echo flag in the ACK packet will be set to '1' if the CE + codepoint is set in any of the data packets being acknowledged. That + is, if any of the received data packets are CE packets, then the + returning ACK has the ECN-Echo flag set. + + To provide robustness against the possibility of a dropped ACK packet + carrying an ECN-Echo flag, the TCP receiver sets the ECN-Echo flag in + a series of ACK packets sent subsequently. The TCP receiver uses the + CWR flag received from the TCP sender to determine when to stop + setting the ECN-Echo flag. + + After a TCP receiver sends an ACK packet with the ECN-Echo bit set, + that TCP receiver continues to set the ECN-Echo flag in all the ACK + packets it sends (whether they acknowledge CE data packets or non-CE + + + +Ramakrishnan, et al. Standards Track [Page 19] + +RFC 3168 The Addition of ECN to IP September 2001 + + + data packets) until it receives a CWR packet (a packet with the CWR + flag set). After the receipt of the CWR packet, acknowledgments for + subsequent non-CE data packets do not have the ECN-Echo flag set. If + another CE packet is received by the data receiver, the receiver + would once again send ACK packets with the ECN-Echo flag set. While + the receipt of a CWR packet does not guarantee that the data sender + received the ECN-Echo message, this does suggest that the data sender + reduced its congestion window at some point *after* it sent the data + packet for which the CE codepoint was set. + + We have already specified that a TCP sender is not required to reduce + its congestion window more than once per window of data. Some care + is required if the TCP sender is to avoid unnecessary reductions of + the congestion window when a window of data includes both dropped + packets and (marked) CE packets. This is illustrated in [Floyd98]. + +6.1.4. Congestion on the ACK-path + + For the current generation of TCP congestion control algorithms, pure + acknowledgement packets (e.g., packets that do not contain any + accompanying data) MUST be sent with the not-ECT codepoint. Current + TCP receivers have no mechanisms for reducing traffic on the ACK-path + in response to congestion notification. Mechanisms for responding to + congestion on the ACK-path are areas for current and future research. + (One simple possibility would be for the sender to reduce its + congestion window when it receives a pure ACK packet with the CE + codepoint set). For current TCP implementations, a single dropped ACK + generally has only a very small effect on the TCP's sending rate. + +6.1.5. Retransmitted TCP packets + + This document specifies ECN-capable TCP implementations MUST NOT set + either ECT codepoint (ECT(0) or ECT(1)) in the IP header for + 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, as well as for robustness of the ECN + congestion indication with packets that are dropped later in the + network. + + First, we note that if the TCP sender were to set an ECT codepoint on + a retransmitted packet, then if an unnecessarily-retransmitted packet + was later dropped in the network, the end nodes would never receive + the indication of congestion from the router setting the CE + codepoint. Thus, setting an ECT codepoint on retransmitted data + packets is not consistent with the robust delivery of the congestion + indication even for packets that are later dropped in the network. + + + + +Ramakrishnan, et al. Standards Track [Page 20] + +RFC 3168 The Addition of ECN to IP September 2001 + + + In addition, an attacker capable of spoofing the IP source address of + the TCP sender could send data packets with arbitrary sequence + numbers, with the CE codepoint 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 codepoint 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 codepoint in an out-of-window + packet, then the TCP data sender would not receive this possibly- + legitimate indication of congestion from the network, 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, we + specify that a legitimate TCP data sender MUST NOT set an ECT + codepoint on retransmitted data packets, and that the TCP data + receiver SHOULD ignore the CE codepoint on out-of-window packets. + + One drawback of not setting ECT(0) or ECT(1) on retransmitted packets + 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. + + We note that if the router sets the CE codepoint 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 + + + +Ramakrishnan, et al. Standards Track [Page 21] + +RFC 3168 The Addition of ECN to IP September 2001 + + + indication of congestion for some packet within the same window of + data as the original packet. Thus, even if the first transmission of + the packet is dropped in the network, or is delayed, if it had the CE + codepoint 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. + + 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 codepoint is set on + the packet within the network, this will be treated by the data + receiver as a valid indication of congestion. + +6.1.6. TCP 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. If a window probe packet + is dropped in the network, this loss is not detected by the receiver. + Therefore, the TCP data sender MUST NOT set either an ECT codepoint + or the CWR bit on window probe packets. + + However, because window probes use exact sequence numbers, they + cannot be easily spoofed in denial-of-service attacks. Therefore, if + a window probe arrives with the CE codepoint set, then the receiver + SHOULD respond to the ECN indications. + +7. Non-compliance by the End Nodes + + This section discusses concerns about the vulnerability of ECN to + non-compliant end-nodes (i.e., end nodes that set the ECT codepoint + in transmitted packets but do not respond to received CE packets). + We argue that the addition of ECN to the IP architecture will not + significantly increase the current vulnerability of the architecture + to unresponsive flows. + + Even for non-ECN environments, there are serious concerns about the + damage that can be done by non-compliant or unresponsive flows (that + is, flows that do not respond to congestion control indications by + reducing their arrival rate at the congested link). For example, an + end-node could "turn off congestion control" by not reducing its + congestion window in response to packet drops. This is a concern for + the current Internet. It has been argued that routers will have to + deploy mechanisms to detect and differentially treat packets from + + + +Ramakrishnan, et al. Standards Track [Page 22] + +RFC 3168 The Addition of ECN to IP September 2001 + + + non-compliant flows [RFC2309,FF99]. It has also been suggested that + techniques such as end-to-end per-flow scheduling and isolation of + one flow from another, differentiated services, or end-to-end + reservations could remove some of the more damaging effects of + unresponsive flows. + + It might seem that dropping packets in itself is an adequate + deterrent for non-compliance, and that the use of ECN removes this + deterrent. We would argue in response that (1) ECN-capable routers + preserve packet-dropping behavior in times of high congestion; and + (2) even in times of high congestion, dropping packets in itself is + not an adequate deterrent for non-compliance. + + First, ECN-Capable routers will only mark packets (as opposed to + dropping them) when the packet marking rate is reasonably low. During + periods where the average queue size exceeds an upper threshold, and + therefore the potential packet marking rate would be high, our + recommendation is that routers drop packets rather then set the CE + codepoint in packet headers. + + During the periods of low or moderate packet marking rates when ECN + would be deployed, there would be little deterrent effect on + unresponsive flows of dropping rather than marking those packets. For + example, delay-insensitive flows using reliable delivery might have + an incentive to increase rather than to decrease their sending rate + in the presence of dropped packets. Similarly, delay-sensitive flows + using unreliable delivery might increase their use of FEC in response + to an increased packet drop rate, increasing rather than decreasing + their sending rate. For the same reasons, we do not believe that + packet dropping itself is an effective deterrent for non-compliance + even in an environment of high packet drop rates, when all flows are + sharing the same packet drop rate. + + Several methods have been proposed to identify and restrict non- + compliant or unresponsive flows. The addition of ECN to the network + environment would not in any way increase the difficulty of designing + and deploying such mechanisms. If anything, the addition of ECN to + the architecture would make the job of identifying unresponsive flows + slightly easier. For example, in an ECN-Capable environment routers + are not limited to information about packets that are dropped or have + the CE codepoint set at that router itself; in such an environment, + routers could also take note of arriving CE packets that indicate + congestion encountered by that packet earlier in the path. + + + + + + + + +Ramakrishnan, et al. Standards Track [Page 23] + +RFC 3168 The Addition of ECN to IP September 2001 + + +8. Non-compliance in the Network + + This section considers the issues when a router is operating, + possibly maliciously, to modify either of the bits in the ECN field. + We note that in IPv4, the IP header is protected from bit errors by a + header checksum; this is not the case in IPv6. Thus for IPv6 the + ECN field can be accidentally modified by bit errors on links or in + routers without being detected by an IP header checksum. + + By tampering with the bits in the ECN field, an adversary (or a + broken router) could do one or more of the following: falsely report + congestion, disable ECN-Capability for an individual packet, erase + the ECN congestion indication, or falsely indicate ECN-Capability. + Section 18 systematically examines the various cases by which the ECN + field could be modified. The important criterion considered in + determining the consequences of such modifications is whether it is + likely to lead to poorer behavior in any dimension (throughput, + delay, fairness or functionality) than if a router were to drop a + packet. + + The first two possible changes, falsely reporting congestion or + disabling ECN-Capability for an individual packet, are no worse than + if the router were to simply drop the packet. From a congestion + control point of view, setting the CE codepoint in the absence of + congestion by a non-compliant router would be no worse than a router + dropping a packet unnecessarily. By "erasing" an ECT codepoint of a + packet that is later dropped in the network, a router's actions could + result in an unnecessary packet drop for that packet later in the + network. + + However, as discussed in Section 18, a router that erases the ECN + congestion indication or falsely indicates ECN-Capability could + potentially do more damage to the flow that if it has simply dropped + the packet. A rogue or broken router that "erased" the CE codepoint + in arriving CE packets would prevent that indication of congestion + from reaching downstream receivers. This could result in the failure + of congestion control for that flow and a resulting increase in + congestion in the network, ultimately resulting in subsequent packets + dropped for this flow as the average queue size increased at the + congested gateway. + + Section 19 considers the potential repercussions of subverting end- + to-end congestion control by either falsely indicating ECN- + Capability, or by erasing the congestion indication in ECN (the CE- + codepoint). We observe in Section 19 that the consequence of + subverting ECN-based congestion control may lead to potential + unfairness, but this is likely to be no worse than the subversion of + either ECN-based or packet-based congestion control by the end nodes. + + + +Ramakrishnan, et al. Standards Track [Page 24] + +RFC 3168 The Addition of ECN to IP September 2001 + + +8.1. Complications Introduced by Split Paths + + If a router or other network element has access to all of the packets + of a flow, then that router could do no more damage to a flow by + altering the ECN field than it could by simply dropping all of the + packets from that flow. However, in some cases, a malicious or + broken router might have access to only a subset of the packets from + a flow. The question is as follows: can this router, by altering + the ECN field in this subset of the packets, do more damage to that + flow than if it has simply dropped that set of the packets? + + This is also discussed in detail in Section 18, which concludes as + follows: It is true that the adversary that has access only to a + subset of packets in an aggregate might, by subverting ECN-based + congestion control, be able to deny the benefits of ECN to the other + packets in the aggregate. While this is undesirable, this is not a + sufficient concern to result in disabling ECN. + +9. Encapsulated Packets + +9.1. IP packets encapsulated in IP + + The encapsulation of IP packet headers in tunnels is used in many + places, including IPsec and IP in IP [RFC2003]. This section + considers issues related to interactions between ECN and IP tunnels, + and specifies two alternative solutions. This discussion is + complemented by RFC 2983's discussion of interactions between + Differentiated Services and IP tunnels of various forms [RFC 2983], + as Differentiated Services uses the remaining six bits of the IP + header octet that is used by ECN (see Figure 2 in Section 5). + + + Some IP tunnel modes are based on adding a new "outer" IP header that + encapsulates the original, or "inner" IP header and its associated + packet. In many cases, the new "outer" IP header may be added and + removed at intermediate points along a connection, enabling the + network to establish a tunnel without requiring endpoint + participation. We denote tunnels that specify that the outer header + be discarded at tunnel egress as "simple tunnels". + + ECN uses the ECN field in the IP header for signaling between routers + and connection endpoints. ECN interacts with IP tunnels based on the + treatment of the ECN field in the IP header. In simple IP tunnels + the octet containing the ECN field is copied or mapped from the inner + IP header to the outer IP header at IP tunnel ingress, and the outer + header's copy of this field is discarded at IP tunnel egress. If the + outer header were to be simply discarded without taking care to deal + with the ECN field, and an ECN-capable router were to set the CE + + + +Ramakrishnan, et al. Standards Track [Page 25] + +RFC 3168 The Addition of ECN to IP September 2001 + + + (Congestion Experienced) codepoint within a packet in a simple IP + tunnel, this indication would be discarded at tunnel egress, losing + the indication of congestion. + + Thus, the use of ECN over simple IP tunnels would result in routers + attempting to use the outer IP header to signal congestion to + endpoints, but those congestion warnings never arriving because the + outer header is discarded at the tunnel egress point. This problem + was encountered with ECN and IPsec in tunnel mode, and RFC 2481 + recommended that ECN not be used with the older simple IPsec tunnels + in order to avoid this behavior and its consequences. When ECN + becomes widely deployed, then simple tunnels likely to carry ECN- + capable traffic will have to be changed. If ECN-capable traffic is + carried by a simple tunnel through a congested, ECN-capable router, + this could result in subsequent packets being dropped for this flow + as the average queue size increases at the congested router, as + discussed in Section 8 above. + + From a security point of view, the use of ECN in the outer header of + an IP tunnel might raise security concerns because an adversary could + tamper with the ECN information that propagates beyond the tunnel + endpoint. Based on an analysis in Sections 18 and 19 of these + concerns and the resultant risks, our overall approach is to make + support for ECN an option for IP tunnels, so that an IP tunnel can be + specified or configured either to use ECN or not to use ECN in the + outer header of the tunnel. Thus, in environments or tunneling + protocols where the risks of using ECN are judged to outweigh its + benefits, the tunnel can simply not use ECN in the outer header. + Then the only indication of congestion experienced at routers within + the tunnel would be through packet loss. + + The result is that there are two viable options for the behavior of + ECN-capable connections over an IP tunnel, including IPsec tunnels: + + * A limited-functionality option in which ECN is preserved in the + inner header, but disabled in the outer header. The only + mechanism available for signaling congestion occurring within + the tunnel in this case is dropped packets. + + * A full-functionality option that supports ECN in both the inner + and outer headers, and propagates congestion warnings from nodes + within the tunnel to endpoints. + + Support for these options requires varying amounts of changes to IP + header processing at tunnel ingress and egress. A small subset of + these changes sufficient to support only the limited-functionality + option would be sufficient to eliminate any incompatibility between + ECN and IP tunnels. + + + +Ramakrishnan, et al. Standards Track [Page 26] + +RFC 3168 The Addition of ECN to IP September 2001 + + + One goal of this document is to give guidance about the tradeoffs + between the limited-functionality and full-functionality options. A + full discussion of the potential effects of an adversary's + modifications of the ECN field is given in Sections 18 and 19. + +9.1.1. The Limited-functionality and Full-functionality Options + + The limited-functionality option for ECN encapsulation in IP tunnels + is for the not-ECT codepoint to be set in the outside (encapsulating) + header regardless of the value of the ECN field in the inside + (encapsulated) header. With this option, the ECN field in the inner + header is not altered upon de-capsulation. The disadvantage of this + approach is that the flow does not have ECN support for that part of + the path that is using IP tunneling, even if the encapsulated packet + (from the original TCP sender) is ECN-Capable. That is, if the + encapsulated packet arrives at a congested router that is ECN- + capable, and the router can decide to drop or mark the packet as an + indication of congestion to the end nodes, the router will not be + permitted to set the CE codepoint in the packet header, but instead + will have to drop the packet. + + The full-functionality option for ECN encapsulation is to copy the + ECN codepoint of the inside header to the outside header on + encapsulation if the inside header is not-ECT or ECT, and to set the + ECN codepoint of the outside header to ECT(0) if the ECN codepoint of + the inside header is CE. On decapsulation, if the CE codepoint is + set on the outside header, then the CE codepoint is also set in the + inner header. Otherwise, the ECN codepoint on the inner header is + left unchanged. That is, for full ECN support the encapsulation and + decapsulation processing involves the following: At tunnel ingress, + the full-functionality option sets the ECN codepoint in the outer + header. If the ECN codepoint in the inner header is not-ECT or ECT, + then it is copied to the ECN codepoint in the outer header. If the + ECN codepoint in the inner header is CE, then the ECN codepoint in + the outer header is set to ECT(0). Upon decapsulation at the tunnel + egress, the full-functionality option sets the CE codepoint in the + inner header if the CE codepoint is set in the outer header. + Otherwise, no change is made to this field of the inner header. + + With the full-functionality option, a flow can take advantage of ECN + in those parts of the path that might use IP tunneling. The + disadvantage of the full-functionality option from a security + perspective is that the IP tunnel cannot protect the flow from + certain modifications to the ECN bits in the IP header within the + tunnel. The potential dangers from modifications to the ECN bits in + the IP header are described in detail in Sections 18 and 19. + + + + + +Ramakrishnan, et al. Standards Track [Page 27] + +RFC 3168 The Addition of ECN to IP September 2001 + + + (1) An IP tunnel MUST modify the handling of the DS field octet at + IP tunnel endpoints by implementing either the limited- + functionality or the full-functionality option. + + (2) Optionally, an IP tunnel MAY enable the endpoints of an IP + tunnel to negotiate the choice between the limited-functionality + and the full-functionality option for ECN in the tunnel. + + The minimum required to make ECN usable with IP tunnels is the + limited-functionality option, which prevents ECN from being enabled + in the outer header of the tunnel. Full support for ECN requires the + use of the full-functionality option. If there are no optional + mechanisms for the tunnel endpoints to negotiate a choice between the + limited-functionality or full-functionality option, there can be a + pre-existing agreement between the tunnel endpoints about whether to + support the limited-functionality or the full-functionality ECN + option. + + All IP tunnels MUST implement the limited-functionality option, and + SHOULD support the full-functionality option. + + In addition, it is RECOMMENDED that packets with the CE codepoint in + the outer header be dropped if they arrive at the tunnel egress point + for a tunnel that uses the limited-functionality option, or for a + tunnel that uses the full-functionality option but for which the + not-ECT codepoint is set in the inner header. This is motivated by + backwards compatibility and to ensure that no unauthorized + modifications of the ECN field take place, and is discussed further + in the next Section (9.1.2). + +9.1.2. Changes to the ECN Field within an IP Tunnel. + + The presence of a copy of the ECN field in the inner header of an IP + tunnel mode packet provides an opportunity for detection of + unauthorized modifications to the ECN field in the outer header. + Comparison of the ECT fields in the inner and outer headers falls + into two categories for implementations that conform to this + document: + + * If the IP tunnel uses the full-functionality option, then the + not-ECT codepoint should be set in the outer header if and only + if it is also set in the inner header. + + * If the tunnel uses the limited-functionality option, then the + not-ECT codepoint should be set in the outer header. + + Receipt of a packet not satisfying the appropriate condition could be + a cause of concern. + + + +Ramakrishnan, et al. Standards Track [Page 28] + +RFC 3168 The Addition of ECN to IP September 2001 + + + Consider the case of an IP tunnel where the tunnel ingress point has + not been updated to this document's requirements, while the tunnel + egress point has been updated to support ECN. In this case, the IP + tunnel is not explicitly configured to support the full-functionality + ECN option. However, the tunnel ingress point is behaving identically + to a tunnel ingress point that supports the full-functionality + option. If packets from an ECN-capable connection use this tunnel, + the ECT codepoint will be set in the outer header at the tunnel + ingress point. Congestion within the tunnel may then result in ECN- + capable routers setting CE in the outer header. Because the tunnel + has not been explicitly configured to support the full-functionality + option, the tunnel egress point expects the not-ECT codepoint to be + set in the outer header. When an ECN-capable tunnel egress point + receives a packet with the ECT or CE codepoint in the outer header, + in a tunnel that has not been configured to support the full- + functionality option, that packet should be processed, according to + whether the CE codepoint was set, as follows. It is RECOMMENDED that + on a tunnel that has not been configured to support the full- + functionality option, packets should be dropped at the egress point + if the CE codepoint is set in the outer header but not in the inner + header, and should be forwarded otherwise. + + An IP tunnel cannot provide protection against erasure of congestion + indications based on changing the ECN codepoint from CE to ECT. The + erasure of congestion indications may impact the network and other + flows in ways that would not be possible in the absence of ECN. It + is important to note that erasure of congestion indications can only + be performed to congestion indications placed by nodes within the + tunnel; the copy of the ECN field in the inner header preserves + congestion notifications from nodes upstream of the tunnel ingress + (unless the inner header is also erased). If erasure of congestion + notifications is judged to be a security risk that exceeds the + congestion management benefits of ECN, then tunnels could be + specified or configured to use the limited-functionality option. + +9.2. IPsec Tunnels + + IPsec supports secure communication over potentially insecure network + components such as intermediate routers. IPsec protocols support two + operating modes, transport mode and tunnel mode, that span a wide + range of security requirements and operating environments. Transport + mode security protocol header(s) are inserted between the IP (IPv4 or + IPv6) header and higher layer protocol headers (e.g., TCP), and hence + transport mode can only be used for end-to-end security on a + connection. IPsec tunnel mode is based on adding a new "outer" IP + header that encapsulates the original, or "inner" IP header and its + associated packet. Tunnel mode security headers are inserted between + these two IP headers. In contrast to transport mode, the new "outer" + + + +Ramakrishnan, et al. Standards Track [Page 29] + +RFC 3168 The Addition of ECN to IP September 2001 + + + IP header and tunnel mode security headers can be added and removed + at intermediate points along a connection, enabling security gateways + to secure vulnerable portions of a connection without requiring + endpoint participation in the security protocols. An important + aspect of tunnel mode security is that in the original specification, + the outer header is discarded at tunnel egress, ensuring that + security threats based on modifying the IP header do not propagate + beyond that tunnel endpoint. Further discussion of IPsec can be + found in [RFC2401]. + + The IPsec protocol as originally defined in [ESP, AH] required that + the inner header's ECN field not be changed by IPsec decapsulation + processing at a tunnel egress node; this would have ruled out the + possibility of full-functionality mode for ECN. At the same time, + this would ensure that an adversary's modifications to the ECN field + cannot be used to launch theft- or denial-of-service attacks across + an IPsec tunnel endpoint, as any such modifications will be discarded + at the tunnel endpoint. + + In principle, permitting the use of ECN functionality in the outer + header of an IPsec tunnel raises security concerns because an + adversary could tamper with the information that propagates beyond + the tunnel endpoint. Based on an analysis (included in Sections 18 + and 19) of these concerns and the associated risks, our overall + approach has been to provide configuration support for IPsec changes + to remove the conflict with ECN. + + In particular, in tunnel mode the IPsec tunnel MUST support the + limited-functionality option outlined in Section 9.1.1, and SHOULD + support the full-functionality option outlined in Section 9.1.1. + + This makes permission to use ECN functionality in the outer header of + an IPsec tunnel a configurable part of the corresponding IPsec + Security Association (SA), so that it can be disabled in situations + where the risks are judged to outweigh the benefits. The result is + that an IPsec security administrator is presented with two + alternatives for the behavior of ECN-capable connections within an + IPsec tunnel, the limited-functionality alternative and full- + functionality alternative described earlier. + + In addition, this document specifies how the endpoints of an IPsec + tunnel could negotiate enabling ECN functionality in the outer + headers of that tunnel based on security policy. The ability to + negotiate ECN usage between tunnel endpoints would enable a security + administrator to disable ECN in situations where she believes the + risks (e.g., of lost congestion notifications) outweigh the benefits + of ECN. + + + + +Ramakrishnan, et al. Standards Track [Page 30] + +RFC 3168 The Addition of ECN to IP September 2001 + + + The IPsec protocol, as defined in [ESP, AH], does not include the IP + header's ECN field in any of its cryptographic calculations (in the + case of tunnel mode, the outer IP header's ECN field is not + included). Hence modification of the ECN field by a network node has + no effect on IPsec's end-to-end security, because it cannot cause any + IPsec integrity check to fail. As a consequence, IPsec does not + provide any defense against an adversary's modification of the ECN + field (i.e., a man-in-the-middle attack), as the adversary's + modification will also have no effect on IPsec's end-to-end security. + In some environments, the ability to modify the ECN field without + affecting IPsec integrity checks may constitute a covert channel; if + it is necessary to eliminate such a channel or reduce its bandwidth, + then the IPsec tunnel should be run in limited-functionality mode. + +9.2.1. Negotiation between Tunnel Endpoints + + This section describes the detailed changes to enable usage of ECN + over IPsec tunnels, including the negotiation of ECN support between + tunnel endpoints. This is supported by three changes to IPsec: + + * An optional Security Association Database (SAD) field indicating + whether tunnel encapsulation and decapsulation processing allows + or forbids ECN usage in the outer IP header. + + * An optional Security Association Attribute that enables + negotiation of this SAD field between the two endpoints of an SA + that supports tunnel mode. + + * Changes to tunnel mode encapsulation and decapsulation + processing to allow or forbid ECN usage in the outer IP header + based on the value of the SAD field. When ECN usage is allowed + in the outer IP header, the ECT codepoint is set in the outer + header for ECN-capable connections and congestion notifications + (indicated by the CE codepoint) from such connections are + propagated to the inner header at tunnel egress. + + If negotiation of ECN usage is implemented, then the SAD field SHOULD + also be implemented. On the other hand, negotiation of ECN usage is + OPTIONAL in all cases, even for implementations that support the SAD + field. The encapsulation and decapsulation processing changes are + REQUIRED, but MAY be implemented without the other two changes by + assuming that ECN usage is always forbidden. The full-functionality + alternative for ECN usage over IPsec tunnels consists of the SAD + field and the full version of encapsulation and decapsulation + processing changes, with or without the OPTIONAL negotiation support. + The limited-functionality alternative consists of a subset of the + encapsulation and decapsulation changes that always forbids ECN + usage. + + + +Ramakrishnan, et al. Standards Track [Page 31] + +RFC 3168 The Addition of ECN to IP September 2001 + + + These changes are covered further in the following three subsections. + +9.2.1.1. ECN Tunnel Security Association Database Field + + Full ECN functionality adds a new field to the SAD (see [RFC2401]): + + ECN Tunnel: allowed or forbidden. + + Indicates whether ECN-capable connections using this SA in tunnel + mode are permitted to receive ECN congestion notifications for + congestion occurring within the tunnel. The allowed value enables + ECN congestion notifications. The forbidden value disables such + notifications, causing all congestion to be indicated via dropped + packets. + + [OPTIONAL. The value of this field SHOULD be assumed to be + "forbidden" in implementations that do not support it.] + + If this attribute is implemented, then the SA specification in a + Security Policy Database (SPD) entry MUST support a corresponding + attribute, and this SPD attribute MUST be covered by the SPD + administrative interface (currently described in Section 4.4.1 of + [RFC2401]). + +9.2.1.2. ECN Tunnel Security Association Attribute + + A new IPsec Security Association Attribute is defined to enable the + support for ECN congestion notifications based on the outer IP header + to be negotiated for IPsec tunnels (see [RFC2407]). This attribute + is OPTIONAL, although implementations that support it SHOULD also + support the SAD field defined in Section 9.2.1.1. + + Attribute Type + + class value type + ------------------------------------------------- + ECN Tunnel 10 Basic + + The IPsec SA Attribute value 10 has been allocated by IANA to + indicate that the ECN Tunnel SA Attribute is being negotiated; the + type of this attribute is Basic (see Section 4.5 of [RFC2407]). The + Class Values are used to conduct the negotiation. See [RFC2407, + RFC2408, RFC2409] for further information including encoding formats + and requirements for negotiating this SA attribute. + + + + + + + +Ramakrishnan, et al. Standards Track [Page 32] + +RFC 3168 The Addition of ECN to IP September 2001 + + + Class Values + + ECN Tunnel + + Specifies whether ECN functionality is allowed to be used with Tunnel + Encapsulation Mode. This affects tunnel encapsulation and + decapsulation processing - see Section 9.2.1.3. + + RESERVED 0 + Allowed 1 + Forbidden 2 + + Values 3-61439 are reserved to IANA. Values 61440-65535 are for + private use. + + If unspecified, the default shall be assumed to be Forbidden. + + ECN Tunnel is a new SA attribute, and hence initiators that use it + can expect to encounter responders that do not understand it, and + therefore reject proposals containing it. For backwards + compatibility with such implementations initiators SHOULD always also + include a proposal without the ECN Tunnel attribute to enable such a + responder to select a transform or proposal that does not contain the + ECN Tunnel attribute. RFC 2407 currently requires responders to + reject all proposals if any proposal contains an unknown attribute; + this requirement is expected to be changed to require a responder not + to select proposals or transforms containing unknown attributes. + +9.2.1.3. Changes to IPsec Tunnel Header Processing + + For full ECN support, the encapsulation and decapsulation processing + for the IPv4 TOS field and the IPv6 Traffic Class field are changed + from that specified in [RFC2401] to the following: + + <-- How Outer Hdr Relates to Inner Hdr --> + Outer Hdr at Inner Hdr at + IPv4 Encapsulator Decapsulator + Header fields: -------------------- ------------ + DS Field copied from inner hdr (5) no change + ECN Field constructed (7) constructed (8) + + IPv6 + Header fields: + DS Field copied from inner hdr (6) no change + ECN Field constructed (7) constructed (8) + + + + + + +Ramakrishnan, et al. Standards Track [Page 33] + +RFC 3168 The Addition of ECN to IP September 2001 + + + (5)(6) If the packet will immediately enter a domain for which the + DSCP value in the outer header is not appropriate, that value MUST + be mapped to an appropriate value for the domain [RFC 2474]. Also + see [RFC 2475] for further information. + + (7) If the value of the ECN Tunnel field in the SAD entry for this + SA is "allowed" and the ECN field in the inner header is set to + any value other than CE, copy this ECN field to the outer header. + If the ECN field in the inner header is set to CE, then set the + ECN field in the outer header to ECT(0). + + (8) If the value of the ECN tunnel field in the SAD entry for this + SA is "allowed" and the ECN field in the inner header is set to + ECT(0) or ECT(1) and the ECN field in the outer header is set to + CE, then copy the ECN field from the outer header to the inner + header. Otherwise, make no change to the ECN field in the inner + header. + + (5) and (6) are identical to match usage in [RFC2401], although + they are different in [RFC2401]. + + The above description applies to implementations that support the ECN + Tunnel field in the SAD; such implementations MUST implement this + processing instead of the processing of the IPv4 TOS octet and IPv6 + Traffic Class octet defined in [RFC2401]. This constitutes the + full-functionality alternative for ECN usage with IPsec tunnels. + + An implementation that does not support the ECN Tunnel field in the + SAD MUST implement this processing by assuming that the value of the + ECN Tunnel field of the SAD is "forbidden" for every SA. In this + case, the processing of the ECN field reduces to: + + (7) Set the ECN field to not-ECT in the outer header. + (8) Make no change to the ECN field in the inner header. + + This constitutes the limited functionality alternative for ECN usage + with IPsec tunnels. + + For backwards compatibility, packets with the CE codepoint set in the + outer header SHOULD be dropped if they arrive on an SA that is using + the limited-functionality option, or that is using the full- + functionality option with the not-ECN codepoint set in the inner + header. + + + + + + + + +Ramakrishnan, et al. Standards Track [Page 34] + +RFC 3168 The Addition of ECN to IP September 2001 + + +9.2.2. Changes to the ECN Field within an IPsec Tunnel. + + If the ECN Field is changed inappropriately within an IPsec tunnel, + and this change is detected at the tunnel egress, then the receipt of + a packet not satisfying the appropriate condition for its SA is an + auditable event. An implementation MAY create audit records with + per-SA counts of incorrect packets over some time period rather than + creating an audit record for each erroneous packet. Any such audit + record SHOULD contain the headers from at least one erroneous packet, + but need not contain the headers from every packet represented by the + entry. + +9.2.3. Comments for IPsec Support + + Substantial comments were received on two areas of this document + during review by the IPsec working group. This section describes + these comments and explains why the proposed changes were not + incorporated. + + The first comment indicated that per-node configuration is easier to + implement than per-SA configuration. After serious thought and + despite some initial encouragement of per-node configuration, it no + longer seems to be a good idea. The concern is that as ECN-awareness + is progressively deployed in IPsec, many ECN-aware IPsec + implementations will find themselves communicating with a mixture of + ECN-aware and ECN-unaware IPsec tunnel endpoints. In such an + environment with per-node configuration, the only reasonable thing to + do is forbid ECN usage for all IPsec tunnels, which is not the + desired outcome. + + In the second area, several reviewers noted that SA negotiation is + complex, and adding to it is non-trivial. One reviewer suggested + using ICMP after tunnel setup as a possible alternative. The + addition to SA negotiation in this document is OPTIONAL and will + remain so; implementers are free to ignore it. The authors believe + that the assurance it provides can be useful in a number of + situations. In practice, if this is not implemented, it can be + deleted at a subsequent stage in the standards process. Extending + ICMP to negotiate ECN after tunnel setup is more complex than + extending SA attribute negotiation. Some tunnels do not permit + traffic to be addressed to the tunnel egress endpoint, hence the ICMP + packet would have to be addressed to somewhere else, scanned for by + the egress endpoint, and discarded there or at its actual + destination. In addition, ICMP delivery is unreliable, and hence + there is a possibility of an ICMP packet being dropped, entailing the + invention of yet another ack/retransmit mechanism. It seems better + simply to specify an OPTIONAL extension to the existing SA + negotiation mechanism. + + + +Ramakrishnan, et al. Standards Track [Page 35] + +RFC 3168 The Addition of ECN to IP September 2001 + + +9.3. IP packets encapsulated in non-IP Packet Headers. + + A different set of issues are raised, relative to ECN, when IP + packets are encapsulated in tunnels with non-IP packet headers. This + occurs with MPLS [MPLS], GRE [GRE], L2TP [L2TP], and PPTP [PPTP]. + For these protocols, there is no conflict with ECN; it is just that + ECN cannot be used within the tunnel unless an ECN codepoint can be + specified for the header of the encapsulating protocol. Earlier work + considered a preliminary proposal for incorporating ECN into MPLS, + and proposals for incorporating ECN into GRE, L2TP, or PPTP will be + considered as the need arises. + +10. Issues Raised by Monitoring and Policing Devices + + One possibility is that monitoring and policing devices (or more + informally, "penalty boxes") will be installed in the network to + monitor whether best-effort flows are appropriately responding to + congestion, and to preferentially drop packets from flows determined + not to be using adequate end-to-end congestion control procedures. + + We recommend that any "penalty box" that detects a flow or an + aggregate of flows that is not responding to end-to-end congestion + control first change from marking to dropping packets from that flow, + before taking any additional action to restrict the bandwidth + available to that flow. Thus, initially, the router may drop packets + in which the router would otherwise would have set the CE codepoint. + This could include dropping those arriving packets for that flow that + are ECN-Capable and that already have the CE codepoint set. In this + way, any congestion indications seen by that router for that flow + will be guaranteed to also be seen by the end nodes, even in the + presence of malicious or broken routers elsewhere in the path. If we + assume that the first action taken at any "penalty box" for an ECN- + capable flow will be to drop packets instead of marking them, then + there is no way that an adversary that subverts ECN-based end-to-end + congestion control can cause a flow to be characterized as being + non-cooperative and placed into a more severe action within the + "penalty box". + + The monitoring and policing devices that are actually deployed could + fall short of the `ideal' monitoring device described above, in that + the monitoring is applied not to a single flow, but to an aggregate + of flows (e.g., those sharing a single IPsec tunnel). In this case, + the switch from marking to dropping would apply to all of the flows + in that aggregate, denying the benefits of ECN to the other flows in + the aggregate also. At the highest level of aggregation, another + form of the disabling of ECN happens even in the absence of + + + + + +Ramakrishnan, et al. Standards Track [Page 36] + +RFC 3168 The Addition of ECN to IP September 2001 + + + monitoring and policing devices, when ECN-Capable RED queues switch + from marking to dropping packets as an indication of congestion when + the average queue size has exceeded some threshold. + +11. Evaluations of ECN + +11.1. Related Work Evaluating ECN + + This section discusses some of the related work evaluating the use of + ECN. The ECN Web Page [ECN] has pointers to other papers, as well as + to implementations of ECN. + + [Floyd94] considers the advantages and drawbacks of adding ECN to the + TCP/IP architecture. As shown in the simulation-based comparisons, + one advantage of ECN is to avoid unnecessary packet drops for short + or delay-sensitive TCP connections. A second advantage of ECN is in + avoiding some unnecessary retransmit timeouts in TCP. This paper + discusses in detail the integration of ECN into TCP's congestion + control mechanisms. The possible disadvantages of ECN discussed in + the paper are that a non-compliant TCP connection could falsely + advertise itself as ECN-capable, and that a TCP ACK packet carrying + an ECN-Echo message could itself be dropped in the network. The + first of these two issues is discussed in the appendix of this + document, and the second is addressed by the addition of the CWR flag + in the TCP header. + + Experimental evaluations of ECN include [RFC2884,K98]. The + conclusions of [K98] and [RFC2884] are that ECN TCP gets moderately + better throughput than non-ECN TCP; that ECN TCP flows are fair + towards non-ECN TCP flows; and that ECN TCP is robust with two-way + traffic (with congestion in both directions) and with multiple + congested gateways. Experiments with many short web transfers show + that, while most of the short connections have similar transfer times + with or without ECN, a small percentage of the short connections have + very long transfer times for the non-ECN experiments as compared to + the ECN experiments. + +11.2. A Discussion of the ECN nonce. + + The use of two ECT codepoints, ECT(0) and ECT(1), can provide a one- + bit ECN nonce in packet headers [SCWA99]. The primary motivation for + this is the desire to allow mechanisms for the data sender to verify + that network elements are not erasing the CE codepoint, and that data + receivers are properly reporting to the sender the receipt of packets + with the CE codepoint set, as required by the transport protocol. + This section discusses issues of backwards compatibility with IP ECN + implementations in routers conformant with RFC 2481, in which only + one ECT codepoint was defined. We do not believe that the + + + +Ramakrishnan, et al. Standards Track [Page 37] + +RFC 3168 The Addition of ECN to IP September 2001 + + + incremental deployment of ECN implementations that understand the + ECT(1) codepoint will cause significant operational problems. This + is particularly likely to be the case when the deployment of the + ECT(1) codepoint begins with routers, before the ECT(1) codepoint + starts to be used by end-nodes. + +11.2.1. The Incremental Deployment of ECT(1) in Routers. + + ECN has been an Experimental standard since January 1999, and there + are already implementations of ECN in routers that do not understand + the ECT(1) codepoint. When the use of the ECT(1) codepoint is + standardized for TCP or for other transport protocols, this could + mean that a data sender is using the ECT(1) codepoint, but that this + codepoint is not understood by a congested router on the path. + + If allowed by the transport protocol, a data sender would be free not + to make use of ECT(1) at all, and to send all ECN-capable packets + with the codepoint ECT(0). However, if an ECN-capable sender is + using ECT(1), and the congested router on the path did not understand + the ECT(1) codepoint, then the router would end up marking some of + the ECT(0) packets, and dropping some of the ECT(1) packets, as + indications of congestion. Since TCP is required to react to both + marked and dropped packets, this behavior of dropping packets that + could have been marked poses no significant threat to the network, + and is consistent with the overall approach to ECN that allows + routers to determine when and whether to mark packets as they see fit + (see Section 5). + +12. Summary of changes required in IP and TCP + + This document specified two bits in the IP header to be used for ECN. + The not-ECT codepoint indicates that the transport protocol will + ignore the CE codepoint. This is the default value for the ECN + codepoint. The ECT codepoints indicate that the transport protocol + is willing and able to participate in ECN. + + The router sets the CE codepoint to indicate congestion to the end + nodes. The CE codepoint in a packet header MUST NOT be reset by a + router. + + TCP requires three changes for ECN, a setup phase and two new flags + in the TCP header. The ECN-Echo flag is used by the data receiver to + inform the data sender of a received CE packet. The Congestion + Window Reduced (CWR) flag is used by the data sender to inform the + data receiver that the congestion window has been reduced. + + + + + + +Ramakrishnan, et al. Standards Track [Page 38] + +RFC 3168 The Addition of ECN to IP September 2001 + + + When ECN (Explicit Congestion Notification) is used, it is required + that congestion indications generated within an IP tunnel not be lost + at the tunnel egress. We specified a minor modification to the IP + protocol's handling of the ECN field during encapsulation and de- + capsulation to allow flows that will undergo IP tunneling to use ECN. + + Two options for ECN in tunnels were specified: + + 1) A limited-functionality option that does not use ECN inside the IP + tunnel, by setting the ECN field in the outer header to not-ECT, and + not altering the inner header at the time of decapsulation. + + 2) The full-functionality option, which sets the ECN field in the + outer header to either not-ECT or to one of the ECT codepoints, + depending on the ECN field in the inner header. At decapsulation, if + the CE codepoint is set in the outer header, and the inner header is + set to one of the ECT codepoints, then the CE codepoint is copied to + the inner header. + + For IPsec tunnels, this document also defines an optional IPsec + Security Association (SA) attribute that enables negotiation of ECN + usage within IPsec tunnels and an optional field in the Security + Association Database to indicate whether ECN is permitted in tunnel + mode on a SA. The required changes to IPsec tunnels for ECN usage + modify RFC 2401 [RFC2401], which defines the IPsec architecture and + specifies some aspects of its implementation. The new IPsec SA + attribute is in addition to those already defined in Section 4.5 of + [RFC2407]. + + This document obsoletes RFC 2481, "A Proposal to add Explicit + Congestion Notification (ECN) to IP", which defined ECN as an + Experimental Protocol for the Internet Community. The rest of this + section describes the relationship between this document and its + predecessor. + + RFC 2481 included a brief discussion of the use of ECN with + encapsulated packets, and noted that for the IPsec specifications at + the time (January 1999), flows could not safely use ECN if they were + to traverse IPsec tunnels. RFC 2481 also described the changes that + could be made to IPsec tunnel specifications to made them compatible + with ECN. + + This document also incorporates work that was done after RFC 2481. + First was to describe the changes to IPsec tunnels in detail, and + extensively discuss the security implications of ECN (now included as + Sections 18 and 19 of this document). Second was to extend the + discussion of IPsec tunnels to include all IP tunnels. Because older + IP tunnels are not compatible with a flow's use of ECN, the + + + +Ramakrishnan, et al. Standards Track [Page 39] + +RFC 3168 The Addition of ECN to IP September 2001 + + + deployment of ECN in the Internet will create strong pressure for + older IP tunnels to be updated to an ECN-compatible version, using + either the limited-functionality or the full-functionality option. + + This document does not address the issue of including ECN in non-IP + tunnels such as MPLS, GRE, L2TP, or PPTP. An earlier preliminary + document about adding ECN support to MPLS was not advanced. + + A third new piece of work after RFC2481 was to describe the ECN + procedure with retransmitted data packets, that an ECT codepoint + should not be set on retransmitted data packets. The motivation for + this additional specification is to eliminate a possible avenue for + denial-of-service attacks on an existing TCP connection. Some prior + deployments of ECN-capable TCP might not conform to the (new) + requirement not to set an ECT codepoint on retransmitted packets; we + do not believe this will cause significant problems in practice. + + This document also expands slightly on the specification of the use + of SYN packets for the negotiation of ECN. While some prior + deployments of ECN-capable TCP might not conform to the requirements + specified in this document, we do not believe that this will lead to + any performance or compatibility problems for TCP connections with a + combination of TCP implementations at the endpoints. + + This document also includes the specification of the ECT(1) + codepoint, which may be used by TCP as part of the implementation of + an ECN nonce. + +13. Conclusions + + Given the current effort to implement AQM, we believe this is the + right time to deploy congestion avoidance mechanisms that do not + depend on packet drops alone. With the increased deployment of + applications and transports sensitive to the delay and loss of a + single packet (e.g., realtime traffic, short web transfers), + depending on packet loss as a normal congestion notification + mechanism appears to be insufficient (or at the very least, non- + optimal). + + We examined the consequence of modifications of the ECN field within + the network, analyzing all the opportunities for an adversary to + change the ECN field. In many cases, the change to the ECN field is + no worse than dropping a packet. However, we noted that some changes + have the more serious consequence of subverting end-to-end congestion + control. However, we point out that even then the potential damage + is limited, and is similar to the threat posed by end-systems + intentionally failing to cooperate with end-to-end congestion + control. + + + +Ramakrishnan, et al. Standards Track [Page 40] + +RFC 3168 The Addition of ECN to IP September 2001 + + +14. Acknowledgements + + Many people have made contributions to this work and this document, + including many that we have not managed to directly acknowledge in + this document. In addition, we would like to thank Kenjiro Cho for + the proposal for the TCP mechanism for negotiating ECN-Capability, + Kevin Fall for the proposal of the CWR bit, Steve Blake for material + on IPv4 Header Checksum Recalculation, Jamal Hadi-Salim for + discussions of ECN issues, and Steve Bellovin, Jim Bound, Brian + Carpenter, Paul Ferguson, Stephen Kent, Greg Minshall, and Vern + Paxson for discussions of security issues. We also thank the + Internet End-to-End Research Group for ongoing discussions of these + issues. + + Email discussions with a number of people, including Dax Kelson, + Alexey Kuznetsov, Jamal Hadi-Salim, and Venkat Venkatsubra, have + addressed the issues raised by non-conformant equipment in the + Internet that does not respond to TCP SYN packets with the ECE and + CWR flags set. We thank Mark Handley, Jitentra Padhye, and others + for discussions on the TCP initialization procedures. + + The discussion of ECN and IP tunnel considerations draws heavily on + related discussions and documents from the Differentiated Services + Working Group. We thank Tabassum Bint Haque from Dhaka, Bangladesh, + for feedback on IP tunnels. We thank Derrell Piper and Kero Tivinen + for proposing modifications to RFC 2407 that improve the usability of + negotiating the ECN Tunnel SA attribute. + + We thank David Wetherall, David Ely, and Neil Spring for the proposal + for the ECN nonce. We also thank Stefan Savage for discussions on + this issue. We thank Bob Briscoe and Jon Crowcroft for raising the + issue of fragmentation in IP, on alternate semantics for the fourth + ECN codepoint, and several other topics. We thank Richard Wendland + for feedback on several issues in the document. + + We also thank the IESG, and in particular the Transport Area + Directors over the years, for their feedback and their work towards + the standardization of ECN. + +15. References + + [AH] Kent, S. and R. Atkinson, "IP Authentication Header", + RFC 2402, November 1998. + + [ECN] "The ECN Web Page", URL + "http://www.aciri.org/floyd/ecn.html". Reference for + informational purposes only. + + + + +Ramakrishnan, et al. Standards Track [Page 41] + +RFC 3168 The Addition of ECN to IP September 2001 + + + [ESP] Kent, S. and R. Atkinson, "IP Encapsulating Security + Payload", RFC 2406, November 1998. + + [FIXES] ECN-under-Linux Unofficial Vendor Support Page, URL + "http://gtf.org/garzik/ecn/". Reference for + informational purposes only. + + [FJ93] Floyd, S., and Jacobson, V., "Random Early Detection + gateways for Congestion Avoidance", IEEE/ACM + Transactions on Networking, V.1 N.4, August 1993, p. + 397-413. + + [Floyd94] Floyd, S., "TCP and Explicit Congestion Notification", + ACM Computer Communication Review, V. 24 N. 5, October + 1994, p. 10-23. + + [Floyd98] Floyd, S., "The ECN Validation Test in the NS + Simulator", URL "http://www-mash.cs.berkeley.edu/ns/", + test tcl/test/test-all- ecn. Reference for + informational purposes only. + + [FF99] Floyd, S., and Fall, K., "Promoting the Use of End-to- + End Congestion Control in the Internet", IEEE/ACM + Transactions on Networking, August 1999. + + [FRED] Lin, D., and Morris, R., "Dynamics of Random Early + Detection", SIGCOMM '97, September 1997. + + [GRE] Hanks, S., Li, T., Farinacci, D. and P. Traina, "Generic + Routing Encapsulation (GRE)", RFC 1701, October 1994. + + [Jacobson88] V. Jacobson, "Congestion Avoidance and Control", Proc. + ACM SIGCOMM '88, pp. 314-329. + + [Jacobson90] V. Jacobson, "Modified TCP Congestion Avoidance + Algorithm", Message to end2end-interest mailing list, + April 1990. URL + "ftp://ftp.ee.lbl.gov/email/vanj.90apr30.txt". + + [K98] Krishnan, H., "Analyzing Explicit Congestion + Notification (ECN) benefits for TCP", Master's thesis, + UCLA, 1998. Citation for acknowledgement purposes only. + + [L2TP] Townsley, W., Valencia, A., Rubens, A., Pall, G., Zorn, + G. and B. Palter, "Layer Two Tunneling Protocol "L2TP"", + RFC 2661, August 1999. + + + + + +Ramakrishnan, et al. Standards Track [Page 42] + +RFC 3168 The Addition of ECN to IP September 2001 + + + [MJV96] S. McCanne, V. Jacobson, and M. Vetterli, "Receiver- + driven Layered Multicast", SIGCOMM '96, August 1996, pp. + 117-130. + + [MPLS] Awduche, D., Malcolm, J., Agogbua, J., O'Dell, M. and J. + McManus, Requirements for Traffic Engineering Over MPLS, + RFC 2702, September 1999. + + [PPTP] Hamzeh, K., Pall, G., Verthein, W., Taarud, J., Little, + W. and G. Zorn, "Point-to-Point Tunneling Protocol + (PPTP)", RFC 2637, July 1999. + + [RFC791] Postel, J., "Internet Protocol", STD 5, RFC 791, + September 1981. + + [RFC793] Postel, J., "Transmission Control Protocol", STD 7, RFC + 793, September 1981. + + [RFC1141] Mallory, T. and A. Kullberg, "Incremental Updating of + the Internet Checksum", RFC 1141, January 1990. + + [RFC1349] Almquist, P., "Type of Service in the Internet Protocol + Suite", RFC 1349, July 1992. + + [RFC1455] Eastlake, D., "Physical Link Security Type of Service", + RFC 1455, May 1993. + + [RFC1701] Hanks, S., Li, T., Farinacci, D. and P. Traina, "Generic + Routing Encapsulation (GRE)", RFC 1701, October 1994. + + [RFC1702] Hanks, S., Li, T., Farinacci, D. and P. Traina, "Generic + Routing Encapsulation over IPv4 networks", RFC 1702, + October 1994. + + [RFC2003] Perkins, C., "IP Encapsulation within IP", RFC 2003, + October 1996. + + [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate + Requirement Levels", BCP 14, RFC 2119, March 1997. + + [RFC2309] Braden, B., et al., "Recommendations on Queue Management + and Congestion Avoidance in the Internet", RFC 2309, + April 1998. + + [RFC2401] Kent, S. and R. Atkinson, Security Architecture for the + Internet Protocol, RFC 2401, November 1998. + + + + + +Ramakrishnan, et al. Standards Track [Page 43] + +RFC 3168 The Addition of ECN to IP September 2001 + + + [RFC2407] Piper, D., "The Internet IP Security Domain of + Interpretation for ISAKMP", RFC 2407, November 1998. + + [RFC2408] Maughan, D., Schertler, M., Schneider, M. and J. Turner, + "Internet Security Association and Key Management + Protocol (ISAKMP)", RFC 2409, November 1998. + + [RFC2409] Harkins D. and D. Carrel, "The Internet Key Exchange + (IKE)", RFC 2409, November 1998. + + [RFC2474] Nichols, K., Blake, S., Baker, F. and D. Black, + "Definition of the Differentiated Services Field (DS + Field) in the IPv4 and IPv6 Headers", RFC 2474, December + 1998. + + [RFC2475] Blake, S., Black, D., Carlson, M., Davies, E., Wang, Z. + and W. Weiss, "An Architecture for Differentiated + Services", RFC 2475, December 1998. + + [RFC2481] Ramakrishnan K. and S. Floyd, "A Proposal to add + Explicit Congestion Notification (ECN) to IP", RFC 2481, + January 1999. + + [RFC2581] Alman, M., Paxson, V. and W. Stevens, "TCP Congestion + Control", RFC 2581, April 1999. + + [RFC2884] Hadi Salim, J. and U. Ahmed, "Performance Evaluation of + Explicit Congestion Notification (ECN) in IP Networks", + RFC 2884, July 2000. + + [RFC2983] Black, D., "Differentiated Services and Tunnels", + RFC2983, October 2000. + + [RFC2780] Bradner S. and V. Paxson, "IANA Allocation Guidelines + For Values In the Internet Protocol and Related + Headers", BCP 37, RFC 2780, March 2000. + + [RJ90] K. K. Ramakrishnan and Raj Jain, "A Binary Feedback + Scheme for Congestion Avoidance in Computer Networks", + ACM Transactions on Computer Systems, Vol.8, No.2, pp. + 158-181, May 1990. + + [SCWA99] Stefan Savage, Neal Cardwell, David Wetherall, and Tom + Anderson, TCP Congestion Control with a Misbehaving + Receiver, ACM Computer Communications Review, October + 1999. + + + + + +Ramakrishnan, et al. Standards Track [Page 44] + +RFC 3168 The Addition of ECN to IP September 2001 + + + [TBIT] Jitendra Padhye and Sally Floyd, "Identifying the TCP + Behavior of Web Servers", ICSI TR-01-002, February 2001. + URL "http://www.aciri.org/tbit/". + +16. Security Considerations + + Security considerations have been discussed in Sections 7, 8, 18, and + 19. + +17. IPv4 Header Checksum Recalculation + + IPv4 header checksum recalculation is an issue with some high-end + router architectures using an output-buffered switch, since most if + not all of the header manipulation is performed on the input side of + the switch, while the ECN decision would need to be made local to the + output buffer. This is not an issue for IPv6, since there is no IPv6 + header checksum. The IPv4 TOS octet is the last byte of a 16-bit + half-word. + + RFC 1141 [RFC1141] discusses the incremental updating of the IPv4 + checksum after the TTL field is decremented. The incremental + updating of the IPv4 checksum after the CE codepoint was set would + work as follows: Let HC be the original header checksum for an ECT(0) + packet, and let HC' be the new header checksum after the CE bit has + been set. That is, the ECN field has changed from '10' to '11'. + Then for header checksums calculated with one's complement + subtraction, HC' would be recalculated as follows: + + HC' = { HC - 1 HC > 1 + { 0x0000 HC = 1 + + For header checksums calculated on two's complement machines, HC' + would be recalculated as follows after the CE bit was set: + + HC' = { HC - 1 HC > 0 + { 0xFFFE HC = 0 + + A similar incremental updating of the IPv4 checksum can be carried + out when the ECN field is changed from ECT(1) to CE, that is, from ' + 01' to '11'. + +18. Possible Changes to the ECN Field in the Network + + This section discusses in detail possible changes to the ECN field in + the network, such as falsely reporting congestion, disabling ECN- + Capability for an individual packet, erasing the ECN congestion + indication, or falsely indicating ECN-Capability. + + + + +Ramakrishnan, et al. Standards Track [Page 45] + +RFC 3168 The Addition of ECN to IP September 2001 + + +18.1. Possible Changes to the IP Header + +18.1.1. Erasing the Congestion Indication + + First, we consider the changes that a router could make that would + result in effectively erasing the congestion indication after it had + been set by a router upstream. The convention followed is: ECN + codepoint of received packet -> ECN codepoint of packet transmitted. + + Replacing the CE codepoint with the ECT(0) or ECT(1) codepoint + effectively erases the congestion indication. However, with the use + of two ECT codepoints, a router erasing the CE codepoint has no way + to know whether the original ECT codepoint was ECT(0) or ECT(1). + Thus, it is possible for the transport protocol to deploy mechanisms + to detect such erasures of the CE codepoint. + + The consequence of the erasure of the CE codepoint for the upstream + router is that there is a potential for congestion to build for a + time, because the congestion indication does not reach the source. + However, the packet would be received and acknowledged. + + The potential effect of erasing the congestion indication is complex, + and is discussed in depth in Section 19 below. Note that the effect + of erasing the congestion indication is different from dropping a + packet in the network. When a data packet is dropped, the drop is + detected by the TCP sender, and interpreted as an indication of + congestion. Similarly, if a sufficient number of consecutive + acknowledgement packets are dropped, causing the cumulative + acknowledgement field not to be advanced at the sender, the sender is + limited by the congestion window from sending additional packets, and + ultimately the retransmit timer expires. + + In contrast, a systematic erasure of the CE bit by a downstream + router can have the effect of causing a queue buildup at an upstream + router, including the possible loss of packets due to buffer + overflow. There is a potential of unfairness in that another flow + that goes through the congested router could react to the CE bit set + while the flow that has the CE bit erased could see better + performance. The limitations on this potential unfairness are + discussed in more detail in Section 19 below. + + The last of the three changes is to replace the CE codepoint with the + not-ECT codepoint, thus erasing the congestion indication and + disabling ECN-Capability at the same time. + + The `erasure' of the congestion indication is only effective if the + packet does not end up being marked or dropped again by a downstream + router. If the CE codepoint is replaced by an ECT codepoint, the + + + +Ramakrishnan, et al. Standards Track [Page 46] + +RFC 3168 The Addition of ECN to IP September 2001 + + + packet remains ECN-Capable, and could be either marked or dropped by + a downstream router as an indication of congestion. If the CE + codepoint is replaced by the not-ECT codepoint, the packet is no + longer ECN-capable, and can therefore be dropped but not marked by a + downstream router as an indication of congestion. + +18.1.2. Falsely Reporting Congestion + + This change is to set the CE codepoint when an ECT codepoint was + already set, even though there was no congestion. This change does + not affect the treatment of that packet along the rest of the path. + In particular, a router does not examine the CE codepoint in deciding + whether to drop or mark an arriving packet. + + However, this could result in the application unnecessarily invoking + end-to-end congestion control, and reducing its arrival rate. By + itself, this is no worse (for the application or for the network) + than if the tampering router had actually dropped the packet. + +18.1.3. Disabling ECN-Capability + + This change is to turn off the ECT codepoint of a packet. This means + that if the packet later encounters congestion (e.g., by arriving to + a RED queue with a moderate average queue size), it will be dropped + instead of being marked. By itself, this is no worse (for the + application) than if the tampering router had actually dropped the + packet. The saving grace in this particular case is that there is no + congested router upstream expecting a reaction from setting the CE + bit. + +18.1.4. Falsely Indicating ECN-Capability + + This change would incorrectly label a packet as ECN-Capable. The + packet may have been sent either by an ECN-Capable transport or a + transport that is not ECN-Capable. + + If the packet later encounters moderate congestion at an ECN-Capable + router, the router could set the CE codepoint instead of dropping the + packet. If the transport protocol in fact is not ECN-Capable, then + the transport will never receive this indication of congestion, and + will not reduce its sending rate in response. The potential + consequences of falsely indicating ECN-capability are discussed + further in Section 19 below. + + If the packet never later encounters congestion at an ECN-Capable + router, then the first of these two changes would have no effect, + other than possibly interfering with the use of the ECN nonce by the + transport protocol. The last change, however, would have the effect + + + +Ramakrishnan, et al. Standards Track [Page 47] + +RFC 3168 The Addition of ECN to IP September 2001 + + + of giving false reports of congestion to a monitoring device along + the path. If the transport protocol is ECN-Capable, then this change + could also have an effect at the transport level, by combining + falsely indicating ECN-Capability with falsely reporting congestion. + For an ECN-capable transport, this would cause the transport to + unnecessarily react to congestion. In this particular case, the + router that is incorrectly changing the ECN field could have dropped + the packet. Thus for this case of an ECN-capable transport, the + consequence of this change to the ECN field is no worse than dropping + the packet. + +18.2. Information carried in the Transport Header + + For TCP, an ECN-capable TCP receiver informs its TCP peer that it is + ECN-capable at the TCP level, conveying this information in the TCP + header at the time the connection is setup. This document does not + consider potential dangers introduced by changes in the transport + header within the network. We note that when IPsec is used, the + transport header is protected both in tunnel and transport modes + [ESP, AH]. + + Another issue concerns TCP packets with a spoofed IP source address + carrying invalid ECN information in the transport header. For + completeness, we examine here some possible ways that a node spoofing + the IP source address of another node could use the two ECN flags in + the TCP header to launch a denial-of-service attack. However, these + attacks would require an ability for the attacker to use valid TCP + sequence numbers, and any attacker with this ability and with the + ability to spoof IP source addresses could damage the TCP connection + without using the ECN flags. Therefore, ECN does not add any new + vulnerabilities in this respect. + + An acknowledgement packet with a spoofed IP source address of the TCP + data receiver could include the ECE bit set. If accepted by the TCP + data sender as a valid packet, this spoofed acknowledgement packet + could result in the TCP data sender unnecessarily halving its + congestion window. However, to be accepted by the data sender, such + a spoofed acknowledgement packet would have to have the correct 32- + bit sequence number as well as a valid acknowledgement number. An + attacker that could successfully send such a spoofed acknowledgement + packet could also send a spoofed RST packet, or do other equally + damaging operations to the TCP connection. + + Packets with a spoofed IP source address of the TCP data sender could + include the CWR bit set. Again, to be accepted, such a packet would + have to have a valid sequence number. In addition, such a spoofed + packet would have a limited performance impact. Spoofing a data + packet with the CWR bit set could result in the TCP data receiver + + + +Ramakrishnan, et al. Standards Track [Page 48] + +RFC 3168 The Addition of ECN to IP September 2001 + + + sending fewer ECE packets than it would otherwise, if the data + receiver was sending ECE packets when it received the spoofed CWR + packet. + +18.3. Split Paths + + In some cases, a malicious or broken router might have access to only + a subset of the packets from a flow. The question is as follows: + can this router, by altering the ECN field in this subset of the + packets, do more damage to that flow than if it had simply dropped + that set of packets? + + We will classify the packets in the flow as A packets and B packets, + and assume that the adversary only has access to A packets. Assume + that the adversary is subverting end-to-end congestion control along + the path traveled by A packets only, by either falsely indicating + ECN-Capability upstream of the point where congestion occurs, or + erasing the congestion indication downstream. Consider also that + there exists a monitoring device that sees both the A and B packets, + and will "punish" both the A and B packets if the total flow is + determined not to be properly responding to indications of + congestion. Another key characteristic that we believe is likely to + be true is that the monitoring device, before `punishing' the A&B + flow, will first drop packets instead of setting the CE codepoint, + and will drop arriving packets of that flow that already have the CE + codepoint set. If the end nodes are in fact using end-to-end + congestion control, they will see all of the indications of + congestion seen by the monitoring device, and will begin to respond + to these indications of congestion. Thus, the monitoring device is + successful in providing the indications to the flow at an early + stage. + + It is true that the adversary that has access only to the A packets + might, by subverting ECN-based congestion control, be able to deny + the benefits of ECN to the other packets in the A&B aggregate. While + this is unfortunate, this is not a reason to disable ECN. + + A variant of falsely reporting congestion occurs when there are two + adversaries along a path, where the first adversary falsely reports + congestion, and the second adversary `erases' those reports. (Unlike + packet drops, ECN congestion reports can be `reversed' later in the + network by a malicious or broken router. However, the use of the ECN + nonce could help the transport to detect this behavior.) While this + would be transparent to the end node, it is possible that a + monitoring device between the first and second adversaries would see + the false indications of congestion. Keep in mind our recommendation + in this document, that before `punishing' a flow for not responding + appropriately to congestion, the router will first switch to dropping + + + +Ramakrishnan, et al. Standards Track [Page 49] + +RFC 3168 The Addition of ECN to IP September 2001 + + + rather than marking as an indication of congestion, for that flow. + When this includes dropping arriving packets from that flow that have + the CE codepoint set, this ensures that these indications of + congestion are being seen by the end nodes. Thus, there is no + additional harm that we are able to postulate as a result of multiple + conflicting adversaries. + +19. Implications of Subverting End-to-End Congestion Control + + This section focuses on the potential repercussions of subverting + end-to-end congestion control by either falsely indicating ECN- + Capability, or by erasing the congestion indication in ECN (the CE + codepoint). Subverting end-to-end congestion control by either of + these two methods can have consequences both for the application and + for the network. We discuss these separately below. + + The first method to subvert end-to-end congestion control, that of + falsely indicating ECN-Capability, effectively subverts end-to-end + congestion control only if the packet later encounters congestion + that results in the setting of the CE codepoint. In this case, the + transport protocol (which may not be ECN-capable) does not receive + the indication of congestion from these downstream congested routers. + + The second method to subvert end-to-end congestion control, `erasing' + the CE codepoint in a packet, effectively subverts end-to-end + congestion control only when the CE codepoint in the packet was set + earlier by a congested router. In this case, the transport protocol + does not receive the indication of congestion from the upstream + congested routers. + + Either of these two methods of subverting end-to-end congestion + control can potentially introduce more damage to the network (and + possibly to the flow itself) than if the adversary had simply dropped + packets from that flow. However, as we discuss later in this section + and in Section 7, this potential damage is limited. + +19.1. Implications for the Network and for Competing Flows + + The CE codepoint of the ECN field is only used by routers as an + indication of congestion during periods of *moderate* congestion. + ECN-capable routers should drop rather than mark packets during heavy + congestion even if the router's queue is not yet full. For example, + for routers using active queue management based on RED, the router + should drop rather than mark packets that arrive while the average + queue sizes exceed the RED queue's maximum threshold. + + + + + + +Ramakrishnan, et al. Standards Track [Page 50] + +RFC 3168 The Addition of ECN to IP September 2001 + + + One consequence for the network of subverting end-to-end congestion + control is that flows that do not receive the congestion indications + from the network might increase their sending rate until they drive + the network into heavier congestion. Then, the congested router + could begin to drop rather than mark arriving packets. For flows + that are not isolated by some form of per-flow scheduling or other + per-flow mechanisms, but are instead aggregated with other flows in a + single queue in an undifferentiated fashion, this packet-dropping at + the congested router would apply to all flows that share that queue. + Thus, the consequences would be to increase the level of congestion + in the network. + + In some cases, the increase in the level of congestion will lead to a + substantial buffer buildup at the congested queue that will be + sufficient to drive the congested queue from the packet-marking to + the packet-dropping regime. This transition could occur either + because of buffer overflow, or because of the active queue management + policy described above that drops packets when the average queue is + above RED's maximum threshold. At this point, all flows, including + the subverted flow, will begin to see packet drops instead of packet + marks, and a malicious or broken router will no longer be able to ` + erase' these indications of congestion in the network. If the end + nodes are deploying appropriate end-to-end congestion control, then + the subverted flow will reduce its arrival rate in response to + congestion. When the level of congestion is sufficiently reduced, + the congested queue can return from the packet-dropping regime to the + packet-marking regime. The steady-state pattern could be one of the + congested queue oscillating between these two regimes. + + In other cases, the consequences of subverting end-to-end congestion + control will not be severe enough to drive the congested link into + sufficiently-heavy congestion that packets are dropped instead of + being marked. In this case, the implications for competing flows in + the network will be a slightly-increased rate of packet marking or + dropping, and a corresponding decrease in the bandwidth available to + those flows. This can be a stable state if the arrival rate of the + subverted flow is sufficiently small, relative to the link bandwidth, + that the average queue size at the congested router remains under + control. In particular, the subverted flow could have a limited + bandwidth demand on the link at this router, while still getting more + than its "fair" share of the link. This limited demand could be due + to a limited demand from the data source; a limitation from the TCP + advertised window; a lower-bandwidth access pipe; or other factors. + Thus the subversion of ECN-based congestion control can still lead to + unfairness, which we believe is appropriate to note here. + + + + + + +Ramakrishnan, et al. Standards Track [Page 51] + +RFC 3168 The Addition of ECN to IP September 2001 + + + The threat to the network posed by the subversion of ECN-based + congestion control in the network is essentially the same as the + threat posed by an end-system that intentionally fails to cooperate + with end-to-end congestion control. The deployment of mechanisms in + routers to address this threat is an open research question, and is + discussed further in Section 10. + + Let us take the example described in Section 18.1.1, where the CE + codepoint that was set in a packet is erased: {'11' -> '10' or '11' + -> '01'}. The consequence for the congested upstream router that set + the CE codepoint is that this congestion indication does not reach + the end nodes for that flow. The source (even one which is completely + cooperative and not malicious) is thus allowed to continue to + increase its sending rate (if it is a TCP flow, by increasing its + congestion window). The flow potentially achieves better throughput + than the other flows that also share the congested router, especially + if there are no policing mechanisms or per-flow queuing mechanisms at + that router. Consider the behavior of the other flows, especially if + they are cooperative: that is, the flows that do not experience + subverted end-to-end congestion control. They are likely to reduce + their load (e.g., by reducing their window size) on the congested + router, thus benefiting our subverted flow. This results in + unfairness. As we discussed above, this unfairness could either be + transient (because the congested queue is driven into the packet- + marking regime), oscillatory (because the congested queue oscillates + between the packet marking and the packet dropping regime), or more + moderate but a persistent stable state (because the congested queue + is never driven to the packet dropping regime). + + The results would be similar if the subverted flow was intentionally + avoiding end-to-end congestion control. One difference is that a + flow that is intentionally avoiding end-to-end congestion control at + the end nodes can avoid end-to-end congestion control even when the + congested queue is in packet-dropping mode, by refusing to reduce its + sending rate in response to packet drops in the network. Thus the + problems for the network from the subversion of ECN-based congestion + control are less severe than the problems caused by the intentional + avoidance of end-to-end congestion control in the end nodes. It is + also the case that it is considerably more difficult to control the + behavior of the end nodes than it is to control the behavior of the + infrastructure itself. This is not to say that the problems for the + network posed by the network's subversion of ECN-based congestion + control are small; just that they are dwarfed by the problems for the + network posed by the subversion of either ECN-based or other + currently known packet-based congestion control mechanisms by the end + nodes. + + + + + +Ramakrishnan, et al. Standards Track [Page 52] + +RFC 3168 The Addition of ECN to IP September 2001 + + +19.2. Implications for the Subverted Flow + + When a source indicates that it is ECN-capable, there is an + expectation that the routers in the network that are capable of + participating in ECN will use the CE codepoint for indication of + congestion. There is the potential benefit of using ECN in reducing + the amount of packet loss (in addition to the reduced queuing delays + because of active queue management policies). When the packet flows + through an IPsec tunnel where the nodes that the tunneled packets + traverse are untrusted in some way, the expectation is that IPsec + will protect the flow from subversion that results in undesirable + consequences. + + In many cases, a subverted flow will benefit from the subversion of + end-to-end congestion control for that flow in the network, by + receiving more bandwidth than it would have otherwise, relative to + competing non-subverted flows. If the congested queue reaches the + packet-dropping stage, then the subversion of end-to-end congestion + control might or might not be of overall benefit to the subverted + flow, depending on that flow's relative tradeoffs between throughput, + loss, and delay. + + One form of subverting end-to-end congestion control is to falsely + indicate ECN-capability by setting the ECT codepoint. This has the + consequence of downstream congested routers setting the CE codepoint + in vain. However, as described in Section 9.1.2, if an ECT codepoint + is changed in an IP tunnel, this can be detected at the egress point + of the tunnel, as long as the inner header was not changed within the + tunnel. + + The second form of subverting end-to-end congestion control is to + erase the congestion indication by erasing the CE codepoint. In this + case, it is the upstream congested routers that set the CE codepoint + in vain. + + If an ECT codepoint is erased within an IP tunnel, then this can be + detected at the egress point of the tunnel, as long as the inner + header was not changed within the tunnel. If the CE codepoint is set + upstream of the IP tunnel, then any erasure of the outer header's CE + codepoint within the tunnel will have no effect because the inner + header preserves the set value of the CE codepoint. However, if the + CE codepoint is set within the tunnel, and erased either within or + downstream of the tunnel, this is not necessarily detected at the + egress point of the tunnel. + + With this subversion of end-to-end congestion control, an end-system + transport does not respond to the congestion indication. Along with + the increased unfairness for the non-subverted flows described in the + + + +Ramakrishnan, et al. Standards Track [Page 53] + +RFC 3168 The Addition of ECN to IP September 2001 + + + previous section, the congested router's queue could continue to + build, resulting in packet loss at the congested router - which is a + means for indicating congestion to the transport in any case. In the + interim, the flow might experience higher queuing delays, possibly + along with an increased bandwidth relative to other non-subverted + flows. But transports do not inherently make assumptions of + consistently experiencing carefully managed queuing in the path. We + believe that these forms of subverting end-to-end congestion control + are no worse for the subverted flow than if the adversary had simply + dropped the packets of that flow itself. + +19.3. Non-ECN-Based Methods of Subverting End-to-end Congestion Control + + We have shown that, in many cases, a malicious or broken router that + is able to change the bits in the ECN field can do no more damage + than if it had simply dropped the packet in question. However, this + is not true in all cases, in particular in the cases where the broken + router subverted end-to-end congestion control by either falsely + indicating ECN-Capability or by erasing the ECN congestion indication + (in the CE codepoint). While there are many ways that a router can + harm a flow by dropping packets, a router cannot subvert end-to-end + congestion control by dropping packets. As an example, a router + cannot subvert TCP congestion control by dropping data packets, + acknowledgement packets, or control packets. + + Even though packet-dropping cannot be used to subvert end-to-end + congestion control, there *are* non-ECN-based methods for subverting + end-to-end congestion control that a broken or malicious router could + use. For example, a broken router could duplicate data packets, thus + effectively negating the effects of end-to-end congestion control + along some portion of the path. (For a router that duplicated + packets within an IPsec tunnel, the security administrator can cause + the duplicate packets to be discarded by configuring anti-replay + protection for the tunnel.) This duplication of packets within the + network would have similar implications for the network and for the + subverted flow as those described in Sections 18.1.1 and 18.1.4 + above. + +20. The Motivation for the ECT Codepoints. + +20.1. The Motivation for an ECT Codepoint. + + The need for an ECT codepoint is motivated by the fact that ECN will + be deployed incrementally in an Internet where some transport + protocols and routers understand ECN and some do not. With an ECT + codepoint, the router can drop packets from flows that are not ECN- + capable, but can *instead* set the CE codepoint in packets that *are* + + + + +Ramakrishnan, et al. Standards Track [Page 54] + +RFC 3168 The Addition of ECN to IP September 2001 + + + ECN-capable. Because an ECT codepoint allows an end node to have the + CE codepoint set in a packet *instead* of having the packet dropped, + an end node might have some incentive to deploy ECN. + + If there was no ECT codepoint, then the router would have to set the + CE codepoint for packets from both ECN-capable and non-ECN-capable + flows. In this case, there would be no incentive for end-nodes to + deploy ECN, and no viable path of incremental deployment from a non- + ECN world to an ECN-capable world. Consider the first stages of such + an incremental deployment, where a subset of the flows are ECN- + capable. At the onset of congestion, when the packet + dropping/marking rate would be low, routers would only set CE + codepoints, rather than dropping packets. However, only those flows + that are ECN-capable would understand and respond to CE packets. The + result is that the ECN-capable flows would back off, and the non- + ECN-capable flows would be unaware of the ECN signals and would + continue to open their congestion windows. + + In this case, there are two possible outcomes: (1) the ECN-capable + flows back off, the non-ECN-capable flows get all of the bandwidth, + and congestion remains mild, or (2) the ECN-capable flows back off, + the non-ECN-capable flows don't, and congestion increases until the + router transitions from setting the CE codepoint to dropping packets. + While this second outcome evens out the fairness, the ECN-capable + flows would still receive little benefit from being ECN-capable, + because the increased congestion would drive the router to packet- + dropping behavior. + + A flow that advertised itself as ECN-Capable but does not respond to + CE codepoints is functionally equivalent to a flow that turns off + congestion control, as discussed earlier in this document. + + Thus, in a world when a subset of the flows are ECN-capable, but + where ECN-capable flows have no mechanism for indicating that fact to + the routers, there would be less effective and less fair congestion + control in the Internet, resulting in a strong incentive for end + nodes not to deploy ECN. + +20.2. The Motivation for two ECT Codepoints. + + The primary motivation for the two ECT codepoints is to provide a + one-bit ECN nonce. The ECN nonce allows the development of + mechanisms for the sender to probabilistically verify that network + elements are not erasing the CE codepoint, and that data receivers + are properly reporting to the sender the receipt of packets with the + CE codepoint set. + + + + + +Ramakrishnan, et al. Standards Track [Page 55] + +RFC 3168 The Addition of ECN to IP September 2001 + + + Another possibility for senders to detect misbehaving network + elements or receivers would be for the data sender to occasionally + send a data packet with the CE codepoint set, to see if the receiver + reports receiving the CE codepoint. Of course, if these packets + encountered congestion in the network, the router might make no + change in the packets, because the CE codepoint would already be set. + Thus, for packets sent with the CE codepoint set, the TCP end-nodes + could not determine if some router intended to set the CE codepoint + in these packets. For this reason, sending packets with the CE + codepoint would have to be done sparingly, and would be a less + effective check against misbehaving network elements and receivers + than would be the ECN nonce. + + The assignment of the fourth ECN codepoint to ECT(1) precludes the + use of this codepoint for some other purposes. For clarity, we + briefly list other possible purposes here. + + One possibility might have been for the data sender to use the fourth + ECN codepoint to indicate an alternate semantics for ECN. However, + this seems to us more appropriate to be signaled using a + differentiated services codepoint in the DS field. + + A second possible use for the fourth ECN codepoint would have been to + give the router two separate codepoints for the indication of + congestion, CE(0) and CE(1), for mild and severe congestion + respectively. While this could be useful in some cases, this + certainly does not seem a compelling requirement at this point. If + there was judged to be a compelling need for this, the complications + of incremental deployment would most likely necessitate more that + just one codepoint for this function. + + A third use that has been informally proposed for the ECN codepoint + is for use in some forms of multicast congestion control, based on + randomized procedures for duplicating marked packets at routers. + Some proposed multicast packet duplication procedures are based on a + new ECN codepoint that (1) conveys the fact that congestion occurred + upstream of the duplication point that marked the packet with this + codepoint and (2) can detect congestion downstream of that + duplication point. ECT(1) can serve this purpose because it is both + distinct from ECT(0) and is replaced by CE when ECN marking occurs in + response to congestion or incipient congestion. Explanation of how + this enhanced version of ECN would be used by multicast congestion + control is beyond the scope of this document, as are ECN-aware + multicast packet duplication procedures and the processing of the ECN + field at multicast receivers in all cases (i.e., irrespective of the + multicast packet duplication procedure(s) used). + + + + + +Ramakrishnan, et al. Standards Track [Page 56] + +RFC 3168 The Addition of ECN to IP September 2001 + + + The specification of IP tunnel modifications for ECN in this document + assumes that the only change made to the outer IP header's ECN field + between tunnel endpoints is to set the CE codepoint to indicate + congestion. This is not consistent with some of the proposed uses of + ECT(1) by the multicast duplication procedures in the previous + paragraph, and such procedures SHOULD NOT be deployed unless this + inconsistency between multicast duplication procedures and IP tunnels + with full ECN functionality is resolved. Limited ECN functionality + may be used instead, although in practice many tunnel protocols + (including IPsec) will not work correctly if multicast traffic + duplication occurs within the tunnel + +21. Why use Two Bits in the IP Header? + + Given the need for an ECT indication in the IP header, there still + remains the question of whether the ECT (ECN-Capable Transport) and + CE (Congestion Experienced) codepoints should have been overloaded on + a single bit. This overloaded-one-bit alternative, explored in + [Floyd94], would have involved a single bit with two values. One + value, "ECT and not CE", would represent an ECN-Capable Transport, + and the other value, "CE or not ECT", would represent either + Congestion Experienced or a non-ECN-Capable transport. + + One difference between the one-bit and two-bit implementations + concerns packets that traverse multiple congested routers. Consider + a CE packet that arrives at a second congested router, and is + selected by the active queue management at that router for either + marking or dropping. In the one-bit implementation, the second + congested router has no choice but to drop the CE packet, because it + cannot distinguish between a CE packet and a non-ECT packet. In the + two-bit implementation, the second congested router has the choice of + either dropping the CE packet, or of leaving it alone with the CE + codepoint set. + + Another difference between the one-bit and two-bit implementations + comes from the fact that with the one-bit implementation, receivers + in a single flow cannot distinguish between CE and non-ECT packets. + Thus, in the one-bit implementation an ECN-capable data sender would + have to unambiguously indicate to the receiver or receivers whether + each packet had been sent as ECN-Capable or as non-ECN-Capable. One + possibility would be for the sender to indicate in the transport + header whether the packet was sent as ECN-Capable. A second + possibility that would involve a functional limitation for the one- + bit implementation would be for the sender to unambiguously indicate + that it was going to send *all* of its packets as ECN-Capable or as + non-ECN-Capable. For a multicast transport protocol, this + unambiguous indication would have to be apparent to receivers joining + an on-going multicast session. + + + +Ramakrishnan, et al. Standards Track [Page 57] + +RFC 3168 The Addition of ECN to IP September 2001 + + + Another concern that was described earlier (and recommended in this + document) is that transports (particularly TCP) should not mark pure + ACK packets or retransmitted packets as being ECN-Capable. A pure + ACK packet from a non-ECN-capable transport could be dropped, without + necessarily having an impact on the transport from a congestion + control perspective (because subsequent ACKs are cumulative). An + ECN-capable transport reacting to the CE codepoint in a pure ACK + packet by reducing the window would be at a disadvantage in + comparison to a non-ECN-capable transport. For this reason (and for + reasons described earlier in relation to retransmitted packets), it + is desirable to have the ECT codepoint set on a per-packet basis. + + Another advantage of the two-bit approach is that it is somewhat more + robust. The most critical issue, discussed in Section 8, is that the + default indication should be that of a non-ECN-Capable transport. In + a two-bit implementation, this requirement for the default value + simply means that the not-ECT codepoint should be the default. In + the one-bit implementation, this means that the single overloaded bit + should by default be in the "CE or not ECT" position. This is less + clear and straightforward, and possibly more open to incorrect + implementations either in the end nodes or in the routers. + + In summary, while the one-bit implementation could be a possible + implementation, it has the following significant limitations relative + to the two-bit implementation. First, the one-bit implementation has + more limited functionality for the treatment of CE packets at a + second congested router. Second, the one-bit implementation requires + either that extra information be carried in the transport header of + packets from ECN-Capable flows (to convey the functionality of the + second bit elsewhere, namely in the transport header), or that + senders in ECN-Capable flows accept the limitation that receivers + must be able to determine a priori which packets are ECN-Capable and + which are not ECN-Capable. Third, the one-bit implementation is + possibly more open to errors from faulty implementations that choose + the wrong default value for the ECN bit. We believe that the use of + the extra bit in the IP header for the ECT-bit is extremely valuable + to overcome these limitations. + +22. Historical Definitions for the IPv4 TOS Octet + + RFC 791 [RFC791] defined the ToS (Type of Service) octet in the IP + header. In RFC 791, bits 6 and 7 of the ToS octet are listed as + "Reserved for Future Use", and are shown set to zero. The first two + fields of the ToS octet were defined as the Precedence and Type of + Service (TOS) fields. + + + + + + +Ramakrishnan, et al. Standards Track [Page 58] + +RFC 3168 The Addition of ECN to IP September 2001 + + + 0 1 2 3 4 5 6 7 + +-----+-----+-----+-----+-----+-----+-----+-----+ + | PRECEDENCE | TOS | 0 | 0 | RFC 791 + +-----+-----+-----+-----+-----+-----+-----+-----+ + + RFC 1122 included bits 6 and 7 in the TOS field, though it did not + discuss any specific use for those two bits: + + 0 1 2 3 4 5 6 7 + +-----+-----+-----+-----+-----+-----+-----+-----+ + | PRECEDENCE | TOS | RFC 1122 + +-----+-----+-----+-----+-----+-----+-----+-----+ + + The IPv4 TOS octet was redefined in RFC 1349 [RFC1349] as follows: + + 0 1 2 3 4 5 6 7 + +-----+-----+-----+-----+-----+-----+-----+-----+ + | PRECEDENCE | TOS | MBZ | RFC 1349 + +-----+-----+-----+-----+-----+-----+-----+-----+ + + Bit 6 in the TOS field was defined in RFC 1349 for "Minimize Monetary + Cost". In addition to the Precedence and Type of Service (TOS) + fields, the last field, MBZ (for "must be zero") was defined as + currently unused. RFC 1349 stated that "The originator of a datagram + sets [the MBZ] field to zero (unless participating in an Internet + protocol experiment which makes use of that bit)." + + RFC 1455 [RFC 1455] defined an experimental standard that used all + four bits in the TOS field to request a guaranteed level of link + security. + + RFC 1349 and RFC 1455 have been obsoleted by "Definition of the + Differentiated Services Field (DS Field) in the IPv4 and IPv6 + Headers" [RFC2474] in which bits 6 and 7 of the DS field are listed + as Currently Unused (CU). RFC 2780 [RFC2780] specified ECN as an + experimental use of the two-bit CU field. RFC 2780 updated the + definition of the DS Field to only encompass the first six bits of + this octet rather than all eight bits; these first six bits are + defined as the Differentiated Services CodePoint (DSCP): + + 0 1 2 3 4 5 6 7 + +-----+-----+-----+-----+-----+-----+-----+-----+ + | DSCP | CU | RFCs 2474, + +-----+-----+-----+-----+-----+-----+-----+-----+ 2780 + + Because of this unstable history, the definition of the ECN field in + this document cannot be guaranteed to be backwards compatible with + all past uses of these two bits. + + + +Ramakrishnan, et al. Standards Track [Page 59] + +RFC 3168 The Addition of ECN to IP September 2001 + + + Prior to RFC 2474, routers were not permitted to modify bits in + either the DSCP or ECN field of packets forwarded through them, and + hence routers that comply only with RFCs prior to 2474 should have no + effect on ECN. For end nodes, bit 7 (the second ECN bit) must be + transmitted as zero for any implementation compliant only with RFCs + prior to 2474. Such nodes may transmit bit 6 (the first ECN bit) as + one for the "Minimize Monetary Cost" provision of RFC 1349 or the + experiment authorized by RFC 1455; neither this aspect of RFC 1349 + nor the experiment in RFC 1455 were widely implemented or used. The + damage that could be done by a broken, non-conformant router would + include "erasing" the CE codepoint for an ECN-capable packet that + arrived at the router with the CE codepoint set, or setting the CE + codepoint even in the absence of congestion. This has been discussed + in the section on "Non-compliance in the Network". + + The damage that could be done in an ECN-capable environment by a + non-ECN-capable end-node transmitting packets with the ECT codepoint + set has been discussed in the section on "Non-compliance by the End + Nodes". + +23. IANA Considerations + + This section contains the namespaces that have either been created in + this specification, or the values assigned in existing namespaces + managed by IANA. + +23.1. IPv4 TOS Byte and IPv6 Traffic Class Octet + + The codepoints for the ECN Field of the IP header are specified by + the Standards Action of this RFC, as is required by RFC 2780. + + When this document is published as an RFC, IANA should create a new + registry, "IPv4 TOS Byte and IPv6 Traffic Class Octet", with the + namespace as follows: + + IPv4 TOS Byte and IPv6 Traffic Class Octet + + Description: The registrations are identical for IPv4 and IPv6. + + Bits 0-5: see Differentiated Services Field Codepoints Registry + (http://www.iana.org/assignments/dscp-registry) + + + + + + + + + + +Ramakrishnan, et al. Standards Track [Page 60] + +RFC 3168 The Addition of ECN to IP September 2001 + + + Bits 6-7, ECN Field: + + Binary Keyword References + ------ ------- ---------- + 00 Not-ECT (Not ECN-Capable Transport) [RFC 3168] + 01 ECT(1) (ECN-Capable Transport(1)) [RFC 3168] + 10 ECT(0) (ECN-Capable Transport(0)) [RFC 3168] + 11 CE (Congestion Experienced) [RFC 3168] + +23.2. TCP Header Flags + + The codepoints for the CWR and ECE flags in the TCP header are + specified by the Standards Action of this RFC, as is required by RFC + 2780. + + When this document is published as an RFC, IANA should create a new + registry, "TCP Header Flags", with the namespace as follows: + + TCP Header Flags + + The Transmission Control Protocol (TCP) included a 6-bit Reserved + field defined in RFC 793, reserved for future use, in bytes 13 and 14 + of the TCP header, as illustrated below. The other six Control bits + are defined separately by RFC 793. + + 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 + +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ + | | | U | A | P | R | S | F | + | Header Length | Reserved | R | C | S | S | Y | I | + | | | G | K | H | T | N | N | + +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ + + RFC 3168 defines two of the six bits from the Reserved field to be + used for ECN, as follows: + + 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 + +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ + | | | C | E | U | A | P | R | S | F | + | Header Length | Reserved | W | C | R | C | S | S | Y | I | + | | | R | E | G | K | H | T | N | N | + +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ + + + + + + + + + + +Ramakrishnan, et al. Standards Track [Page 61] + +RFC 3168 The Addition of ECN to IP September 2001 + + + TCP Header Flags + + Bit Name Reference + --- ---- --------- + 8 CWR (Congestion Window Reduced) [RFC 3168] + 9 ECE (ECN-Echo) [RFC 3168] + +23.3. IPSEC Security Association Attributes + + IANA allocated the IPSEC Security Association Attribute value 10 for + the ECN Tunnel use described in Section 9.2.1.2 above at the request + of David Black in November 1999. The IANA has changed the Reference + for this allocation from David Black's request to this RFC. + +24. Authors' Addresses + + K. K. Ramakrishnan + TeraOptic Networks, Inc. + + Phone: +1 (408) 666-8650 + EMail: kk@teraoptic.com + + + Sally Floyd + ACIRI + + Phone: +1 (510) 666-2989 + EMail: floyd@aciri.org + URL: http://www.aciri.org/floyd/ + + + David L. Black + EMC Corporation + 42 South St. + Hopkinton, MA 01748 + + Phone: +1 (508) 435-1000 x75140 + EMail: black_david@emc.com + + + + + + + + + + + + + +Ramakrishnan, et al. Standards Track [Page 62] + +RFC 3168 The Addition of ECN to IP September 2001 + + +25. Full Copyright Statement + + Copyright (C) The Internet Society (2001). 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. + + + + + + + + + + + + + + + + + + + +Ramakrishnan, et al. Standards Track [Page 63] + |