idnits 2.17.1 draft-ietf-tsvwg-tcp-nonce-04.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: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There are 10 instances of too long lines in the document, the longest one being 2 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- 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.) -- Couldn't find a document date in the document -- date freshness check skipped. 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: 'RFC2119' is mentioned on line 97, but not defined == Unused Reference: 'B97' is defined on line 514, but no explicit reference was found in the text -- Possible downref: Non-RFC (?) normative reference: ref. 'ECN' -- Possible downref: Non-RFC (?) normative reference: ref. 'Eifel' -- Possible downref: Non-RFC (?) normative reference: ref. 'Savage' -- Possible downref: Non-RFC (?) normative reference: ref. 'Schneier' Summary: 3 errors (**), 0 flaws (~~), 4 warnings (==), 6 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Engineering Task Force Neil Spring 3 INTERNET DRAFT David Wetherall 4 draft-ietf-tsvwg-tcp-nonce-04.txt David Ely 5 University of Washington 6 October, 2002 7 Expires: April, 2002 9 Robust ECN Signaling with Nonces 11 Status of this Memo 13 This document is an Internet-Draft and is in full conformance with 14 all provisions of Section 10 of RFC2026. 16 Internet-Drafts are working documents of the Internet Engineering 17 Task Force (IETF), its areas, and its working groups. Note that 18 other groups may also distribute working documents as Internet- 19 Drafts. 21 Internet-Drafts are draft documents valid for a maximum of six months 22 and may be updated, replaced, or obsoleted by other documents at any 23 time. It is inappropriate to use Internet-Drafts as reference 24 material or to cite them other than as "work in progress." 26 The list of current Internet-Drafts can be accessed at 27 http://www.ietf.org/ietf/1id-abstracts.txt 29 The list of Internet-Draft Shadow Directories can be accessed at 30 http://www.ietf.org/shadow.html. 32 Abstract 34 This note describes the ECN-nonce, an optional addition to ECN that 35 protects against accidental or malicious concealment of marked 36 packets from the TCP sender. It improves the robustness of 37 congestion control by preventing receivers from exploiting ECN to 38 gain an unfair share of network bandwidth. The ECN-nonce uses the 39 two ECT codepoints in the ECN field of the IP header, and requires a 40 flag in the TCP header. It is computationally efficient for both 41 routers and hosts. 43 1. Introduction 45 The correct operation of ECN requires the cooperation of the receiver 46 to return Congestion Experienced signals to the sender, but the 47 protocol lacks a mechanism to enforce this cooperation. This raises 48 the possibility that an unscrupulous or poorly implemented receiver 49 could always clear ECN-Echo and simply not return congestion signals 50 to the sender. This would give the receiver a performance advantage 51 at the expense of competing connections that behave properly. More 52 generally, any device along the path (NAT box, firewall, QOS 53 bandwidth shapers, and so forth) could remove congestion marks with 54 impunity. 56 The above behaviors may or may not constitute a threat to the 57 operation of congestion control in the Internet. However, given the 58 central role of congestion control, it is prudent to design the ECN 59 signaling loop to be robust against as many threats as possible. In 60 this way, ECN can provide a clear incentive for improvement over the 61 prior state-of-the-art without potential incentives for abuse. The 62 ECN-nonce is a simple, efficient mechanism to eliminate the potential 63 abuse of ECN. 65 The ECN-nonce enables the sender to verify the correct behavior of 66 the ECN receiver and that there is no other interference that 67 conceals marked (or dropped) packets in the signaling path. The ECN- 68 nonce protects against both implementation errors and deliberate 69 abuse. The ECN-nonce: 71 - catches a misbehaving receiver with a high probability, and never 72 implicates an innocent receiver. 74 - does not change other aspects of ECN, nor does it reduce the 75 benefits of ECN for behaving receivers. 77 - is cheap in both per-packet overhead (one TCP header flag) and 78 processing requirements. 80 - is simple and, to the best of our knowledge, not prone to other 81 attacks. 83 We also note that use of the ECN-nonce has two additional benefits, 84 even when only drop-tail routers are used. First, packet drops 85 cannot be concealed from the sender. Second, it prevents optimistic 86 acknowledgements [Savage], in which TCP segments are acknowledged 87 before they have been received. These benefits also serve to 88 increase the robustness of congestion control from attacks. We do 89 not elaborate on these benefits in this draft. 91 The rest of this draft describes the ECN-nonce. We present an 92 overview followed by detailed behavior at senders and receivers. 94 The keywords MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD, 95 SHOULD NOT, RECOMMENDED, MAY, and OPTIONAL, when they appear in this 96 document, are to be interpreted as described in [RFC2119]. 98 2. Overview 100 The ECN-nonce builds on the existing ECN-Echo and CWR signaling 101 mechanism. Familiarity with ECN [ECN] is assumed. For simplicity, 102 we describe the ECN-nonce in one direction only, though it is run in 103 both directions in parallel. 105 The ECN protocol for TCP remains unchanged, except for the definition 106 of a new field in the TCP header. As in [ECN], ECT(0) or ECT(1) 107 (ECN-Capable Transport) is set in the ECN field of the IP header on 108 outgoing packets. Congested routers change this field to CE 109 (Congestion Experienced). When TCP receivers notice CE, the ECE 110 (ECN-Echo) flag is set in subsequent acknowledgements until receiving 111 a CWR (Congestion Window Reduced) flag. The CWR flag is sent on new 112 data whenever the sender reacts to congestion. 114 The ECN-nonce adds to this protocol, and enables the receiver to 115 demonstrate to the sender that segments being acknowledged were 116 received unmarked. A random one-bit value (a nonce) is encoded in 117 the two ECT codepoints. The one-bit sum of these nonces is returned 118 in a TCP header flag, the nonce sum (NS) bit. Packet marking erases 119 the nonce value in the ECT codepoints because CE overwrites both ECN 120 IP header bits. Since each nonce is required to calculate the sum, 121 the correct nonce sum implies receipt of only unmarked packets. Not 122 only are receivers prevented from concealing marked packets, middle- 123 boxes along the network path cannot unmark a packet without 124 successfully guessing the value of the original nonce. 126 The sender can verify the nonce sum returned by the receiver to 127 ensure that congestion indications in the form of marked (or dropped) 128 packets are not being concealed. Because the nonce sum is only one 129 bit long, senders have a 50-50 chance of catching a lying receiver 130 whenever an acknowledgement conceals a mark. Because each 131 acknowledgement is an independent trial, cheaters will be caught 132 quickly if there are repeated congestion signals. 134 The following paragraphs describe aspects of the ECN-nonce protocol 135 in greater detail. 137 Each acknowledgement carries a nonce sum, which is the one bit sum 138 (exclusive-or, or parity) of nonces over the byte range represented 139 by the acknowledgement. The sum is used because not every packet is 140 acknowledged individually, nor are packets acknowledged reliably. If 141 a sum were not used, the nonce in an unmarked packet could be echoed 142 to prove to the sender that the individual packet arrived unmarked. 143 However, since these acks are not reliably delivered, the sender 144 could not distinguish a lost ACK from one that was never sent in 145 order to conceal a marked packet. The nonce sum prevents individual 146 marked packets from being concealed by not acknowledging them. 147 Because the nonce and nonce sum are both one bit quantities, the sum 148 is no easier to guess than the individual nonces. We show the nonce 149 sum calculation below in Figure 1. 151 Sender Receiver 152 initial sum = 1 153 -- 1:4 ECT(0) --> NS = 1 + 0(1:4) = 1(:4) 154 <- ACK 4, NS=1 --- 155 -- 4:8 ECT(1) --> NS = 1(:4) + 1(4:8) = 0(:8) 156 <- ACK 8, NS=0 --- 157 -- 8:12 ECT(1) -> NS = 0(:8) + 1(8:12) = 1(:12) 158 <- ACK 12, NS=1 -- 159 -- 12:16 ECT(1) -> NS = 1(:12) + 1(12:16) = 0(:16) 160 <- ACK 16, NS=0 -- 161 Figure 1: The calculation of nonce sums at the receiver. 163 After congestion has occurred and packets have been marked or lost, 164 resynchronization of the sender and receiver nonce sums is needed. 165 When packets are marked, the nonce is cleared, and the sum of the 166 nonces at the receiver will no longer match the sum at the sender. 167 Once nonces have been lost, the difference between sender and 168 receiver nonce sums is constant until there is further loss. This 169 means that it is possible to resynchronize the sender and receiver 170 after congestion by having the sender set its nonce sum to that of 171 the receiver. Because congestion indications do not need to be 172 conveyed more frequently than once per round trip, the sender 173 suspends checking while the CWR signal is being delivered and resets 174 its nonce sum to the receiver's when new data is acknowledged. This 175 has the benefit that the receiver is not explicitly involved in the 176 re-synchronization process. The resynchronization process is shown 177 in Figure 2 below. Note that the nonce sum returned in ACK 12 (NS=0) 178 differs from that in the previous example (NS=1), and it continues to 179 differ for ACK 16. 181 Sender Receiver 182 initial sum = 1 183 -- 1:4 ECT(0) -> NS = 1 + 0(1:4) = 1(:4) 184 <- ACK 4, NS=1 -- 185 -- 4:8 ECT(1) -> CE -> NS = 1(:4) + ?(4:8) = 1(:8) 186 <- ACK 8, ECE NS=1 -- 187 -- 8:12 ECT(1), CWR -> NS = 1(:8) + 1(8:12) = 0(:12) 188 <- ACK 12, NS=0 -- 189 -- 12:16 ECT(1) -> NS = 0(:12) + 1(12:16) = 1(:16) 190 <- ACK 16, NS=1 -- 191 Figure 2: The calculation of nonce sums at the receiver when a 192 packet (4:8) is marked. The receiver may calculate the wrong 193 nonce sum when the original nonce information is lost after a 194 packet is marked. 196 Third, we need to reconcile that nonces are sent with packets but 197 acknowledgements cover byte ranges. Acknowledged byte boundaries 198 need not match the transmitted boundaries, and information can be 199 retransmitted in packets with different byte boundaries. However, 200 ECN is disabled for retransmissions, so can carry no nonce. Since 201 retransmissions are associated with congestion events, nonce checking 202 is suspended until after CWR is acknowledged and the congestion event 203 is over. 205 The next sections describe the detailed behavior of senders, routers 206 and receivers, starting with sender transmit behavior, then around 207 the ECN signaling loop, and finish with sender acknowledgement 208 processing. 210 3. Sender Behavior (Transmit) 212 Senders manage CWR and ECN-Echo as before. In addition, they must 213 place nonces on packets as they are transmitted and check the 214 validity of the nonce sums in acknowledgments as they are received. 215 This section describes the transmit process. 217 To place a one bit nonce value on every ECN-capable IP packet, the 218 sender uses the two ECT codepoints: ECT(0) represents a nonce of 0, 219 and ECT(1) a nonce of 1. As in ECN, retransmissions are not ECN- 220 capable, so carry no nonce. 222 The sender maintains a mapping from each packet's end sequence number 223 to the expected nonce sum (not the nonce placed in the original 224 transmission) in the acknowledgement bearing that sequence number. 226 4. Router Behavior 228 Routers behave as specified in [RFC3168]. By marking packets to 229 signal congestion, the original value of the nonce, in ECT(0) or 230 ECT(1), is removed. Neither the receiver nor any other party can 231 unmark the packet without successfully guessing the value of the 232 original nonce. 234 5. Receiver Behavior (Receive and Transmit) 236 ECN-nonce receivers maintain the nonce sum as in-order packets arrive 237 and return the current nonce sum in each acknowledgement. Receiver 238 behavior is otherwise unchanged from [RFC3168]. Returning the nonce 239 sum is optional, but recommended, as senders are allowed to 240 discontinue sending ECN-capable packets to receivers that do not 241 support the ECN-nonce. 243 As packets are removed from the queue of out-of-order packets to be 244 acknowledged, the nonce is recovered from the IP header. The nonce 245 is added to the current nonce sum as the acknowledgement sequence 246 number is advanced for the recent packet. 248 In the case of marked packets, one or more nonce values may be 249 unknown to the receiver. In this case the missing nonce values are 250 ignored when calculating the sum (or equivalently a value of zero is 251 assumed) and ECN-Echo will be set to signal congestion to the sender. 253 Returning the nonce sum corresponding to a given acknowledgement is 254 straightforward. It is carried in a single "NS" (Nonce Sum) bit in 255 the TCP header. This bit is adjacent to the CWR and ECN-Echo bits, 256 set as Bit 7 in the Reserved field of the TCP header, as shown below: 258 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 259 +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 260 | | | C | E | U | A | P | R | S | F | 261 | Header Length | Reserved | W | C | R | C | S | S | Y | I | 262 | | | R | E | G | K | H | T | N | N | 263 +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 265 Figure 3: The old definition of bytes 13 and 14 of the TCP Header. 267 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 268 +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 269 | | | N | C | E | U | A | P | R | S | F | 270 | Header Length | Reserved | S | W | C | R | C | S | S | Y | I | 271 | | | | R | E | G | K | H | T | N | N | 272 +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 274 Figure 4: The new definition of bytes 13 and 14 of the TCP Header. 276 The initial nonce sum is 1, and is included in the SYN/ACK and ACK of 277 the three way TCP handshake. This allows the other endpoint to infer 278 nonce support, but is not a negotiation, in that the receiver of the 279 SYN/ACK need not check if NS is set to decide whether to set NS in 280 the subsequent ACK. 282 6. Sender Behavior (Receive) 284 This section completes the description of sender behavior by 285 describing how senders check the validity of the nonce sums. 287 The nonce sum is checked when an acknowledgement of new data is 288 received, except during congestion recovery when additional ECN-Echo 289 signals would be ignored. Checking consists of comparing the correct 290 nonce sum stored in a buffer to that carried in the acknowledgement, 291 with a correction described in the following subsection. 293 If ECN-Echo is not set, the receiver claims to have received no 294 marked packets, and can therefore compute and return the correct 295 nonce sum. To conceal a mark, the receiver must successfully guess 296 the sum of the nonces that it did not receive, because at least one 297 packet was marked and the corresponding nonce was erased. Provided 298 the individual nonces are equally likely to be 0 or 1, their sum is 299 equally likely to be 0 or 1. In other words, any guess is equally 300 likely to be wrong and has a 50-50 chance of being caught by the 301 sender. Because each new acknowledgement is an independent trial, a 302 cheating receiver is likely to be caught after a small number of 303 lies. 305 If ECN-Echo is set, the receiver is sending a congestion signal and 306 it is not necessary to check the nonce sum. The congestion window 307 will be halved, CWR will be set on the next packet with new data 308 sent, and ECN-Echo will be cleared once the CWR signal is received, 309 as in [RFC3168]. During this recovery process, the sum may be 310 incorrect because one or more nonces were not received. This does 311 not matter during recovery, because TCP invokes congestion mechanisms 312 at most once per RTT, whether there are one or more losses during 313 that period. 315 6.1 Resynchronization After Loss or Mark 317 After recovery, it is necessary to re-synchronize the sender and 318 receiver nonce sums so that further acknowledgments can be checked. 319 When the receiver's sum is incorrect, it will remain incorrect until 320 further loss. 321 This leads to a simple re-synchronization mechanism where the sender 322 resets its nonce sum to that of the receiver when it receives an 323 acknowledgment for new data sent after the congestion window was 324 reduced. When responding to explicit congestion signals, this will 325 be the first acknowledgement without the ECN-Echo flag set: the 326 acknowledgement of the packet containing the CWR flag. 328 Sender Receiver 329 initial sum = 1 330 -- 1:4 ECT(0) -> NS = 1 + 0(1:4) = 1(:4) 331 <- ACK 4, NS=1 -- 332 -- 4:8 ECT(1) -> LOST 333 -- 8:12 ECT(1) -> nonce sum calculation deferred 334 until in-order data received 335 <- ACK 4, NS=0 -- 336 -- 12:16 ECT(1) -> nonce sum calculation deferred 337 <- ACK 4, NS=0 -- 338 -- 4:8 retransmit -> NS = 1(:4) + ?(4:8) + 339 1(8:12) + 1(12:16) = 1(:16) 340 <- ACK 16, NS=1 -- 341 -- 16:20 ECT(1) CWR -> 342 <- ACK 20, NS=0 -- NS = 1(:16) + 1(16:20) = 0(:20) 344 Figure 5: The calculation of nonce sums at the receiver when a 345 packet is lost, and resynchronization after loss. The nonce sum 346 is not changed until the cumulative acknowledgement is advanced. 348 In practice, resynchronization can be accomplished by storing a bit 349 that has the value one if the expected nonce sum stored by the sender 350 and the received nonce sum in the acknowledgement of CWR differ, and 351 zero otherwise. This synchronization offset bit can then be used in 352 the comparison between expected nonce sum and received nonce sum. 354 The sender should ignore the nonce sum returned on any 355 acknowledgements bearing the ECN-echo flag. 357 When an acknowledgment covers only a portion of a segment, such as 358 when a middlebox resegments at the TCP layer instead of fragmenting 359 IP packets, the sender should accept the nonce sum expected at the 360 next segment boundary. In other words, an acknowledgement covering 361 part of an original segment will include the nonce sum expected when 362 the entire segment is acknowledged. 364 Finally, in ECN, senders can choose not to indicate ECN capability on 365 some packets for any reason. An ECN-nonce sender must resynchronize 366 after sending such ECN-incapable packets, as though a CWR had been 367 sent with the first new data after the ECN-incapable packets. The 368 sender loses protection for any unacknowledged packets until 369 resynchronization occurs. 371 6.2 Sender Behavior - Incorrect Nonce Received 373 The sender's response to an incorrect nonce is a matter of policy. 374 It is separate from the checking mechanism and does not need to be 375 handled uniformly by senders. Further, checking received nonce sums 376 at all is optional, and may be disabled. 378 If the receiver has never sent a non-zero nonce sum, the sender can 379 infer that the receiver does not understand the nonce, and rate limit 380 the connection, place it in a lower-priority queue, or cease setting 381 ECT in outgoing segments. 383 If the received nonce sum has been set in a previous acknowledgement, 384 the sender might infer that a network device has interfered with 385 correct ECN signaling between ECN-nonce supporting endpoints. The 386 minimum response to an incorrect nonce is the same as the response to 387 a received ECE. However, to compensate for hidden congestion 388 signals, the sender might reduce the congestion window to one segment 389 and cease setting ECT in outgoing segments. An incorrect nonce sum is 390 a sign of misbehavior or error between ECN-nonce supporting 391 endpoints. 393 6.2.1 Using the ECN-nonce to Protect Against Other Misbehaviors 395 The ECN-nonce can provide robustness beyond checking that marked 396 packets are signaled to the sender. It also ensures that dropped 397 packets cannot be concealed from the sender (because their nonces 398 have been lost). Drops could potentially be concealed by a faulty 399 TCP implementation, certain attacks, or even a hypothetical TCP 400 accelerator. Such an accelerator could gamble that it can either 401 successfully ``fast start'' to a preset bandwidth quickly, retry with 402 another connection, or provide reliability at the application level. 403 If robustness against these faults is also desired, then the ECN- 404 nonce should not be disabled. Instead, reducing the congestion 405 window to one, or using a low-priority queue, would penalize faulty 406 operation while providing continued checking. 408 The ECN-nonce can also detect misbehavior in Eifel [Eifel], a 409 recently proposed mechanism for removing the retransmission ambiguity 410 to improve TCP performance. A misbehaving receiver might claim to 411 have received only original transmissions to convince the sender to 412 undo congestion actions. Since retransmissions are sent without ECT, 413 and thus no nonce, returning the correct nonce sum confirms that only 414 original transmissions were received. 416 7. Interactions 417 7.1 Path MTU Discovery 419 As described in RFC3168, use of the Don't Fragment bit with ECN is 420 recommended. Receivers that receive unmarked fragments can 421 reconstruct the original nonce to conceal a marked fragment. The 422 ECN-nonce cannot protect against misbehaving receivers that conceal 423 marked fragments, so some protection is lost in situations where Path 424 MTU discovery is disabled. 426 When responding to a small path MTU, the sender will retransmit a 427 smaller frame in place of a larger one. Since these smaller packets 428 are retransmissions, they will be ECN-incapable and bear no nonce. 429 The sender should resynchronize on the first newly transmitted 430 packet. 432 7.2 SACK 434 Selective acknowledgements allow receivers to acknowledge out of 435 order segments as an optimization. It is not necessary to modify the 436 selective acknowledgment option to fit per-range nonce sums, because 437 SACKs cannot be used by a receiver to hide a congestion signal. The 438 nonce sum corresponds only to the data acknowledged by the cumulative 439 acknowledgement. 441 7.3 IPv6 443 Although the IPv4 header is protected by a checksum, this is not the 444 case with IPv6, making undetected bit errors in the IPv6 header more 445 likely. Bit errors that compromise the integrity of the congestion 446 notification fields may cause an incorrect nonce to be received, and 447 an incorrect nonce sum to be returned. 449 8. Security Considerations 451 The random one-bit nonces need not be from a cryptographic-quality 452 pseudo-random number generator. A strong random number generator 453 would compromise performance. Consequently, the sequence of random 454 nonces should not be used for any other purpose. 456 Conversely, the pseudo-random bit sequence should not be generated by 457 a linear feedback shift register [Schneier], or similar scheme that 458 would allow an adversary who has seen several previous bits to infer 459 the generation function and thus its future output. 461 Although the ECN-nonce protects against concealment of congestion 462 signals and optimistic acknowledgement, it provides no additional 463 protection for the integrity of the connection. 465 9. IANA Considerations 467 The Nonce Sum (NS) is carried in a reserved TCP header bit that must 468 be allocated. This document describes the use of Bit 7, adjacent to 469 the other header bits used by ECN. 471 The codepoint for the NS flag in the TCP header is specified by the 472 Standards Action of this RFC, as is required by RFC 2780. When this 473 draft is published as an RFC, IANA should add the following to the 474 registry for "TCP Header Flags": 476 RFC xxx defines bit 7 from the Reserved field to be used for the 477 Nonce Sum, as follows: 479 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 480 +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 481 | | | N | C | E | U | A | P | R | S | F | 482 | Header Length | Reserved | S | W | C | R | C | S | S | Y | I | 483 | | | | R | E | G | K | H | T | N | N | 484 +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 486 TCP Header Flags 488 Bit Name Reference 489 --- ---- --------- 490 7 NS (Nonce Sum) [RFC xxx] 492 10. Conclusion 494 The ECN-nonce is a simple modification to the ECN signaling mechanism 495 that improves ECN's robustness by preventing receivers from 496 concealing marked (or dropped) packets. The intent of this work is 497 to help improve the robustness of congestion control in the Internet. 498 The modification retains the character and simplicity of existing ECN 499 signaling. It is also practical for deployment in the Internet. It 500 uses the ECT(0) and ECT(1) codepoints and one TCP header flag (as 501 well as CWR and ECN-Echo) and has simple processing rules. 503 10. References 505 [ECN] "The ECN Web Page", URL "http://www- 506 nrg.ee.lbl.gov/floyd/ecn.html". 507 [RFC3168] K. Ramakrishnan, S. Floyd, and D. Black. The addition of 508 explicit congestion notification (ECN) to IP. RFC 3168, September, 509 2001. 510 [Eifel] R. Ludwig and R. Katz. The Eifel Algorithm: Making TCP Robust 511 Against Spurious Retransmissions. Computer Communications Review, 512 January, 2000. 514 [B97] Bradner, S., "Key words for use in RFCs to Indicate Requirement 515 Levels", BCP 14, RFC 2119, March 1997. 516 [Savage] S. Savage, N. Cardwell, D. Wetherall, T. Anderson. TCP 517 congestion control with a misbehaving receiver. SIGCOMM CCR, October 518 1999. 519 [Schneier] Bruce Schneier. Applied Cryptography, 2nd ed., 1996 521 Acknowledgements 523 This note grew out of research done by Stefan Savage, David Ely, 524 David Wetherall, Tom Anderson and Neil Spring. We are very grateful 525 for feedback and assistance from Sally Floyd. 527 Authors' Addresses 529 Neil Spring 530 Email: nspring@cs.washington.edu 532 David Wetherall 533 Email: djw@cs.washington.edu 534 Phone +1 (206) 616 4367 536 David Ely 537 Email: ely@cs.washington.edu 539 Computer Science and Engineering, 352350 540 University of Washington 541 Seattle, WA 98195-2350 543 Send comments by electronic mail to all three authors. 545 This draft was created in October 2002. 546 It expires April 2002.