idnits 2.17.1 draft-ietf-tsvwg-ecn-tunnels-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 12 longer pages, the longest (page 2) being 60 lines == It seems as if not all pages are separated by form feeds - found 0 form feeds but 13 pages Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** The abstract seems to contain references ([PPTP], [RFC2481], [RFC2003], [GRE], [MPLS], [RFD99], [L2TP]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 237: '... addition, it is RECOMMENDED that pack...' RFC 2119 keyword, line 338: '... It is RECOMMENDED that such packets...' Miscellaneous warnings: ---------------------------------------------------------------------------- -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (October 2000) is 8595 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'RFC 2481' is mentioned on line 66, but not defined ** Obsolete undefined reference: RFC 2481 (Obsoleted by RFC 3168) == Missing Reference: 'IPsecECN' is mentioned on line 446, but not defined == Unused Reference: 'FF98' is defined on line 464, but no explicit reference was found in the text == Unused Reference: 'RFC 2401' is defined on line 492, but no explicit reference was found in the text == Unused Reference: 'RFC2407' is defined on line 495, but no explicit reference was found in the text == Unused Reference: 'RFC1701' is defined on line 505, but no explicit reference was found in the text == Unused Reference: 'RFC1702' is defined on line 508, but no explicit reference was found in the text -- Possible downref: Non-RFC (?) normative reference: ref. 'FF98' ** Downref: Normative reference to an Informational RFC: RFC 1701 (ref. 'GRE') ** Downref: Normative reference to an Informational RFC: RFC 2702 (ref. 'MPLS') ** Downref: Normative reference to an Informational RFC: RFC 2637 (ref. 'PPTP') -- Possible downref: Non-RFC (?) normative reference: ref. 'RFD99' ** Obsolete normative reference: RFC 2401 (Obsoleted by RFC 4301) ** Obsolete normative reference: RFC 2407 (Obsoleted by RFC 4306) ** Obsolete normative reference: RFC 2481 (Obsoleted by RFC 3168) -- Duplicate reference: RFC1701, mentioned in 'RFC1701', was also mentioned in 'GRE'. ** Downref: Normative reference to an Informational RFC: RFC 1701 ** Downref: Normative reference to an Informational RFC: RFC 1702 -- Possible downref: Non-RFC (?) normative reference: ref. 'SCWA99' Summary: 16 errors (**), 0 flaws (~~), 10 warnings (==), 6 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Internet Engineering Task Force S. Floyd 2 INTERNET DRAFT K. K. Ramakrishnan 3 draft-ietf-tsvwg-ecn-tunnels-00.txt D. Black 4 October 2000 6 ECN Interactions with IP Tunnels 8 Status of this Memo 10 This document is an Internet-Draft and is in full conformance with 11 all provisions of Section 10 of RFC2026. 13 Internet-Drafts are working documents of the Internet Engineering 14 Task Force (IETF), its areas, and its working groups. Note that 15 other groups may also distribute working documents as Internet- 16 Drafts. 18 Internet-Drafts are draft documents valid for a maximum of six months 19 and may be updated, replaced, or obsoleted by other documents at any 20 time. It is inappropriate to use Internet- Drafts as reference 21 material or to cite them other than as "work in progress." 23 The list of current Internet-Drafts can be accessed at 24 http://www.ietf.org/ietf/1id-abstracts.txt 26 The list of Internet-Draft Shadow Directories can be accessed at 27 http://www.ietf.org/shadow.html. 29 Abstract 31 The encapsulation of IP packet headers in tunnels is used in many 32 places, including IPsec and IP in IP [RFC2003]. Explicit Congestion 33 Notification (ECN) is an experimental addition to the IP architecture 34 that uses the ECN field in the IP header to provide an indication of 35 the onset of congestion to applications. ECN provides this 36 congestion indication to enable end-node adaptation to network 37 conditions without the use of dropped packets [RFC 2481]. Currently, 38 the ECN specification does not accommodate the constraints imposed by 39 some of these pre-existing specifications for tunnels. This document 40 considers issues related to interactions between ECN and IP tunnels, 41 and proposes two alternative solutions. 43 A different set of issues are raised, relative to ECN, when IP 44 packets are encapsulated in tunnels with non-IP packet headers. This 45 occurs with MPLS [MPLS], GRE [GRE], L2TP [L2TP], and PPTP [PPTP]. 46 For these protocols, there is no conflict with ECN; it is just that 47 ECN cannot be used within the tunnel unless an ECN codepoint can be 48 specified for the header of the encapsulating protocol. [RFD99] 49 presents a proposal for incorporating ECN into MPLS, and proposals 50 for incorporating ECN into GRE, L2TP, or PPTP will be considered as 51 the need arises. 53 1. Introduction. 55 Some IP tunnel modes are based on adding a new "outer" IP header that 56 encapsulates the original, or "inner" IP header and its associated 57 packet. In many cases, the new "outer" IP header may be added and 58 removed at intermediate points along a connection, enabling the 59 network to establish a tunnel without requiring endpoint 60 participation. We denote tunnels that specify that the outer header 61 be discarded at tunnel egress as ``simple tunnels''. 63 Explicit Congestion Notification (ECN) is an experimental addition to 64 the IP architecture that provides congestion indication to end-nodes 65 to enable them to adapt to network conditions without requiring the 66 packet to be dropped [RFC 2481]. An ECN-capable router uses the ECN 67 mechanism to signal congestion to connection endpoints by setting a 68 bit in the IP header. These endpoints then react, in terms of 69 congestion control, as if a packet had been dropped (e.g., TCP halves 70 its congestion window). This ability to avoid dropping packets in 71 response to congestion is supported by the use of active queue 72 management mechanisms (e.g., RED) in routers; such mechanisms begin 73 to mark or drop packets as a consequence of congestion before the 74 congested router queue is completely full. ECN is defined to be used 75 as an optimization -- routers are not required to support ECN, and 76 even an ECN-capable router may drop packets from ECN-capable 77 connections when necessary. The advantage to a router of not 78 dropping such packets is that ECN can provide a more timely 79 indication of congestion to the end nodes than indications based on 80 packet drops being detected by duplicate ACKs or timeout. As a 81 result, the queues at the router are better managed. 83 Currently, the ECN specification does not interact appropriately with 84 simple IP tunnels. Current use of ECN over simple IP tunnels results 85 in routers attempting to use the outer IP header to signal congestion 86 to endpoints, but those congestion warnings never arrive because the 87 outer header is discarded at the tunnel egress point. It is 88 desirable for the tunnel egress point to recognize the use of ECN on 89 the inner IP header. This problem was encountered with ECN and IPsec 90 in tunnel mode, and RFC 2481 recommends that ECN not be used with the 91 older simple IPsec tunnels in order to avoid this behavior and its 92 consequences. 94 This document considers issues related to interactions between ECN 95 and IP tunnels and proposes solutions. From a security point of 96 view, the use of ECN in the outer header of an IP tunnel might raise 97 security concerns because an adversary could tamper with the ECN 98 information that propagates beyond the tunnel endpoint. Based on an 99 analysis of these concerns and the resultant risks [IPsecECN], our 100 overall approach is to make support for ECN an option for IP tunnels, 101 so that an IP tunnel can be specified or configured either to use ECN 102 or not to use ECN in the outer header of the tunnel. Thus, in 103 environments or tunneling protocols where the risks of using ECN are 104 judged to outweigh its benefits, the tunnel can simply not use ECN in 105 the outer header. Then the only indication of congestion experienced 106 at routers within the tunnel would be through packet loss. 108 The result is that there are two viable options for the behavior of 109 ECN-capable connections over an IP tunnel, especially IPSec tunnels: 110 - A limited-functionality option in which ECN is preserved in the 111 inner header, but disabled in the outer header. The only 112 mechanism available for signaling congestion occurring within the 113 tunnel in this case is dropped packets. 114 - A full functionality option that supports ECN in both the inner 115 and outer headers, and propagates congestion warnings from nodes 116 within the tunnel to endpoints. 117 Support for these options requires varying amounts of changes to IP 118 header processing at tunnel ingress and egress. A small subset of 119 these changes sufficient to support only the limited-functionality 120 option would be sufficient to eliminate any incompatibility between 121 ECN and IP tunnels. 123 One goal of this document is to give guidance about the tradeoffs 124 between the limited-functionality and full-functionality options. A 125 full discussion of the potential effects of an adversary's 126 modifications of the CE and ECT bits is given in [IPsecECN]. This 127 document draws heavily on [IPsecECN], both in terms of the approach 128 and the text itself. 130 2. Architecture. 132 ECN uses two bits in the IP header, the ECT bit (ECN-Capable 133 Transport) and the CE bit (Congestion Experienced), for signaling 134 between routers and connection endpoints, and uses two flags in the 135 TCP header, the ECN-Echo bit (to Echo the ECN bit in IP header) and 136 the CWR bit (Congestion Window Reduced) for TCP-endpoint to TCP- 137 endpoint signaling. For a TCP connection, a typical sequence of 138 events in an ECN-based reaction to congestion is as follows: 140 - The ECT bit is set in packets transmitted by the sender to 141 indicate that ECN is supported on this TCP connection. 142 - An ECN-capable router detects impending congestion and detects 143 that the ECT bit is set in the packet it is about to drop. 144 Instead of dropping the packet, the router sets the CE bit and 145 forwards the packet. 146 - The receiver receives the packet with CE set, and sets the ECN- 147 Echo flag in its next TCP ACK sent to the sender. 148 - The sender receives the TCP ACK with ECN-Echo set, and reacts to 149 the congestion as if a packet had been dropped. 150 - The sender sets the CWR flag in the TCP header of the next 151 packet sent to the receiver to acknowledge its receipt of and 152 reaction to the ECN-Echo flag. 154 Further details on ECN functionality, including negotiation of ECN- 155 capability as part of TCP connection setup as well as the 156 responsibilities and requirements of ECN-capable routers and 157 transports, can be found in [RFC2481]. 159 ECN interacts with IP tunnels because the two ECN bits are in the DS 160 field octet in the IP header [RFC2474] (also referred to as the IPv4 161 TOS octet or IPv6 Traffic Class octet). The DS field octet is 162 generally copied or mapped from the inner IP header to the outer IP 163 header at IP tunnel ingress, and in simple IP tunnels the outer 164 header's copy of this field is discarded at IP tunnel egress. If an 165 ECN-capable router were to set the CE (Congestion Experienced) bit 166 within a packet in a simple IP tunnel, this indication would be 167 discarded at tunnel egress, losing the indication of congestion. As 168 a consequence of this behavior, ECN usage within a simple IP tunnels 169 (with no changes at the ingress and egress) is not recommended. 171 The limited-functionality option for ECN encapsulation in IP tunnels 172 is for the ECT bit in the outside (encapsulating) header to be off 173 (i.e., set to 0), regardless of the value of the ECT bit in the 174 inside (encapsulated) header. With this option, the ECN field in the 175 inner header is not altered upon de-capsulation. The disadvantage of 176 this approach is that the flow does not have ECN support for that 177 part of the path that is using IP tunneling, even if the encapsulated 178 packet is ECN-Capable. That is, if the encapsulated packet arrives 179 at a congested router that is ECN-capable, and the router can decide 180 to drop or mark the packet as an indication of congestion to the end 181 nodes, the router will not be permitted to set the CE bit in the 182 packet header, but instead will have to drop the packet. 184 The IP full-functionality option for ECN encapsulation follows the 185 description in Section 10.1 of RFC 2481 of tunneling with ECN. This 186 option is to copy the ECT bit of the inside header to the outside 187 header on encapsulation, and to OR the CE bit from the outer header 188 with the CE bit of the inside header on decapsulation. With the 189 full-functionality option, a flow can take advantage of ECN for those 190 parts of the path that might use IP tunneling. The disadvantage of 191 the full-functionality option from a security perspective is that the 192 IP tunnel cannot protect the flow from certain modifications to the 193 ECN bits in the IP header within the tunnel. The potential dangers 194 from modifications to the ECN bits in the IP header are described in 195 detail in [IPsecECN]. 197 This document proposes either the limited-functionality or full- 198 functionality option for IP tunnels in order to enable ECN 199 experimentation over IP tunnels, and avoid losing congestion 200 indications in the case that an ECN-capable router or routers are 201 traversed by an IP tunnel carrying ECN-capable connections. In 202 summary, two changes are proposed to IP tunnel functionality: 204 (1) Modify the handling of the DS field octet at IP tunnel 205 endpoints by implementing either the limited-functionality or the 206 full-functionality option. 207 (2) Optionally, enable the endpoints of an IP tunnel to negotiate 208 the choice between the limited-functionality and the full- 209 functionality option for ECN in the tunnel. 211 The minimum required to make ECN usable with IP tunnels is the 212 limited-functionality option, which prevents ECN from being enabled 213 in the outer header of an IPsec tunnel. Full support for ECN 214 requires the use of the full-functionality option. Optional 215 mechanisms to negotiate a choice between the tunnel endpoints of 216 either the limited-functionality or full-functionality option are not 217 discussed in this document. We assume that there is a pre-existing 218 agreement between the tunnel endpoints about whether to support the 219 limited-functionality or the full-functionality ECN option. 221 The two ECN bits in the IP header, ECT and CE, occupy bits 6 and 7 of 222 the DS Field octet [RFC2481]. For full ECN support the encapsulation 223 and decapsulation processing for the DS field octet involves the 224 following: At tunnel ingress, the full-functionality option copies 225 the value of ECT (bit 6) in the inner header to the outer header. CE 226 (bit 7) is set to 0 in the outer header. At tunnel egress, the full- 227 functionality option sets CE to 1 in the inner header if the value of 228 ECT (bit 6) in the inner header is 1, and the value of CE (bit 7) in 229 the outer header is 1. Otherwise, no change is made to this field of 230 the inner header. 232 For the limited-functionality option, at tunnel ingress bits 6 and 7 233 (ECT and CE) of the DS field in the outer header are set to zero, and 234 at tunnel egress no change is made to the DS field in the inner 235 header. 237 In addition, it is RECOMMENDED that packets with ECN and CE both set 238 to 1 in the outer header be dropped if they arrive on an tunnel 239 egress for a tunnel that uses the limited-functionality option, or 240 for a tunnel that uses the full-functionality option but for which 241 the ECT bit in the inner header is set to zero. This is motivated by 242 backwards compatibility and to ensure that no unauthorized 243 modifications of the ECN field takes place and is discussed further 244 in Section 6. 246 4. Possible Changes to the ECN Field 248 This section considers the issues when a router is operating, 249 possibly maliciously, to modify either of the bits in the ECN field. 250 In this section we represent the ECN field in the IP header by the 251 tuple (ECT bit, CE bit). The ECT bit, when set to 1, indicates an 252 ECN-Capable Transport. The CE bit, when set to 1, indicates that 253 Congestion was Experienced in the path. 255 By tampering with the bits in the ECN field, an adversary (or a 256 broken router) could do one or more of the following: falsely report 257 congestion, disable ECN-Capability for an individual packet, erase 258 the ECN congestion indication, or falsely indicate ECN-Capability. 259 [IPsecECN] systematically examines the various cases by which the ECN 260 field could be modified. The important criterion considered in 261 determining the consequences of such modifications is whether it is 262 likely to lead to poorer behavior in any dimension (throughput, 263 delay, fairness or functionality) than if a router were to drop a 264 packet. 266 The first two possible changes, falsely report congestion or 267 disabling ECN-Capability for an individual packet, are no worse than 268 if the router were to simply drop the packet. However, as discussed 269 in Section 5 below, a router that erases the ECN congestion 270 indication or falsely indicates ECN-Capability could potentially do 271 more damage to the flow that if it has simply dropped the packet. 273 5. Implications of Subverting End-to-End Congestion Control 275 This section considers the potential repercussions of subverting end- 276 to-end congestion control by either falsely indicating ECN- 277 Capability, or by erasing the congestion indication in ECN (the CE- 278 bit). Subverting end-to-end congestion control by either of these 279 two methods can have consequences both for the application and for 280 the network. 282 The first method to subvert end-to-end congestion control, falsely 283 indicating ECN-Capability, effectively subverts end-to-end congestion 284 control only if the packet would later encounter congestion that 285 results in the setting of the CE bit. In this case, the transport 286 protocol (which itself was not ECN capable) does not react 287 appropriately to the indication of congestion from these downstream 288 congested routers. It would have been better for these downstream 289 congested routers to drop the packet instead. 291 The second method to subvert end-to-end congestion control, `erasing' 292 the (set) CE bit in a packet, effectively subverts end-to-end 293 congestion control only when the CE bit in the packet was set earlier 294 by a congested router. In this case, the transport protocol does not 295 receive the indication of congestion from the upstream congested 296 routers. 298 Either of these two methods of subverting end-to-end congestion 299 control can potentially introduce more damage to the network (and 300 possibly to the flow itself) than if the adversary had simply dropped 301 packets from that flow. However, as we discuss in the subsequent 302 sections, this potential damage is limited. This is also discussed 303 extensively in [IPsecECN]. 305 6. Changes to the ECN Field within an IP Tunnel. 307 The presence of a copy of the ECN field in the inner header of an IP 308 tunnel mode packet provides an opportunity for detection of 309 unauthorized modifications to the ECT bit in the outer header. 310 Comparison of the ECT bits in the inner and outer headers falls into 311 two categories for implementations that conform to this document: 312 (a) If the IP tunnel uses the full-functionality option, then the 313 values of the ECT bits in the inner and outer headers should be 314 identical. 315 (b) If the tunnel uses the limited-functionality option, then the 316 ECT bit in the outer header should be 0. 318 Receipt of a packet not satisfying the appropriate condition could be 319 a cause of concern. 321 Consider the case of an IP tunnel where the tunnel ingress point has 322 not been updated to this document's requirements, while the tunnel 323 egress point has been updated to support ECN. In this case, the IP 324 tunnel is not explicitly configured to support the full-functionality 325 ECN option. However, the tunnel ingress point is behaving identically 326 to a tunnel ingress point that supports the full-functionality 327 option. If packets from an ECN-capable connection use this tunnel, 328 ECT will be set to 1 in the outer header at the tunnel ingress point. 329 Congestion within the tunnel may then result in ECN-capable routers 330 setting CE in the outer header. Because the tunnel has not been 331 explicitly configured to support the full-functionality option, the 332 tunnel egress point expects the ECT bit in the outer header to be 0. 334 When an ECN-capable tunnel egress point receives a packet with the 335 ECT bit in the outer header set to 1, in a tunnel that has not been 336 configured to support the full-functionality option, that packet 337 should be processed, according to whether CE bit was set, as follows. 338 It is RECOMMENDED that such packets, with the ECT bit set to 1 on a 339 tunnel that has not been configured to support the full-functionality 340 option, be dropped at the egress point if CE is set to 1 in the outer 341 header but 0 in the inner header, and forwarded otherwise. 343 An IP tunnel cannot provide protection against erasure of congestion 344 indications based on resetting the value of the CE bit in packets for 345 which ECT is set in the outer header. The erasure of congestion 346 indications may impact the network and other flows in ways that would 347 not be possible in the absence of ECN. It is important to note that 348 erasure of congestion indications can only be performed to congestion 349 indications placed by nodes within the tunnel; the copy of the CE bit 350 in the inner header preserves congestion notifications from nodes 351 upstream of the tunnel ingress. If erasure of congestion 352 notifications is judged to be a security risk that exceeds the 353 congestion management benefits of ECN, then tunnels could be 354 specified or configured to use the limited-functionality option. 356 7. Issues Raised by Monitoring and Policing Devices 358 One possibility is that monitoring and policing devices (or more 359 informally, ``penalty boxes'') will be installed in the network to 360 monitor whether best-effort flows are appropriately responding to 361 congestion, and to preferentially drop packets from flows determined 362 not to be using adequate end-to-end congestion control procedures. 363 This is discussed in more detail in [IPsecECN] 365 For an ECN-capable flow, an `ideal' penalty box at a router would be 366 a device that, when it detected that a flow was not responding to ECN 367 indications, would switch to dropping, instead of marking, those 368 packets of a flow that would otherwise have been chosen to carry 369 indications of congestion. In this way, these congestion indications 370 could not be `erased' later in the network, and at the same time 371 there would be no change in the router's treatment of packets of 372 other flows. If a router determines that a flow is still not 373 responding to congestion indications when the congestion indications 374 consist of packet drops, then the router could take whatever further 375 action it deems appropriate for that flow. 377 We recommend that any ``penalty box'' that detects a flow or an 378 aggregate of flows that is not responding to end-to-end congestion 379 control first change from marking to dropping packets from that flow, 380 before taking any additional action to restrict the bandwidth 381 available to that flow. Thus, initially, the router may drop packets 382 in which the router would otherwise would have set the CE bit. This 383 could include dropping those arriving packets for that flow that are 384 ECN-Capable and that already have the CE bit set. In this way, any 385 congestion indications seen by that router for that flow will be 386 guaranteed to also be seen by the end nodes, even in the presence of 387 malicious or broken routers elsewhere in the path. If we assume that 388 the first action taken at any ``penalty box'' for an ECN-capable flow 389 will be to drop packets instead of marking them, then there is no way 390 that an adversary that subverts ECN-based end-to-end congestion 391 control can cause a flow to be characterized as being non-cooperative 392 and placed into a more severe action within the ``penalty box''. 394 If there were serious operational problems with routers 395 inappropriately erasing the CE bit in packet headers, one potential 396 fix would be to include a one-bit ECN nonce in packet headers, and 397 for routers to erase the nonce when they set the CE bit [SCWA99]. 398 Routers would be unable to consistently reconstruct the nonce when 399 they erased the CE bit, and thus the repeated erasure of the CE bit 400 would be detected by the end-nodes. (This could in fact be done 401 without adding any extra bits for ECN in the IP header, by using the 402 ECN codepoints (ECT=1, CE=0) and (ECT=0, CE=1) as the two values for 403 the nonce, and by defining the codepoint (ECT=0, CE=1) to mean 404 exactly the same as the codepoint (ECT=1, CE=0).) However, at this 405 point the potential danger does not seem of sufficient concern to 406 warrant this additional complication of adding an ECN nonce to 407 protect against the erasure of the CE bit. 409 7.1. Complications Introduced by Split Paths 411 If a router or other network element has access to all of the packets 412 of a flow, then that router could do no more damage to a flow by 413 altering the ECN field than it could by simply dropping all of the 414 packets from that flow. However, in some cases, a malicious or 415 broken router might have access to only a subset of the packets from 416 a flow. The question is as follows: can this router, by altering 417 the ECN field in this subset of the packets, do more damage to that 418 flow than if it has simply dropped that set of the packets? 420 This is also discussed in detail in [IPsecECN], which concludes as 421 follows: It is true that the adversary that has access only to the A 422 packets might, by subverting ECN-based congestion control, be able to 423 deny the benefits of ECN to the other packets in the A&B aggregate. 424 While this is undesireable, this is not a sufficient concern to 425 result in disabling ECN within an IP tunnel. 427 8. Conclusions. 429 When ECN (Explicit Congestion Notification [RFC2481]) is used, it is 430 desirable that congestion indications generated within an IP tunnel 431 not be lost at the tunnel egress. We propose a minor modification to 432 the IP protocol's handling of the ECN field during encapsulation and 433 de-capsulation to allow flows that will undergo IP tunneling to use 434 ECN. 436 Two options were proposed: 437 1) A preferred alternative, which is the full-functionality option as 438 described in RFC 2481. This copies the ECT bit of the inner header to 439 the encapsulating header. At decapsulation, if the ECT bit is set in 440 the inner header, the CE bit on the outer header is ORed with the CE 441 bit of the inner header to update the CE bit of the packet. 442 2) A limited-functionality option that does not use ECN inside the IP 443 tunnel, by turning the ECT bit in the outer header off, and not 444 altering the inner header at the time of decapsulation. 446 In [IPsecECN] we examined the consequence of modifications of the ECN 447 field within the tunnel, analyzing all the opportunities for an 448 adversary to change the ECN field. In many cases, the change to the 449 ECN field is no worse than dropping a packet. However, we noted that 450 some changes have the more serious consequence of subverting end-to- 451 end congestion control. However, we point out that even then the 452 potential damage is limited, and is similar to the threat posed by an 453 end-system intentionally failing to cooperate with end-to-end 454 congestion control. We therefore believe that with these changes it 455 is reasonable to use ECN with IP tunnels, as described in RFC 2481. 457 9. Acknowledgements 459 We thank Tabassum Bint Haque from Dhaka, Bangladesh, for feedback on 460 an earlier version of this draft. 462 10. References 464 [FF98] Floyd, S., and Fall, K., Promoting the Use of End-to-End 465 Congestion Control in the Internet, IEEE/ACM Transactions on 466 Networking, August 1999. URL "http://www- 467 nrg.ee.lbl.gov/floyd/end2end-paper.html". 469 [GRE] S. Hanks, T. Li, D. Farinacci, and P. Traina, Generic Routing 470 Encapsulation (GRE), RFC 1701, October 1994. URL 471 "http://www.ietf.cnri.reston.va.us/rfc/rfc1701.txt". 473 [L2TP] W. Townsley, A. Valencia, A. Rubens, G. Pall, G. Zorn, and B. 474 Palter Layer Two Tunneling Protocol "L2TP", RFC 2661, August 1999. 475 URL "ftp://ftp.isi.edu/in-notes/rfc2661.txt". 477 [MPLS] D. Awduche, J. Malcolm, J. Agogbua, M. O'Dell, J. McManus, 478 Requirements for Traffic Engineering Over MPLS, RFC 2702, September 479 1999. URL "ftp://ftp.isi.edu/in-notes/rfc2702.txt". 481 [PPTP] Hamzeh, K., Pall, G., Verthein, W., Taarud, J., Little, W. 482 and G. Zorn, "Point-to-Point Tunneling Protocol (PPTP)", RFC 2637, 483 July 1999. URL "ftp://ftp.isi.edu/in-notes/rfc2637.txt". 485 [RFD99] Ramakrishnan, Floyd, S., and Davie, B., A Proposal to 486 Incorporate ECN in MPLS, work in progress, June 1999. URL 487 "http://www.aciri.org/floyd/papers/draft-ietf-mpls-ecn-00.txt". 489 [RFC2003] Perkins, C., IP Encapsulation within IP, RFC 2003, October 490 1996. URL "http://www.ietf.cnri.reston.va.us/rfc/rfc2003.txt". 492 [RFC 2401] S. Kent, R. Atkinson, Security Architecture for the 493 Internet Protocol, RFC 2401, November 1998. 495 [RFC2407] D. Piper, The Internet IP Security Domain of Interpretation 496 for ISAKMP, RFC 2407, November 1998. 498 [RFC2474] K. Nichols, S. Blake, F. Baker, D. Black, Definition of the 499 Differentiated Services Field (DS Field) in the IPv4 and IPv6 500 Headers, RFC 2474, December 1998. 502 [RFC2481] K. Ramakrishnan, S. Floyd, A Proposal to add Explicit 503 Congestion Notification (ECN) to IP, RFC 2481, January 1999. 505 [RFC1701] Hanks, S., Li, T., Farinacci, D., and P. Traina, Generic 506 Routing Encapsulation (GRE), RFC 1701, October 1994. 508 [RFC1702] Hanks, S., Li, T., Farinacci, D., and P. Traina, Generic 509 Routing Encapsulation over IPv4 networks, RFC 1702, October 1994. 511 [SCWA99] Stefan Savage, Neal Cardwell, David Wetherall, and Tom 512 Anderson, TCP Congestion Control with a Misbehaving Receiver, ACM 513 Computer Communications Review, October 1999. 515 11. Security Considerations 517 Security considerations have been addressed in the main body of the 518 document. 520 AUTHORS' ADDRESSES 522 Sally Floyd 523 AT&T Center for Internet Research at ICSI (ACIRI) 524 Phone: +1 (510) 666-2989 525 Email: floyd@aciri.org 526 URL: http://www-nrg.ee.lbl.gov/floyd/ 528 K. K. Ramakrishnan 529 TeraOptic Networks 530 Phone: +1 (408) 666-8650 531 Email: kk@teraoptic.com 533 David L. Black 534 EMC Corporation 535 42 South St. 536 Hopkinton, MA 01748 537 Phone: +1 (508) 435-1000 x75140 538 Email: black_david@emc.com 540 This draft was created in October 2000. 541 It expires April 2001.