idnits 2.17.1 draft-ietf-tcpm-tcpsecure-09.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 16. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 807. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 818. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 825. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 831. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The abstract seems to contain references ([RFC4271]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. == There are 3 instances of lines with non-RFC2606-compliant FQDNs in the document. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust Copyright Line does not match the current year -- 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 (January 7, 2008) is 5953 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) == Unused Reference: 'RFC3562' is defined on line 753, but no explicit reference was found in the text ** Obsolete normative reference: RFC 793 (Obsoleted by RFC 9293) -- Obsolete informational reference (is this intentional?): RFC 1323 (Obsoleted by RFC 7323) -- Obsolete informational reference (is this intentional?): RFC 2385 (Obsoleted by RFC 5925) Summary: 3 errors (**), 0 flaws (~~), 3 warnings (==), 9 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 TCP Maintenance and Minor A. Ramaiah 3 Extensions Working Group R. Stewart 4 Internet-Draft M. Dalal 5 Intended status: Standards Track Cisco Systems 6 Expires: July 10, 2008 January 7, 2008 8 Improving TCP's Robustness to Blind In-Window Attacks 9 draft-ietf-tcpm-tcpsecure-09.txt 11 Status of this Memo 13 By submitting this Internet-Draft, each author represents that any 14 applicable patent or other IPR claims of which he or she is aware 15 have been or will be disclosed, and any of which he or she becomes 16 aware will be disclosed, in accordance with Section 6 of BCP 79. 18 Internet-Drafts are working documents of the Internet Engineering 19 Task Force (IETF), its areas, and its working groups. Note that 20 other groups may also distribute working documents as Internet- 21 Drafts. 23 Internet-Drafts are draft documents valid for a maximum of six months 24 and may be updated, replaced, or obsoleted by other documents at any 25 time. It is inappropriate to use Internet-Drafts as reference 26 material or to cite them other than as "work in progress." 28 The list of current Internet-Drafts can be accessed at 29 http://www.ietf.org/ietf/1id-abstracts.txt. 31 The list of Internet-Draft Shadow Directories can be accessed at 32 http://www.ietf.org/shadow.html. 34 This Internet-Draft will expire on July 10, 2008. 36 Copyright Notice 38 Copyright (C) The IETF Trust (2008). 40 Abstract 42 TCP has historically been considered protected against spoofed off- 43 path packet injection attacks by relying on the fact that it is 44 difficult to guess the 4-tuple (the source and destination IP 45 addresses and the source and destination ports) in combination with 46 the 32 bit sequence number(s). A combination of increasing window 47 sizes and applications using longer term connections (e.g. H-323 or 48 Border Gateway Protocol [RFC4271]) have left modern TCP 49 implementations more vulnerable to these types of spoofed packet 50 injection attacks. 52 Many of these long term TCP applications tend to have predictable IP 53 addresses and ports which makes it far easier for the 4-tuple to be 54 guessed. Having guessed the 4-tuple correctly, an attacker can 55 inject a RST, SYN or DATA segment into a TCP connection by 56 systematically guessing the sequence number of the spoofed segment to 57 be in the current receive window. This can cause the connection to 58 either abort or possibly cause data corruption. This document 59 specifies small modifications to the way TCP handles inbound segments 60 that can reduce the chances of a successful attack. 62 Table of Contents 64 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 65 1.1. Applicability Statement . . . . . . . . . . . . . . . . . 4 66 1.2. Basic Attack Methodology . . . . . . . . . . . . . . . . . 4 67 1.3. Attack probabilities . . . . . . . . . . . . . . . . . . . 6 68 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 8 69 3. Blind reset attack using the RST bit . . . . . . . . . . . . . 9 70 3.1. Description of the attack . . . . . . . . . . . . . . . . 9 71 3.2. Mitigation . . . . . . . . . . . . . . . . . . . . . . . . 9 72 4. Blind reset attack using the SYN bit . . . . . . . . . . . . . 11 73 4.1. Description of the attack . . . . . . . . . . . . . . . . 11 74 4.2. Mitigation . . . . . . . . . . . . . . . . . . . . . . . . 11 75 5. Blind data injection attack . . . . . . . . . . . . . . . . . 13 76 5.1. Description of the attack . . . . . . . . . . . . . . . . 13 77 5.2. Mitigation . . . . . . . . . . . . . . . . . . . . . . . . 13 78 6. ACK throttling . . . . . . . . . . . . . . . . . . . . . . . . 15 79 7. Backward Compatibility and Other considerations . . . . . . . 16 80 8. Middlebox considerations . . . . . . . . . . . . . . . . . . . 17 81 8.1. Middlebox that resend RST's . . . . . . . . . . . . . . . 17 82 8.2. Middleboxes that advance sequence numbers . . . . . . . . 17 83 9. Security Considerations . . . . . . . . . . . . . . . . . . . 19 84 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 20 85 11. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 21 86 12. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 22 87 13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 23 88 13.1. Normative References . . . . . . . . . . . . . . . . . . . 23 89 13.2. Informative References . . . . . . . . . . . . . . . . . . 23 90 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 25 91 Intellectual Property and Copyright Statements . . . . . . . . . . 26 93 1. Introduction 95 TCP [RFC0793] is widely deployed and the most common reliable end to 96 end transport protocol used for data communication in today's 97 Internet. Yet when it was standardized over 20 years ago, the 98 Internet, was a different place, lacking many of the threats that are 99 now common. The TCP spoofing attacks, which are seen in the Internet 100 today, fall into this category. 102 In a TCP spoofing attack, an off-path attacker crafts TCP packets by 103 forging the IP source and destination addresses as well as the source 104 and destination ports (commonly referred to as a 4-tuple value). The 105 targeted TCP endpoint will then associate such a packet with an 106 existing TCP connection. It needs to be noted that, guessing this 107 4-tuple value is not always easy for an attacker. But there are some 108 applications (e.g. BGP [RFC4271]) that have a tendency to use the 109 same set(s) of ports on either endpoint making the odds of guessing 110 correctly the 4-tuple value much easier. When an attacker is 111 successful in guessing the 4-tuple value, one of three types of 112 injection attacks may be waged against a long-lived connection. 114 RST - Where an attacker injects a RST segment hoping to cause the 115 connection to be torn down. 117 SYN - Where an attacker injects a SYN hoping to cause the receiver 118 to believe the peer has restarted and so tear down the connection 119 state. 121 DATA - Where an attacker tries to inject a DATA segment to corrupt 122 the contents of the transmission. 124 1.1. Applicability Statement 126 The mitigations presented in this document talks about some known in- 127 window attacks and the solutions to the same. The mitigations 128 suggested in this draft SHOULD be implemented in devices where the 129 TCP connections are most vulnerable to the attacks described in this 130 document. Some examples of such TCP connections are the ones that 131 tend to be long-lived where the connection end points can be 132 determined, in cases where no auxiliary anti-spoofing protection 133 mechanisms like TCP MD5 [RFC2385] can be deployed. These mitigations 134 MAY be implemented in other cases. 136 1.2. Basic Attack Methodology 138 Focusing upon the RST attack, we examine this attack in more detail 139 to get an overview as to how it works and how this document addresses 140 the issue. For this attack the goal is for the attacker to cause one 141 of the two endpoints of the connection to incorrectly tear down the 142 connection state, effectively aborting the connection. One of the 143 important things to note is that, for the attack to succeed the RST 144 needs to be in the valid receive window. It also needs to be 145 emphasized that the receive window is independent of the current 146 congestion window of the TCP connection. The attacker would try to 147 forge many RST segments to try to cover the space of possible windows 148 by putting out a packet in each potential window. To do this the 149 attacker needs to have or guess several pieces of information namely: 151 1) The 4-tuple value containing the IP address and TCP port number of 152 both ends of the connection. For one side (usually the server) 153 guessing the port number is a trivial exercise. The client side 154 may or may not be easy for an attacker to guess depending on a 155 number of factors, most notably the operating system and 156 application involved. 158 2) A sequence number that will be used in the RST. This sequence 159 number will be a starting point for a series of guesses to attempt 160 to present a RST segment to a connection endpoint that would be 161 acceptable to it. Any random value may be used to guess the 162 initial sequence number. 164 3) The window size that the two endpoints are using. This value does 165 NOT have to be the exact window size since a smaller value used in 166 lieu of the correct one will just cause the attacker to generate 167 more segments before succeeding in his mischief. Most modern 168 operating systems have a default window size which usually is 169 applied to most connections. Some applications however may change 170 the window size to better suit the needs of the application. So 171 often times the attacker, with a fair degree of certainty (knowing 172 the application that is under attack), can come up with a very 173 close approximation as to the actual window size in use on the 174 connection. 176 After assembling the above set of information the attacker begins 177 sending spoofed TCP segments with the RST bit set and a guessed TCP 178 sequence number. Each time a new RST segment is sent, the sequence 179 number guess is incremented by the window size. The feasibility of 180 this methodology (without mitigations) was first shown in [SITW]. 181 This is because [RFC0793] specifies that any RST within the current 182 window is acceptable. Also [I-D.ietf-tcpm-tcp-antispoof] talks about 183 the probability of a successful attack with varying window sizes and 184 bandwidth. 186 A slight enhancement to the TCP's segment processing rules can be 187 made which makes such an attack much more difficult to accomplish. 188 If the receiver examines the incoming RST segment and validates that 189 the sequence number exactly matches the sequence number that is next 190 expected, then such an attack becomes much more difficult than 191 outlined in [SITW] (i.e. the attacker would have to generate 1/2 the 192 entire sequence space, on average). This document will discuss the 193 exact details of what needs to be changed within TCP's segment 194 processing rules to mitigate all three types of attacks (RST, SYN and 195 DATA). 197 1.3. Attack probabilities 199 Every application has control of a number of factors that effect 200 drastically the probability of a successful spoofing attack. These 201 factors include such things as: 203 Window Size - Normally settable by the application but often times 204 defaulting to 32,768 or 65,535 depending upon the operating system 205 ([Medina05]). 207 Server Port number - This value is normally a fixed value so that a 208 client will know where to connect to the peer at. Thus this value 209 normally provides no additional protection. 211 Client Port number - This value may be a random ephemeral value, if 212 so, this makes a spoofing attack more difficult. There are some 213 clients, however, that for whatever reason either pick a fixed 214 client port or have a very guessable one (due to the range of 215 ephemeral ports available with their operating system or other 216 application considerations) for such applications a spoofing 217 attack becomes less difficult. 219 For the purposes of the rest of this discussion we will assume that 220 the attacker knows the 4-tuple values. This assumption will help us 221 focus on the effects of the window size versus the number of TCP 222 packets an attacker must generate. This assumption will rarely be 223 true in the real Internet since at least the client port number will 224 provide us with some amount of randomness (depending on the operating 225 system). 227 To successfully inject a spoofed packet (RST, SYN or DATA), in the 228 past, the entire sequence space (i.e. 2^32) was often considered 229 available to make such an attack unlikely. [SITW] demonstrated that 230 this assumption was incorrect and that instead of [1/2 * 2^32] 231 packets (assuming a random distribution) [1/2 * (2^32/window)] 232 packets is required. 234 Substituting numbers into this formula we see that for a window size 235 of 32,768, an average of 65,536 packets would need to be transmitted 236 in order to "spoof" a TCP segment that would be acceptable to a TCP 237 receiver. A window size of 65,535 reduces this even further to 238 32,768 packets. At today's access bandwidths an attack of that size 239 is feasible. 241 With rises in bandwidth to both the home and office, it can only be 242 expected that the values for default window sizes will continue to 243 rise in order to better take advantage of the newly available 244 bandwidth. It also needs to be noted that this attack can be 245 performed in a distributed fashion in order potentially gain access 246 to more bandwidth. 248 As we can see from the above discussion this weakness lowers the bar 249 quite considerably for likely attacks. But there is one additional 250 dependency which is the duration of the TCP connection. A TCP 251 connection that lasts only a few brief packets, as often is the case 252 for web traffic, would not be subject to such an attack since the 253 connection may not be established long enough for an attacker to 254 generate enough traffic. However there is a set of applications such 255 as BGP [RFC4271] which is judged to be potentially most affected by 256 this vulnerability. BGP relies on a persistent TCP session between 257 BGP peers. Resetting the connection can result in medium term 258 unavailability due to the need to rebuild routing tables and route 259 flapping; see [NISCC] for further details. 261 For applications that can use the TCP MD5 option [RFC2385], such as 262 BGP, that option makes the attacks described in this specification 263 effectively impossible. However, some applications or 264 implementations may find that option expensive to implement. 266 There are alternative protections against the threats that this 267 document addresses. For further details regarding the attacks and 268 the existing techniques, please refer to draft 269 [I-D.ietf-tcpm-tcp-antispoof] 271 2. Terminology 273 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 274 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 275 document are to be interpreted as described in [RFC2119]. TCP 276 terminology should be interpreted as described in [RFC0793]. 278 3. Blind reset attack using the RST bit 280 3.1. Description of the attack 282 As described in the introduction, it is possible for an attacker to 283 generate a "RST" segment that would be acceptable to a TCP receiver 284 by guessing "in-window" sequence numbers. In particular [RFC0793], 285 p37, states the following: 287 "In all states except SYN-SENT, all reset (RST) segments are 288 validated by checking their SEQ-fields [sequence numbers]. A reset 289 is valid if its sequence number is in the window. In the SYN-SENT 290 state (a RST received in response to an initial SYN), the RST is 291 acceptable if the ACK field acknowledges the SYN." 293 3.2. Mitigation 295 [RFC0793] currently requires handling of a segment with the RST bit 296 when in a synchronized state to be processed as follows: 298 1) If the RST bit is set and the sequence number is outside the 299 current receive window (SEG.SEQ <= RCV.NXT || SEG.SEQ > RCV.NXT+ 300 RCV.WND) , silently drop the segment. 302 2) If the RST bit is set and the sequence number is acceptable i.e.: 303 (RCV.NXT <= SEG.SEQ < RCV.NXT+RCV.WND) then reset the connection. 305 Instead, this document requires that implementations SHOULD implement 306 the following steps in place of those specified in [RFC0793] (as 307 listed above). 309 A) If the RST bit is set and the sequence number is outside the 310 current receive window, silently drop the segment. 312 B) If the RST bit is set and the sequence number exactly matches the 313 next expected sequence number (RCV.NXT), then TCP MUST reset the 314 connection. 316 C) If the RST bit is set and the sequence number does not exactly 317 match the next expected sequence value, yet is within the current 318 receive window (RCV.NXT < SEG.SEQ < RCV.NXT+RCV.WND), TCP MUST 319 send an acknowledgment (challenge ACK): 321 322 After sending the challenge ACK, TCP MUST drop the unacceptable 323 segment and stop processing the incoming packet further. Further 324 segments destined to this connection will be processed as normal. 326 The previous text, quoted from [RFC0793] pg 37 would thus become: 328 In all states except SYN-SENT, all reset (RST) segments are validated 329 by checking their SEQ-fields [sequence numbers]. A reset is valid if 330 its sequence number exactly matches the next expected sequence 331 number. If the RST arrives and its sequence number field does NOT 332 match the next expected sequence number but is within the window, 333 then the receiver should generate an ACK. In all other cases where 334 the SEQ-field does not match and is outside the window, the receiver 335 MUST silently discard the segment. 337 In the SYN-SENT state (a RST received in response to an initial SYN), 338 the RST is acceptable if the ACK field acknowledges the SYN. In all 339 other cases the receiver MUST silently discard the segment. 341 With the above slight change to the TCP state machine, it becomes 342 much harder for an attacker to generate an acceptable reset segment. 344 In cases where the remote peer did generate a RST but it fails to 345 meet the above criteria (the RST sequence number was within the 346 window but NOT the exact expected sequence number) when the challenge 347 ACK is sent back, it will no longer have the transmission control 348 block (TCB) related to this connection and hence as per [RFC0793], 349 the remote peer will send a second RST back. The sequence number of 350 the second RST is derived from the acknowledgment number of the 351 incoming ACK. This second RST, if it reaches the sender, will cause 352 the connection to be aborted since the sequence number would now be 353 an exact match. 355 A valid RST received out-of-order would still generate a challenge 356 ACK in response. If this RST happens to be a genuine one, the other 357 end would send an RST with an exact sequence number match which would 358 cause the connection to be dropped. 360 Note that the above mitigation may cause a non-amplification ACK 361 exchange. This concern is discussed in Section 9. 363 4. Blind reset attack using the SYN bit 365 4.1. Description of the attack 367 The analysis of the reset attack using the RST bit highlights another 368 possible avenue for a blind attacker using a similar set of sequence 369 number guessing. Instead of using the RST bit an attacker can use 370 the SYN bit with the exact same semantics to tear down a connection. 372 4.2. Mitigation 374 [RFC0793] currently requires handling of a segment with the SYN bit 375 set in the synchronized state to be as follows: 377 1) If the SYN bit is set and the sequence number is outside the 378 expected window, send an ACK back to the sender. 380 2) If the SYN bit is set and the sequence number is acceptable i.e.: 381 (RCV.NXT <= SEG.SEQ <= RCV.NXT+RCV.WND) then send a RST segment to 382 the sender. 384 Instead, the handling of the SYN in the synchronized state SHOULD be 385 performed as follows: 387 A) If the SYN bit is set, irrespective of the sequence number, TCP 388 MUST send an ACK (also referred to as challenge ACK) to the remote 389 peer: 391 393 After sending the acknowledgment, TCP MUST drop the unacceptable 394 segment and stop processing further. 396 By sending an ACK, the remote end sender is challenged to confirm the 397 loss of the previous connection and the request to start a new 398 connection. A legitimate peer, after restart, would not have a TCB 399 in the synchronized state. Thus when the ACK arrives the peer should 400 send a RST segment back with the sequence number derived from the ACK 401 field that caused the RST. 403 This RST will confirm that the remote TCP endpoint has indeed closed 404 the previous connection. Upon receipt of a valid RST, the local TCP 405 endpoint MUST terminate its connection. The local TCP endpoint 406 should then rely on SYN retransmission from the remote end to re- 407 establish the connection. 409 A spoofed SYN, on the other hand, will then have generated an 410 additional ACK which the peer will discard as a duplicate ACK and 411 will not affect the established connection. 413 Note that this mitigation does leave one corner case un-handled which 414 will prevent the reset of a connection when it should be reset (i.e. 415 it is a non-spoofed SYN wherein a peer really did restart). This 416 problem occurs when the restarting host chooses the exact same IP 417 address and port number that it was using prior to its restart. By 418 chance the restarted host must also choose an initial sequence number 419 of exactly (RCV.NXT - 1) of the remote TCP endpoint that is still in 420 the established state. Such a case would cause the receiver to 421 generate a "challenge" ACK as described above. But since the ACK 422 would be within the outgoing connections window the inbound ACK would 423 be acceptable, and the sender of the SYN will do nothing with the 424 response ACK. This sequence will continue as the SYN sender 425 continually times out and retransmits the SYN until such time as the 426 connection attempt fails. 428 This corner case is a result of the [RFC0793] specification and is 429 not introduced by these new requirements. 431 Note that the above mitigation may cause a non-amplification ACK 432 exchange. This concern is discussed in Section 9. 434 5. Blind data injection attack 436 5.1. Description of the attack 438 A third type of attack is also highlighted by both the RST and SYN 439 attacks. It is also possible to inject data into a TCP connection by 440 simply guessing a sequence number within the current receive window 441 of the victim. The ACK value of any data segment is considered valid 442 as long as it does not acknowledge data ahead of the next segment to 443 send. In other words an ACK value is acceptable if it is ((SND.UNA- 444 (2^31-1)) <= SEG.ACK <= SND.NXT). The (2^31 - 1) in the above 445 inequality takes into account the fact that comparisons on TCP 446 sequence and acknowledgement numbers is done using the modulo 32 bit 447 arithmetic to accommodate the number wraparound. This means that an 448 attacker has to guess two ACK values with every guessed sequence 449 number so that the chances of successfully injecting data into a 450 connection are 1 in ((2^32 / RCV.WND) * 2). 452 When an attacker successfully injects data into a connection the data 453 will sit in the receiver's re-assembly queue until the peer sends 454 enough data to bridge the gap between the RCV.NXT value and the 455 injected data. At that point one of two things will occur : 457 a) A packet war will ensue with the receiver indicating that it has 458 received data up until RCV.NXT (which includes the attackers data) 459 and the sender sending an ACK with an acknowledgment number less 460 than RCV.NXT. 462 b) The sender will send enough data to the peer which will move 463 RCV.NXT even further along past the injected data. 465 Depending upon the TCP implementation in question and the TCP traffic 466 characteristics at that time, data corruption may result. In case 467 (a) the connection will eventually be reset by one of the sides 468 unless the sender produces more data that will transform the ACK war 469 into case (b). The reset will usually occur via User Time Out (UTO) 470 (see section 4.2.3.5 of [RFC1122]). 472 Note that the protections illustrated in this section neither cause 473 an ACK war nor prevent one from occurring if data is actually 474 injected into a connection. The ACK war is a product of the attack 475 itself and cannot be prevented (other than by preventing the data 476 from being injected). 478 5.2. Mitigation 480 All TCP stacks SHOULD implement the following mitigation. TCP stacks 481 which implement this mitigation MUST add an additional input check to 482 any incoming segment. The ACK value is considered acceptable only if 483 it is in the range of ((SND.UNA - MAX.SND.WND) <= SEG.ACK <= 484 SND.NXT). All incoming segments whose ACK value doesn't satisfy the 485 above condition MUST be discarded silently. A new state variable 486 MAX.SND.WND is defined as the largest window that the local sender 487 has ever received from its peer. This window may be scaled to a 488 value larger than 65,535 bytes ([RFC1323]). This small check will 489 reduce the vulnerability to an attacker guessing a valid sequence 490 number, since he/she not only must guess the in-window sequence 491 number, but also guess a proper ACK value within a scoped range. 492 This mitigation reduces, but does not eliminate, the ability to 493 generate false segments. It does however reduce the probability that 494 invalid data will be injected. 496 Implementations can also chose to hard code the MAX.SND.WND value to 497 the maximum permissible window size i.e., 65535 in the absence of 498 window scaling. In presence of the window scaling option the value 499 becomes (MAX.SND.WND << Snd.Wind.Scale). 501 This mitigation also helps in improving robustness on accepting 502 spoofed FIN segments (FIN attacks). Among other things, this 503 mitigation requires that the attacker also needs to get the 504 acknowledgment number to fall in the range mentioned above in order 505 to successfully spoof a FIN segment leading to the closure of the 506 connection. Thus, this mitigation greatly improves the robustness to 507 spoofed FIN segments. 509 Note that the above mitigation may cause a non-amplification ACK 510 exchange. This concern is discussed in Section 9. 512 6. ACK throttling 514 In order to alleviate multiple RSTs/SYNs from triggering multiple 515 challenge ACKs, an ACK throttling mechanism is suggested as follows : 517 1) The system administrator can configure the number of challenge 518 ACKs that can be sent out in a given interval. For example, in 519 any 5 second window, no more than 10 challenge ACKs should be 520 sent. 522 2) The values for both the time and number of ACKs SHOULD be tunable 523 by the system administrator to accommodate different perceived 524 levels of threat and/or system resources. 526 It should be noted that these numbers are empirical in nature and 527 have been obtained from the RST throttling mechanisms existing in 528 some implementations. Also note that no timer is needed to implement 529 the above mechanism, instead a timestamp and a counter can be used. 531 An implementation SHOULD include an ACK throttling mechanism to be 532 conservative. Currently there is no known bad behavior that can be 533 attributed to the lack of ACK throttling, but as a general principle, 534 if ever invoked, something incorrect is occurring and such a 535 mechanism will act as a failsafe that protects both the sender and 536 the network. 538 An administrator who is more concerned about protecting his bandwidth 539 and CPU utilization may set smaller ACK throttling values whereas an 540 administrator who is more interested in faster cleanup of stale 541 connections (i.e. concerned about excess TCP state) may decide to set 542 a higher value thus allowing more RST's to be processed in any given 543 time period. 545 The time limit SHOULD be tunable to help timeout brute force attacks 546 faster than a potential legitimate flood of RSTs. 548 7. Backward Compatibility and Other considerations 550 All of the new required mitigation techniques in this document are 551 totally compatible with existing ([RFC0793]) compliant TCP 552 implementations as this document introduces no new assumptions or 553 conditions. 555 There is a corner scenario in the above mitigations which will 556 require more than one round trip time to successfully abort the 557 connection as per the figure below. This scenario is similar to the 558 one in which the original RST was lost in the network. 560 TCP A TCP B 561 1.a. ESTAB <-- <-- ESTAB 562 b. (delayed) ... <-- ESTAB 563 c. (in flight) ... <-- CLOSED 564 2. ESTAB --> --> CLOSED 565 (ACK for 1.a) 566 ... <-- CLOSED 567 3. CHALLENGE --> --> CLOSED 568 (for 1.c) 569 ... <-- RESPONSE 570 4.a. ESTAB <-- 1.b reaches A 571 b. ESTAB --> 572 c. (in flight) ... <-- CLOSED 573 5. RESPONSE arrives at A, but dropped since its outside of window. 574 6. ESTAB <-- 4.c reaches A 575 7. CLOSED CLOSED 577 For the mitigation to be maximally effective against the 578 vulnerabilities discussed in this document, both ends of the TCP 579 connection need to have the fix. Although, having the mitigations at 580 one end might prevent that end from being exposed to the attack, the 581 connection is still vulnerable at the other end. 583 8. Middlebox considerations 585 8.1. Middlebox that resend RST's 587 Consider a middlebox M-B tracking connections between two TCP end 588 hosts E-A and E-C. If E-C sends a RST with a sequence number that is 589 within the window but not an exact match to reset the connection and 590 M-B does not have the fix recommended in this document, it may clear 591 the connection and forward the RST to E-A saving an incorrect 592 sequence number. If E-A does not have the fix the connection would 593 get cleared as required. However if E-A does have the required fix, 594 it will send a challenge ACK to E-C. M-B, being a middlebox, may 595 intercept this ACK and resend the RST on behalf of E-C with the old 596 sequence number. This RST will, again, not be acceptable and may 597 trigger a challenge ACK. 599 The above situation may result in a RST/ACK war. However, we believe 600 that if such a case exists in the Internet, the middle box design 601 does not comply to [RFC0793]. [RFC0793] dictates that the sequence 602 number of a RST has to be derived from the acknowledgment number of 603 the incoming ACK segment. It is outside the scope of this document 604 to suggest mitigations to the ill-behaved middleboxes. 606 Consider a similar scenario where the RST from M-B to E-A gets lost, 607 E-A will continue to hold the connection and E-A might send an ACK an 608 arbitrary time later after the connection state was destroyed at M-B. 609 For this case, M-B will have to cache the RST for an arbitrary amount 610 of time till until it is confirmed that the connection has been 611 cleared at E-A. 613 8.2. Middleboxes that advance sequence numbers 615 Some middleboxes may compute RST sequence numbers at the higher end 616 of the acceptable window. The scenario is the same as the earlier 617 case, but in this case instead of sending the cached RST, the 618 middlebox (M-B) sends a RST that computes its sequence number as the 619 sum of the acknowledgement field in the ACK and the window advertised 620 by the ACK that was sent by E-A to challenge the RST as depicted 621 below. The difference in the sequence numbers between step 1 and 2 622 below is due to data lost in the network. 624 TCP A Middlebox 626 1. ESTABLISHED <-- <-- CLOSED 628 2. ESTABLISHED --> --> CLOSED 630 3. ESTABLISHED <-- <-- CLOSED 632 4. ESTABLISHED --> --> CLOSED 634 5. ESTABLISHED <-- <-- CLOSED 636 Although the authors are not aware of an implementation that does the 637 above, it could be mitigated by implementing the ACK throttling 638 mechanism described earlier. 640 9. Security Considerations 642 These changes to the TCP state machine do NOT protect an 643 implementation from on-path attacks. It also needs to be emphasized 644 that while mitigations within this document make it harder for off- 645 path attackers to inject segments, it does NOT make it impossible. 646 The only way to fully protect a TCP connection from both on and off 647 path attacks is by using either IPSEC-AH [RFC4302] or IPSEC-ESP 648 [RFC4303]. 650 Implementers also should be aware that the attacks detailed in this 651 specification are not the only attacks available to an off-path 652 attacker and that the counter measures described herein are not a 653 comprehensive defense against such attacks. 655 In particular, administrators should be aware that forged ICMP 656 messages provide off-path attackers the opportunity to disrupt 657 connections or degrade service. Such attacks may be subject to even 658 less scrutiny than the TCP attacks addressed here, especially in 659 stacks not tuned for hostile environments. It is important to note 660 that some ICMP messages, validated or not, are key to the proper 661 function of TCP. Those ICMP messages used to properly set the path 662 maximum transmission unit are the most obvious example. There are a 663 variety of ways to choose which, if any, ICMP messages to trust in 664 the presence of off-path attackers and choosing between them depends 665 on the assumptions and guarantees developers and administrators can 666 make about their network. This specification does not attempt to do 667 more than note this and related issues. 669 In any case, this RFC details only part of a complete strategy to 670 prevent off-path attackers from disrupting services that use TCP. 671 Administrators and implementers should consider the other attack 672 vectors and determine appropriate mitigations in securing their 673 systems. 675 Another notable consideration is that a reflector attack is possible 676 with the required RST/SYN mitigation techniques. In this attack, an 677 off-path attacker can cause a victim to send an ACK segment for each 678 spoofed RST/SYN segment that lies within the current receive window 679 of the victim. It should be noted, however, that this does not cause 680 any amplification since the attacker must generate a segment for each 681 one that the victim will generate. 683 10. IANA Considerations 685 This document contains no IANA considerations. 687 11. Contributors 689 Mitesh Dalal and Amol Khare of Cisco Systems came up with the 690 solution for the RST/SYN attacks. Anantha Ramaiah and Randall 691 Stewart of Cisco Systems discovered the data injection vulnerability 692 and together with Patrick Mahan and Peter Lei of Cisco Systems found 693 solutions for the same. Paul Goyette, Mark Baushke, Frank 694 Kastenholz, Art Stine and David Wang of Juniper Networks provided the 695 insight that apart from RSTs, SYNs could also result in formidable 696 attacks. Shrirang Bage of Cisco Systems, Qing Li and Preety Puri of 697 Wind River Systems and Xiaodan Tang of QNX Software along with the 698 folks above helped in ratifying and testing the interoperability of 699 the suggested solutions. 701 ACK throttling was introduced to this document by combining the 702 suggestions from the tcpm working group. 704 12. Acknowledgments 706 Special thanks to Mark Allman, Ted Faber, Steve Bellovin, Vern 707 Paxson, Allison Mankin, Sharad Ahlawat, Damir Rajnovic, John Wong, 708 Joe Touch, Alfred Hoenes and other members of the tcpm WG for 709 suggestions and comments. 711 13. References 713 13.1. Normative References 715 [RFC0793] Postel, J., "Transmission Control Protocol", STD 7, 716 RFC 793, September 1981. 718 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 719 Requirement Levels", BCP 14, RFC 2119, March 1997. 721 [RFC4302] Kent, S., "IP Authentication Header", RFC 4302, 722 December 2005. 724 [RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)", 725 RFC 4303, December 2005. 727 13.2. Informative References 729 [I-D.ietf-tcpm-tcp-antispoof] 730 Touch, J., "Defending TCP Against Spoofing Attacks", 731 draft-ietf-tcpm-tcp-antispoof-06 (work in progress), 732 February 2007. 734 [Medina05] 735 Medina, A., Allman, M., and S. Floyd, "Measuring the 736 Evolution of Transport Protocols in the Internet. ACM 737 Computer Communication Review, 35(2), April 2005. 738 http://www.icir.org/mallman/papers/tcp-evo-ccr05.ps 739 (figure 6)". 741 [NISCC] NISCC, "NISCC Vulnerability Advisory 236929 - 742 Vulnerability Issues in TCP". 744 [RFC1122] Braden, R., "Requirements for Internet Hosts - 745 Communication Layers", STD 3, RFC 1122, October 1989. 747 [RFC1323] Jacobson, V., Braden, B., and D. Borman, "TCP Extensions 748 for High Performance", RFC 1323, May 1992. 750 [RFC2385] Heffernan, A., "Protection of BGP Sessions via the TCP MD5 751 Signature Option", RFC 2385, August 1998. 753 [RFC3562] Leech, M., "Key Management Considerations for the TCP MD5 754 Signature Option", RFC 3562, July 2003. 756 [RFC4271] Rekhter, Y., Li, T., and S. Hares, "A Border Gateway 757 Protocol 4 (BGP-4)", RFC 4271, January 2006. 759 [SITW] Watson, P., "Slipping in the Window: TCP Reset attacks, 760 Presentation at 2004 CanSecWest 761 http://www.cansecwest.com/archives.html". 763 Authors' Addresses 765 Anantha Ramaiah 766 Cisco Systems 767 170 Tasman Drive 768 San Jose, CA 95134 769 USA 771 Phone: +1 (408) 525-6486 772 Email: ananth@cisco.com 774 Randall R. Stewart 775 Cisco Systems 776 4875 Forest Drive 777 Suite 200 778 Columbia, SC 29206 779 USA 781 Phone: +1 (803) 345-0369 782 Email: rrs@cisco.com 784 Mitesh Dalal 785 Cisco Systems 786 170 Tasman Drive 787 San Jose, CA 95134 788 USA 790 Phone: +1 (408) 853-5257 791 Email: mdalal@cisco.com 793 Full Copyright Statement 795 Copyright (C) The IETF Trust (2008). 797 This document is subject to the rights, licenses and restrictions 798 contained in BCP 78, and except as set forth therein, the authors 799 retain all their rights. 801 This document and the information contained herein are provided on an 802 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 803 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 804 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 805 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 806 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 807 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 809 Intellectual Property 811 The IETF takes no position regarding the validity or scope of any 812 Intellectual Property Rights or other rights that might be claimed to 813 pertain to the implementation or use of the technology described in 814 this document or the extent to which any license under such rights 815 might or might not be available; nor does it represent that it has 816 made any independent effort to identify any such rights. Information 817 on the procedures with respect to rights in RFC documents can be 818 found in BCP 78 and BCP 79. 820 Copies of IPR disclosures made to the IETF Secretariat and any 821 assurances of licenses to be made available, or the result of an 822 attempt made to obtain a general license or permission for the use of 823 such proprietary rights by implementers or users of this 824 specification can be obtained from the IETF on-line IPR repository at 825 http://www.ietf.org/ipr. 827 The IETF invites any interested party to bring to its attention any 828 copyrights, patents or patent applications, or other proprietary 829 rights that may cover technology that may be required to implement 830 this standard. Please address the information to the IETF at 831 ietf-ipr@ietf.org. 833 Acknowledgment 835 Funding for the RFC Editor function is provided by the IETF 836 Administrative Support Activity (IASA).