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