idnits 2.17.1 draft-ietf-tsvwg-tcp-ecn-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** 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 8 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 9 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 ([RFC2481]), 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 38: '...in the IP header SHOULD NOT be set on ...' RFC 2119 keyword, line 39: '...CP data receiver SHOULD ignore the ECN...' RFC 2119 keyword, line 45: '...n the TCP header SHOULD NOT be set on ...' RFC 2119 keyword, line 47: '...stion window, it SHOULD set the CWR bi...' RFC 2119 keyword, line 81: '... TCP data sender SHOULD NOT set the EC...' (12 more instances...) 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 (November 2000) is 8562 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) ** Obsolete normative reference: RFC 2481 (Obsoleted by RFC 3168) Summary: 7 errors (**), 0 flaws (~~), 3 warnings (==), 2 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 ACIRI 3 draft-ietf-tsvwg-tcp-ecn-00.txt K. K. Ramakrishnan 4 TeraOptic Networks 5 November 2000 6 Expires: May 2001 8 TCP with ECN: The Treatment of Retransmitted Data Packets 10 Status of this Memo 12 This document is an Internet-Draft and is in full conformance with 13 all provisions of Section 10 of RFC2026. 15 Internet-Drafts are working documents of the Internet Engineering 16 Task Force (IETF), its areas, and its working groups. Note that 17 other groups may also distribute working documents as Internet- 18 Drafts. 20 Internet-Drafts are draft documents valid for a maximum of six months 21 and may be updated, replaced, or obsoleted by other documents at any 22 time. It is inappropriate to use Internet- Drafts as reference 23 material or to cite them other than as "work in progress." 25 The list of current Internet-Drafts can be accessed at 26 http://www.ietf.org/ietf/1id-abstracts.txt 28 The list of Internet-Draft Shadow Directories can be accessed at 29 http://www.ietf.org/shadow.html. 31 Abstract 33 This document makes recommendations for the use of ECN with 34 retransmitted data packets, for an ECN-capable TCP connection. This 35 document supplements RFC 2481 [RFC2481], which did not address the 36 issue of retransmitted data packets. This document recommends that 37 for ECN-capable TCP implementations, the ECT bit (ECN-Capable 38 Transport) in the IP header SHOULD NOT be set on retransmitted data 39 packets, and that the TCP data receiver SHOULD ignore the ECN field 40 on arriving data packets that are outside of the receiver's current 41 window. This is for greater security against denial-of-service 42 attacks. 44 In addition, this document recommends that the CWR bit (Congestion 45 Window Reduced) in the TCP header SHOULD NOT be set on retransmitted 46 packets. When the TCP data sender is ready to set the CWR bit after 47 reducing the congestion window, it SHOULD set the CWR bit on the 48 first new data packet that it transmits. 50 1. Introduction 52 RFC 2481, which describes both the TCP and IP semantics for ECN, does 53 not make any special mention of retransmitted TCP packets. It is 54 important to make special mention of the use of ECN with 55 retransmitted packets, especially the setting of the ECT bit on 56 retransmitted packets. If TCP is allowed to set the ECT bit on 57 retransmitted data packets, this could open the door for denial-of- 58 service attacks. 60 In particular, an attacker capable of spoofing the IP source address 61 could send data packets with arbitrary sequence numbers, with both 62 the ECT and CE bits set in the IP header. On receiving this spoofed 63 data packet, the TCP data receiver would determine that the data does 64 not lie in the current receive window, and return a duplicate 65 acknowledgement. We define an out-of-window packet at the TCP data 66 receiver as a data packet that lies outside the receiver's current 67 window. On receiving an out-of-window packet, the TCP data receiver 68 has to decide whether or not to treat the CE bit in the packet header 69 as a valid indication of congestion, and therefore whether to return 70 ECN-Echo indications to the TCP data sender. If the TCP data 71 receiver ignored the CE bit in an out-of-window packet, then the TCP 72 data sender would not receive this possibly-legitimate indication of 73 congestion, resulting in a violation of end-to-end congestion 74 control. On the other hand, if the TCP data receiver honors the CE 75 indication in the out-of-window packet, and reports the indication of 76 congestion to the TCP data sender, then the malicious node that 77 created the spoofed, out-of-window packet has successfully 78 ``attacked'' the TCP connection by forcing the data sender to 79 unnecessarily reduce (halve) its congestion window. To prevent such 80 a denial-of-service attack, Section 2 of this document recommends 81 that a legitimate TCP data sender SHOULD NOT set the ECT bit on 82 retransmitted data packets, and that the TCP data receiver SHOULD 83 ignore the CE bit on out-of-window packets. 85 2. ECN and Retransmitted Data Packets 87 In this document we assume an environment where it is possible for a 88 malicious host to spoof the legitimate IP source address of a TCP 89 connection, and to send a data packet with the spoofed source address 90 along with the ECT and CE bits set. In order to protect itself 91 against a denial-of-service attack, the TCP connection has to refrain 92 from halving its congestion window in response to such a spoofed data 93 packet. 95 There are several possible ways that a TCP connection could protect 96 itself from such a denial-of-service attack: 98 (1) Not using ECN on retransmits: The TCP receiver could ignore 99 the CE bit on out-of-window packets, knowing that a conformant 100 sender would not set the ECT bit on retransmitted packets. 102 (2) Ignoring ECN on out-of-window packets: The TCP receiver could 103 ignore the CE bit on out-of-window packets, knowing that a 104 conformant sender would not set the ECT bit on retransmitted 105 packets. 107 (3) Ignoring ECN on significantly out-of-window packets: The TCP 108 receiver could ignore the CE bit on packets far outside the 109 current window, while a conformant sender could be allowed to set 110 the ECT bit on retransmitted packets. 112 (4) Verifying out-of-window ECN packets: The TCP receiver could 113 report to the sender the sequence numbers of an out-of-window data 114 packet with the CE bit set, and the sender could halve its 115 congestion window only if it had in fact recently sent this 116 packet. 118 In this document we discuss each of these four proposals, and explain 119 why we follow the first proposal, to not use ECN on retransmitted 120 data packets (by not setting the ECT bit on these packets), for ECN- 121 Capable TCP implementations. 123 2.1. Option 1: Not Using ECN on Retransmits. 125 This document recommends Option 1, not using ECN on retransmitted 126 packets. This approach is simple, straightforward, and protects 127 against ECN-based denial-of-service attacks. (This assumes that the 128 attacker is unable to guess the initial sequence number (ISN) of a 129 TCP connection, and therefore is unlikely to guess a sequence number 130 for a spoofed packet that is within the current window.) 132 The drawback of Option 1 is that it denies ECN protection for 133 retransmitted packets. However, for an ECN-capable TCP connection in 134 a fully-ECN-capable environment with mild congestion, packets should 135 rarely be dropped due to congestion in the first place, and so 136 instances of retransmitted packets should rarely arise. If packets 137 are being retransmitted, then there are already packet losses (from 138 corruption or from congestion) that ECN has been unable to prevent. 140 We note that, with Option 1, if the router sets the CE bit for an 141 ECN-capable data packet within a TCP connection, then the TCP 142 connection is guaranteed to receive that indication of congestion, or 143 to receive some other indication of congestion within the same window 144 of data, even if this packet is dropped or reordered in the network. 145 We consider two cases, when the packet is later retransmitted, and 146 when the packet is not later retransmitted. 148 In the first case, if the packet is either dropped or delayed, and at 149 some point retransmitted by the data sender, then the retransmission 150 is a result of a Fast Retransmit or a Retransmit Timeout for either 151 that packet or for some prior packet in the same window of data. In 152 this case, because the data sender already has retransmitted this 153 packet, we know that the data sender has already responded to an 154 indication of congestion for some packet within the same window of 155 data as the original packet. Thus, even if this retransmitted packet 156 is dropped in the network, or is delayed, with the CE bit set, and is 157 later ignored by the data receiver as an out-of-window packet, this 158 is not a problem, because the sender has already responded to an 159 indication of congestion for that window of data. Communicating the 160 indication of congestion with the CE bit for this retransmitted 161 packet (if that indication is provided to the sender within the same 162 window of data as a previously dropped packet) would not have 163 resulted in any further reduction of the window by the sender. 165 In the second case, if the packet is never retransmitted by the data 166 sender, then this data packet is the only copy of this data received 167 by the data receiver, and therefore arrives at the data receiver as 168 an in-window packet, regardless of how much the packet might be 169 delayed or reordered. In this case, if the CE bit is set on the 170 packet within the network, this will be treated by the data receiver 171 as a valid indication of congestion. 173 2.2. Option 2: Ignoring ECN on Out-of-window Packets? 175 A second option for protecting against ECN-based denial-of-service 176 attacks would be for the TCP data sender to be allowed to set the CE 177 bit on retransmitted packets, but for the TCP data receiver to ignore 178 the CE bit on out-of-window data packets. However, this would have 179 the unfortunate consequence of weakening the effectiveness of ECN- 180 based end-to-end congestion control (by carrying over to ECN some of 181 the existing weaknesses of packet drops as indications of 182 congestion). 184 We will say that a retransmitted TCP packet is ``necessarily- 185 retransmitted'' if the retransmission is the only copy of this data 186 received at the TCP receiver, and ``unnecessarily-retransmitted'' 187 otherwise. For TCP, drops of unnecessarily-retransmitted data 188 packets are not detected as indications of congestion by the TCP end 189 nodes. That is, if a necessarily-retransmitted TCP packet is 190 dropped, then the packet loss is detected by the TCP receiver, and 191 TCP reduces its sending rate. In contrast, if an unnecessarily- 192 retransmitted TCP packet is dropped, then that loss is not detected 193 by the TCP receiver, and TCP does not reduce its sending rate. 195 Option 2, of ignoring ECN on out-of-window packets, would effectively 196 prevent ECN-based denial-of-service attacks using retransmitted 197 packets. At the same time, allowing the data receiver to ignore ECN 198 information on out-of-window packets would carry over to ECN the 199 weaknesses of packet drops as indications of congestion: that packet 200 drops of unnecessarily-retransmitted packets are not detected as 201 indications of congestion by the TCP end hosts. With Option 2, a 202 necessarily-retransmitted TCP packet would be in-window when received 203 at the TCP receiver, and ECN indications in the packet header would 204 be treated normally by the TCP receiver. However, an unnecessarily- 205 retransmitted TCP packet would most likely be out-of-window when 206 received at the TCP receiver, and therefore, with Option 2, any ECN 207 information in the packet header would be ignored. Setting the ECT 208 bit on unnecessarily-retransmitted TCP packets has the potential that 209 routers would mark rather than drop such packets. A receiver ignoring 210 the CE bit on such a packet would result in not communicating the 211 congestion indication to the TCP sender, making the ECN information 212 as unreliable as packet drops for unnecessarily-retransmitted 213 packets. However, it is not sufficient for ECN to be merely as 214 reliable as packet losses as indications of congestion. An attempt 215 by a congested router to avoid dropping the unnecessarily- 216 retransmitted packet and provide an indication of congestion via ECN 217 would be negated by Option 2. With Option 2, a transport would 218 communicate that it is ECN-capable by setting the ECT bit, but would 219 ignore the CE bit. In addition to violating the semantics of ECN, 220 this could also have an impact on other flows, both in terms of 221 fairness and the possible congestion experienced by such other flows. 223 The principle has already been established for TCP that the ECT bit 224 should not be set on a packet if there will be no viable congestion- 225 control response by the transport to a router setting the CE bit in 226 the packet header. Consider the example of pure acknowledgement 227 (ACK) packets. TCP does not have effective, loss-based end-to-end 228 congestion control for ACK packets, that is, packets that don't 229 contain any data. If a pure ACK packet in a TCP connection is 230 dropped, the TCP connection does not respond by reducing its sending 231 rate along that path. Because current TCP receivers have no 232 mechanisms for reducing traffic on the ACK-path in response to 233 congestion notification, RFC 2481 specifies that the ECT bit should 234 not be set on pure ACK packets. 236 Therefore, our view is that Option 2 is not a viable option for 237 preventing ECN-based denial-of-service attacks on a connection. 239 2.3. Option 3: Ignoring ECN on significantly out-of-window packets: 241 With Option 3, the TCP data sender would be allowed to set the CE bit 242 on retransmitted packets, and the TCP connection would protect itself 243 from ECN on spoofed packets by checking the sequence numbers of out- 244 of-window packets that arrive with the CE bit set. Consider a data 245 receiver that has acknowledged data up to and including sequence 246 number N, and has a window of W bytes. If the out-of-window data is 247 contained within the sequence number range (N-W, N] (modulo the 248 proper amount), then the CE bit on the out-of-window packet is 249 treated as a valid indication of congestion, and otherwise the CE bit 250 on the out-of-window packet is ignored. This is based on the view 251 that the receiver considers the range (N-W, N] to represent a range 252 of data that could plausibly result from retransmissions from the 253 legitimate data source. 255 Option 3 would make it somewhat easier for a malicious host to guess 256 a sequence-number range for which a CE bit would be treated as a 257 valid indication of congestion, and therefore would make an ECN-based 258 denial-of-service attack somewhat more likely to be successful. 259 However, Option 3 would still offer a significant protection against 260 denial-of-service attacks because the malicious host has to guess the 261 appropriate sequence number range. 263 However, Option 3 introduces some additional complexity at the TCP 264 data receiver, and would not necessarily result in the CE bit being 265 respected on all data packets actually sent by the legitimate data 266 sender. While Option 3 has the benefit over Option 1 of allowing the 267 sender to set the ECT bit on retransmitted packets, the benefit does 268 not seem worth the additional cost at the data receiver. 270 2.4. Option 4: Verifying out-of-window ECN packets? 272 With Option 4, the TCP data sender would be allowed to set the CE bit 273 on retransmitted packets, and the TCP connection would protect itself 274 from ECN on spoofed packets by having the data receiver report to the 275 data sender the sequence numbers of the data in out-of-window packets 276 with the CE bit set. Using this sequence-number information, the 277 data sender could verify that it had actually sent this retransmitted 278 packet before honoring the ECN indication of congestion. If the data 279 sender determined that this packet was in fact from another host that 280 had spoofed its IP address, then the data sender could ignore this 281 indication of congestion. 283 At first glance this seems simple, but Option 4 would actually turn 284 into something rather complicated. The ECN-Echo information is 285 carried from the data receiver to the data sender not just in one ACK 286 packet, but possibly in a number of successive ACK packets. In 287 addition, the data receiver could receive multiple data packets with 288 the CE bit set, which are treated by the data sender as a single 289 instance of congestion. The benefits of Option 4 do not seem likely 290 to be worth the extra complexity that would be entailed. In 291 addition, this would require significant additional changes to the 292 header and to the standardization process for such use. 294 In summary, this document recommends Option 1, that the ECT bit 295 SHOULD NOT be set on retransmitted data packets, and that the TCP 296 data receiver SHOULD ignore the ECN field on out-of-window data 297 packets. 299 3. Setting the CWR bit. 301 RFC 2481 says the following regarding the setting of the CWR bit: 302 ``When an ECN-Capable TCP reduces its congestion window for any 303 reason (because of a retransmit timeout, a Fast Retransmit, or in 304 response to an ECN Notification), the TCP sets the CWR flag in the 305 TCP header of the first data packet sent after the window reduction. 306 If that data packet is dropped in the network, then the sending TCP 307 will have to reduce the congestion window again and retransmit the 308 dropped packet. Thus, the Congestion Window Reduced message is 309 reliably delivered to the data receiver." 311 However, as noted earlier in this document, if a retransmitted data 312 packet is dropped in the network, the sending TCP does not 313 necessarily respond by reducing its congestion window. Therefore, 314 the CWR bit SHOULD NOT be set on retransmitted packets. Instead, 315 when the TCP data sender is ready to set the CWR bit after reducing 316 the congestion window, it SHOULD set the CWR bit on the first *new* 317 data packet that it subsequently transmits. 319 4. ECN and window probes. 321 When the TCP data receiver advertises a zero window, the TCP data 322 sender sends window probes to determine if the receiver's window has 323 increased. Window probe packets do not contain any user data except 324 for the sequence number, which is a byte. Because window probes use 325 the exact sequence numbers, they cannot be easily spoofed in denial- 326 of-service attacks. Therefore, if a window probe arrives with ECT 327 and CE set, then the receiver SHOULD respond to the ECN indications. 329 At the same time, if a window probe packet is dropped in the network, 330 this loss is not detected by the receiver. Therefore, the TCP data 331 sender SHOULD NOT set either the ECT or CWR bits on window probe 332 packets. 334 5. Conclusions 336 This document recommends that for ECN-capable TCP implementations, 337 the ECT bit SHOULD NOT be set on retransmitted data packets, and that 338 the TCP data receiver SHOULD ignore the ECN field on out-of-window 339 data packets. This is for greater security against denial-of-service 340 attacks. 342 In addition, this document recommends that the CWR bit (Congestion 343 Window Reduced) in the TCP header SHOULD NOT be set on retransmitted 344 packets. When the TCP data sender is ready to set the CWR bit after 345 reducing the congestion window, it SHOULD set the CWR bit on the 346 first *new* data packet that it transmits. 348 Finally, this document recommends that a TCP data sender SHOULD NOT 349 set either the ECT or CWR bits on window probe packets. 351 6. Acknowledgements 353 This note resulted from email discussions with a number of people, 354 including Alexey Kuznetsov, Jamal Hadi-Salim, and Venkat Venkatsubra. 356 7. References 358 [RFC2481] K. Ramakrishnan, S. Floyd, A Proposal to add Explicit 359 Congestion Notification (ECN) to IP, RFC 2481, January 1999. 361 8. Security Considerations 363 Security considerations have been addressed in the main body of the 364 document. 366 AUTHORS' ADDRESSES 368 K. K. Ramakrishnan 369 TeraOptic Networks 370 Phone: +1 (408) 666-8650 371 Email: kk@teraoptic.com 373 Sally Floyd 374 Phone: +1 (510) 666-2989 375 ACIRI 376 Email: floyd@aciri.org 377 URL: http://www.aciri.org/floyd/ 379 This draft was created in November 2000. 380 It expires May 2001.