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