idnits 2.17.1 draft-ietf-ipsec-ecn-02.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: ---------------------------------------------------------------------------- ** 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? ** The document is more than 15 pages and seems to lack a Table of Contents. == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 23 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 24 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 ([RFC2401], [RFC2481]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. 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 (December 1999) is 8896 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 176, but not defined ** Obsolete undefined reference: RFC 2481 (Obsoleted by RFC 3168) == Missing Reference: 'RFC2119' is mentioned on line 136, but not defined == Missing Reference: 'RFC2401' is mentioned on line 377, but not defined ** Obsolete undefined reference: RFC 2401 (Obsoleted by RFC 4301) == Missing Reference: 'RFC 2474' is mentioned on line 353, but not defined == Unused Reference: 'RFC 2119' is defined on line 1027, but no explicit reference was found in the text -- Possible downref: Non-RFC (?) normative reference: ref. 'FF98' ** Obsolete normative reference: RFC 2401 (Obsoleted by RFC 4301) ** Obsolete normative reference: RFC 2407 (Obsoleted by RFC 4306) ** Downref: Normative reference to an Informational RFC: RFC 2475 ** Obsolete normative reference: RFC 2481 (Obsoleted by RFC 3168) == Outdated reference: A later version (-04) exists of draft-bradner-iana-allocation-03 Summary: 12 errors (**), 0 flaws (~~), 9 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Internet Engineering Task Force Sally Floyd 2 INTERNET DRAFT David Black 3 draft-ietf-ipsec-ecn-02.txt K. K. Ramakrishnan 4 December 1999 5 Expires: June 2000 7 IPsec Interactions with ECN 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 IPsec supports secure communication over potentially insecure network 33 components such as intermediate routers. IPsec protocols support two 34 operating modes, transport mode and tunnel mode. Explicit Congestion 35 Notification (ECN) is an experimental addition to the IP architecture 36 that provides notification of onset of congestion to delay- or loss- 37 sensitive applications. ECN provides congestion notifications to 38 enable adaptation to network conditions without the impact of dropped 39 packets [RFC 2481]. The use of two bits in the IP header for ECN 40 experimentation conflicts with header processing at IPsec tunnel 41 endpoints in a manner that makes ECN unusable in the presence of 42 IPsec tunnels. This document considers issues related to this 43 conflict, describes two alternative solutions, and updates the IPsec 44 architecture [RFC 2401] to include these alternatives. Support for 45 one or the other of these alternatives is REQUIRED to remove the 46 underlying conflict. 48 1. Introduction. 50 IPsec supports secure communication over potentially insecure network 51 components such as intermediate routers. IPsec protocols support two 52 operating modes, transport mode and tunnel mode, that span a wide 53 range of security requirements and operating environments. Transport 54 mode security protocol header(s) are inserted between the IP (IPv4 or 55 IPv6) header and higher layer protocol headers (e.g., TCP), and hence 56 transport mode can only be used for end-to-end security on a 57 connection. IPsec tunnel mode is based on adding a new "outer" IP 58 header that encapsulates the original, or "inner" IP header and its 59 associated packet. Tunnel mode security headers are inserted between 60 these two IP headers. In contrast to transport mode, the new "outer" 61 IP header and tunnel mode security headers can be added and removed 62 at intermediate points along a connection, enabling security gateways 63 to secure vulnerable portions of a connection without requiring 64 endpoint participation in the security protocols. An important 65 aspect of tunnel mode security is that the outer header is discarded 66 at tunnel egress, ensuring that security threats based on modifying 67 the IP header do not propagate beyond that tunnel endpoint. Further 68 discussion of IPsec can be found in [RFC 2401]. 70 Explicit Congestion Notification (ECN) is an experimental addition to 71 the IP architecture that provides congestion notifications to delay- 72 or loss-sensitive applications to enable them to adapt to network 73 conditions without the impact of dropped packets [RFC 2481]. An ECN- 74 capable router uses the ECN mechanism to signal congestion to 75 connection endpoints by setting a bit in the IP header. These 76 endpoints then react, in terms of congestion control, as if a packet 77 had been dropped (e.g., TCP halves its congestion window). This 78 ability to avoid dropping packets in response to congestion is 79 supported by the use of active queue management mechanisms (e.g., 80 RED) in routers; such mechanisms begin to mark or drop packets as a 81 consequence of congestion before a congested router queue is 82 completely full. ECN is an experimental optimization -- not all 83 routers may be expected to support ECN, and even ECN-capable routers 84 drop packets from ECN-capable connections when necessary. The 85 advantage to routers of not dropping such packets is that ECN can 86 provide a more timely reaction to congestion than reactions based on 87 drop detection via duplicate ACKs or timeout. 89 ECN as currently specified uses two bits within the IP header in a 90 manner that conflicts with current header processing at IPsec tunnel 91 endpoints. Use of ECN over an IPsec tunnel results in routers 92 attempting to use the outer IP header to signal congestion to 93 endpoints, but discarding of the outer header at tunnel egress also 94 discards those indications of congestion. RFC 2481 recommended that 95 ECN not be used with IPsec tunnels in order to avoid this behavior 96 and its undesirable consequences. This document updates the IPsec 97 architecture to remove that conflict. 99 In principle, permitting the use of ECN functionality in the outer 100 header of an IPsec tunnel raises security concerns because an 101 adversary could tamper with the information that propagates beyond 102 the tunnel endpoint. Based on an analysis (included in this 103 document) of these concerns and the associated risks, our overall 104 approach is to provide configuration support for the IPsec changes 105 that remove the conflict with ECN. This makes permission to use ECN 106 functionality in the outer header of an IPsec tunnel a configurable 107 part of the corresponding IPsec Security Association (SA), so that it 108 can be disabled in situations where the risks are judged to outweigh 109 the benefits. The result is that an IPsec security administrator is 110 presented with two alternatives for the behavior of ECN-capable 111 connections within an IPsec tunnel: 112 - A limited-functionality alternative in which the ECN bits are 113 preserved in the inner header, but ECN functionality is disabled 114 in the outer header. The only mechanism available for signaling 115 congestion occurring within the tunnel in this case is dropped 116 packets. 117 - A full functionality alternative that supports ECN in both the 118 inner and outer headers. This alternative propagates ECN 119 congestion notifications from nodes within the tunnel to endpoints 120 outside the tunnel. 121 Support for these alternatives involves changes to IP header 122 processing at tunnel ingress and egress. All IPsec implementations 123 MUST implement one of the above two alternatives in order to 124 eliminate the current incompatibility between ECN and IPsec tunnels, 125 but implementers MAY choose to implement either alternative. 127 The main goal of this document is to provide guidance about the 128 tradeoffs between the limited-functionality and full-functionality 129 alternatives. This includes a full discussion of the potential 130 effects of an adversary's modification to the two bits used by ECN in 131 the IP header. 133 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 134 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 135 document are to be interpreted as described in RFC 2119 [RFC2119] . 137 2. Architecture. 139 ECN as specified for experimental purposes uses two bits in the IP 140 header (ECT - ECN Capable Transport, and CE - Congestion Experienced) 141 for signaling between routers and connection endpoints, and uses two 142 flags in the TCP header (ECN-Echo - Echo ECN bit in IP header, CWR - 143 Congestion Window Reduced) for TCP-endpoint to TCP-endpoint 144 signaling. For a TCP connection, a typical sequence of events in an 145 ECN-based reaction to congestion is as follows: 146 - The ECT bit is set in packets transmitted by the sender to 147 indicate that this TCP connection reacts to ECN congestion 148 notifications for these packets. 149 - An ECN-capable router detects impending congestion and notices 150 that the ECT bit is set in the packet that the router is about to 151 drop. Instead of dropping the packet, the router sets the CE bit 152 and forwards the packet. 153 - The packet with the CE bit set arrives at the receiver. The 154 receiver sets the ECN-Echo flag in its next TCP ACK to the sender. 155 - The sender receives the TCP ACK with ECN-Echo set, and reacts to 156 the congestion as if a packet had been dropped. 157 - The sender sets the CWR flag in the TCP header of the next 158 packet sent to the receiver to acknowledge its receipt of and 159 reaction to the ECN-Echo flag. 161 Further details on ECN functionality including negotiation of ECN- 162 capability as part of connection setup as well as the 163 responsibilities and requirements of ECN-capable routers and 164 transports can be found in [RFC2481]. These requirements apply only 165 to routers and transports participating in ECN experimentation. 167 ECN interacts with IPsec tunnels because the bits it uses in the IP 168 header are part of what IPsec refers to as the IPv4 TOS octet or IPv6 169 Traffic Class octet; this field is copied or mapped from the inner IP 170 header to the outer IP header at IPsec tunnel ingress, and the outer 171 header's copy of this field is discarded at IPsec tunnel egress 172 [RFC2401]. If an ECN-capable router were to set the CE (Congestion 173 Experienced) bit in an IPsec-tunneled packet, this would be discarded 174 at tunnel egress, losing the notification of congestion. As a 175 consequence of this behavior, use of ECN over IPsec tunnels is 176 currently not recommended [RFC 2481]. 178 The IPsec limited-functionality alternative for ECN encapsulation is 179 to always clear (i.e., set to 0) the ECT bit in the outer 180 (encapsulating) header, regardless of the value of the ECT bit in the 181 inner (encapsulated) header. Under this alternative, the ECN bits in 182 the inner header are not altered upon decapsulation. The 183 disadvantage of this approach is that ECN-capable flows do not have 184 ECN support for that part of the path that uses IPsec tunneling. 185 That is, if the encapsulated packet arrives at a congested router 186 that is ECN-capable, and the router decides to drop or mark the 187 packet as an indication of congestion to the end nodes, the router 188 has no alternative but to drop the packet. 190 The IPsec full-functionality alternative for ECN encapsulation copies 191 the ECT bit of the inside header to the outside header on 192 encapsulation, and performs an OR of the CE bits from the outer and 193 inner headers to determine the value of the CE bit on decapsulation. 194 Under the full-functionality alternative, an ECN-capable flow can 195 take advantage of ECN for those parts of the path that use IPsec 196 tunneling. The disadvantage of the full-functionality alternative is 197 that IPsec cannot protect flows from certain modifications to the ECN 198 bits in the IP header within the tunnel. The potential dangers from 199 modifications to the ECN bits in the IP header are described in 200 detail in Section 4 below. 202 This document describes the changes to IPsec that are REQUIRED to 203 enable ECN experimentation over IPsec tunnels without discarding 204 congestion notifications when ECN-capable router or routers are 205 traversed by an IPsec tunnel carrying ECN-capable connections. In 206 summary, two changes to IPsec functionality are involved: 208 (1) Modify the handling of the IPv4 TOS octet and IPv6 Traffic 209 Class octet at IPsec tunnel endpoints to prevent loss of ECN 210 congestion notifications when an IPsec tunnel traverses an ECN- 211 capable router. 213 (2) Enable the endpoints of an IPsec tunnel to negotiate enabling 214 ECN functionality in the outer headers of that tunnel based on 215 security policy. ECN is only used in the outer header of packets 216 from ECN-capable connections. 218 The minimum effort to make ECN compatible with IPsec tunnels is a 219 simplified version of the first change that prevents ECN from being 220 enabled in the outer header of an IPsec tunnel. In contrast, full 221 support for ECN includes the ability to negotiate ECN usage between 222 tunnel endpoints; this enables a security administrator to disable 223 ECN in situations where she believes the risks (e.g., of lost 224 congestion notifications) outweigh the benefits of ECN. 226 3. IPsec Changes for ECN usage 228 This section describes the detailed changes to enable usage of ECN 229 over IPsec tunnels, including the negotiation of ECN support between 230 tunnel endpoints. In order to avoid the loss of congestion 231 notifications at tunnel egress, full ECN functionality for an IPsec 232 tunnel supports agreement between both ends of the tunnel that ECN is 233 being used. This is supported by three changes to IPsec: 234 - A Security Association Database (SAD) field indicating whether 235 tunnel encapsulation and decapsulation processing allows or 236 forbids ECN usage in the outer IP header. 237 - A new Security Association Attribute that enables negotiation of 238 this SAD field between the two endpoints of an SA that supports 239 tunnel mode. 240 - Changes to tunnel mode encapsulation and decapsulation 241 processing to allow or forbid ECN usage in the outer IP header 242 based on the value of the SAD field. When ECN usage is allowed in 243 the outer IP header, ECT is set in the outer header for ECN- 244 capable connections and congestion notifications (indicated by the 245 CE bit) from such connections are propagated to the inner header 246 at tunnel egress. 247 These changes are covered further in the following three subsections. 249 The first two changes are OPTIONAL, but if negotiation of ECN usage 250 is implemented, then the SAD field SHOULD also be implemented. On 251 the other hand, negotiation of ECN usage is OPTIONAL in all cases, 252 even for implementations that support the SAD field. The 253 encapsulation and decapsulation processing changes are REQUIRED, but 254 MAY be implemented without the other two changes by assuming that ECN 255 usage is always forbidden. The full-functionality alternative for 256 ECN usage over IPsec tunnels consists of the SAD field and the full 257 version of encapsulation and decapsulation processing changes, with 258 or without the OPTIONAL negotiation support. The limited- 259 functionality alternative consists of a subset of the encapsulation 260 and decapsulation changes that always forbids ECN usage. 262 3.1. ECN Tunnel Security Association Database Field 264 Full ECN functionality adds a new field to the SAD (see [RFC2401]): 266 ECN Tunnel: allowed or forbidden. 268 Indicates whether ECN-capable connections using this SA in tunnel 269 mode are permitted to receive ECN congestion notifications for 270 congestion occurring within the tunnel. The allowed value enables 271 ECN congestion notifications. The forbidden value disables such 272 notifications, causing all congestion to be indicated via dropped 273 packets. 275 [OPTIONAL. The value of this field SHOULD be assumed to be 276 "forbidden" in implementations that do not support it.] 278 If this attribute is implemented, then the SA specification in a 279 Security Policy Database (SPD) entry MUST support a corresponding 280 attribute, and this SPD attribute MUST be covered by the SPD 281 administrative interface (currently described in Section 4.4.1 of 282 [RFC2401]). 284 3.2. ECN Tunnel Security Association Attribute 286 A new IPsec Security Association Attribute is defined to enable the 287 support for ECN congestion notifications based on the outer IP header 288 to be negotiated for IPsec tunnels (see [RFC2407]). This attribute 289 is OPTIONAL, although implementations that support it SHOULD also 290 support the SAD field defined in Section 3.1. 292 Attribute Type 294 class value type 295 ------------------------------------------------- 296 ECN Tunnel 10 Basic 298 Class Values 300 ECN Tunnel 302 Specifies whether ECN experimental functionality is allowed to 303 be used with Tunnel Encapsulation Mode. 304 This affects tunnel encapsulation and decapsulation processing - 305 see Section 3.3. 307 RESERVED 0 308 Allowed 1 309 Forbidden 2 311 Values 3-61439 are reserved to IANA. Values 61440-65535 are for 312 private use. 314 If unspecified, the default shall be assumed to be Forbidden. 316 ECN Tunnel is a new SA attribute, and hence initiators that use it 317 can expect to encounter responders that do not understand it, and 318 therefore reject proposals containing it. For backwards 319 compatibility with such implementations initiators SHOULD always also 320 include a proposal without the ECN Tunnel attribute to enable such a 321 responder to select a transform or proposal that does not contain the 322 ECN Tunnel attribute. RFC 2407 currently requires responders to 323 reject all proposals if any proposal contains an unknown attribute; 324 this requirement is expected to be changed to require a responder not 325 to select proposals or transforms containing unknown attributes. 327 3.3. Changes to IPsec Tunnel Header Processing 329 Subsequent to the publication of [RFC 2401], the TOS octet of IPv4 330 and the Traffic Class octet of IPv6 have been superseded by the six- 331 bit DS Field [RFC2474, RFC TBD] and a two-bit "currently unused" (CU) 332 field [RFC TBD]. The two bits in the IP header used for ECN 333 experimentation, ECT and CE, occupy bits 0 and 1 of the CU field. 335 For full ECN support, the encapsulation and decapsulation processing 336 for the IPv4 TOS field and the IPv6 Traffic Class field are changed 337 from that specified in [RFC2401] to the following: 339 <-- How Outer Hdr Relates to Inner Hdr --> 340 Outer Hdr at Inner Hdr at 341 IPv4 Encapsulator Decapsulator 342 Header fields: -------------------- ------------ 343 DS Field copied from inner hdr (5) no change 344 CU Field constructed (7) constructed (8) 346 IPv6 347 Header fields: 348 DS Field copied from inner hdr (6) no change 349 CU Field constructed (7) constructed (8) 351 (5)(6) If the packet will immediately enter a domain for which the 352 DSCP value in the outer header is not appropriate, that value MUST 353 be mapped to an appropriate value for the domain [RFC 2474]. Also 354 see [RFC 2475] for further information. 356 (7) If the value of the ECN Tunnel field in the SAD entry for this 357 SA is "allowed" and the value of ECT (bit 0) is 1 in the inner 358 header, set ECT to 1 in the outer header, else set ECT to 0 in the 359 outer header. Set CE (bit 1) to 0 in the outer header. 361 (8) If the value of the ECN tunnel field in the SAD entry for this 362 SA is "allowed" and the value of ECT (bit 0) in the inner header 363 is 1, then set the CE bit (bit 1) in the inner header to the 364 logical OR of the CE bit in the inner header with the CE bit in 365 the outer header, else make no change to the CU field. 367 (5) and (6) are identical to match usage in [RFC2401], although they 368 are different in [RFC2401]. The Differentiated Services Working 369 Group is currently considering interactions between Differentiated 370 Services and tunnels, so implementers are advised to check for 371 additional RFCs that further update the IPsec architecture in this 372 area. 374 The above description applies to implementations that support the ECN 375 Tunnel field in the SAD; such implementations MUST implement this 376 processing of the DS field instead of the processing of the IPv4 TOS 377 octet and IPv6 Traffic Class octet defined in [RFC2401]. This 378 constitutes the full-functionality alternative for ECN usage with 379 IPsec tunnels. 381 An implementation that does not support the ECN Tunnel field in the 382 SAD MUST implement processing of the DS Field by assuming that the 383 value of the ECN Tunnel field of the SAD is "forbidden" for every SA. 384 In this case, the processing of the CU field reduces to: 386 (7) Set the CU field to zero in the outer header. 387 (8) Make no change to the CU field. 389 This constitutes the limited functionality alternative for ECN usage 390 with IPsec tunnels. 392 In addition, for backwards compatibility, packets with ECT and CE 393 both set to 1 in the outer header SHOULD be dropped if they arrive on 394 an SA that forbids or is assumed to forbid ECN usage in tunnel mode. 395 This applies to both the complete ECN support and partial ECN support 396 implementation approaches. This is discussed further in Section 6. 398 4. Possible Changes to the ECN Field 400 This section considers the issues when a router is operating, 401 possibly maliciously, to modify either of the ECN bits in IP header. 402 In this section we represent the ECN bits in the IP header by the 403 tuple (ECT bit, CE bit). The ECT bit, when set to 1, indicates an 404 ECN-Capable Transport. The CE bit, when set to 1, indicates that 405 Congestion was Experienced in the path. 407 By tampering with the ECN bits, an adversary (or a broken router) 408 could do one or more of the following: erase the ECN congestion 409 indication, falsely report congestion, disable ECN-Capability for an 410 individual packet, or falsely indicate ECN-Capability. We 411 systematically examine the various cases by which the ECN bits could 412 be modified. The important criterion we consider in determining the 413 consequences of such modifications is whether it is likely to lead to 414 worse behavior in any dimension (throughput, delay, fairness or 415 functionality) than if a router were to drop a packet. 417 4.1. Erasing the Congestion Indication 419 First, we consider the changes that a router could make that would 420 result in effectively erasing the congestion indication after it had 421 been set by a router upstream. The convention followed is: 422 (ECT, CE) of received packet -> (ECT, CE) of packet transmitted. 424 (1, 1) -> (1, 0): erase only the CE bit that was set. 425 (1, 1) -> (0, 0): erase both the ECT bit and the CE bit. 426 (1, 1) -> (0, 1): erase the ECT bit 428 The first change turns off the CE bit after it has been set by some 429 upstream router along the path. The consequence for the upstream 430 router is that there is a potential for congestion to build for a 431 time, because the congestion indication does not reach the source. 432 However, the packet would be received and acknowledged. 434 The potential effect of erasing the congestion indication is complex, 435 and is discussed in depth in Section 5 below. Note that the effect 436 of erasing the congestion indication is different from dropping a 437 packet in the network. When a data packet is dropped, the drop is 438 detected by the TCP sender, and interpreted as an indication of 439 congestion. Similarly, if a sufficient number of consecutive 440 acknowledgement packets are dropped, causing the cumulative 441 acknowledgement field not to be advanced at the sender, the sender is 442 limited by the congestion window from sending additional packets, and 443 ultimately the retransmit timer expires. 445 In contrast, a systematic erasure of the CE bit by a downstream 446 router can have the effect of causing a queue buildup at an upstream 447 router, including the possible loss of packets due to buffer 448 overflow. There is a potential of unfairness in that another flow 449 that goes through the congested router could react to the CE bit set 450 while the flow that has the CE bit erased could see better 451 performance. The limitations on this potential unfairness are 452 discussed in more detail in Section 5 below. 454 The second change is to turn off both the ECT and the CE bits, thus 455 erasing the congestion indication and disabling ECN-Capability at the 456 same time. The third change turns off only the ECT bit, disabling 457 ECN-Capability. The proposal in this Internet Draft is for the 458 receiver at the end of a tunnel to copy the CE bit, if set, from the 459 outer header to the inner header during decapsulation, if the ECT bit 460 in the inner header is set and the tunnel provides full ECN support. 461 In this case, the third change within an IPsec tunnel would not erase 462 the congestion indication, but would only disable ECN-Capability for 463 that packet within the rest of the tunnel. However, when performed 464 outside of an IPsec tunnel, the third change would also effectively 465 erase the congestion indication, because an ECN field of (0, 1) is 466 undefined. 468 The `erasure' of the congestion indication is only effective if the 469 packet does not end up being marked or dropped again by a downstream 470 router. With the first change, the packet remains ECN-Capable, and 471 could be either marked or dropped by a downstream router as an 472 indication of congestion. With the second and third changes, the 473 packet is no longer ECN-capable, and can therefore be dropped but not 474 marked by a downstream router as an indication of congestion. 476 4.2. Falsely Reporting Congestion 478 (1, 0) -> (1, 1) 480 This change is to set the CE bit when the ECT bit was already set, 481 even though there was no congestion. This change does not affect the 482 treatment of that packet along the rest of the path. In particular, 483 a router does not examine the CE bit in deciding whether to drop or 484 mark an arriving packet. 486 However, this could result in the application unnecessarily invoking 487 end-to-end congestion control, and reducing its arrival rate. By 488 itself, this is no worse (for the application or for the network) 489 than if the tampering router had actually dropped the packet. 491 4.3. Disabling ECN-Capability 493 (1, 0) -> (0, *) 495 This change is to turn off the ECT bit of a packet that does not have 496 the CE bit set. (Section 4.1 discussed the case of turning off the 497 ECT bit of a packet that does have the CE bit set.) This means that 498 if the packet later encounters congestion (e.g., by arriving to a RED 499 queue with a moderate average queue size), it will be dropped instead 500 of being marked. By itself, this is no worse (for the application) 501 than if the tampering router had actually dropped the packet. The 502 saving grace in this particular case is that there is no congested 503 router upstream expecting a reaction from setting the CE bit. 505 4.4. Falsely Indicating ECN-Capability 507 This change is to incorrectly label a packet as ECN-Capable. 509 (0, *) -> (1, 0); 510 (0, *) -> (1, 1); 512 If the packet later encounters moderate congestion at an ECN-Capable 513 router, the router could set the CE bit instead of dropping the 514 packet. If the transport protocol in fact is not ECN-Capable, then 515 the transport will never receive this indication of congestion, and 516 will not reduce its sending rate in response. The potential 517 consequences of falsely indicating ECN-capability are discussed 518 further in Section 5 below. 520 If the packet never later encounters congestion at an ECN-Capable 521 router, then the first of these two changes would have no effect. 522 The second change, however, would have the effect of giving false 523 reports of congestion to a monitoring device along the path. If the 524 transport protocol is ECN-Capable, then the second of these two 525 changes (when, for example, (0,0) was changed to (1,1)) could also 526 have an effect at the transport level, by combining falsely 527 indicating ECN-Capability with falsely reporting congestion. For an 528 ECN-capable transport, this would cause the transport to 529 unnecessarily react to congestion. In this particular case, the 530 router that is incorrectly changing the ECN field could have dropped 531 the packet. Thus for this case of an ECN-capable transport, the 532 consequence of this change to the ECN field is no worse than dropping 533 the packet. 535 4.5. Changes with No Functional Effect 537 (0, *) -> (0, *) 539 The CE bit is ignored in a packet that does not have the ECT bit set. 540 Thus, this change would have no effect, in terms of ECN. 542 4.6. Information carried in the Transport Header 544 For TCP, an ECN-capable TCP receiver informs its TCP peer that it is 545 ECN-capable at the TCP level, using information in the TCP header at 546 the time the connection is setup. This document does not consider 547 potential dangers introduced by changes in the transport header 548 because the IPsec tunnel protects the transport header. 550 5. Implications of Subverting End-to-End Congestion Control 552 This section focuses on the potential repercussions of subverting 553 end-to-end congestion control by either falsely indicating ECN- 554 Capability, or by erasing the congestion indication in ECN (the CE- 555 bit). Subverting end-to-end congestion control by either of these 556 two methods can have consequences both for the application and for 557 the network. We discuss these separately below. 559 The first method to subvert end-to-end congestion control, falsely 560 indicating ECN-Capability, effectively subverts end-to-end congestion 561 control only if the packet later encounters congestion that results 562 in the setting of the CE bit. In this case, the transport protocol 563 does not receive the indication of congestion from these downstream 564 congested routers. 566 The second method to subvert end-to-end congestion control, `erasing' 567 the (set) CE bit in a packet, effectively subverts end-to-end 568 congestion control only when the CE bit in the packet was set earlier 569 by a congested router. In this case, the transport protocol does not 570 receive the indication of congestion from the upstream congested 571 routers. 573 Either of these two methods of subverting end-to-end congestion 574 control can potentially introduce more damage to the network (and 575 possibly to the flow itself) than if the adversary had simply dropped 576 packets from that flow. However, as we discuss later in this section 577 and in Section 7, this potential damage is limited. 579 5.1. Implications for the Network and for Competing Flows 581 The CE bit of the ECN field is only used by routers as an indication 582 of congestion during periods of *moderate* congestion. ECN-capable 583 routers should drop rather than mark packets during heavy congestion 584 even if the router's queue is not yet full. For example, for routers 585 using active queue management based on RED, the router should drop 586 rather than mark packets that arrive while the average queue sizes 587 exceed the RED queue's maximum threshold. 589 One consequence for the network of subverting end-to-end congestion 590 control is that flows that do not receive the congestion indications 591 from the network might increase their sending rate until they drive 592 the network into heavier congestion. Then, the congested router 593 could begin to drop rather than mark arriving packets. For flows 594 that are not isolated by some form of per-flow scheduling or other 595 per-flow mechanisms, but that are instead aggregated with other flows 596 in a single queue in an undifferentiated fashion, this packet- 597 dropping at the congested router would apply to all flows that share 598 that queue. Thus, the consequences would be to increase the level of 599 congestion in the network. 601 In some cases, the increase in the level of congestion will lead to a 602 substantial buffer buildup at the congested queue that will be 603 sufficient to drive the congested queue from the packet-marking to 604 the packet-dropping regime. This transition could occur either 605 because of buffer overflow, or because of the active queue management 606 policy described above that drops packets when the average queue is 607 above RED's maximum threshold. At this point, all flows, including 608 the subverted flow, will begin to see packet drops instead of packet 609 marks, and a malicious or broken router will no longer be able to 610 `erase' these indications of congestion in the network. If the end 611 nodes are deploying appropriate end-to-end congestion control, then 612 the subverted flow will reduce its arrival rate in response to 613 congestion. When the level of congestion is sufficiently reduced, 614 the congested queue can return from the packet-dropping regime to the 615 packet-marking regime. The steady-state pattern could be one of the 616 congested queue oscillating between these two regimes. 618 In other cases, the consequences of subverting end-to-end congestion 619 control will not be severe enough to drive the congested link into 620 sufficiently-heavy congestion that packets are dropped instead of 621 being marked. In this case, the implications for competing flows in 622 the network will be a slightly-increased rate of packet marking or 623 dropping, and a corresponding decrease in the bandwidth available to 624 those flows. This can be a stable state if the arrival rate of the 625 subverted flow is sufficiently small, relative to the link bandwidth, 626 that the average queue size at the congested router remains under 627 control. In particular, the subverted flow could have a limited 628 bandwidth demand on the link at this router, while still getting more 629 than its "fair" share of the link. This limited demand could be due 630 to a limited demand from the data source; a limitation from the TCP 631 advertised window; a lower-bandwidth access pipe; or other factors. 632 Thus the subversion of ECN-based congestion control can still lead to 633 unfairness, which we believe is appropriate to note here. 635 The threat to the network posed by the subversion of ECN-based 636 congestion control in the network is essentially the same as the 637 threat posed by an end-system that intentionally fails to cooperate 638 with end-to-end congestion control. The deployment of mechanisms in 639 routers to address this threat is an open research question, and is 640 discussed further in Section 7. 642 Let us take the example described in Section 4.1, where the CE bit 643 that was set in a packet is erased: {(1, 1) -> (1, 0)}. The 644 consequence for the congested upstream router that set the CE bit is 645 that this congestion indication does not reach the end nodes for that 646 flow. The source (even one which is completely cooperative and not 647 malicious) is thus allowed to continue to increase its sending rate 648 (if it is a TCP flow, by increasing its congestion window). The flow 649 potentially achieves better throughput than the other flows that also 650 share the congested router, especially if there are no policing 651 mechanisms or per-flow queueing mechanisms at that router. Consider 652 the behavior of the other flows, especially if they are cooperative: 653 that is, the flows that do not experience subverted end-to-end 654 congestion control. They are likely to reduce their load (e.g., by 655 reducing their window size) on the congested router, thus benefiting 656 our subverted flow. This results in unfairness. As we discussed 657 above, this unfairness could either be transient (because the 658 congested queue is driven into the packet-marking regime), 659 oscillatory (because the congested queue oscillated between the 660 packet marking and the packet dropping regime), or more moderate but 661 a persistent stable state (because the congested queue is never 662 driven to the packet dropping regime). 664 The results would be similar if the subverted flow was intentionally 665 avoiding end-to-end congestion control. One difference is that a 666 flow that is intentionally avoiding end-to-end congestion control at 667 the end nodes can avoid end-to-end congestion control even when the 668 congested queue is in packet-dropping mode, by refusing to reduce its 669 sending rate in response to packet drops in the network. Thus the 670 problems for the network of the subversion of ECN-based congestion 671 control are less severe than the problems caused by the intentional 672 avoidance of end-to-end congestion control in the end nodes. It is 673 also the case that it is considerably more difficult to control the 674 behavior of the end nodes than it is to control the behavior of the 675 infrastructure itself. This is not to say that the problems for the 676 network posed by the network's subversion of ECN-based congestion 677 control are small; just that they are dwarfed by the problems for the 678 network posed by the subversion of either ECN-based or packet-based 679 congestion control by the end nodes. 681 5.2. Implications for the Subverted Flow 683 When a source indicates that it is ECN-capable, there is an 684 expectation that the routers in the network that are capable of 685 participating in ECN will use the CE bit for indication of 686 congestion. There is the potential benefit of using ECN in reducing 687 the amount of packet loss (in addition to the reduced queueing delays 688 because of active queue management policies). When the packet flows 689 through a tunnel where the nodes that the tunneled packets traverse 690 are untrusted in some way, the expectation is that IPsec will protect 691 the flow from subversion that results in undesirable consequences. 693 In many cases, a subverted flow will benefit from the subversion of 694 end-to-end congestion control for that flow in the network, by 695 receiving more bandwidth that it would have otherwise, relative to 696 competing non-subverted flows. If the congested queue reaches the 697 packet-dropping stage, then the subversion of end-to-end congestion 698 control might or might not be of overall benefit to the subverted 699 flow, depending on that flow's relative tradeoffs between throughput, 700 loss, and delay. 702 One form of subverting end-to-end congestion control is to falsely 703 indicate ECN-capability by setting the ECT bit. This has the 704 consequence of downstream congested routers setting the CE bit in 705 vain. However, as we describe in the section below, if the ECT bit 706 is changed in the IPsec tunnel, this can be detected at the egress 707 point of the tunnel. 709 The second form of subverting end-to-end congestion control is to 710 erase the congestion indication, either by erasing the CE bit 711 directly, or by erasing the ECT bit when the CE bit is already set. 713 In this case, it is the upstream congested routers that set the CE 714 bit in vain. There are several possible scenarios for this 715 subversion of end-to-end congestion control within an IPsec tunnel. 716 If the ECT bit is erased within an IPsec tunnel, then this can be 717 detected at the egress point of the tunnel. If the CE bit is set 718 upstream of the IPsec tunnel, then any erasure of the outer header's 719 CE bit within the tunnel will have no effect because the inner header 720 preserves the set value of the CE bit. However, if the CE bit is set 721 within the tunnel, and erased either within or downstream of the 722 tunnel, this is not necessarily detected at the egress point of the 723 tunnel. 725 With this subversion of end-to-end congestion control, an end-system 726 transport does not respond to the congestion indication. Along with 727 the increased unfairness for the non-subverted flows described in the 728 previous section, the congested router's queue could continue to 729 build, resulting in packet loss at the congested router - which is a 730 means for indicating congestion to the transport in any case. In the 731 interim, the flow might experience higher queueing delays, possibly 732 along with an increased bandwidth relative to other non-subverted 733 flows. But transports do not inherently make assumptions of 734 consistently experiencing carefully managed queueing in the path. We 735 believe that these forms of subverting end-to-end congestion control 736 are no worse for the subverted flow than if the adversary had simply 737 dropped the packets of that flow itself. 739 5.3. Non-ECN-Based Methods of Subverting End-to-end Congestion Control 741 We have shown that, in many cases, a malicious or broken router that 742 is able to change the bits in the ECN field can do no more damage 743 than if it had simply dropped the packet in question. However, this 744 is not true in all cases, in particular in the cases where the broken 745 router subverted end-to-end congestion control by either falsely 746 indicating ECN-Capability or by erasing the ECN congestion indication 747 (in the CE-bit). While there are many ways that a router can harm a 748 flow by dropping packets, a router cannot subvert end-to-end 749 congestion control by dropping packets. As an example, a router 750 cannot subvert TCP congestion control by dropping data packets, 751 acknowledgement packets, or control packets. 753 Even though packet-dropping cannot be used to subvert end-to-end 754 congestion control, there *are* non-ECN-based methods for subverting 755 end-to-end congestion control that a broken or malicious router could 756 use. For example, a broken router could duplicate data packets, thus 757 effectively negating the effects of end-to-end congestion control 758 along some portion of the path. (For a router that duplicated 759 packets within an IPsec tunnel, the security administrator can cause 760 the duplicate packets to be discarded by configuring anti-replay 761 protection for the tunnel.) This duplication of packets within the 762 network would have similar implications for the network and for the 763 subverted flow as those described in Sections 5.1 and 5.2 above. 765 6. Changes to the ECN Field within an IPsec Tunnel. 767 The presence of a copy of the ECN field in the inner header of an 768 IPsec tunnel mode packet provides an opportunity for detection of 769 modifications to the ECT bit in the outer header. Comparison of the 770 ECT bits in the inner and outer headers falls into two categories for 771 implementations that conform to this document: 772 (a) If the SA allows ECN usage within the tunnel, then the values 773 of the ECT bits in the inner and outer headers are expected be 774 identical. 775 (b) If the SA disallows ECN usage within the tunnel, then the ECT 776 bit in the outer header is expected to be 0. 778 Receipt of a packet not satisfying the appropriate condition for its 779 SA is an auditable event, but an implementation MAY create audit 780 records with per-SA counts of incorrect packets over some time period 781 rather than creating an audit record for each erroneous packet. Any 782 such audit record SHOULD contain the headers from at least one 783 erroneous packet, but need not contain the headers from every packet 784 represented by the entry. 786 An important and likely situation involves an IPsec implementation 787 not updated to this document's requirements serving as tunnel ingress 788 for a tunnel egress at an implementation that has been updated. The 789 ECN Tunnel attribute cannot be negotiated in this case because the 790 tunnel ingress implementation does not support it. If packets from 791 an ECN-capable connection use this tunnel, ECT will be set in the 792 outer header. Congestion along the route could then result in ECN- 793 capable routers setting CE in the outer header. All packets arriving 794 at the tunnel egress on this SA will appear to be case (b) errors, 795 but SHOULD be processed according to whether CE was set. Therefore 796 it is RECOMMENDED that packets violating the condition for case (b) 797 above be dropped if CE is set to 1 in the outer header and forwarded 798 if CE is 0 in the outer header. 800 An IPsec tunnel cannot provide protection against erasure of 801 congestion indications or false reports of congestion based on 802 flipping the value of the CE bit in packets for which ECT is set in 803 the outer header. As described in Section 5, false reports of 804 congestion are equivalent to dropping the packet, an action against 805 which IPsec also provides no protection. On the other hand, erasure 806 of congestion indications could impact the network and other flows in 807 ways that would not be possible in the absence of ECN. It is 808 important to note that erasure of congestion indications can only be 809 performed to congestion indications placed by nodes within the 810 tunnel; the copy of the CE bit in the inner header preserves 811 congestion notifications from nodes upstream of the tunnel ingress. 812 If erasure of congestion notifications is judged to be a security 813 risk that exceeds the congestion management benefits of ECN, the 814 security administrator can configure the appropriate tunnel SAs to 815 forbid ECN usage in the outer header. 817 7. Issues Raised by Monitoring and Policing Devices 819 One possibility is that monitoring and policing devices (or more 820 informally, `penalty boxes') will be installed in the network to 821 monitor whether best-effort flows are appropriately responding to 822 congestion, and to preferentially drop packets from flows determined 823 not to be using adequate end-to-end congestion control procedures. 824 [FF98] proposes three potential classifications for high-bandwidth 825 flows in times in congestion: (1) flows that are not TCP-friendly, 826 in that the arrival rate from that flow exceeds the arrival rate of a 827 conformant TCP connection under the same conditions; (2) flows that 828 are unresponsive, in that they do not decrease their arrival rate 829 appropriately in response to an increase in congestion; and (3) 830 flows using disproportionate bandwidth, defined as flows using a 831 significantly larger share of bandwidth than other flows in times of 832 high congestion. The methods of identifying and classifying flows to 833 be in one of these three categories is outside the scope of this 834 discussion. 836 [FF98] proposes that flows that are simply determined to be using 837 disproportionate bandwidth could have their bandwidth restricted, in 838 much the same way that a round-robin per-flow scheduling algorithm 839 would restrict the bandwidth received by individual flows, while 840 flows determined to be unresponsive or not TCP-friendly in times of 841 congestion could have their bandwidth even more strongly reduced, as 842 a concrete incentive to end nodes to use end-to-end congestion 843 control. 845 For an ECN-capable flow, an `ideal' penalty box at a router would be 846 a device that, when it detected that a flow was not responding to ECN 847 indications, would switch to dropping, instead of marking, those 848 packets of a flow that would otherwise have been chosen to carry 849 indications of congestion. In this way, these congestion indications 850 could not be `erased' later in the network, and at the same time 851 there would be no change in the router's treatment of packets of 852 other flows. If a router determines that a flow is still not 853 responding to congestion indications, when the congestion indications 854 consist of packet drops, then the router could take whatever action 855 it deems appropriate for that flow. 857 We RECOMMEND that any `penalty box' that detects a flow or an 858 aggregate of flows that is not responding to end-to-end congestion 859 control first change from marking to dropping packets from that flow, 860 before taking any additional action to restrict the bandwidth 861 available to that flow. Thus, initially, the router could drop 862 packets in which the router would otherwise would have set the CE 863 bit. This could include dropping those arriving packets for that 864 flow that are ECN-Capable and that already have the CE bit set. In 865 this way, any congestion indications seen by that router for that 866 flow will be guaranteed to also be seen by the end nodes, even in the 867 presence of malicious or broken routers elsewhere in the path. If we 868 assume that the first action taken at any `penalty box' for an ECN- 869 capable flow will be to drop packets instead of marking them, then 870 there is no way that an adversary that subverts ECN-based end-to-end 871 congestion control can cause a flow to be characterized as being non- 872 cooperative and placed into a more severe action within the `penalty 873 box'. 875 The monitoring and policing devices that are actually deployed could 876 fall short of the `ideal' monitoring device described above, in that 877 the monitoring is applied not to a single flow or to a single IPsec 878 tunnel, but to an aggregate of flows. In this case, the switch from 879 marking to dropping would apply to all of the flows in that 880 aggregate, denying the benefits of ECN to the other flows in the 881 aggregate also. At the highest level of aggregation, another form of 882 the disabling of ECN happens even in the absence of monitoring and 883 policing devices, when ECN-Capable RED queues switch from marking to 884 dropping packets as an indication of congestion when the average 885 queue size has exceeded some threshold. 887 7.1. Complications Introduced by Split Paths 889 If a router or other network element has access to all of the packets 890 of a flow, then that router could do no more damage to a flow by 891 altering the ECN field that it could by simply dropping all of the 892 packets from that flow. However, in some cases, a malicious or 893 broken router might have access to only a subset of the packets from 894 a flow. The question is as follows: can this router, by altering 895 the ECN field in this subset of the packets, do more damage to that 896 flow than if it has simply dropped that set of the packets? 898 We will classify the packets in the flow as A packets and B packets, 899 and assume that the adversary only has access to A packets. Assume 900 that the adversary is subverting end-to-end congestion control along 901 the path traveled by A packets only, by either falsely indicating 902 ECN-Capability upstream of the point where congestion occurs, or 903 erasing the congestion indication downstream. Consider also that 904 there exists a monitoring device that sees both the A and B packets, 905 and will "punish" both the A and B packets if the total flow is 906 determined not to be properly responding to indications of 907 congestion. Another key characteristic that we believe is likely to 908 be true is that the monitoring device, before `punishing' the A&B 909 flow, will first drop packets instead of setting the CE bit, and will 910 drop arriving packets of that flow that already have the ECT and CE 911 bits set. If the end nodes are in fact using end-to-end congestion 912 control, they will see all of the indications of congestion seen by 913 the monitoring device, and will begin to respond to these indications 914 of congestion. Thus, the monitoring device is successful in providing 915 the indications to the flow at an early stage. 917 It is true that the adversary that has access only to the A packets 918 might, by subverting ECN-based congestion control, be able to deny 919 the benefits of ECN to the other packets in the A&B aggregate. While 920 this is unfortunate, this is not a reason to disable ECN within an 921 IPsec tunnel. 923 A variant of falsely reporting congestion occurs when there are two 924 adversaries along a path, where the first adversary falsely reports 925 congestion, and the second adversary `erases' those reports. (Unlike 926 packet drops, ECN congestion reports can be `reversed' later in the 927 network by a malicious or broken router.) While this would be 928 transparent to the end node, it is possible that a monitoring device 929 between the first and second adversaries would see the false 930 indications of congestion. Given our recommendation in this 931 document, before `punishing' a flow for not responding appropriately 932 to congestion, the router will first switch to dropping rather than 933 marking as an indication of congestion, for that flow. When this 934 includes dropping arriving packets from that flow that have the CE 935 bit set, this ensures that these indications of congestion are being 936 seen by the end nodes. Thus, there is no additional harm that we are 937 able to postulate as a result of multiple conflicting adversaries. 939 8. Comments and Rationale 941 Substantial comments were received on two areas of this document 942 during review by the ipsec working group. This section describes 943 these comments and explains why the proposed changes were not 944 incorporated. 946 The first comment indicated that per-node configuration is easier to 947 implement than per-SA configuration. After serious thought and 948 despite some initial encouragement of per-node configuration, it no 949 longer seems to be a good idea. The concern is that as IPsec is 950 progressively deployed, many ECN-aware IPsec implementations will 951 find themselves communicating with a mixture of ECN-aware and ECN- 952 unaware IPsec tunnel endpoints. In such an environment with per-node 953 configuration, the only reasonable thing to do is forbid ECN usage 954 for all IPsec tunnels, which is not the desired outcome. 956 In the second area, several reviewers noted that SA negotiation is 957 complex, and adding to it is non-trivial. One reviewer suggested 958 using ICMP after tunnel setup as a possible alternative. The 959 addition to SA negotiation in the draft is OPTIONAL and will remain 960 so; implementers are free to ignore it. The authors believe that the 961 assurance it provides can be useful in a number of situations. In 962 practice, if this is not implemented, it can be deleted at a 963 subsequent stage in the standards process. Extending ICMP to 964 negotiate ECN after tunnel setup is more complex than extending SA 965 attribute negotiation. Some tunnels do not permit traffic to be 966 addressed to the egress endpoint, hence the ICMP packet would have to 967 be addressed to somewhere else, scanned for by the egress endpoint, 968 and discarded there or at its actual destination. In addition, ICMP 969 delivery is unreliable, and hence there is a possibility of an ICMP 970 packet being dropped, entailing the invention of yet another 971 ack/retransmit mechanism. It seems better simply to specify an 972 OPTIONAL extension to the existing SA negotiation mechanism. 974 9. Conclusions. 976 This document revises the IPsec architecture to remove a conflict 977 between the experimental usage of Explicit Congestion Notification 978 and IPsec tunnels. This revision consists primarily of modifying the 979 IPsec protocol's handling of the bits in the IP header used by ECN 980 during encapsulation and de-capsulation to allow flows that undergo 981 IPsec tunneling to obtain ECN congestion notifications. 983 Two alternatives were described: 984 1) A preferred full-functionality alternative that copies the ECT bit 985 of the inner header to the encapsulating header. At decapsulation, if 986 the ECT bit is set in the inner header, the CE bit from the outer 987 header is ORed with the CE bit of the inner header to update the CE 988 bit of the packet. 989 2) A limited-functionality alternative that does not permit 990 generation of ECN notifications inside the IPsec tunnel, by setting 991 the ECT bit in the outer header to zero, and not altering the bits 992 used by ECN in inner header upon decapsulation. 994 This document also specifies a new IPsec SA attribute that enables 995 negotiation of ECN usage within IPsec tunnels and a new field in the 996 Security Association database to indicate whether ECN is permitted in 997 tunnel mode on a SA. 999 We examined the consequence of modifications of the ECN field within 1000 the tunnel, analyzing all the opportunities for an adversary to 1001 change the ECN field. In many cases, the change to the ECN field is 1002 no worse than dropping a packet. However, we noted that some changes 1003 have the more serious consequence of subverting end-to-end congestion 1004 control. However, we point out that even then the potential damage 1005 is limited, and is similar to the threat posed by an end-system 1006 intentionally failing to cooperate with end-to-end congestion 1007 control. 1009 In order to permit the experimental usage of ECN with IPsec tunnels, 1010 all IPsec implementations MUST implement one of the two alternative 1011 approaches described above. 1013 10. Acknowledgements 1015 We thank Steve Bellovin and Vern Paxson for discussions of these 1016 matters. We thank Derrell Piper and Kero Tivinen for proposing 1017 modifications to RFC 2407 that improve the usability of negotiating 1018 the ECN Tunnel SA attribute. 1020 11. References 1022 [FF98] Floyd, S., and Fall, K., Promoting the Use of End-to-End 1023 Congestion Control in the Internet. IEEE/ACM Transactions on 1024 Networking, August 1999. URL "http://www- 1025 nrg.ee.lbl.gov/floyd/end2end-paper.html". 1027 [RFC 2119] S. Bradner, Key words for use in RFCs to Indicate 1028 Requirement Levels, RFC 2119, March 1997. 1030 [RFC 2401] S. Kent, R. Atkinson, Security Architecture for the 1031 Internet Protocol, RFC 2401, November 1998. 1033 [RFC2407] D. Piper, The Internet IP Security Domain of Interpretation 1034 for ISAKMP, RFC 2407, November 1998. 1036 [RFC2474] K. Nichols, S. Blake, F. Baker, D. Black, Definition of the 1037 Differentiated Services Field (DS Field) in the IPv4 and IPv6 1038 Headers, RFC 2474, December 1998. 1040 [RFC 2475] S. Blake, D. Black, M. Carlson, E. Davies, Z. Wang, and W. 1041 Weiss, An Architecture for Differentiated Services, RFC 2475, 1042 December 1998. 1044 [RFC2481] K. Ramakrishnan, S. Floyd, A Proposal to add Explicit 1045 Congestion Notification (ECN) to IP, RFC 2481, January 1999. 1047 [RFC TBD] S. Bradner and V. Paxson, IANA Allocation Guidelines For 1048 Values In the Internet Protocol and Related Headers, Internet-Draft 1049 (draft-bradner-iana-allocation-03.txt), November 1999. 1051 12. Security Considerations 1053 Security considerations have been addressed in the main body of the 1054 document. 1056 AUTHORS' ADDRESSES 1058 Sally Floyd 1059 AT&T Center for Internet Research at ICSI (ACIRI) 1060 Phone: +1 (510) 642-4274 x189 1061 Email: floyd@aciri.org 1062 URL: http://www.aciri.org/floyd/ 1064 David L. Black 1065 EMC Corporation 1066 42 South St. 1068 Hopkinton, MA 01748 1069 Phone: +1 (508) 435-1000 x75140 1070 Email: black_david@emc.com 1072 K. K. Ramakrishnan 1073 AT&T Labs. Research 1074 Phone: +1 (973) 360-8766 1075 Email: kkrama@research.att.com 1076 URL: http://www.research.att.com/info/kkrama 1078 This draft was created in December 1999. 1079 It expires June 2000.