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