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