--- 1/draft-ietf-tsvwg-ecn-03.txt 2006-02-05 01:44:56.000000000 +0100 +++ 2/draft-ietf-tsvwg-ecn-04.txt 2006-02-05 01:44:56.000000000 +0100 @@ -1,19 +1,19 @@ Internet Engineering Task Force K. K. Ramakrishnan INTERNET DRAFT TeraOptic Networks -draft-ietf-tsvwg-ecn-03.txt Sally Floyd +draft-ietf-tsvwg-ecn-04.txt Sally Floyd ACIRI D. Black EMC - March, 2001 - Expires: September, 2001 + June, 2001 + Expires: December, 2001 The Addition of Explicit Congestion Notification (ECN) to IP Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that @@ -40,61 +40,77 @@ 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. + 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. - 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. - One of the guiding principles for this document is that all the - mechanisms specified here are incrementally deployable. + This document is intended to obsolete RFC 2481, "A Proposal to add + Explicit Congestion Notification (ECN) to IP", which defined ECN as + an Experimental Protocol for the Internet Community. + + RFC EDITOR - REMOVE THE FOLLOWING PARAGRAPH ON PUBLICATION - This + document also obsoletes three subsequent internet-drafts on ECN, + "IPsec Interactions with ECN", "ECN Interactions with IP Tunnels", + and "TCP with ECN: The Treatment of Retransmitted Data Packets". + This document also updates RFC 2401 on "Security Architecture for the + Internet Protocol". Table of Contents 1. Introduction 2. Conventions and Acronyms 3. Assumptions and General Principles 4. Active Queue Management (AQM) 5. Explicit Congestion Notification in IP 5.1. ECN as an Indication of Persistent Congestion 5.2. Dropped or Corrupted Packets 5.3. Fragmentation 6. Support from the Transport Protocol 6.1. TCP 6.1.1 TCP Initialization - 6.1.1.1. Robust TCP Initialization with an Echoed Reserve Field + 6.1.1.1. Middlebox Issues + 6.1.1.2. Robust TCP Initialization with an Echoed Reserved Field 6.1.2. The TCP Sender 6.1.3. The TCP Receiver 6.1.4. Congestion on the ACK-path 6.1.5. Retransmitted TCP packets 6.1.6. TCP Window Probes. 7. Non-compliance by the End Nodes 8. Non-compliance in the Network 8.1. Complications Introduced by Split Paths 9. Encapsulated Packets 9.1. IP packets encapsulated in IP 9.1.1. The Limited-functionality and Full-functionality Options 9.1.2. Changes to the ECN Field within an IP Tunnel. 9.2. IPsec Tunnels 9.2.1. Negotiation between Tunnel Endpoints 9.2.1.1. ECN Tunnel Security Association Database Field 9.2.1.2. ECN Tunnel Security Association Attribute 9.2.1.3. Changes to IPsec Tunnel Header Processing 9.2.2. Changes to the ECN Field within an IPsec Tunnel. 9.2.3. Comments for IPsec Support - 9.3. IP packets encapsulated in non-IP packet headers. + 9.3. IP packets encapsulated in non-IP Packet Headers. 10. Issues Raised by Monitoring and Policing Devices 11. Evaluations of ECN 11.1. Related Work Evaluating ECN 11.2. A Discussion of the ECN nonce. 11.2.1. The Incremental Deployment of ECT(1) in Routers. 12. Summary of changes required in IP and TCP 13. Conclusions 14. Acknowledgements 15. References 16. Security Considerations @@ -110,25 +126,41 @@ 19. Implications of Subverting End-to-End Congestion Control 19.1. Implications for the Network and for Competing Flows 19.2. Implications for the Subverted Flow 19.3. Non-ECN-Based Methods of Subverting End-to-end Congestion Control 20. The Motivation for the ECT Codepoints. 20.1. The Motivation for an ECT Codepoint. 20.2. The Motivation for two ECT Codepoints. 21. Why use Two Bits in the IP Header? 22. Historical Definitions for the IPv4 TOS Octet 23. IANA Considerations + 23.1. IPv4 TOS Byte and IPv6 Traffic Class Octet + 23.2. TCP Header Flags + 23.3. IPSEC Security Association Attributes -RFC EDITOR - REMOVE THE FOLLOWING PARAGRAPH ON PUBLICATION - To compare -this with draft-ietf-tsvwg-ecn-02, compare the following: -"http://www.aciri.org/floyd/papers/draft-ietf-tsvwg-ecn-02.troff" +RFC EDITOR - REMOVE THE FOLLOWING PARAGRAPH ON PUBLICATION - +To compare this with draft-ietf-tsvwg-ecn-03, compare the following: "http://www.aciri.org/floyd/papers/draft-ietf-tsvwg-ecn-03.troff" +"http://www.aciri.org/floyd/papers/draft-ietf-tsvwg-ecn-04.troff" +Changes from draft-ietf-tsvwg-ecn-03: + An expanded section on IANA Considerations. + Added back the section on "Middlebox Issues" about devices that either +drop an ECN-setup SYN packet or respond with a RST. + Clarified MUSTs and SHOULDs for limited-functionality and full- +functionality modes of tunnels. + Changed "should" to "MUST" for the sentence about not using ECT with +pure ACK TCP packets. + Specified that ECN status is ignored in TCP once TIME-WAIT state is +entered. + Moved notes to the RFC editor about obsoleted documents to the +beginning of this document. + Some minor rephrasing for clarity. Changes from draft-ietf-tsvwg-ecn-02: Revised Section 5.3 on fragmentation. Changes from draft-ietf-tsvwg-ecn-01: Added the ECT(1) codepoint, and changed references about bits to references about codepoints in many places. Also added Section 11.2 on "A Discussion of the ECN nonce", and Section 20.2 on "The Motivation for two ECT Codepoints". Added a paragraph saying that by default, the discussion of setting the CE codepoint applies to all Differentiated Services Per-Hop Behaviors. @@ -185,37 +218,35 @@ 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 queueing 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. + 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. + This document is intended to obsolete RFC 2481, "A Proposal to add Explicit Congestion Notification (ECN) to IP", which defined ECN as an Experimental Protocol for the Internet Community. - RFC EDITOR - REMOVE THE FOLLOWING PARAGRAPH ON PUBLICATION - This - document obsoletes three subsequent internet-drafts on ECN, "IPsec - Interactions with ECN", "ECN Interactions with IP Tunnels", and "TCP - with ECN: The Treatment of Retransmitted Data Packets". This - document is intended largely to merge the earlier documents all into - a single document, for greater clarity, in preparation to becoming a - Proposed Standard. - 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 [B97]. + 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 @@ -300,41 +330,42 @@ 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 The ECT and CE bits defined in RFC 2481. + 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. Backwards - compatibility with earlier ECN implementations that do not understand - the ECT(1) codepoint is discussed in Section 11. + 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 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. @@ -518,21 +549,21 @@ 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: * 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 reassmembled, for any + * 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- @@ -572,27 +603,30 @@ 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 - [RFC 2001]. + [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. @@ -689,21 +722,23 @@ 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: + 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. * 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. @@ -715,21 +751,72 @@ 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. -6.1.1.1. Robust TCP Initialization with an Echoed Reserve Field + 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. + + 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 possi- + ble: + + (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. @@ -849,29 +937,28 @@ 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) should 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. + 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 @@ -1022,20 +1109,24 @@ 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. 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 accidentially 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 @@ -1074,21 +1165,21 @@ 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 conclude as + 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 @@ -1122,42 +1213,45 @@ 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. + 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, especially IPsec tunnels: + 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. @@ -1162,21 +1256,21 @@ ECN and IP tunnels. 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 non-ECT codepoint to be set in the outside (encapsulating) + 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 @@ -1210,27 +1304,30 @@ (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 an IPsec 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. + 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). @@ -1319,36 +1416,32 @@ 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 either - the limited-functionality or the full-functionality mode outlined in - Section 9.1.1. + 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. All IPsec - implementations MUST implement either the limited-functionality or - the full-functionality alternative in order to eliminate - incompatibility between ECN and IPsec tunnels, but implementers MAY - choose to implement either alternative. + 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. The IPsec protocol, as defined in [ESP, AH], does not include the IP @@ -1574,21 +1668,21 @@ 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. -9.3. IP packets encapsulated in non-IP packet headers. +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. @@ -1714,63 +1808,61 @@ 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. - When ECN (Explicit Congestion Notification [RFC2481]) 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. + 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. - All IP tunnels MUST implement one of the two alternative approaches - described above. 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]. + 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 is intended to obsolete 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, + 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 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 @@ -1825,55 +1917,60 @@ 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 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. + 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 draft. + 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. - [B97] Bradner, S., "Key words for use in RFCs to Indicate Requirement - Levels", BCP 14, RFC 2119, March 1997. - [ECN] "The ECN Web Page", URL "http://www.aciri.org/floyd/ecn.html". Reference for informational purposes only. [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. @@ -1882,32 +1979,33 @@ 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] S. Hanks, T. Li, D. Farinacci, 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, URL - "http://www.cs.ucla.edu/~hari/software/ecn/ ecn_report.ps.gz". + benefits for TCP", Master's thesis, UCLA, 1998. Citation for + acknowledgement purposes only. [L2TP] W. Townsley, A. Valencia, A. Rubens, G. Pall, G. Zorn, and B. - Palter Layer Two Tunneling Protocol "L2TP", RFC 2661, August 1999. + Palter, Layer Two Tunneling Protocol "L2TP", RFC 2661, August 1999. [MJV96] S. McCanne, V. Jacobson, and M. Vetterli, "Receiver-driven Layered Multicast", SIGCOMM '96, August 1996, pp. 117-130. [MPLS] D. Awduche, J. Malcolm, J. Agogbua, M. O'Dell, 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, @@ -1982,20 +2080,24 @@ 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. + [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 @@ -2069,21 +2171,21 @@ 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 + 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 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. @@ -2139,22 +2242,23 @@ 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. In the case of IPsec tunnels, the IPsec - tunnel protects the transport header. + 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 @@ -2204,22 +2308,21 @@ 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 within an - IPsec tunnel. + 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 @@ -2365,23 +2468,24 @@ nodes. 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 queueing delays because of active queue management policies). When the packet flows - through a 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. + 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. @@ -2512,22 +2616,22 @@ 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 other purposes. For clarity, we briefly - list those possible purposes here. + 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 signalled 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 @@ -2550,23 +2654,24 @@ 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). 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 within tunnels - configured for full ECN functionality. Limited ECN functionality may - be used instead, although in practice many tunnel protocols + 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 @@ -2609,21 +2714,21 @@ 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 non-ECT codepoint should be the default. In + 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 @@ -2682,22 +2787,21 @@ 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 - +-----+-----+-----+-----+-----+-----+-----+-----+ + +-----+-----+-----+-----+-----+-----+-----+-----+ 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. 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 @@ -2711,38 +2815,103 @@ 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 - The codepoints for the ECN Field of the IP header and the bits for - CWR and ECE in the TCP header are specified by the Standards Action - of this RFC, as is required by RFC 2780. + 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 draft 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) + + Bits 6-7, ECN Field: + + Binary Keyword References + ------ ------- ---------- + 00 Not-ECT (Not ECN-Capable Transport) [RFC xxx] + 01 ECT(1) (ECN-Capable Transport(1)) [RFC xxx] + 10 ECT(0) (ECN-Capable Transport(0)) [RFC xxx] + 11 CE (Congestion Experienced) [RFC xxx] + +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 draft 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 xxx 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 | + +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ + + TCP Header Flags + + Bit Name Reference + --- ---- --------- + 8 CWR (Congestion Window Reduced) [RFC xxx] + 9 ECE (ECN-Echo) [RFC xxx] + +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. If this draft is approved for - publication as an RFC, IANA should change the Reference for this - allocation from David Black's request to this RFC based on its RFC - number. + of David Black in November 1999. When this draft is published as an + RFC, IANA should change the Reference for this allocation from David + Black's request to this RFC based on its RFC number. AUTHORS' ADDRESSES K. K. Ramakrishnan TeraOptic Networks, Inc. Phone: +1 (408) 666-8650 Email: kk@teraoptic.com - Sally Floyd Phone: +1 (510) 666-2989 ACIRI Email: floyd@aciri.org URL: http://www.aciri.org/floyd/ David L. Black EMC Corporation 42 South St. Hopkinton, MA 01748 @@ -2742,12 +2911,12 @@ 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 - This draft was created in March 2001. - It expires September 2001. + This draft was created in June 2001. + It expires December 2001.