idnits 2.17.1 draft-gont-tcpm-icmp-attacks-03.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.a on line 19. -- Found old boilerplate from RFC 3978, Section 5.5 on line 1293. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1270. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1277. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1283. ** The document seems to lack an RFC 3978 Section 5.1 IPR Disclosure Acknowledgement. ** 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. ** The document uses RFC 3667 boilerplate or RFC 3978-like boilerplate instead of verbatim RFC 3978 boilerplate. After 6 May 2005, submission of drafts without verbatim RFC 3978 boilerplate is not accepted. The following non-3978 patterns matched text found in the document. That text should be removed or replaced: This document is an Internet-Draft and is subject to all provisions of Section 3 of RFC 3667. By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) 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 (December 22, 2004) is 7065 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) ** Obsolete normative reference: RFC 793 (ref. '1') (Obsoleted by RFC 9293) ** Obsolete normative reference: RFC 2401 (ref. '7') (Obsoleted by RFC 4301) ** Obsolete normative reference: RFC 2463 (ref. '8') (Obsoleted by RFC 4443) ** Obsolete normative reference: RFC 2460 (ref. '9') (Obsoleted by RFC 8200) ** Obsolete normative reference: RFC 1981 (ref. '10') (Obsoleted by RFC 8201) -- Obsolete informational reference (is this intentional?): RFC 1323 (ref. '13') (Obsoleted by RFC 7323) == Outdated reference: A later version (-13) exists of draft-ietf-tcpm-tcpsecure-02 -- Obsolete informational reference (is this intentional?): RFC 2385 (ref. '17') (Obsoleted by RFC 5925) -- Obsolete informational reference (is this intentional?): RFC 816 (ref. '19') (Obsoleted by RFC 7805) -- Obsolete informational reference (is this intentional?): RFC 2581 (ref. '21') (Obsoleted by RFC 5681) == Outdated reference: A later version (-11) exists of draft-ietf-pmtud-method-03 == Outdated reference: A later version (-02) exists of draft-gont-tcpm-tcp-soft-errors-01 -- Obsolete informational reference (is this intentional?): RFC 2821 (ref. '26') (Obsoleted by RFC 5321) -- Obsolete informational reference (is this intentional?): RFC 2616 (ref. '27') (Obsoleted by RFC 7230, RFC 7231, RFC 7232, RFC 7233, RFC 7234, RFC 7235) -- Obsolete informational reference (is this intentional?): RFC 896 (ref. '28') (Obsoleted by RFC 7805) Summary: 11 errors (**), 0 flaws (~~), 5 warnings (==), 14 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 TCP Maintenance and Minor F. Gont 3 Extensions (tcpm) UTN/FRH 4 Internet-Draft December 22, 2004 5 Expires: June 22, 2005 7 ICMP attacks against TCP 8 draft-gont-tcpm-icmp-attacks-03.txt 10 Status of this Memo 12 This document is an Internet-Draft and is subject to all provisions 13 of section 3 of RFC 3667. By submitting this Internet-Draft, each 14 author represents that any applicable patent or other IPR claims of 15 which he or she is aware have been or will be disclosed, and any of 16 which he or she become aware will be disclosed, in accordance with 17 RFC 3668. This document may not be modified, and derivative works of 18 it may not be created, except to publish it as an RFC and to 19 translate it into languages other than English. 21 Internet-Drafts are working documents of the Internet Engineering 22 Task Force (IETF), its areas, and its working groups. Note that 23 other groups may also distribute working documents as 24 Internet-Drafts. 26 Internet-Drafts are draft documents valid for a maximum of six months 27 and may be updated, replaced, or obsoleted by other documents at any 28 time. It is inappropriate to use Internet-Drafts as reference 29 material or to cite them other than as "work in progress." 31 The list of current Internet-Drafts can be accessed at 32 http://www.ietf.org/ietf/1id-abstracts.txt. 34 The list of Internet-Draft Shadow Directories can be accessed at 35 http://www.ietf.org/shadow.html. 37 This Internet-Draft will expire on June 22, 2005. 39 Copyright Notice 41 Copyright (C) The Internet Society (2004). 43 Abstract 45 This document discusses the use of the Internet Control Message 46 Protocol (ICMP) to perform a variety of attacks against the 47 Transmission Control Protocol (TCP) and other similar protocols. It 48 proposes several counter-measures to eliminate or minimize the impact 49 of these attacks. 51 Table of Contents 53 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 54 2. Background . . . . . . . . . . . . . . . . . . . . . . . . . . 3 55 2.1 The Internet Control Message Protocol (ICMP) . . . . . . . 3 56 2.1.1 ICMP for IP version 4 (ICMP) . . . . . . . . . . . . . 4 57 2.1.2 ICMP for IP version 6 (ICMPv6) . . . . . . . . . . . . 5 58 2.2 Handling of ICMP errors . . . . . . . . . . . . . . . . . 5 59 3. ICMP attacks against TCP . . . . . . . . . . . . . . . . . . . 6 60 4. Constraints in the possible solutions . . . . . . . . . . . . 6 61 5. General counter-measures against ICMP attacks . . . . . . . . 7 62 5.1 TCP sequence number checking . . . . . . . . . . . . . . . 7 63 5.2 TCP acknowledgement number checking . . . . . . . . . . . 8 64 5.3 Port randomization . . . . . . . . . . . . . . . . . . . . 8 65 5.4 Authentication . . . . . . . . . . . . . . . . . . . . . . 8 66 5.5 Filtering ICMP errors based on the ICMP payload . . . . . 9 67 6. Blind connection-reset attacks . . . . . . . . . . . . . . . . 9 68 6.1 Description . . . . . . . . . . . . . . . . . . . . . . . 9 69 6.2 Attack-specific counter-measures . . . . . . . . . . . . . 10 70 6.2.1 Changing the reaction to hard errors . . . . . . . . . 10 71 6.2.2 Delaying the connection-reset . . . . . . . . . . . . 11 72 7. Blind throughput-reduction attacks . . . . . . . . . . . . . . 12 73 7.1 ICMP Source Quench attack . . . . . . . . . . . . . . . . 12 74 7.1.1 Description . . . . . . . . . . . . . . . . . . . . . 12 75 7.1.2 Attack-specific counter-measures . . . . . . . . . . . 12 76 7.2 ICMP attack against the PMTU Discovery mechanism . . . . . 12 77 7.2.1 Description . . . . . . . . . . . . . . . . . . . . . 13 78 7.2.2 Attack-specific counter-measures . . . . . . . . . . . 14 79 8. Future work . . . . . . . . . . . . . . . . . . . . . . . . . 17 80 9. Security Considerations . . . . . . . . . . . . . . . . . . . 17 81 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 17 82 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 17 83 11.1 Normative References . . . . . . . . . . . . . . . . . . . . 17 84 11.2 Informative References . . . . . . . . . . . . . . . . . . . 18 85 Author's Address . . . . . . . . . . . . . . . . . . . . . . . 19 86 A. The counter-measure for the PMTUD attack in action . . . . . . 19 87 A.1 Normal operation for bulk transfers . . . . . . . . . . . 20 88 A.2 Operation during Path-MTU changes . . . . . . . . . . . . 22 89 A.3 Idle connection being attacked . . . . . . . . . . . . . . 23 90 A.4 Active connection being attacked after discovery of 91 the Path-MTU . . . . . . . . . . . . . . . . . . . . . . . 23 92 B. An attack that could still succeed . . . . . . . . . . . . . . 24 93 C. Advice and guidance to vendors . . . . . . . . . . . . . . . . 26 94 D. Changes from previous versions of the draft . . . . . . . . . 26 95 D.1 Changes from draft-gont-tcpm-icmp-attacks-02 . . . . . . . 26 96 D.2 Changes from draft-gont-tcpm-icmp-attacks-01 . . . . . . . 27 97 D.3 Changes from draft-gont-tcpm-icmp-attacks-00 . . . . . . . 27 98 Intellectual Property and Copyright Statements . . . . . . . . 28 100 1. Introduction 102 Recently, awareness has been raised about several threats against the 103 TCP [1] protocol, which include blind connection-reset attacks [12]. 104 These attacks are based on sending forged TCP segments to any of the 105 TCP endpoints, requiring the attacker to be able to guess the 106 four-tuple that identifies the connection to be attacked. 108 While these attacks were known by the research community, they were 109 considered to be unfeasible. However, increases in bandwidth 110 availability, and the use of larger TCP windows [13] have made these 111 attacks feasible. Several general solutions have been proposed to 112 either eliminate or minimize the impact of these attacks 113 [14][15][16]. For protecting BGP sessions, specifically, a 114 counter-measure had already been documented in [17], which defines a 115 new TCP option that allows a sending TCP to include a MD5 [18] 116 signature in each transmitted segment. 118 All these counter-measures address attacks that require an attacker 119 to send forged TCP segments to the attacked host. However, there is 120 still a possibility for performing a number of attacks against the 121 TCP protocol, by means of ICMP [2]. These attacks include, among 122 others, blind connection-reset attacks. 124 This document aims to raise awareness of the use of ICMP to perform a 125 number of attacks against TCP, and proposes several counter-measures 126 that can eliminate or minimize the impact of these attacks. 128 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 129 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 130 document are to be interpreted as described in RFC 2119 [3]. 132 2. Background 134 2.1 The Internet Control Message Protocol (ICMP) 136 The Internet Control Message Protocol (ICMP) is used in the Internet 137 Architecture to perform the fault-isolation function, that is, the 138 group of actions that hosts and routers take to determine that there 139 is some network failure [19]. 141 When an intermediate router detects a network problem while trying to 142 forward an IP packet, it will usually send an ICMP error message to 143 the source host, to raise awareness of the network problem. In the 144 same way, there are a number of cases in which an end-system may 145 generate an ICMP error message when it finds a problem while 146 processing a datagram. These error messages are notified to the 147 corresponding transport-protocol instance. 149 When the transport protocol is notified of the error condition, it 150 will perform a fault recovery function. That is, it will try to 151 survive the network failure. 153 In the case of TCP, the typical fault recovery policy is as follows: 155 o If the network problem being reported is a hard error, abort the 156 corresponding connection. 158 o If the network problem being reported is a soft error, just record 159 this information, and repeatedly retransmit the segment until 160 either it gets acknowledged, or the connection times out. 162 Some stacks honor hard errors only for connections in any of the 163 synchronized states (ESTABLISHED, FIN-WAIT-1, FIN-WAIT-2, CLOSE-WAIT, 164 CLOSING, LAST-ACK or TIME-WAIT). 166 2.1.1 ICMP for IP version 4 (ICMP) 168 [2] specifies the Internet Control Message Protocol (ICMP) to be used 169 with the Internet Protocol version 4 (IPv4). It defines, among other 170 things, a number of error messages that can be used by end-systems 171 and intermediate systems to report network errors to the sending 172 host. 174 The Host Requirements RFC [4] states that ICMP error messages of type 175 3 (Destination Unreachable) codes 2 (protocol unreachable), 3 (port 176 unreachable), and 4 (fragmentation needed and DF bit set) should be 177 considered hard errors. Thus, any of these ICMP messages could 178 elicit a connection abort. 180 The ICMP specification also defines the ICMP Source Quench message 181 (type 4, code 0), which is meant to provide a mechanism for flow 182 control and congestion control. The Requirements for IP Version 4 183 Routers RFC [5], however, states that experience has shown this ICMP 184 message is ineffective for handling these issues. 186 [6] defines a mechanism called "Path MTU Discovery" (PMTUD), which 187 makes use of ICMP error messages of type 3 (Destination Unreachable), 188 code 4 (fragmentation needed and DF bit set) to allow hosts to 189 determine the MTU of an arbitrary internet path. For obvious 190 reasons, those systems implementing the Path MTU Discovery (PMTUD) 191 mechanism do not treat ICMP error messages of type 3 code 4 as hard 192 errors. 194 Appendix D of [7] provides information about which ICMP error 195 messages are produced by hosts, intermediate routers, or both. 197 2.1.2 ICMP for IP version 6 (ICMPv6) 199 [8] specifies the Internet Control Message Protocol (ICMPv6) to be 200 used with the Internet Protocol version 6 (IPv6) [9]. 202 Even though ICMPv6 didn't exist when [4] was written, one could 203 extrapolate the concept of "hard errors" to ICMPv6 Type 1 204 (Destination Unreachable) codes 1 (communication with destination 205 administratively prohibited) and 4 (port unreachable). Thus, any of 206 these messages could elicit a connection abort. 208 ICMPv6 defines the "Packet Too Big" (type 2, code 0) error message, 209 that is analogous to the ICMP "fragmentation needed and DF bit set" 210 (type 3, code 4) error message. For IPv6, intermediate systems do 211 not fragment IP packets. Thus, there is an implicit "don't fragment" 212 bit set in every IPv6 datagram sent on a network. Therefore, hosts 213 do not treat ICMPv6 "Packet Too Big" messages as a hard errors, but 214 use them to discover the MTU of the corresponding internet path, as 215 part of the Path MTU Discovery mechanism for IP Version 6 [10]. 217 Appendix D of [7] provides information about which ICMPv6 error 218 messages are produced by hosts, intermediate routers, or both. 220 2.2 Handling of ICMP errors 222 The Host Requirements RFC [4] states that a TCP MUST act on an ICMP 223 error message passed up from the IP layer, directing it to the 224 connection that created the error. 226 In order to allow ICMP messages to be demultiplexed by the receiving 227 host, part of the original packet that elicited the message is 228 included in the payload of the ICMP error message. Thus, the 229 receiving host can use that information to match the ICMP error to 230 the instance of the transport protocol that elicited it. 232 Neither the Host Requirements RFC [4] nor the original TCP 233 specification [1] recommend any security checks on the received ICMP 234 messages. Thus, as long as the ICMP payload contains the correct 235 four-tuple that identifies the communication instance, it will be 236 processed by the corresponding transport-protocol instance, and the 237 corresponding action will be performed. 239 Therefore, an attacker could send a forged ICMP message to the 240 attacked host, and, as long as he is able to guess the four-tuple 241 that identifies the communication instance to be attacked, he can use 242 ICMP to perform a variety of attacks. 244 As discussed in [12], there are a number of scenarios in which an 245 attacker may be able to know or guess this four-tuple. Furthermore, 246 it must be noted that most Internet services use the so-called 247 "well-known" ports, so that only the client port would need to be 248 guessed. In the event that an attacker had no knowledge about the 249 range of port numbers used by clients, this would mean that an 250 attacker would need to send, at most, 65536 packets to perform any of 251 the attacks described in this document. 253 It is clear that security checks should be performed on the received 254 ICMP error messages, to mitigate the impact of the attacks described 255 in this document. 257 3. ICMP attacks against TCP 259 ICMP messages can be used to perform a variety of attacks. These 260 attacks have been discussed by the research community to a large 261 extent. 263 Some TCP/IP implementations have added security checks on the 264 received ICMP error messages to minimize the impact of these attacks. 265 However, as there has not been any official proposal about what would 266 be the best way to deal with these attacks, these security checks 267 have not been widely implemented. 269 Section 4 of this document discusses the constraints in the general 270 counter-measures that can be implemented against the attacks 271 described in this document. Section 5 proposes several general 272 counter-measures that apply to all the ICMP attacks described in this 273 document. Finally, Section 6 and Section 7 discuss a variety of ICMP 274 attacks that can be performed against TCP, and propose 275 attack-specific counter-measures that eliminate or mitigate their 276 impact. These attack-specific counter-measures are meant to be 277 additional counter-measures to the ones proposed in Section 5. In 278 particular, all TCP implementations SHOULD perform the TCP sequence 279 number checking described in Section 5.1. 281 4. Constraints in the possible solutions 283 For ICMPv4, [2] states that the internet header plus the first 64 284 bits of the packet that elicited the ICMP message are to be included 285 in the payload of the ICMP error message. Thus, it is assumed that 286 all data needed to identify a transport protocol instance and process 287 the ICMP error message is contained in the first 64 bits of the 288 transport protocol header. [4] states that "the Internet header and 289 at least the first 8 data octets of the datagram that triggered the 290 error" are to be included in the payload of ICMP error messages, and 291 that "more than 8 octets MAY be sent", thus suggesting that 292 implementations may include more data from the original packet than 293 that required by the original ICMP specification. The Requirements 294 for IP Version 4 Routers RFC [5] states that ICMP error messages 295 "SHOULD contain as much of the original datagram as possible without 296 the length of the ICMP datagram exceeding 576 bytes". 298 Thus, for ICMP messages generated by hosts, we can only expect to get 299 the entire IP header of the original packet, plus the first 64 bits 300 of its payload. For TCP, that means that the only fields that will 301 be included are: the source port number, the destination port number, 302 and the 32-bit TCP sequence number. This clearly imposes a 303 constraint on the possible security checks that can be performed, as 304 there is not much information avalable on which to perform them. 305 While there exists a proposal to recommend hosts to include more data 306 from the original datagram in the payload of ICMP error messages 307 [20], and some TCP/IP implementations already do this, we cannot yet 308 propose any work-around based on checks performed on any data past 309 the first 64 bits of the payload of the original IP datagram that 310 elicited the ICMP error message. Thus, the only check that can be 311 performed on the ICMP error message is that of the TCP sequence 312 number contained in the payload. 314 As discussed above, for those ICMP error messages generated by 315 routers, we can expect to receive much more octets from the original 316 packet than just the entire IP header and the first 64 bits of the 317 transport protocol header. Therefore, not only can hosts check the 318 TCP sequence number contained in the payload of the ICMP error 319 message, but they can also perform further checks such as checking 320 the TCP acknowledgement number, as discussed in Section 5.2. 322 For ICMPv6, the payload of ICMPv6 error messages includes as many 323 octets from the IPv6 packet that elicited the ICMPv6 error message as 324 will fit without making the resulting ICMPv6 packet exceed the 325 minimum IPv6 MTU (1280 octets) [8]. Thus, further checks (as those 326 described above) can be performed on the received ICMP error 327 messages. 329 5. General counter-measures against ICMP attacks 331 There are a number of counter-measures that can be implemented to 332 eliminate or mitigate the impact of the attacks discussed in this 333 document. Rather than being alternative counter-measures, they can 334 be implemented together to increase the protection against these 335 attacks. In particular, all TCP implementations SHOULD perform the 336 TCP sequence number checking described in Section 5.1. 338 5.1 TCP sequence number checking 340 TCP SHOULD check that the TCP sequence number contained in the 341 payload of the ICMP error message is within the range SND.UNA =< 342 SEG.SEQ < SND.NXT. This means that the sequence number should be 343 within the range of the data already sent but not yet acknowledged. 344 If an ICMP error message does not pass this check, it SHOULD be 345 discarded. 347 Even if an attacker were able to guess the four-tuple that identifies 348 the TCP connection, this additional check would reduce the 349 possibility of considering a spoofed ICMP packet as valid to 350 Flight_Size/2^^32 (where Flight_Size is the number of data bytes 351 already sent to the remote peer, but not yet acknowledged [21]). For 352 connections in the SYN-SENT or SYN-RECEIVED states, this would reduce 353 the possibility of considering a spoofed ICMP packet as valid to 354 1/2^^32. For a TCP endpoint with no data "in flight", this would 355 completely eliminate the possibility of success of these attacks. 357 5.2 TCP acknowledgement number checking 359 As discussed in Section 4, for those ICMP error messages that are 360 generated by intermediate routers, additional checks can be 361 performed. TCP SHOULD check that the TCP Acknowledgement number 362 contained in the payload of the ICMP error message is withing the 363 range SEG.ACK <= RCV.NXT. This means that the TCP Acknowledgement 364 number should correspond to data that have already been acknowledged. 366 This would reduce the possibility of considering a spoofed ICMP 367 packet as valid by a factor of two. 369 5.3 Port randomization 371 As discussed in the previous sections, in order to perform any of the 372 attacks described in this document, an attacker needs to guess (or 373 know) the four-tuple that identifies the connection to be attacked. 374 Randomizing the ephemeral ports used by the clients would make it 375 harder for an attacker to perform any of the attacks discussed in 376 this document. 378 [22] discusses a number of algorithms to randomize the ephemeral 379 ports used by clients. 381 Also, a proposal exists to enable TCP to reassign a well-known port 382 number to a random value [23]. 384 5.4 Authentication 386 Hosts could require ICMP error messages to be authenticated [7], in 387 order to act upon them. However, while this requirement could make 388 sense for those ICMP error messages sent by hosts, it would not be 389 feasible for those ICMP error messages generated by intermediate 390 routers. 392 [7] contains a discussion on the authentication of ICMP messages. 394 5.5 Filtering ICMP errors based on the ICMP payload 396 The source address of ICMP error messages does not need to be spoofed 397 to perform the attacks described in this document. Thus, simple 398 filtering based on the source address of ICMP error messages does not 399 serve as a counter-measure against these attacks. However, a more 400 advanced packet filtering could be used as a counter-measure. 401 Systems performing such advanced filtering would look at the payload 402 of the ICMP error messages, and would perform ingress and egress 403 packet filtering based on the source IP address of the IP header 404 contained in the payload of the ICMP error message. As the source IP 405 address contained in the payload of the ICMP error message does need 406 to be spoofed to perform the attacks described in this document, this 407 kind of advanced filtering would serve as a counter-measure against 408 these attacks. 410 6. Blind connection-reset attacks 412 6.1 Description 414 The Host Requirements RFC [4] states that a host SHOULD abort the 415 corresponding connection when receiving an ICMP error message that 416 indicates a hard error. 418 Thus, an attacker could use ICMP to perform a blind connection-reset 419 attack. That is, even being off-path, an attacker could reset any 420 TCP connection taking place. In order to perform such an attack, an 421 attacker would send any ICMP error message that indicates a "hard 422 error", to either of the two TCP endpoints of the connection. 423 Because of TCP's fault recovery policy, the connection would be 424 immediately aborted. 426 As discussed in Section 2.2, all an attacker needs to know to perform 427 such an attack is the socket pair that identifies the TCP connection 428 to be attacked. In some scenarios, the IP addresses and port numbers 429 in use may be easily guessed or known to the attacker [12]. 431 Some stacks are known to extrapolate ICMP errors across TCP 432 connections, increasing the impact of this attack, as a single ICMP 433 packet could bring down all the TCP connections between the 434 corresponding peers. 436 There are some points to be considered about this type of attack: 438 o The source address of the ICMP error message need not be forged. 439 Thus, simple filtering based on the source address of ICMP packets 440 would not serve as a counter-measure against this type of attack. 442 o Even if TCP itself were protected against the blind 443 connection-reset attack described in [12] and [14], the type of 444 attack described in this document could still succeed. 446 6.2 Attack-specific counter-measures 448 6.2.1 Changing the reaction to hard errors 450 An analysis of the circumstances in which ICMP messages that indicate 451 hard errors may be received can shed some light to minimize (or even 452 eliminate) the impact of blind connection-reset attacks. 454 ICMP type 3 (Destination Unreachable), code 2 (protocol unreachable) 456 This ICMP error message indicates that the host sending the ICMP 457 error message received a packet meant for a transport protocol it 458 does not support. For connection-oriented protocols such as TCP, 459 one could expect to receive such an error as the result of a 460 connection-establishment attempt. However, it would be strange to 461 get such an error during the life of a connection, as this would 462 indicate that support for that transport protocol has been removed 463 from the host sending the error message during the life of the 464 corresponding connection. Thus, it would be fair to treat ICMP 465 protocol unreachable error messages as soft errors (or completely 466 ignore them) if they are meant for connections that are in 467 synchronized states. For TCP, this means one would treat ICMP 468 protocol unreachable error messages as soft errors (or completely 469 ignore them) if they are meant for connections that are in the 470 ESTABLISHED, FIN-WAIT-1, FIN-WAIT-2, CLOSE-WAIT, CLOSING, LAST-ACK 471 or TIME-WAIT states. 473 ICMP type 3 (Destination Unreachable), code 3 (port unreachable) 475 This error message indicates that the host sending the ICMP error 476 message received a packet meant for a socket (IP address, port 477 number) on which there is no process listening. Those transport 478 protocols which have their own mechanisms for notifying this 479 condition should not be receiving these error messages. However, 480 the Host Requirements RFC [4] states that even those transport 481 protocols that have their own mechanism for notifying the sender 482 that a port is unreachable MUST nevertheless accept an ICMP Port 483 Unreachable for the same purpose. For security reasons, it would 484 be fair to treat ICMP port unreachable messages as soft errors (or 485 completely ignore them) when they are meant for protocols that 486 have their own mechanism for reporting this error condition. 488 ICMP type 3 (Destination Unreachable), code 4 (fragmentation needed 489 and DF bit set) 491 This error message indicates that an intermediate node needed to 492 fragment a datagram, but the DF (Don't Fragment) bit in the IP 493 header was set. Those systems that do not implement the PMTUD 494 mechanism should not be sending their IP packets with the DF bit 495 set, and thus should not be receiving these ICMP error messages. 496 Thus, it would be fair for them to completely ignore this ICMP 497 error message. On the other hand, and for obvious reasons, those 498 systems implementing the Path-MTU Discovery (PMTUD) mechanism [6] 499 should not abort the corresponding connection when such an ICMP 500 error message is received. 502 ICMPv6 type 1 (Destination Unreachable), code 1 (communication with 503 destination administratively prohibited) 505 This error message indicates that the destination is unreachable 506 because of an administrative policy. For connection-oriented 507 protocols such as TCP, one could expect to receive such an error 508 as the result of a connection-establishment attempt. Receiving 509 such an error for a connection in any of the synchronized states 510 would mean that the administrative policy changed during the life 511 of the connection. Therefore, while it would be possible for a 512 firewall to be reconfigured during the life of a connection, it 513 would be fair, for security reasons, to ignore these messages for 514 connections that are in the ESTABLISHED, FIN-WAIT-1, FIN-WAIT-2, 515 CLOSE-WAIT, CLOSING, LAST-ACK or TIME-WAIT states. 517 ICMPv6 type 1 (Destination Unreachable), code 4 (port unreachable) 519 This error message is analogous to the ICMP type 3 (Destination 520 Unreachable), code 3 (Port unreachable) error message discussed 521 above. Therefore, the same considerations apply. 523 Finally, it is important to note that, as discussed in Section 6.1, 524 hosts MUST NOT extrapolate ICMP errors across TCP connections. 526 6.2.2 Delaying the connection-reset 528 An alternative counter-measure could be to delay the connection 529 reset. Rather than immediately aborting a connection, a TCP could 530 abort a connection only after an ICMP error message indicating a hard 531 error has been received a specified number of times, and the 532 corresponding data have already been retransmitted more than some 533 specified number of times. 535 For example, hosts could abort connections only after a fourth ICMP 536 error message indicating a hard error is received, and the 537 corresponding data have already been retransmitted more than six 538 times. 540 The rationale behind this proposed fix is that if a host can make 541 forward progress on a connection, it can completely disregard the 542 "hard errors" being indicated by the received ICMP error messages. 544 While this counter-measure could be useful, we think that the 545 counter-measure discussed in Section 6.2.1 is more simple to 546 implement and provides increased protection against this type of 547 attack. 549 7. Blind throughput-reduction attacks 551 The following subsections discuss a number of attacks that can be 552 performed against TCP to reduce the throughput of a TCP connection. 553 While these attacks do not reset the attacked TCP connections, they 554 may reduce their throughput to such an extent that they may become 555 practically unusable. 557 7.1 ICMP Source Quench attack 559 7.1.1 Description 561 The Host requirements RFC states hosts MUST react to ICMP Source 562 Quench messages by slowing transmission on the connection. Thus, an 563 attacker could send ICMP Source Quench (type 4, code 0) messages to a 564 TCP endpoint to make it reduce the rate at which it sends data to the 565 other party. While this would not reset the connection, it would 566 certainly degrade the performance of the data transfer taking place 567 over it. 569 7.1.2 Attack-specific counter-measures 571 The Host Requirements RFC [4] states that hosts MUST react to ICMP 572 Source Quench messages by slowing transmission on the connection. 573 However, as discussed in the Requirements for IP Version 4 Routers 574 RFC [5], research seems to suggest ICMP Source Quench is an 575 ineffective (and unfair) antidote for congestion. Thus, we recommend 576 hosts to completely ignore ICMP Source Quench messages. 578 7.2 ICMP attack against the PMTU Discovery mechanism 579 7.2.1 Description 581 When one IP host has a large amount of data to send to another host, 582 the data will be transmitted as a series of IP datagrams. It is 583 usually preferable that these datagrams be of the largest size that 584 does not require fragmentation anywhere along the path from the 585 source to the destination. This datagram size is referred to as the 586 Path MTU (PMTU), and is equal to the minimum of the MTUs of each hop 587 in the path [6]. 589 A technique called "Path MTU Discovery mechanism" (PMTUD) lets IP 590 hosts determine the Path MTU of an arbitrary internet path. [6] and 591 [10] specify the PMTUD mechanism for IPv4 and IPv6, respectively. 593 The PMTUD mechanism for IPv4 uses the Don't Fragment (DF) bit in the 594 IP header to dynamically discover the Path MTU. The basic idea 595 behind the PMTUD mechanism is that a source host assumes that the MTU 596 of the path is that of the first hop, and sends all its datagrams 597 with the DF bit set. If any of the datagrams is too large to be 598 forwarded without fragmentation by some intermediate router, the 599 router will discard the corresponding datagram, and will return an 600 ICMP "Destination Unreachable" (type 3) "fragmentation neeed and DF 601 set" (code 4) error message to sending host. This message will 602 report the MTU of the constricting hop, so that the sending host 603 reduces the assumed Path-MTU. 605 For IPv6, intermediate systems do not fragment packets. Thus, 606 there's an "implicit" DF bit set in every packet sent on a network. 607 If any of the datagrams is too large to be forwarded without 608 fragmentation by some intermediate router, the router will discard 609 the corresponding datagram, and will return an ICMPv6 "Packet Too 610 Big" (type 2, code 0) error message to sending host. This message 611 will report the MTU of the constricting hop, so that the sending host 612 can reduce the assumed Path-MTU accordingly. 614 As discussed in both [6] and [10], the PMTUD can be used to attack 615 TCP. An attacker could reduce the throughput of a TCP connection by 616 sending forged ICMP "Destination Unreachable, fragmentation needed 617 and DF set" packets (or their IPv6 counterpart) to the sending host, 618 and making these packets report a low MTU. 620 For IPv4, this reported Next-Hop MTU could be as low as 68 octets, as 621 [11] requires every internet module to be able to forward a datagram 622 of 68 octets without further fragmentation. For IPv6, the reported 623 Next-Hop MTU could be as low as 1280 octets (the minimum IPv6 MTU) 624 [9]. 626 Thus, this attack could considerably readuce the throughput that can 627 be achieved with the attacked TCP connection. 629 7.2.2 Attack-specific counter-measures 631 An analogous counter-measure to that described in Section 6.2.2 could 632 be implemented to greatly minimize the impact of this attack. 634 For IPv4, this would mean that upon receipt of an ICMP "fragmentation 635 needed and DF bit set" error message, TCP would just record this 636 information, and would honor it only when it had received a specified 637 number of ICMP "fragmentation needed and DF bit set" messages, and 638 provided the corresponding data had already been retransmitted a 639 specified number of times. 641 For IPv6, the same mechanism would be implemented for handling ICMPv6 642 "Packet Too Big" error messages. 644 While this policy would greatly mitigate the impact of the attack 645 against the PMTUD mechanism, it would also mean that it might take 646 TCP more time to discover the Path-MTU for a TCP connection. This 647 would be particularly annoying for connections that have just been 648 established, as it might take TCP several transmission attempts (and 649 the corresponding timeouts) until it discovers the PMTU for the 650 corresponding connection. Thus, this policy would increase the time 651 it takes for data to begin to be received at the destination host. 653 We would like to protect TCP from the attack against the PMTUD 654 mechanism, while still allowing TCP to quickly determine the initial 655 Path-MTU for a connection. 657 To achieve both goals, we can divide the traditional PMTUD mechanism 658 into two stages: Initial Path-MTU Discovery, and Path-MTU Update. 660 The Initial Path-MTU Discovery stage is when TCP tries to send 661 segments that are larger than the ones that have so far been sent for 662 this connection. That is, in the Initial Path-MTU Discovery stage 663 TCP has no record of these large segments getting to the destination 664 host, and thus it would be fair to believe the network when it 665 reports that these packets are too large to reach the destination 666 host without being fragmented. 668 The Path-MTU Update stage is when TCP tries to send segments that are 669 equal to or smaller than the ones that have already been sent and 670 acknowledged for this connection. During the Path-MTU Update stage, 671 TCP already has knowledge of the estimated Path-MTU for the given 672 connection. Thus, it would be fair to be more cautious with the 673 errors being reported by the network. 675 In order to allow TCP to distinguish segments performing Initial 676 Path-MTU Discovery from those performing Path-MTU Update, a new 677 variable should be introduced to TCP: maxsizeacked. 679 This variable would hold the size (in octets) of the largest packet 680 that has so far been sent and acknowledged for this connection. It 681 would be initialized to 68 (the minimum IPv4 MTU) when the underlying 682 internet protocol is IPv4, and would be initialized to 1280 (the 683 minimum IPv6 MTU) when the underlying internet protocol is IPv6. 684 Whenever an acknowledgement for a packet larger than maxsizeacked 685 octets is received, maxsizeacked should be set to the size of that 686 acknowledged packet. 688 Henceforth, we will refer to both ICMP "fragmentation needed and DF 689 bit set" and ICMPv6 "Packet Too Big" messages as "ICMP Packet Too 690 Big" messages. 692 Upon receipt of an ICMP "Packet Too Big" error message, the Next-Hop 693 MTU claimed by the ICMP message (henceforth "claimedmtu") would be 694 compared with maxsizeacked. If claimedmtu is equal to or larger than 695 maxsizeacked, then TCP is supposed to be at the Initial Path-MTU 696 Discovery stage, and thus the ICMP "Packet Too Big" error message 697 should be honored. That is, the assumed Path-MTU should be updated 698 according to the Next-Hop MTU claimed in the ICMP error message. 700 On the other hand, if claimedmtu is smaller than maxsizeacked, TCP is 701 supposed to be in the Path-MTU Update stage. At this stage, we 702 should be more cautious with the errors being reported by the 703 network, and will therefore delay the update of the assumed Path-MTU. 705 To perform this delay, two new parameters should be introduced to 706 TCP: MAXPKTTOOBIG, and MAXSEGRTO. MAXPKTTOOBIG would specify the 707 number of times an ICMP "Packet Too Big" must be received before it 708 can be honored to change the Path-MTU. MAXSEGRRTO would specify the 709 number of times a given segment must timeout before an ICMP "Packet 710 Too Big" error message can be honored. 712 Two variables would be needed to implement the proposed fix: 713 npkttoobig, and nsegrto. npkttoobig would be initialized to zero, 714 and would be incremented by one everytime a valid ICMP "Packet Too 715 Big" error message is received. It would be reset to zero everytime 716 an ICMP "Packet Too Big" error message is honored to change the 717 assumed Path-MTU for given internet path. nsegrto would be 718 initialized to zero, and would be incremented by one everytime the 719 corresponding segment times out. 721 Thus, the assumed Path-MTU for a given internet path would be changed 722 when an ICMP "Packet Too Big" is received, provided npkttoobig >= 723 MAXPKTTOOBIG and nsegrto >= MAXSEGRTO. When the assumed Path-MTU is 724 updated, maxsizeacked should be set to claimedmtu, so as to allow the 725 Path-MTU to be discovered quickly in the event the Path-MTU for the 726 connection increases some time later. 728 The rationale behind this proposed delay is that if there is progress 729 on the connection, the ICMP "Packet Too Big" errors must be a false 730 claim. 732 MAXPKTTOOBIG can be set to any value greater than or equal to 1. 733 MAXSEGRTO can be set, in principle, to any value greater than or 734 equal to 0. 736 Setting MAXPKTTOOBIG to 1 and MAXSEGRTO to 0 would make TCP perform 737 the traditional PMTUD mechanism defined in [6] and [10]. 739 When the values chosen for MAXSEGRTO and MAXPKTTOOBIG are such that 740 (MAXSEGRTO - MAXPKTTOOBIG) > 0, it somehow means the implementation 741 is acknowledging that segments may be lost and routers may be 742 rate-limiting their ICMP traffic. 744 MAXPKTTOOBIG and MAXSEGRTO might be a function of the Next-Hop MTU 745 claimed in the received ICMP "Packet Too Big" message. That is, 746 higher values for MAXPKTTOOBIG and MAXSEGRTO could be imposed when 747 the received ICMP "Packet Too Big" message claims a Next-Hop MTU that 748 is smaller some specified value. 750 A MAXPKTTOOBIG of 1 and a MAXSEGRTO of 1 should provide enough 751 protection for most cases. In any case, implementations are free to 752 choose higher values for any of these two constants. 754 In the event a higher level of protection is desired at the expense 755 of a higher delay in the discovery of the Path-MTU, an implementation 756 could consider TCP to always be in the Path-MTU Update stage, thus 757 always delaying the update of the assumed Path-MTU. 759 Appendix A shows the proposed counter-measure in action. 761 Appendix B describes an attack against the PMTUD mechanism that could 762 still succeed, along with a counter-measure against it. However, 763 this attack is unfeasible, and in most cases, non-sensical. 765 A mechanism that allows hosts to determine the Path-MTU of an 766 arbitrary internet path without the use of ICMP has been is described 767 in [24]. 769 8. Future work 771 The same considerations discussed in this document for TCP should be 772 applied to other similar protocols. 774 9. Security Considerations 776 This document describes the use of ICMP error messages to perform a 777 number of attacks against the TCP protocol, and proposes a number of 778 counter-measures that either eliminate or reduce the impact of these 779 attacks. 781 10. Acknowledgements 783 This document was inspired by Mika Liljeberg, while discussing some 784 issues related to [25] by private e-mail. The author would like to 785 thank James Carlson, Alan Cox, Juan Fraschini, Markus Friedl, 786 Guillermo Gont, Vivek Kakkar, Michael Kerrisk, Mika Liljeberg, David 787 Miller, Miles Nordin, Eloy Paris, Kacheong Poon, Andrew Powell, and 788 Pekka Savola for contributing many valuable comments. 790 The author wishes to express deep and heartfelt gratitude to Jorge 791 Oscar Gont and Nelida Garcia, for their precious motivation and 792 guidance. 794 11. References 796 11.1 Normative References 798 [1] Postel, J., "Transmission Control Protocol", STD 7, RFC 793, 799 September 1981. 801 [2] Postel, J., "Internet Control Message Protocol", STD 5, RFC 802 792, September 1981. 804 [3] Bradner, S., "Key words for use in RFCs to Indicate Requirement 805 Levels", BCP 14, RFC 2119, March 1997. 807 [4] Braden, R., "Requirements for Internet Hosts - Communication 808 Layers", STD 3, RFC 1122, October 1989. 810 [5] Baker, F., "Requirements for IP Version 4 Routers", RFC 1812, 811 June 1995. 813 [6] Mogul, J. and S. Deering, "Path MTU discovery", RFC 1191, 814 November 1990. 816 [7] Kent, S. and R. Atkinson, "Security Architecture for the 817 Internet Protocol", RFC 2401, November 1998. 819 [8] Conta, A. and S. Deering, "Internet Control Message Protocol 820 (ICMPv6) for the Internet Protocol Version 6 (IPv6) 821 Specification", RFC 2463, December 1998. 823 [9] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) 824 Specification", RFC 2460, December 1998. 826 [10] McCann, J., Deering, S. and J. Mogul, "Path MTU Discovery for 827 IP version 6", RFC 1981, August 1996. 829 [11] Postel, J., "Internet Protocol", STD 5, RFC 791, September 830 1981. 832 11.2 Informative References 834 [12] Watson, P., "Slipping in the Window: TCP Reset Attacks", 2004 835 CanSecWest Conference , 2004. 837 [13] Jacobson, V., Braden, B. and D. Borman, "TCP Extensions for 838 High Performance", RFC 1323, May 1992. 840 [14] Stewart, R., "Transmission Control Protocol security 841 considerations", draft-ietf-tcpm-tcpsecure-02 (work in 842 progress), November 2004. 844 [15] Touch, J., "ANONsec: Anonymous IPsec to Defend Against Spoofing 845 Attacks", draft-touch-anonsec-00 (work in progress), May 2004. 847 [16] Poon, K., "Use of TCP timestamp option to defend against blind 848 spoofing attack", draft-poon-tcp-tstamp-mod-01 (work in 849 progress), October 2004. 851 [17] Heffernan, A., "Protection of BGP Sessions via the TCP MD5 852 Signature Option", RFC 2385, August 1998. 854 [18] Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321, April 855 1992. 857 [19] Clark, D., "Fault isolation and recovery", RFC 816, July 1982. 859 [20] Gont, F., "Increasing the payload of ICMP error messages", 860 (work in progress) draft-gont-icmp-payload-00.txt, 2004. 862 [21] Allman, M., Paxson, V. and W. Stevens, "TCP Congestion 863 Control", RFC 2581, April 1999. 865 [22] Larsen, M., "Port Randomisation", 866 draft-larsen-tsvwg-port-randomisation-00 (work in progress), 867 October 2004. 869 [23] Shepard, T., "Reassign Port Number option for TCP", 870 draft-shepard-tcp-reassign-port-number-00 (work in progress), 871 July 2004. 873 [24] Mathis, M., "Path MTU Discovery", draft-ietf-pmtud-method-03 874 (work in progress), October 2004. 876 [25] Gont, F., "TCP's Reaction to Soft Errors", 877 draft-gont-tcpm-tcp-soft-errors-01 (work in progress), October 878 2004. 880 [26] Klensin, J., "Simple Mail Transfer Protocol", RFC 2821, April 881 2001. 883 [27] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., Masinter, L., 884 Leach, P. and T. Berners-Lee, "Hypertext Transfer Protocol -- 885 HTTP/1.1", RFC 2616, June 1999. 887 [28] Nagle, J., "Congestion control in IP/TCP internetworks", RFC 888 896, January 1984. 890 Author's Address 892 Fernando Gont 893 Universidad Tecnologica Nacional 894 Evaristo Carriego 2644 895 Haedo, Provincia de Buenos Aires 1706 896 Argentina 898 Phone: +54 11 4650 8472 899 EMail: fernando@gont.com.ar 901 Appendix A. The counter-measure for the PMTUD attack in action 903 This appendix shows the proposed counter-measure for the ICMP attack 904 against the PMTUD mechanism in action. It shows both how the fix 905 protects TCP from being attacked and how the counter-measure works in 906 normal scenarios. As discussed in Section 5, this Appendix assumes 907 the PMTUD-specific counter-measure is implemented in addition to the 908 TCP sequence number checking described in Section 5.1. 910 Figure 1 illustrates an hypothetical scenario in which two hosts are 911 connected by means of three intermediate routers. It also shows the 912 MTU of each hypothetical hop. All the following subsections assume 913 the network setup of this figure. 915 Also, for simplicity, all subsections assume an IP header of 20 916 octets and a TCP header of 20 octets. Thus, for example, when the 917 PMTU is assumed to be 1500 octets, TCP will send segments that 918 contain, at most, 1460 octets of data. 920 For simplicity, all the following subsections assume the TCP 921 implementation at Host 1 has chosen a MAXPKTTOOBIG of 1, and a 922 MAXSEGRTO of 1. 924 +----+ +----+ +----+ +----+ +----+ 925 | H1 |--------| R1 |--------| R2 |--------| R3 |--------| H2 | 926 +----+ +----+ +----+ +----+ +----+ 927 MTU=4464 MTU=2048 MTU=1500 MTU=4464 929 Figure 1: Hypothetical scenario 931 A.1 Normal operation for bulk transfers 933 This subsection shows the proposed counter-measure in normal 934 operation, when a TCP connection is used for bulk transfers. That 935 is, it shows how the proposed counter-measure works when there is no 936 attack taking place, and a TCP connection is used for transferring 937 large amounts of data. This section assumes that just after the 938 connection is established, one of the TCP endpoints begins to 939 transfer data in packets that are as large as possible. 941 Host 1 Host 2 943 1. --> --> 944 2. <-- <-- 945 3. --> --> 946 4. --> --> 947 5. <--- ICMP "Packet Too Big" MTU=2048, TCPseq#=101 <--- R1 948 6. --> --> 949 7. <--- ICMP "Packet Too Big" MTU=1500, TCPseq#=101 <--- R2 950 8. --> --> 951 9. <-- <-- 953 Figure 2: Normal operation for bulk transfers 955 Both npkttoobig and nsegrto are initialized to zero. maxsizeacked is 956 initialized to the minimum MTU for the internet protocol being used 957 (68 for IPv4, and 1280 for IPv6). 959 In lines 1 to 3 the three-way handshake takes place, and the 960 connection is established. In line 4, H1 tries to send a full-sized 961 TCP segment. As described by [6] and [10], in this case TCP will try 962 to send a segment with 4424 bytes of data, which will result in an IP 963 packet of 4464 octets. When the packet reaches R1, it elicits an 964 ICMP "Packet Too Big" error message. 966 In line 5, H1 receives the ICMP error message, which reports a 967 Next-Hop MTU of 2048 octets. After performing the TCP sequence 968 number check, the Next-Hop MTU reported by the ICMP error message 969 (claimedmtu) is compared with maxsizeacked. As claimedmtu is larger 970 than maxsizeacked, TCP assumes that the corresponding TCP segment was 971 performing the Initial PMTU Discovery. Therefore, the TCP at H1 972 honors the ICMP message by updating the assumed Path-MTU. 974 In line 6, the TCP at H1 sends a segment with 2008 bytes of data, 975 which results in an IP packet of 2048 octets. When the packet 976 reaches R2, it elicits an ICMP "Packet Too Big" error message. 978 In line 7, H1 receives the ICMP error message, which reports a 979 Next-Hop MTU of 1500 octets. After performing the TCP sequence 980 number check, the Next-Hop MTU reported by the ICMP error message 981 (claimedmtu) is compared with maxsizeacked. As claimedmtu is larger 982 than maxsizeacked, TCP assumes that the corresponding TCP segment was 983 performing the Initial PMTU Discovery. Therefore, the TCP at H1 984 honors the ICMP message by updating the assumed Path-MTU. 986 In line 8, the TCP at H1 sends a segment with 1460 bytes of data, 987 which results in an IP packet of 1500 octets. This packet reaches 988 H2, where it elicits an acknowledgement (ACK) segment. 990 In line 9, H1 finally gets the acknowledgement for the data segment. 991 As the corresponding packet was larger than maxsizeacked, TCP updates 992 maxsizeacked, setting it to 1500. At this point TCP has discovered 993 the Path-MTU for this TCP connection. 995 A.2 Operation during Path-MTU changes 997 Let us suppose a TCP connection between H1 and H2 has already been 998 established, and that the PMTU for the connection has already been 999 discovered to be 1500. At this point, maxsizeacked is equal to 1500, 1000 maxsegrto is equal to 0, and maxpkttoobig is equal to 0. Suppose 1001 some time later the PMTU decreases to 1492. For simplicity, let us 1002 suppose that the Path-MTU has decreased because the MTU of the link 1003 between R2 and R3 has decreased from 1500 to 1492. Figure 3 1004 illustrates how the proposed counter-measure would work in this 1005 scenario. 1007 Host 1 Host 2 1009 1. (Path-MTU decreases) 1010 2. --> --> 1011 3. <--- ICMP "Packet Too Big" MTU=1492, TCPseq#=100 <--- R2 1012 4. (Segment times out) 1013 5. --> --> 1014 6. <-- <-- 1016 Figure 3: Operation during Path-MTU changes 1018 In line 1, the Path-MTU for this connection decreases from 1500 to 1019 1492. In line 2, the TCP at H1, without being aware of the Path-MTU 1020 change, sends a packet to H2. When the packet reaches R2, it elicits 1021 an ICMP "Packet Too Big" error message. 1023 In line 3, H1 receives the ICMP error message, which reports a 1024 Next-Hop MTU of 1492 octets. After performing the TCP sequence 1025 number check, the Next-Hop MTU reported by the ICMP error message 1026 (claimedmtu) is compared with maxsizeacked. As claimedmtu is smaller 1027 than maxsizeacked, this packet is assumed to be performing Path-MTU 1028 Update. Thus, npkttoobig is incremented by one. While npkttoobig is 1029 greater than or equal to MAXPKTTOOBIG, nsegrto is still smaller than 1030 MAXSEGRTO, and thus the assumed PMTU will not yet be updated. 1032 In line 4, the segment times out. Thus, nsegrto is incremented by 1. 1033 As npkttoobig is greater than or equal to MAXPKTTOOBIG and nsegrto is 1034 greater than or equal to MAXSEGRTO, the assumed Path-MTU is updated. 1035 npkttoobig and nsegrto are reset to 0, and maxsizeacked is set to 1036 claimedmtu. 1038 In line 5, H1 retransmits the data using the updated PMTU. The 1039 resulting packet reaches H2, where it elicits an acknowledgement 1040 (ACK) segment. 1042 In line 6, H1 finally gets the acknowledgement for the data segment. 1043 At this point TCP has discovered the new Path-MTU for this TCP 1044 connection. 1046 A.3 Idle connection being attacked 1048 Let us suppose a TCP connection between H1 and H2 has already been 1049 established, and the PMTU for the connection has already been 1050 discovered to be 1500. Figure 4 shows a sample time-line diagram 1051 that illustrates an idle connection being attacked. We assume the 1052 attacker has guessed the four-tuple that identifies the connection. 1054 Host 1 Host 2 1056 1. --> --> 1057 2. <-- <-- 1058 3. <--- ICMP "Packet Too Big" MTU=68, TCPseq#=100 <--- 1059 4. <--- ICMP "Packet Too Big" MTU=68, TCPseq#=100 <--- 1060 5. <--- ICMP "Packet Too Big" MTU=68, TCPseq#=100 <--- 1062 Figure 4: Idle connection being attacked 1064 In line 1, H1 sends its last bunch of data. At line 2, H2 1065 acknowledges the receipt of these data. Then the connection becomes 1066 idle. In lines 3, 4, and 5, an attacker sends forged ICMP "Packet 1067 Too Big" error messages to H1. Regardless of how many packets it 1068 sends and the TCP sequence number each ICMP packet includes, none of 1069 these ICMP error messages will pass the TCP sequence number check 1070 described in Section 5.1, as H1 has no unacknowledged data in flight 1071 to H2. Therefore, the attack does not succeed. 1073 A.4 Active connection being attacked after discovery of the Path-MTU 1075 Let us suppose an attacker attacks a TCP connection for which the 1076 PMTU has already been discovered. In this case, as illustrated in 1077 Figure 1, the PMTU would be found to be 1500 bytes. Figure 5 shows a 1078 possible packet exchange. 1080 Host 1 Host 2 1082 1. --> --> 1083 2. --> --> 1084 3. --> --> 1085 4. --> --> 1086 5. <--- ICMP "Packet Too Big" MTU=68, TCPseq#=100 <--- 1087 6. <-- <-- 1089 Figure 5: Active connection being attacked after discovery of PMTU 1091 As we assume the PMTU has already been discovered, we also assume 1092 maxsizeacked is equal to 1500. Also, npkttoobig must be equal to 1093 zero, as no ICMP "Packet Too Big" error messages have been received 1094 for the outstanding segments. In the same way, we assume nsegrto is 1095 equal to zero, as there have been no segment timeouts. 1097 In lines 1, 2, 3, and 4, H1 sends four data segments to H2. In line 1098 5, an attacker sends a forged ICMP packet to H1. We assume the 1099 attacker is lucky enough to guess both the four-tuple that identifies 1100 the connection and a valid TCP sequence number. As the Next-Hop MTU 1101 claimed in the ICMP "Packet Too Big" message (claimedmtu) is smaller 1102 than maxsizeacked, this packet is assumed to be performing Path-MTU 1103 Update. Thus, npkttoobig is incremented by one. While npkttoobig is 1104 greater than or equal to MAXPKTTOOBIG, nsegrto is still smaller than 1105 MAXSEGRTO, and thus the assumed PMTU will not yet be updated. 1107 In line 6, H1 receives an acknowledgement for the segment from line 1108 1, before it times out. At this point, npkttoobig is set back to 1109 zero, and the pending ICMP "Packet Too Big" error message is ignored. 1110 Therefore, the attack does not succeed. 1112 Appendix B. An attack that could still succeed 1114 This Appendix is for completeness-sake only. The author believes 1115 this Appendix will be removed in future revisions of this document. 1116 In any case, input on this issue is welcome. 1118 As mentioned in Section 7.2.2, even if the proposed counter-measure 1119 for the PMTUD attack were implemented, there is an attack that could 1120 still succeed. 1122 Suppose a TCP connection is used by an application which involves the 1123 exchange of small amounts of data before large transfers take place. 1124 Applications using protocols such as SMTP [26] and HTTP [27], for 1125 example, usually behave like this. 1127 Figure 6 shows a possible packet exchange for such scenario. 1129 Host 1 Host 2 1131 1. --> --> 1132 2. <-- <-- 1133 3. --> --> 1134 4. --> --> 1135 5. <-- <-- 1136 6. --> --> 1137 7. --> --> 1138 8. <--- ICMP "Packet Too Big" MTU=150, TCPseq#=101 <--- 1140 Figure 6: An attack against the PMTUD that could still succeed 1142 Both npkttoobig and nsegrto are initialized to zero. maxsizeacked is 1143 initialized to the minimum MTU for the internet protocol being used 1144 (68 for IPv4, and 1280 for IPv6). 1146 In lines 1 to 3 the three-way handshake takes place, and the 1147 connection is established. In line 4, H1 sends a small segment to 1148 H2. In line 5 this segment is acknowledged, and thus maxsizeacked is 1149 set to 140. 1151 In lines 6 and 7, H1 sends two small segments to H2. In line 8, 1152 while the segments from lines 6 and 7 are still in flight to H2, an 1153 attacker sends a forged ICMP "Packet Too Big" error message to H1. 1154 Assuming the attacker is lucky enough to guess a valid TCP sequence 1155 number, this ICMP message will pass the TCP sequence number check. 1156 The Next-Hop MTU reported by the ICMP error message (claimedmtu) is 1157 then compared with maxsizeacked. As claimedmtu is larger than 1158 maxsizeacked, TCP assumes that the corresponding TCP segment was 1159 performing the Initial PMTU Discovery. Therefore, the TCP at H1 will 1160 incorrectly honor the ICMP message by updating the assumed MTU. 1162 Thus, the connection will assume a PMTU of 150 octets until the next 1163 PMTU-increase "probe" is sent. Depending on the implementation, this 1164 "probe" could be sent several minutes later [6][10]. 1166 It must be noted that while this attack is theoretically possible, we 1167 have assumed the attacker is lucky enough not only to guess the 1168 four-tuple that identifies the connection, but also to guess the 1169 sequence number of unacknowledged data that are in flight to H2. 1170 Given that we assume that only a few small segments are in flight to 1171 H2, this is very unlikely. Furthermore, in order to produce any 1172 performance impact, the forged ICMP error message should report a 1173 Next-Hop MTU that is small enough, but that is larger than 1174 maxsizeacked, as TCP would otherwise assume this segment is 1175 performing Path-MTU Update, and therefore would delay the update of 1176 the assumed Path-MTU. 1178 Also, it must be noted that algorithms such as that described in [28] 1179 will help to avoid sending small segments, and therefore will also 1180 help to make maxsizeacked increase quickly, making this attack 1181 non-sensical. 1183 In any case, this attack could be completely eliminated by 1184 introducing an additional variable: maxsizeinflight. For new 1185 connections, this variable would be initialized to the minimum MTU of 1186 the internet protocol being used (68 for IPv4, and 1280 for IPv6). 1188 Whenever a packet is to be transmitted, the size of the packet is 1189 compared with maxsizeinflight. If the size of the packet to be 1190 transmitted is larger than maxsizeinflight, maxsizeinflight is set to 1191 that packet size. 1193 Whenever the assumed Path-MTU is updated (either as the result of a 1194 segment performing Initial Path-MTU Discovery, or as the result of a 1195 segment performing Path-MTU Update), maxsizeinflight is set to the 1196 new assumed Path-MTU value. 1198 This way, TCP has a record of the largest packet size it has in 1199 flight, and thus can ignore ICMP "Packet Too Big" messages that claim 1200 errors that could never have happened. 1202 Appendix C. Advice and guidance to vendors 1204 Vendors are urged to contact NISCC (vulteam@niscc.gov.uk) if they 1205 think they will be effected by the issues described in this document. 1206 As the lead coordination center for these issues, NISCC is well 1207 placed to give advice and guidance as required. 1209 NISCC works extensively with government departments and agencies, 1210 commercial organizations and the academic community to research 1211 vulnerabilities and potential threats to IT systems especially where 1212 they may have an impact on Critical National Infrastructure's (CNI). 1214 Other ways to contact NISCC, plus NISCC's PGP public key, are 1215 available at http://www.uniras.gov.uk/vuls/ . 1217 Appendix D. Changes from previous versions of the draft 1219 D.1 Changes from draft-gont-tcpm-icmp-attacks-02 1221 o Fixed errors in Section 6.2.1 1223 o The proposed counter-measure for the attack against the PMTUD 1224 mechanism was refined to allow quick discovery of the Path-MTU 1226 o Appendix A was added so as to clarify the operation of the 1227 counter-measure for the attack against the PMTUD mechanism 1229 o Added Appendix C 1231 o Miscellaneous editorial changes 1233 D.2 Changes from draft-gont-tcpm-icmp-attacks-01 1235 o The document was restructured for easier reading 1237 o A discussion of ICMPv6 was added in several sections of the 1238 document 1240 o Added Section 5.2 1242 o Added Section 5.5 1244 o Added Section 7.2 1246 o Fixed typo in the ICMP types, in several places 1248 o Fixed typo in the TCP sequence number check formula 1250 o Miscellaneous editorial changes 1252 D.3 Changes from draft-gont-tcpm-icmp-attacks-00 1254 o Added a proposal to change the handling of the so-called ICMP hard 1255 errors during the synchronized states 1257 o Added a summary of the relevant RFCs in several sections 1259 o Miscellaneous editorial changes 1261 Intellectual Property Statement 1263 The IETF takes no position regarding the validity or scope of any 1264 Intellectual Property Rights or other rights that might be claimed to 1265 pertain to the implementation or use of the technology described in 1266 this document or the extent to which any license under such rights 1267 might or might not be available; nor does it represent that it has 1268 made any independent effort to identify any such rights. Information 1269 on the procedures with respect to rights in RFC documents can be 1270 found in BCP 78 and BCP 79. 1272 Copies of IPR disclosures made to the IETF Secretariat and any 1273 assurances of licenses to be made available, or the result of an 1274 attempt made to obtain a general license or permission for the use of 1275 such proprietary rights by implementers or users of this 1276 specification can be obtained from the IETF on-line IPR repository at 1277 http://www.ietf.org/ipr. 1279 The IETF invites any interested party to bring to its attention any 1280 copyrights, patents or patent applications, or other proprietary 1281 rights that may cover technology that may be required to implement 1282 this standard. Please address the information to the IETF at 1283 ietf-ipr@ietf.org. 1285 Disclaimer of Validity 1287 This document and the information contained herein are provided on an 1288 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 1289 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 1290 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 1291 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 1292 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1293 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1295 Copyright Statement 1297 Copyright (C) The Internet Society (2004). This document is subject 1298 to the rights, licenses and restrictions contained in BCP 78, and 1299 except as set forth therein, the authors retain all their rights. 1301 Acknowledgment 1303 Funding for the RFC Editor function is currently provided by the 1304 Internet Society.