idnits 2.17.1 draft-ietf-tcpm-tcpsecure-13.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. 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 ([RFC0793], [RFC4271]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. == There are 4 instances of lines with non-RFC2606-compliant FQDNs in the document. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors 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 (May 3, 2010) is 5100 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 793 (Obsoleted by RFC 9293) == Outdated reference: A later version (-09) exists of draft-ietf-tsvwg-port-randomization-07 -- Obsolete informational reference (is this intentional?): RFC 1323 (Obsoleted by RFC 7323) -- Obsolete informational reference (is this intentional?): RFC 1948 (Obsoleted by RFC 6528) -- Obsolete informational reference (is this intentional?): RFC 2385 (Obsoleted by RFC 5925) Summary: 2 errors (**), 0 flaws (~~), 3 warnings (==), 5 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 Cisco Systems 4 Internet-Draft R. Stewart 5 Intended status: Standards Track Huawei 6 Expires: November 4, 2010 M. Dalal 7 Cisco Systems 8 May 3, 2010 10 Improving TCP's Robustness to Blind In-Window Attacks 11 draft-ietf-tcpm-tcpsecure-13.txt 13 Abstract 15 TCP has historically been considered protected against spoofed off- 16 path packet injection attacks by relying on the fact that it is 17 difficult to guess the 4-tuple (the source and destination IP 18 addresses and the source and destination ports) in combination with 19 the 32 bit sequence number(s). A combination of increasing window 20 sizes and applications using longer term connections (e.g. H-323 or 21 Border Gateway Protocol [RFC4271]) have left modern TCP 22 implementations more vulnerable to these types of spoofed packet 23 injection attacks. 25 Many of these long term TCP applications tend to have predictable IP 26 addresses and ports which makes it far easier for the 4-tuple 27 (4-tuple is the same as the socket pair mentioned in [RFC0793]) to be 28 guessed. Having guessed the 4-tuple correctly, an attacker can 29 inject a TCP segment with the RST bit set, the SYN bit set or data 30 into a TCP connection by systematically guessing the sequence number 31 of the spoofed segment to be in the current receive window. This can 32 cause the connection to abort or cause data corruption. This 33 document specifies small modifications to the way TCP handles inbound 34 segments that can reduce the chances of a successful attack. 36 Status of this Memo 38 This Internet-Draft is submitted in full conformance with the 39 provisions of BCP 78 and BCP 79. 41 Internet-Drafts are working documents of the Internet Engineering 42 Task Force (IETF). Note that other groups may also distribute 43 working documents as Internet-Drafts. The list of current Internet- 44 Drafts is at http://datatracker.ietf.org/drafts/current/. 46 Internet-Drafts are draft documents valid for a maximum of six months 47 and may be updated, replaced, or obsoleted by other documents at any 48 time. It is inappropriate to use Internet-Drafts as reference 49 material or to cite them other than as "work in progress." 51 This Internet-Draft will expire on November 4, 2010. 53 Copyright Notice 55 Copyright (c) 2010 IETF Trust and the persons identified as the 56 document authors. All rights reserved. 58 This document is subject to BCP 78 and the IETF Trust's Legal 59 Provisions Relating to IETF Documents 60 (http://trustee.ietf.org/license-info) in effect on the date of 61 publication of this document. Please review these documents 62 carefully, as they describe your rights and restrictions with respect 63 to this document. Code Components extracted from this document must 64 include Simplified BSD License text as described in Section 4.e of 65 the Trust Legal Provisions and are provided without warranty as 66 described in the Simplified BSD License. 68 Table of Contents 70 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 71 1.1. Applicability Statement . . . . . . . . . . . . . . . . . 4 72 1.2. Basic Attack Methodology . . . . . . . . . . . . . . . . . 5 73 1.3. Attack probabilities . . . . . . . . . . . . . . . . . . . 6 74 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 8 75 3. Blind reset attack using the RST bit . . . . . . . . . . . . . 9 76 3.1. Description of the attack . . . . . . . . . . . . . . . . 9 77 3.2. Mitigation . . . . . . . . . . . . . . . . . . . . . . . . 9 78 4. Blind reset attack using the SYN bit . . . . . . . . . . . . . 11 79 4.1. Description of the attack . . . . . . . . . . . . . . . . 11 80 4.2. Mitigation . . . . . . . . . . . . . . . . . . . . . . . . 11 81 5. Blind data injection attack . . . . . . . . . . . . . . . . . 13 82 5.1. Description of the attack . . . . . . . . . . . . . . . . 13 83 5.2. Mitigation . . . . . . . . . . . . . . . . . . . . . . . . 14 84 6. Suggested Mitigation strengths . . . . . . . . . . . . . . . . 15 85 7. ACK throttling . . . . . . . . . . . . . . . . . . . . . . . . 16 86 8. Backward Compatibility and Other considerations . . . . . . . 17 87 9. Middlebox considerations . . . . . . . . . . . . . . . . . . . 18 88 9.1. Middlebox that resend RST's . . . . . . . . . . . . . . . 18 89 9.2. Middleboxes that advance sequence numbers . . . . . . . . 18 90 9.3. Middleboxes that drop the challenge ACK . . . . . . . . . 19 91 10. Security Considerations . . . . . . . . . . . . . . . . . . . 20 92 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 21 93 12. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 22 94 13. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 23 95 14. References . . . . . . . . . . . . . . . . . . . . . . . . . . 24 96 14.1. Normative References . . . . . . . . . . . . . . . . . . . 24 97 14.2. Informative References . . . . . . . . . . . . . . . . . . 24 98 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 26 100 1. Introduction 102 TCP [RFC0793] is widely deployed and the most common reliable end to 103 end transport protocol used for data communication in today's 104 Internet. Yet when it was standardized over 20 years ago, the 105 Internet, was a different place, lacking many of the threats that are 106 now common. The off-path TCP spoofing attacks, which are seen in the 107 Internet today, fall into this category. 109 In a TCP spoofing attack, an off-path attacker crafts TCP packets by 110 forging the IP source and destination addresses as well as the source 111 and destination ports (referred to as a 4-tuple value in this 112 document). The targeted TCP endpoint will then associate such a 113 packet with an existing TCP connection. It needs to be noted that, 114 guessing this 4-tuple value is not always easy for an attacker. But 115 there are some applications (e.g. BGP [RFC4271]) that have a 116 tendency to use the same set(s) of ports on either endpoint making 117 the odds of correctly guessing the 4-tuple value much easier. When 118 an attacker is successful in guessing the 4-tuple value, one of three 119 types of injection attacks may be waged against a long-lived 120 connection. 122 RST - Where an attacker injects a RST segment hoping to cause the 123 connection to be torn down. RST segment here refers to a TCP 124 segment with RST bit set. 126 SYN - Where an attacker injects a SYN hoping to cause the receiver 127 to believe the peer has restarted and so tear down the connection 128 state. SYN segment here refers to a TCP segment with SYN bit set. 130 DATA - Where an attacker tries to inject a DATA segment to corrupt 131 the contents of the transmission. DATA segment here refers to any 132 TCP segment containing data. 134 1.1. Applicability Statement 136 This document talks about some known in-window attacks and suitable 137 defenses against these. The mitigations suggested in this draft 138 SHOULD be implemented in devices that regularly need to maintain TCP 139 connections of the kind most vulnerable to the attacks described in 140 this document. Examples of such TCP connections are the ones that 141 tend to be long-lived and where the connection end points can be 142 determined, in cases where no auxiliary anti-spoofing protection 143 mechanisms like TCP MD5 [RFC2385] can be deployed. These mitigations 144 MAY be implemented in other cases. 146 1.2. Basic Attack Methodology 148 Focusing upon the RST attack, we examine this attack in more detail 149 to get an overview as to how it works and how this document addresses 150 the issue. For this attack the goal is for the attacker to cause one 151 of the two endpoints of the connection to incorrectly tear down the 152 connection state, effectively aborting the connection. One of the 153 important things to note is that for the attack to succeed the RST 154 needs to be in the valid receive window. It also needs to be 155 emphasized that the receive window is independent of the current 156 congestion window of the TCP connection. The attacker would try to 157 forge many RST segments to try to cover the space of possible windows 158 by putting out a packet in each potential window. To do this the 159 attacker needs to have or guess several pieces of information namely: 161 1) The 4-tuple value containing the IP address and TCP port number of 162 both ends of the connection. For one side (usually the server) 163 guessing the port number is a trivial exercise. The client side 164 may or may not be easy for an attacker to guess depending on a 165 number of factors, most notably the operating system and 166 application involved. 168 2) A sequence number that will be used in the RST. This sequence 169 number will be a starting point for a series of guesses to attempt 170 to present a RST segment to a connection endpoint that would be 171 acceptable to it. Any random value may be used to guess the 172 starting sequence number. 174 3) The window size that the two endpoints are using. This value does 175 NOT have to be the exact window size since a smaller value used in 176 lieu of the correct one will just cause the attacker to generate 177 more segments before succeeding in his mischief. Most modern 178 operating systems have a default window size which usually is 179 applied to most connections. Some applications however may change 180 the window size to better suit the needs of the application. So 181 often times the attacker, with a fair degree of certainty (knowing 182 the application that is under attack), can come up with a very 183 close approximation as to the actual window size in use on the 184 connection. 186 After assembling the above set of information the attacker begins 187 sending spoofed TCP segments with the RST bit set and a guessed TCP 188 sequence number. Each time a new RST segment is sent, the sequence 189 number guess is incremented by the window size. The feasibility of 190 this methodology (without mitigations) was first shown in [SITW]. 191 This is because [RFC0793] specifies that any RST within the current 192 window is acceptable. Also [RFC4953] talks about the probability of 193 a successful attack with varying window sizes and bandwidth. 195 A slight enhancement to TCP's segment processing rules can be made 196 which makes such an attack much more difficult to accomplish. If the 197 receiver examines the incoming RST segment and validates that the 198 sequence number exactly matches the sequence number that is next 199 expected, then such an attack becomes much more difficult than 200 outlined in [SITW] (i.e. the attacker would have to generate 1/2 the 201 entire sequence space, on average). This document will discuss the 202 exact details of what needs to be changed within TCP's segment 203 processing rules to mitigate all three types of attacks (RST, SYN and 204 DATA). 206 1.3. Attack probabilities 208 Every application has control of a number of factors that drastically 209 affect the probability of a successful spoofing attack. These 210 factors include such things as: 212 Window Size - Normally settable by the application but often times 213 defaulting to 32,768 or 65,535 depending upon the operating system 214 ([Medina05]). 216 Server Port number - This value is normally a fixed value so that a 217 client will know where to connect to the peer at. Thus this value 218 normally provides no additional protection. 220 Client Port number - This value may be a random ephemeral value, if 221 so, this makes a spoofing attack more difficult. There are some 222 clients, however, that for whatever reason either pick a fixed 223 client port or have a very guessable one (due to the range of 224 ephemeral ports available with their operating system or other 225 application considerations) for such applications a spoofing 226 attack becomes less difficult. 228 For the purposes of the rest of this discussion we will assume that 229 the attacker knows the 4-tuple values. This assumption will help us 230 focus on the effects of the window size versus the number of TCP 231 packets an attacker must generate. This assumption will rarely be 232 true in the real Internet since at least the client port number will 233 provide us with some amount of randomness (depending on the operating 234 system). 236 To successfully inject a spoofed packet (RST, SYN or DATA), in the 237 past, the entire sequence space (i.e. 2^32) was often considered 238 available to make such an attack unlikely. [SITW] demonstrated that 239 this assumption was incorrect and that instead of (1/2 * 2^32) 240 packets (assuming a random distribution), (1/2 * (2^32/window)) 241 packets is required. In other words, the mean number of tries needed 242 to inject a RST segment is (2^31/window) rather than the 2^31 assumed 243 before. 245 Substituting numbers into this formula we see that for a window size 246 of 32,768, an average of 65,536 packets would need to be transmitted 247 in order to "spoof" a TCP segment that would be acceptable to a TCP 248 receiver. A window size of 65,535 reduces this even further to 249 32,768 packets. At today's access bandwidths an attack of that size 250 is feasible. 252 With rises in bandwidth to both the home and office, it can only be 253 expected that the values for default window sizes will continue to 254 rise in order to better take advantage of the newly available 255 bandwidth. It also needs to be noted that this attack can be 256 performed in a distributed fashion in order potentially gain access 257 to more bandwidth. 259 As we can see from the above discussion this weakness lowers the bar 260 quite considerably for likely attacks. But there is one additional 261 dependency which is the duration of the TCP connection. A TCP 262 connection that lasts only a few brief packets, as often is the case 263 for web traffic, would not be subject to such an attack since the 264 connection may not be established long enough for an attacker to 265 generate enough traffic. However there is a set of applications such 266 as BGP [RFC4271] which is judged to be potentially most affected by 267 this vulnerability. BGP relies on a persistent TCP session between 268 BGP peers. Resetting the connection can result in medium term 269 unavailability due to the need to rebuild routing tables and route 270 flapping; see [NISCC] for further details. 272 For applications that can use the TCP MD5 option [RFC2385], such as 273 BGP, that option makes the attacks described in this specification 274 effectively impossible. However, some applications or 275 implementations may find that option expensive to implement. 277 There are alternative protections against the threats that this 278 document addresses. For further details regarding the attacks and 279 the existing techniques, please refer to [RFC4953]. It also needs to 280 be emphasized that, as suggested in 281 [I-D.ietf-tsvwg-port-randomization] and [RFC1948], port randomization 282 and ISN randomization would help improve the robustness of the TCP 283 connection against off-path attacks. 285 2. Terminology 287 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 288 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 289 document are to be interpreted as described in [RFC2119]. TCP 290 terminology should be interpreted as described in [RFC0793]. 292 3. Blind reset attack using the RST bit 294 3.1. Description of the attack 296 As described in the introduction, it is possible for an attacker to 297 generate a "RST" segment that would be acceptable to a TCP receiver 298 by guessing "in-window" sequence numbers. In particular [RFC0793], 299 p37, states the following: 301 "In all states except SYN-SENT, all reset (RST) segments are 302 validated by checking their SEQ-fields [sequence numbers]. A reset 303 is valid if its sequence number is in the window. In the SYN-SENT 304 state (a RST received in response to an initial SYN), the RST is 305 acceptable if the ACK field acknowledges the SYN." 307 3.2. Mitigation 309 [RFC0793] currently requires handling of a segment with the RST bit 310 when in a synchronized state to be processed as follows: 312 1) If the RST bit is set and the sequence number is outside the 313 current receive window (SEG.SEQ <= RCV.NXT || SEG.SEQ > RCV.NXT+ 314 RCV.WND) , silently drop the segment. 316 2) If the RST bit is set and the sequence number is acceptable i.e.: 317 (RCV.NXT <= SEG.SEQ < RCV.NXT+RCV.WND) then reset the connection. 319 Instead, this document requires that implementations SHOULD implement 320 the following steps in place of those specified in [RFC0793] (as 321 listed above). 323 1) If the RST bit is set and the sequence number is outside the 324 current receive window, silently drop the segment. 326 2) If the RST bit is set and the sequence number exactly matches the 327 next expected sequence number (RCV.NXT), then TCP MUST reset the 328 connection. 330 3) If the RST bit is set and the sequence number does not exactly 331 match the next expected sequence value, yet is within the current 332 receive window (RCV.NXT < SEG.SEQ < RCV.NXT+RCV.WND), TCP MUST 333 send an acknowledgment (challenge ACK): 335 336 After sending the challenge ACK, TCP MUST drop the unacceptable 337 segment and stop processing the incoming packet further. Further 338 segments destined to this connection will be processed as normal. 340 The modified RST segment processing would thus become : 342 In all states except SYN-SENT, all reset (RST) segments are validated 343 by checking their SEQ-fields [sequence numbers]. A reset is valid if 344 its sequence number exactly matches the next expected sequence 345 number. If the RST arrives and its sequence number field does NOT 346 match the next expected sequence number but is within the window, 347 then the receiver should generate an ACK. In all other cases where 348 the SEQ-field does not match and is outside the window, the receiver 349 MUST silently discard the segment. 351 In the SYN-SENT state (a RST received in response to an initial SYN), 352 the RST is acceptable if the ACK field acknowledges the SYN. In all 353 other cases the receiver MUST silently discard the segment. 355 With the above slight change to the TCP state machine, it becomes 356 much harder for an attacker to generate an acceptable reset segment. 358 In cases where the remote peer did generate a RST but it fails to 359 meet the above criteria (the RST sequence number was within the 360 window but NOT the exact expected sequence number) when the challenge 361 ACK is sent back, it will no longer have the transmission control 362 block (TCB) related to this connection and hence as per [RFC0793], 363 the remote peer will send a second RST back. The sequence number of 364 the second RST is derived from the acknowledgment number of the 365 incoming ACK. This second RST, if it reaches the sender, will cause 366 the connection to be aborted since the sequence number would now be 367 an exact match. 369 A valid RST received out-of-order would still generate a challenge 370 ACK in response. If this RST happens to be a genuine one, the other 371 end would send an RST with an exact sequence number match which would 372 cause the connection to be dropped. 374 Note that the above mitigation may cause a non-amplification ACK 375 exchange. This concern is discussed in Section 10. 377 4. Blind reset attack using the SYN bit 379 4.1. Description of the attack 381 The analysis of the reset attack using the RST bit highlights another 382 possible avenue for a blind attacker using a similar set of sequence 383 number guessing. Instead of using the RST bit an attacker can use 384 the SYN bit with the exact same semantics to tear down a connection. 386 4.2. Mitigation 388 [RFC0793] currently requires handling of a segment with the SYN bit 389 set in the synchronized state to be as follows: 391 1) If the SYN bit is set and the sequence number is outside the 392 expected window, send an ACK back to the sender. 394 2) If the SYN bit is set and the sequence number is acceptable i.e.: 395 (RCV.NXT <= SEG.SEQ < RCV.NXT+RCV.WND) then send a RST segment to 396 the sender. 398 Instead, the handling of the SYN in the synchronized state SHOULD be 399 performed as follows: 401 1) If the SYN bit is set, irrespective of the sequence number, TCP 402 MUST send an ACK (also referred to as challenge ACK) to the remote 403 peer: 405 407 After sending the acknowledgment, TCP MUST drop the unacceptable 408 segment and stop processing further. 410 By sending an ACK, the remote peer is challenged to confirm the loss 411 of the previous connection and the request to start a new connection. 412 A legitimate peer, after restart, would not have a TCB in the 413 synchronized state. Thus when the ACK arrives the peer should send a 414 RST segment back with the sequence number derived from the ACK field 415 that caused the RST. 417 This RST will confirm that the remote peer has indeed closed the 418 previous connection. Upon receipt of a valid RST, the local TCP 419 endpoint MUST terminate its connection. The local TCP endpoint 420 should then rely on SYN retransmission from the remote end to re- 421 establish the connection. 423 A spoofed SYN, on the other hand, will then have generated an 424 additional ACK which the peer will discard as a duplicate ACK and 425 will not affect the established connection. 427 Note that this mitigation does leave one corner case un-handled which 428 will prevent the reset of a connection when it should be reset (i.e. 429 it is a non-spoofed SYN wherein a peer really did restart). This 430 problem occurs when the restarting host chooses the exact same IP 431 address and port number that it was using prior to its restart. By 432 chance the restarted host must also choose an initial sequence number 433 of exactly (RCV.NXT - 1) of the remote peer that is still in the 434 established state. Such a case would cause the receiver to generate 435 a "challenge" ACK as described above. But since the ACK would be 436 within the outgoing connections window the inbound ACK would be 437 acceptable, and the sender of the SYN will do nothing with the 438 response ACK. This sequence will continue as the SYN sender 439 continually times out and retransmits the SYN until such time as the 440 connection attempt fails. 442 This corner case is a result of the [RFC0793] specification and is 443 not introduced by these new requirements. 445 Note that the above mitigation may cause a non-amplification ACK 446 exchange. This concern is discussed in Section 10. 448 5. Blind data injection attack 450 5.1. Description of the attack 452 A third type of attack is also highlighted by both the RST and SYN 453 attacks. It is also possible to inject data into a TCP connection by 454 simply guessing a sequence number within the current receive window 455 of the victim. The ACK value of any data segment is considered valid 456 as long as it does not acknowledge data ahead of the next segment to 457 send. In other words an ACK value is acceptable if it is ((SND.UNA- 458 (2^31-1)) <= SEG.ACK <= SND.NXT). The (2^31 - 1) in the above 459 inequality takes into account the fact that comparisons on TCP 460 sequence and acknowledgement numbers is done using the modulo 32 bit 461 arithmetic to accommodate the number wraparound. This means that an 462 attacker has to guess two ACK values with every guessed sequence 463 number so that the chances of successfully injecting data into a 464 connection are 1 in ( 1/2 (2^32 / RCV.WND) * 2). Thus the mean 465 number of tries needed to inject data successfully is 1/2 (2*2^32/ 466 RWND) = 2^32/RCV.WND. 468 When an attacker successfully injects data into a connection the data 469 will sit in the receiver's re-assembly queue until the peer sends 470 enough data to bridge the gap between the RCV.NXT value and the 471 injected data. At that point one of two things will occur : 473 1) A packet war will ensue with the receiver indicating that it has 474 received data up until RCV.NXT (which includes the attacker's 475 data) and the sender sending an ACK with an acknowledgment number 476 less than RCV.NXT. 478 2) The sender will send enough data to the peer which will move 479 RCV.NXT even further along past the injected data. 481 Depending upon the TCP implementation in question and the TCP traffic 482 characteristics at that time, data corruption may result. In case 483 (a) the connection will eventually be reset by one of the sides 484 unless the sender produces more data that will transform the ACK war 485 into case (b). The reset will usually occur via User Time Out (UTO) 486 (see section 4.2.3.5 of [RFC1122]). 488 Note that the protections illustrated in this section neither cause 489 an ACK war nor prevent one from occurring if data is actually 490 injected into a connection. The ACK war is a product of the attack 491 itself and cannot be prevented (other than by preventing the data 492 from being injected). 494 5.2. Mitigation 496 All TCP stacks MAY implement the following mitigation. TCP stacks 497 which implement this mitigation MUST add an additional input check to 498 any incoming segment. The ACK value is considered acceptable only if 499 it is in the range of ((SND.UNA - MAX.SND.WND) <= SEG.ACK <= 500 SND.NXT). All incoming segments whose ACK value doesn't satisfy the 501 above condition MUST be discarded and an ACK sent back. It needs to 502 be noted that RFC 793 on page 72 (fifth check) says: "If the ACK is a 503 duplicate (SEG.ACK < SND.UNA), it can be ignored. If the ACK 504 acknowledges something not yet sent (SEG.ACK > SND.NXT) then send an 505 ACK, drop the segment, and return." The "ignored" above implies that 506 the processing of the incoming data segment continues, which means 507 the ACK value is treated as acceptable. This mitigation makes the 508 ACK check more stringent since any ACK < SND.UNA wouldn't be 509 accepted, instead only ACKs which are in the range ((SND.UNA - 510 MAX.SND.WND) <= SEG.ACK <= SND.NXT) gets through. 512 A new state variable MAX.SND.WND is defined as the largest window 513 that the local sender has ever received from its peer. This window 514 may be scaled to a value larger than 65,535 bytes ([RFC1323]). This 515 small check will reduce the vulnerability to an attacker guessing a 516 valid sequence number, since, not only one must guess the in-window 517 sequence number, but also guess a proper ACK value within a scoped 518 range. This mitigation reduces, but does not eliminate, the ability 519 to generate false segments. It does however reduce the probability 520 that invalid data will be injected. 522 Implementations can also chose to hard code the MAX.SND.WND value to 523 the maximum permissible window size i.e., 65535 in the absence of 524 window scaling. In presence of the window scaling option the value 525 becomes (MAX.SND.WND << Snd.Wind.Scale). 527 This mitigation also helps in improving robustness on accepting 528 spoofed FIN segments (FIN attacks). Among other things, this 529 mitigation requires that the attacker also needs to get the 530 acknowledgment number to fall in the range mentioned above in order 531 to successfully spoof a FIN segment leading to the closure of the 532 connection. Thus, this mitigation greatly improves the robustness to 533 spoofed FIN segments. 535 Note that the above mitigation may cause a non-amplification ACK 536 exchange. This concern is discussed in Section 10. 538 6. Suggested Mitigation strengths 540 As described in the above sections, recommendation levels for RST, 541 SYN and DATA are tagged as SHOULD, SHOULD and MAY respectively. The 542 reason that DATA mitigation is tagged as MAY, even though it 543 increased the TCP robustness in general is because, the DATA 544 injection is perceived to be more difficult (twice as unlikely) when 545 compared to RST and SYN counterparts. However, it needs to be noted 546 that all the suggested mitigations improve TCP's robustness in 547 general and hence the choice of implementing some or all mitigations 548 recommended in the document is purely left to the implementer. 550 7. ACK throttling 552 In order to alleviate multiple RSTs/SYNs from triggering multiple 553 challenge ACKs, an ACK throttling mechanism is suggested as follows : 555 1) The system administrator can configure the number of challenge 556 ACKs that can be sent out in a given interval. For example, in 557 any 5 second window, no more than 10 challenge ACKs should be 558 sent. 560 2) The values for both the time and number of ACKs SHOULD be tunable 561 by the system administrator to accommodate different perceived 562 levels of threat and/or system resources. 564 It should be noted that these numbers are empirical in nature and 565 have been obtained from the RST throttling mechanisms existing in 566 some implementations. Also note that no timer is needed to implement 567 the above mechanism, instead a timestamp and a counter can be used. 569 An implementation SHOULD include an ACK throttling mechanism to be 570 conservative. While we have not encountered a case where the lack of 571 ACK throttling can be exploited, as a fail-safe mechanism we 572 recommend its use. An implementation may take an excessive number of 573 invocations of the throttling mechanism as an indication that network 574 conditions are unusual or hostile. 576 An administrator who is more concerned about protecting his bandwidth 577 and CPU utilization may set smaller ACK throttling values whereas an 578 administrator who is more interested in faster cleanup of stale 579 connections (i.e. concerned about excess TCP state) may decide to set 580 a higher value thus allowing more RST's to be processed in any given 581 time period. 583 The time limit SHOULD be tunable to help timeout brute force attacks 584 faster than a potential legitimate flood of RSTs. 586 8. Backward Compatibility and Other considerations 588 All of the new required mitigation techniques in this document are 589 totally compatible with existing ([RFC0793]) compliant TCP 590 implementations as this document introduces no new assumptions or 591 conditions. 593 There is a corner scenario in the above mitigations which will 594 require more than one round trip time to successfully abort the 595 connection as per the figure below. This scenario is similar to the 596 one in which the original RST was lost in the network. 598 TCP A TCP B 599 1.a. ESTAB <-- <-- ESTAB 600 b. (delayed) ... <-- ESTAB 601 c. (in flight) ... <-- CLOSED 602 2. ESTAB --> --> CLOSED 603 (ACK for 1.a) 604 ... <-- CLOSED 605 3. CHALLENGE --> --> CLOSED 606 (for 1.c) 607 ... <-- RESPONSE 608 4.a. ESTAB <-- 1.b reaches A 609 b. ESTAB --> 610 c. (in flight) ... <-- CLOSED 611 5. RESPONSE arrives at A, but dropped since its outside of window. 612 6. ESTAB <-- 4.c reaches A 613 7. CLOSED CLOSED 615 For the mitigation to be maximally effective against the 616 vulnerabilities discussed in this document, both ends of the TCP 617 connection need to have the fix. Although, having the mitigations at 618 one end might prevent that end from being exposed to the attack, the 619 connection is still vulnerable at the other end. 621 9. Middlebox considerations 623 9.1. Middlebox that resend RST's 625 Consider a middlebox M-B tracking connections between two TCP end 626 hosts E-A and E-C. If E-C sends a RST with a sequence number that is 627 within the window but not an exact match to reset the connection and 628 M-B does not have the fix recommended in this document, it may clear 629 the connection and forward the RST to E-A saving an incorrect 630 sequence number. If E-A does not have the fix the connection would 631 get cleared as required. However if E-A does have the required fix, 632 it will send a challenge ACK to E-C. M-B, being a middlebox, may 633 intercept this ACK and resend the RST on behalf of E-C with the old 634 sequence number. This RST will, again, not be acceptable and may 635 trigger a challenge ACK. 637 The above situation may result in a RST/ACK war. However, we believe 638 that if such a case exists in the Internet, the middle box is 639 generating packets a conformant TCP endpoint would not generate. 640 [RFC0793] dictates that the sequence number of a RST has to be 641 derived from the acknowledgment number of the incoming ACK segment. 642 It is outside the scope of this document to suggest mitigations to 643 the ill-behaved middleboxes. 645 Consider a similar scenario where the RST from M-B to E-A gets lost, 646 E-A will continue to hold the connection and E-A might send an ACK an 647 arbitrary time later after the connection state was destroyed at M-B. 648 For this case, M-B will have to cache the RST for an arbitrary amount 649 of time till until it is confirmed that the connection has been 650 cleared at E-A. 652 9.2. Middleboxes that advance sequence numbers 654 Some middleboxes may compute RST sequence numbers at the higher end 655 of the acceptable window. The scenario is the same as the earlier 656 case, but in this case instead of sending the cached RST, the 657 middlebox (M-B) sends a RST that computes its sequence number as the 658 sum of the acknowledgement field in the ACK and the window advertised 659 by the ACK that was sent by E-A to challenge the RST as depicted 660 below. The difference in the sequence numbers between step 1 and 2 661 below is due to data lost in the network. 663 TCP A Middlebox 665 1. ESTABLISHED <-- <-- CLOSED 667 2. ESTABLISHED --> --> CLOSED 669 3. ESTABLISHED <-- <-- CLOSED 671 4. ESTABLISHED --> --> CLOSED 673 5. ESTABLISHED <-- <-- CLOSED 675 Although the authors are not aware of an implementation that does the 676 above, it could be mitigated by implementing the ACK throttling 677 mechanism described earlier. 679 9.3. Middleboxes that drop the challenge ACK 681 It also needs to be noted that, some middleboxes (Firewalls/NATs) 682 which doesn't have the fix recommended in the document, may drop the 683 challenge ACK. This can happen because, the original RST segment 684 which was in window had already cleared the flow state pertaining to 685 the TCP connection in the middlebox. In such cases, the end hosts 686 which have implemented the RST mitigation described in this document, 687 will have the TCP connection left open. This is a corner case and 688 can go away if the middlebox is conformant with the changes proposed 689 in this document. 691 10. Security Considerations 693 These changes to the TCP state machine do NOT protect an 694 implementation from on-path attacks. It also needs to be emphasized 695 that while mitigations within this document make it harder for off- 696 path attackers to inject segments, it does NOT make it impossible. 697 The only way to fully protect a TCP connection from both on and off 698 path attacks is by using either IPSEC-AH [RFC4302] or IPSEC-ESP 699 [RFC4303]. 701 Implementers also should be aware that the attacks detailed in this 702 specification are not the only attacks available to an off-path 703 attacker and that the counter measures described herein are not a 704 comprehensive defense against such attacks. 706 In particular, administrators should be aware that forged ICMP 707 messages provide off-path attackers the opportunity to disrupt 708 connections or degrade service. Such attacks may be subject to even 709 less scrutiny than the TCP attacks addressed here, especially in 710 stacks not tuned for hostile environments. It is important to note 711 that some ICMP messages, validated or not, are key to the proper 712 function of TCP. Those ICMP messages used to properly set the path 713 maximum transmission unit are the most obvious example. There are a 714 variety of ways to choose which, if any, ICMP messages to trust in 715 the presence of off-path attackers and choosing between them depends 716 on the assumptions and guarantees developers and administrators can 717 make about their network. This specification does not attempt to do 718 more than note this and related issues. Unless implementers address 719 spoofed ICMP messages [I-D.ietf-tcpm-icmp-attacks], the mitigations 720 specified in this document may not provide the desired protection 721 level. 723 In any case, this RFC details only part of a complete strategy to 724 prevent off-path attackers from disrupting services that use TCP. 725 Administrators and implementers should consider the other attack 726 vectors and determine appropriate mitigations in securing their 727 systems. 729 Another notable consideration is that a reflector attack is possible 730 with the required RST/SYN mitigation techniques. In this attack, an 731 off-path attacker can cause a victim to send an ACK segment for each 732 spoofed RST/SYN segment that lies within the current receive window 733 of the victim. It should be noted, however, that this does not cause 734 any amplification since the attacker must generate a segment for each 735 one that the victim will generate. 737 11. IANA Considerations 739 This document contains no IANA considerations. 741 12. Contributors 743 Mitesh Dalal and Amol Khare of Cisco Systems came up with the 744 solution for the RST/SYN attacks. Anantha Ramaiah and Randall 745 Stewart of Cisco Systems discovered the data injection vulnerability 746 and together with Patrick Mahan and Peter Lei of Cisco Systems found 747 solutions for the same. Paul Goyette, Mark Baushke, Frank 748 Kastenholz, Art Stine and David Wang of Juniper Networks provided the 749 insight that apart from RSTs, SYNs could also result in formidable 750 attacks. Shrirang Bage of Cisco Systems, Qing Li and Preety Puri of 751 Wind River Systems and Xiaodan Tang of QNX Software along with the 752 folks above helped in ratifying and testing the interoperability of 753 the suggested solutions. 755 13. Acknowledgments 757 Special thanks to Mark Allman, Ted Faber, Steve Bellovin, Vern 758 Paxson, Allison Mankin, Sharad Ahlawat, Damir Rajnovic, John Wong, 759 Joe Touch, Alfred Hoenes, Andre Oppermann, Fernando Gont, Sandra 760 Murphy, Brian Carpenter, Cullen Jennings and other members of the 761 tcpm WG for suggestions and comments. ACK throttling was introduced 762 to this document by combining the suggestions from the tcpm working 763 group. 765 14. References 767 14.1. Normative References 769 [RFC0793] Postel, J., "Transmission Control Protocol", STD 7, 770 RFC 793, September 1981. 772 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 773 Requirement Levels", BCP 14, RFC 2119, March 1997. 775 14.2. Informative References 777 [I-D.ietf-tcpm-icmp-attacks] 778 Gont, F., "ICMP attacks against TCP", 779 draft-ietf-tcpm-icmp-attacks-12 (work in progress), 780 March 2010. 782 [I-D.ietf-tsvwg-port-randomization] 783 Larsen, M. and F. Gont, "Transport Protocol Port 784 Randomization Recommendations", 785 draft-ietf-tsvwg-port-randomization-07 (work in progress), 786 April 2010. 788 [Medina05] 789 Medina, A., Allman, M., and S. Floyd, "Measuring the 790 Evolution of Transport Protocols in the Internet. ACM 791 Computer Communication Review, 35(2), April 2005. 792 http://www.icir.org/mallman/papers/tcp-evo-ccr05.ps 793 (figure 6)". 795 [NISCC] NISCC, "NISCC Vulnerability Advisory 236929 - 796 Vulnerability Issues in TCP". 798 [RFC1122] Braden, R., "Requirements for Internet Hosts - 799 Communication Layers", STD 3, RFC 1122, October 1989. 801 [RFC1323] Jacobson, V., Braden, B., and D. Borman, "TCP Extensions 802 for High Performance", RFC 1323, May 1992. 804 [RFC1948] Bellovin, S., "Defending Against Sequence Number Attacks", 805 RFC 1948, May 1996. 807 [RFC2385] Heffernan, A., "Protection of BGP Sessions via the TCP MD5 808 Signature Option", RFC 2385, August 1998. 810 [RFC4271] Rekhter, Y., Li, T., and S. Hares, "A Border Gateway 811 Protocol 4 (BGP-4)", RFC 4271, January 2006. 813 [RFC4302] Kent, S., "IP Authentication Header", RFC 4302, 814 December 2005. 816 [RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)", 817 RFC 4303, December 2005. 819 [RFC4953] Touch, J., "Defending TCP Against Spoofing Attacks", 820 RFC 4953, July 2007. 822 [SITW] Watson, P., "Slipping in the Window: TCP Reset attacks, 823 Presentation at 2004 CanSecWest 824 http://www.cansecwest.com/archives.html". 826 Authors' Addresses 828 Anantha Ramaiah 829 Cisco Systems 830 170 Tasman Drive 831 San Jose, CA 95134 832 USA 834 Phone: +1 (408) 525-6486 835 Email: ananth@cisco.com 837 Randall R. Stewart 838 Huawei 839 148 Crystal Cove Ct 840 Chapin, SC 29036 841 USA 843 Phone: +1 (803) 345-0369 844 Email: rstewart@huawei.com 846 Mitesh Dalal 847 Cisco Systems 848 170 Tasman Drive 849 San Jose, CA 95134 850 USA 852 Phone: +1 (408) 853-5257 853 Email: mdalal@cisco.com