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