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