idnits 2.17.1 draft-gont-tcpm-icmp-attacks-02.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 864. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 841. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 848. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 854. ** 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 8, 2004) is 7072 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 Summary: 11 errors (**), 0 flaws (~~), 5 warnings (==), 11 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 8, 2004 5 Expires: June 8, 2005 7 ICMP attacks against TCP 8 draft-gont-tcpm-icmp-attacks-02.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 8, 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 Ackowledgement 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 . . . . . . . . . . . . 12 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 . . . . . 13 77 7.2.1 Description . . . . . . . . . . . . . . . . . . . . . 13 78 7.2.2 Attack-specific counter-measures . . . . . . . . . . . 14 79 8. Future work . . . . . . . . . . . . . . . . . . . . . . . . . 15 80 9. Security Considerations . . . . . . . . . . . . . . . . . . . 15 81 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 15 82 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 15 83 11.1 Normative References . . . . . . . . . . . . . . . . . . . . 15 84 11.2 Informative References . . . . . . . . . . . . . . . . . . . 16 85 Author's Address . . . . . . . . . . . . . . . . . . . . . . . 17 86 A. Changes from draft-gont-tcpm-icmp-attacks-01 . . . . . . . . . 17 87 B. Changes from draft-gont-tcpm-icmp-attacks-00 . . . . . . . . . 18 88 Intellectual Property and Copyright Statements . . . . . . . . 19 90 1. Introduction 92 Recently, awareness has been raised about several threats against the 93 TCP [1] protocol, which include blind connection-reset attacks [12]. 94 These attacks are based on sending forged TCP segments to any of the 95 TCP endpoints, requiring the attacker to be able to guess the 96 four-tuple that identifies the connection to be attacked. 98 While these attacks were known by the research community, they were 99 considered to be unfeasible. However, increases in bandwidth 100 availability, and the use of larger TCP windows [13] have made these 101 attacks feasible. Several general solutions have been proposed to 102 either eliminate or minimize the impact of these attacks 103 [14][15][16]. For protecting BGP sessions, specifically, a 104 counter-measure had already been documented in [17], which defines a 105 new TCP option that allows a sending TCP to include a MD5 [18] 106 signature in each transmitted segment. 108 All these counter-measures address attacks that require an attacker 109 to send spoofed TCP segments to the attacked host. However, there is 110 still a possibility for performing a number of attacks against the 111 TCP protocol, by means of ICMP [2]. These attacks include, among 112 others, blind connection-reset attacks. 114 This document aims to raise awareness of the use of ICMP to perform a 115 number of attacks against TCP, and proposes several counter-measures 116 that can eliminate or minimize the impact of these attacks. 118 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 119 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 120 document are to be interpreted as described in RFC 2119 [3]. 122 2. Background 124 2.1 The Internet Control Message Protocol (ICMP) 126 The Internet Control Message Protocol (ICMP) is used in the Internet 127 Architecture to perform the fault-isolation function, that is, the 128 group of actions that hosts and routers take to determine that there 129 is some network failure [19]. 131 When an intermediate router detects a network problem while trying to 132 forward an IP packet, it will usually send an ICMP error message to 133 the source host, to raise awareness of the network problem. In the 134 same way, there are a number of cases in which an end-system may 135 generate an ICMP error message when it finds a problem while 136 processing a datagram. These error messages are notified to the 137 corresponding transport-protocol instance. 139 When the transport protocol is notified of the error condition, it 140 will perform a fault recovery function. That is, it will try to 141 survive the network failure. 143 In the case of TCP, the typical fault recovery policy is as follows: 145 o If the network problem being reported is a hard error, abort the 146 corresponding connection. 148 o If the network problem being reported is a soft error, just record 149 this information, and repeatedly retransmit the segment until 150 either it gets acknowledged, or the connection times out. 152 Some stacks honor hard errors only for connections in any of the 153 synchronized states (ESTABLISHED, FIN-WAIT-1, FIN-WAIT-2, CLOSE-WAIT, 154 CLOSING, LAST-ACK or TIME-WAIT). 156 2.1.1 ICMP for IP version 4 (ICMP) 158 [2] specifies the Internet Control Message Protocol (ICMP) to be used 159 with the Internet Protocol version 4 (IPv4). It defines, among other 160 things, a number of error messages that can be used by end-systems 161 and intermediate systems to report network errors to the sending 162 host. 164 The Host Requirements RFC [4] states that ICMP error messages of type 165 3 (Destination Unreachable) codes 2 (protocol unreachable), 3 (port 166 unreachable), and 4 (fragmentation needed and DF bit set) should be 167 considered hard errors. Thus, any of these ICMP messages could 168 elicit a connection abort. 170 The ICMP specification also defines the ICMP Source Quench message 171 (type 4, code 0), which is meant to provide a mechanism for flow 172 control and congestion control. The Requirements for IP Version 4 173 Routers RFC [5], however, states that experience has shown this ICMP 174 message is ineffective for handling these issues. 176 [6] defines a mechanism called "Path MTU Discovery" (PMTUD), which 177 makes use of ICMP error messages of type 3 (Destination Unreachable), 178 code 4 (fragmentation needed and DF bit set) to allow hosts to 179 determine the MTU of an arbitrary internet path. For obvious 180 reasons, those systems implementing the PMTUD do not treat ICMP error 181 messages of type 3 code 4 as hard errors. 183 Appendix D of [7] provides information about which ICMP error 184 messages are produced by hosts, intermediate routers, or both. 186 2.1.2 ICMP for IP version 6 (ICMPv6) 188 [8] specifies the Internet Control Message Protocol (ICMPv6) to be 189 used with the Internet Protocol version 6 (IPv6) [9]. 191 Even though ICMPv6 didn't exist when [4] was written, one could 192 extrapolate the concept of "hard errors" to ICMPv6 Type 1 193 (Destination Unreachable) codes 1 (communication with destination 194 administratively prohibited) and 4 (port unreachable). Thus, any of 195 these messages could elicit a connection abort. 197 ICMPv6 defines the "Packet Too Big" (type 2, code 0) error message, 198 that is analogous to the ICMP "fragmentation needed and DF bit set" 199 (type 3, code 4) error message. For IPv6, intermediate systems do 200 not fragment IP packets. Thus, there's an implicit "don't fragment" 201 bit set in every IPv6 datagram sent on a network. Therefore, hosts 202 do not treat ICMPv6 "Packet Too Big" messages as a hard errors, but 203 use them to discover the MTU of the corresponding internet path, as 204 part of the Path MTU Discovery mechanism for IP Version 6 [10]. 206 Appendix D of [7] provides information about which ICMPv6 error 207 messages are produced by hosts, intermediate routers, or both. 209 2.2 Handling of ICMP errors 211 The Host Requirements RFC [4] states that a TCP instance should be 212 notified of ICMP error messages received for its corresponding 213 connection. 215 In order to allow ICMP messages to be demultiplexed by the receiving 216 host, part of the orignal packet that elicited the message is 217 included in the payload of the ICMP error message. Thus, the 218 receiving host can use that information to match the ICMP error to 219 the instance of the transport protocol that elicited it. 221 Neither the Host Requirements RFC nor the original TCP specification 222 [1] recommend any security checks on the received ICMP messages. 223 Thus, as long as the ICMP payload contains the correct four-tuple 224 that identifies the communication instance, it will be processed by 225 the corresponding transport-protocol instance, and the corresponding 226 action will be performed. 228 Therefore, an attacker could send a spoofed ICMP message to the 229 attacked host, and, as long as he is able to guess the four-tuple 230 that identifies the communication instance to be attacked, he can use 231 ICMP to perform a variety of attacks. 233 As discussed in [12], there are a number of scenarios in which an 234 attacker may be able to know or guess this four-tuple. Furthermore, 235 it must be noted that most Internet services use the so-called 236 "well-known" ports, so that only the client port would need to be 237 guessed. In the event that an attacker had no knowledge about the 238 range of port numbers used by clients, this would mean that an 239 attacker would need to send, at most, 65536 packets to perform any of 240 the attacks described in this document. 242 It is clear that security checks should be performed on the received 243 ICMP error messages, to mitigate the impact of the attacks described 244 in this document. 246 3. ICMP attacks against TCP 248 ICMP messages can be used to perform a variety of attacks. These 249 attacks have been discussed by the research community to a large 250 extent. 252 Some TCP/IP implementations have added security checks on the 253 received ICMP error messages to minimize the impact of these attacks. 254 However, as there has not been any official proposal about what would 255 be the best way to deal with these attacks, these security checks 256 have not been widely implemented. 258 Section 4 of this document discusses the constraints in the general 259 counter-measures that can be implemented against the attacks 260 described in this document. Section 5 proposes several general 261 conter-measures that apply to all the ICMP attacks described in this 262 document. Finally, Section 6 and Section 7 discuss a variety of ICMP 263 attacks that can be performed against TCP, and propose 264 attack-specific counter-measures that eliminate or mitigate them. 265 These attack-specific counter-measures are meant to be additional 266 counter-measures to the ones proposed in Section 5. In particular, 267 all TCP implementations SHOULD perform the TCP sequence number 268 checking described in Section 5.1. 270 4. Constraints in the possible solutions 272 For ICMPv4, [2] states that the internet header plus the first 64 273 bits of the packet that elicited the ICMP message are to be included 274 in the payload of the ICMP error message. Thus, it is assumed that 275 all data needed to identify a transport protocol instance and process 276 the ICMP error message is contained in the first 64 bits of the 277 transport protocol header. [4] states that "the Internet header and 278 at least the first 8 data octets of the datagram that triggered the 279 error" are to be included in the payload of ICMP error messages, and 280 that "more than 8 octets MAY be sent", thus requiring implementations 281 to include more data from the original packet than that required by 282 the original ICMP specification. The "Requirements for IP Version 4 283 Routers RFC" [5] states that ICMP error messages "SHOULD contain as 284 much of the original datagram as possible without the length of the 285 ICMP datagram exceeding 576 bytes". 287 Thus, for ICMP messages generated by hosts, we can only expect to get 288 the entire IP header of the original packet, plus the first 64 bits 289 of its payload. For TCP, that means that the only fields that will 290 be included are: the source port number, the destination port number, 291 and the 32-bit TCP sequence number. This clearly imposes a 292 constraint on the possible checks we can perform, as there is not 293 much information avalable on which to perform these security checks. 294 While there exists a proposal to recommend hosts to include more data 295 from the original datagram in the payload of ICMP error messages 296 [20], and some TCP/IP implementations already do this, we cannot yet 297 propose any work-around based on checks performed on any data past 298 the first 64 bits of the payload of the original IP datagram that 299 elicited the ICMP error message. Thus, the only check that can be 300 performed on the ICMP error message is that of the TCP sequence 301 number contained in the payload. 303 As discussed above, for those ICMP error messages generated by 304 routers, we can expect to receive much more octets from the original 305 packet than just the entire IP header and the first 64 bits of the 306 transport protocol header. Therefore, not only can hosts check the 307 TCP sequence number contained in the payload of the ICMP error 308 message, but they could perform further checks such as checking the 309 TCP acknowledgement number, as discussed in Section 5.2. 311 For ICMPv6, the payload of ICMPv6 error messages includes as many 312 octets of the IPv6 packet that elicited the ICMPv6 error message as 313 will fit without making the resulting ICMPv6 packet exceed the 314 minimum IPv6 MTU (1280 octets) [8]. Thus, further checks (as those 315 described above) can be performed on the received ICMP error 316 messages. 318 5. General counter-measures against ICMP attacks 320 There are a number of counter-measures that can be implemented to 321 eliminate or mitigate the attacks discussed in this document. Rather 322 than being alternative counter-measures, they can be implemented 323 together to increase the protection against these attacks. 325 5.1 TCP sequence number checking 327 TCP SHOULD check that the TCP sequence number contained in the 328 payload of the ICMP error message is within the range SND.UNA =< 329 SEG.SEQ < SND.NXT. This means that the sequence number should be 330 within the range of the data already sent but not yet acknowledged. 331 If an ICMP error message doesn't pass this check, it SHOULD be 332 discarded. 334 Even if an attacker were able to guess the four-tuple that identifies 335 the TCP connection, this additional check would reduce the 336 possibility of considering a spoofed ICMP packet as valid to 337 Flight_Size/2^^32 (where Flight_Size is the number of data bytes 338 already sent to the remote peer, but not yet acknowledged [21]). For 339 connections in the SYN-SENT or SYN-RECEIVED states, this would reduce 340 the possibility of considering a spoofed ICMP packet as valid to 341 1/2^^32. For a TCP endpoint with no data "in flight", this would 342 completely eliminate the possibility of success of these attacks. 344 5.2 TCP Ackowledgement number checking 346 As discussed in Section 4, for those ICMP error messages that are 347 generated by intermediate routers, additional checks can be 348 performed. TCP SHOULD check that the TCP Acknowledgement number 349 contained in the payload of the ICMP error message is withing the 350 range SEG.ACK <= RCV.NXT. This means that the TCP Acknowledgement 351 number should correspond to data that have already been acknowledged. 353 This would reduce the possibility of considering a spoofed ICMP 354 packet as valid by a factor of two. 356 5.3 Port randomization 358 As discussed in the previous sections, in order to perform any of the 359 attacks described in this document, an attacker needs to guess (or 360 know) the four-tuple that identifies the connection to be attacked. 361 Randomizing the ephemeral ports used by the clients would make it 362 harder for an attacker to perform any of the attacks discussed in 363 this document. 365 [22] discusses a number of algorithms to randomize the ephemeral 366 ports used by clients. 368 Also, a proposal exists to enable TCP to reassign a well-known port 369 number to a random value [23]. 371 5.4 Authentication 373 Hosts could require ICMP error messages to be authenticated [7], in 374 order to act upon them. However, while this requirement could make 375 sense for those ICMP error messages sent by hosts, it would not be 376 feasible for those ICMP error messages generated by intermediate 377 routers. 379 [7] contains a discussion on the authentication of ICMP messages. 381 5.5 Filtering ICMP errors based on the ICMP payload 383 As discussed in Section 4, the source address of ICMP error messages 384 does not need to be spoofed to perform the attacks described in this 385 draft. Thus, simple filtering based on the source address of ICMP 386 error messages does not serve as a counter-measure against these 387 attacks. However, a more advanced packet filtering could be used as 388 a counter-measure. Systems performing such advanced filtering would 389 look at the payload of the ICMP error messages, and would perform 390 ingress and egress packet filtering based on the source IP address of 391 the IP header contained in the payload of the ICMP error message. As 392 the source IP address contained in the payload of the ICMP error 393 message does need to be spoofed to perform the attacks described in 394 this document, this kind of advanced filtering would serve as a 395 counter-measure against these attacks. 397 6. Blind connection-reset attacks 399 6.1 Description 401 The Host Requirements RFC [4] states that a host SHOULD abort the 402 corresponding connection when receiving an ICMP error message that 403 indicates a hard error. 405 Thus, an attacker could use ICMP to perform a blind connection-reset 406 attack. That is, even being off-path, an attacker could reset any 407 TCP connection taking place. In order to perform such an attack, an 408 attacker would send any ICMP error message that indicates a "hard 409 error", to either of the two TCP endpoints of the connection. 410 Because of TCP's fault recovery policy, the connection would be 411 immediately aborted. 413 As discussed in Section 2.2, all an attacker needs to know to perform 414 such an attack is the socket pair that identifies the TCP connection 415 to be attacked. In some scenarios, the IP addresses and port numbers 416 in use may be easily guessed or known to the attacker [12]. 418 Some stacks are known to extrapolate ICMP errors across TCP 419 connections, increasing the impact of this attack, as a single ICMP 420 packet could bring down all the TCP connections between the 421 corresponding peers. 423 There are some points to be considered about this type of attack: 425 o The source address of the ICMP error message need not be forged. 426 Thus, simple filtering based on the source address of ICMP packets 427 would not serve as a counter-measure against this type of attack. 429 o Even if TCP itself were protected against the blind 430 connection-reset attack described in [12] and [14], the type of 431 attack described in this document could still succeed. 433 6.2 Attack-specific counter-measures 435 6.2.1 Changing the reaction to hard errors 437 As discussed in Section 6.1, hosts MUST NOT extrapolate ICMP errors 438 across TCP connections. 440 An analysis of the circumstances in which ICMP messages that indicate 441 hard errors may be received can shed some light to minimize (or even 442 eliminate) the impact of blind connection-reset attacks. 444 ICMP type 3 (Destination Unreachable), code 2 (protocol unreachable) 446 For ICMP messages of type 3 (Destination Unreachable) code 2 447 (protocol unreachable), specifically, the Host Requirements RFC 448 states that even those transport protocols that have their own 449 mechanisms to indicate that a port is unreachable MUST accept 450 these ICMP error messages for the same purpose. That is, they 451 MUST abort the corresponding connection when an ICMP port 452 unreachable message is received. 454 This ICMP error message indicates that the host sending the ICMP 455 error message received a packet meant for a transport protocol it 456 does not support. For connection-oriented protocols such as TCP, 457 one could expect to receive such an error as the result of a 458 connection establishment attempt. However, it would be strange to 459 get such an error during the life of a connection, as this would 460 indicate that support for that transport protocol has been removed 461 from the host sending the error message during the life of the 462 corresponding connection. Thus, it would be fair to treat ICMP 463 protocol unreachable error messages as soft errors (or completely 464 ignore them) if they are meant for connections that are in 465 synchronized states. For TCP, this means one would treat ICMP 466 port unreachable error messages as soft errors (or completely 467 ignore them) if they are meant for connections that are in the 468 ESTABLISHED, FIN-WAIT-1, FIN-WAIT-2, CLOSE-WAIT, CLOSING, LAST-ACK 469 or TIME-WAIT states. 471 ICMP type 3 (Destination Unreachable), code 3 (port unreachable) 473 This error message indicates that the host sending the ICMP error 474 message received a packet meant for a socket (IP address, port 475 number) on which there is no process listening. Those transport 476 protocols which have their own mechanisms for notifying this 477 condition should not be receiving these error messages. However, 478 the Host Requirements RFC [4] states that even those transport 479 protocols that have their own mechanism for notifying the sender 480 that a port is unreachable MUST nevertheless accept an ICMP Port 481 Unreachable for the same purpose. For security reasons, it would 482 be fair to treat ICMP port unreachable messages as soft errors (or 483 completely ignore them) when they are meant for protocols that 484 have their own mechanism for reporting this condition. 486 ICMP type 3 (Destination Unreachable), code 4 (fragmentation needed 487 and DF bit set) 489 This error message indicates that an intermediate node needed to 490 fragment a datagram, but the DF (Don't Fragment) bit in the IP 491 header was set. Those systems that do not implement the PMTUD 492 mechanism should not be sending their IP packets with the DF bit 493 set, and thus should not be receiving these ICMP error messages. 494 Thus, it would be fair for them to completely ignore this ICMP 495 error message. On the other hand, and for obvious reasons, those 496 systems implementing the Path-MTU Discovery (PMTUD) mechanism [6] 497 should not abort the corresponding connection when such an ICMP 498 error message is received. 500 ICMPv6 type 1 (Destination Unreachable), code 1 (communication with 501 destination administratively prohibited) 503 This error message indicates that the destination is unreachable 504 because of an administrative policy. For connection-oriented 505 protocols such as TCP, one could expect to receive such an error 506 as the result of a connection-establishment attempt. Receiving 507 such an error for a connection in any of the synchronized states 508 would mean that the administrative policy changed during the life 509 of the connection. Therefore, while it would be possible for a 510 firewall to be reconfigured during the life of a connection, it 511 would be fair, for security reasons, to ignore these messages for 512 connections that are in the ESTABLISHED, FIN-WAIT-1, FIN-WAIT-2, 513 CLOSE-WAIT, CLOSING, LAST-ACK or TIME-WAIT states. 515 ICMPv6 type 1 (Destination Unreachable), code 4 (port unreachable) 517 This error message is analogous to the ICMP type 3 (Destination 518 unreachable), code 3 (Port unreachable) error message discussed 519 above. Therefore, the same considerations apply. 521 6.2.2 Delaying the connection-reset 523 An alternative counter-measure could be to delay the conenction 524 reset. Rather than immediately aborting a connection, a TCP could 525 abort a connection only after an ICMP error message indicating a hard 526 error has been received a specified number of times, and the 527 corresponding data have already been retransmitted more than some 528 specified number of times. 530 For example, hosts could abort connections only after a fourth ICMP 531 error message indicating a hard error is received, and the 532 corresponding data have already been retransmitted more than six 533 times. 535 The rationale behind this proposed fix is that if a host can make 536 forward progress on a connection, it can completely disregard the 537 "hard errors" being indicated by the received ICMP error messages. 539 While this counter-measure could be useful, we think that the 540 counter-measure discussed in Section 6.2.1 is more simple to 541 implement and provides increased protection against this type of 542 attack. 544 7. Blind throughput-reduction attacks 546 The following subsections discuss a number of attacks that can be 547 performed against TCP to reduce the throughput of a TCP connection. 548 While these attacks do not reset the corresponding TCP connection, 549 they may reduce their throughput to such an extent that they may 550 become practically unusable. 552 7.1 ICMP Source Quench attack 554 7.1.1 Description 556 The Host requirements RFC states hosts MUST react to ICMP Source 557 Quench messages by slowing transmission on the connection. Thus, an 558 attacker could send ICMP Source Quench (type 4, code 0) messages to a 559 TCP endpoint to make it reduce the rate at which it sends data to the 560 other party. While this would not reset the connection, it would 561 certainly degrade the performance of the data transfer taking place 562 over it. 564 7.1.2 Attack-specific counter-measures 566 The Host Requirements RFC [4] states that hosts MUST react to ICMP 567 Source Quench messages by slowing transmission on the connection. 568 However, as discussed in the Requirements for IP Version 4 Routers 569 RFC [5], research seems to suggest ICMP Source Quench is an 570 ineffective (and unfair) antidote for congestion. Thus, we recommend 571 hosts to completely ignore ICMP Source Quench messages. 573 7.2 ICMP attack against the PMTU Discovery mechanism 575 7.2.1 Description 577 When one IP host has a large amount of data to send to another host, 578 the data will be transmitted as a series of IP datagrams. It is 579 usually preferable that these datagrams be of the largest size that 580 does not require fragmentation anywhere along the path from the 581 source to the destination. This datagram size is referred to as the 582 Path MTU (PMTU), and is equal to the minimum of the MTUs of each hop 583 in the path [6]. 585 A technique called "Path MTU Discovery mechanism" (PMTUD) lets IP 586 hosts determine the Path MTU of an arbitrary internet path. [6] and 587 [10] specify the PMTUD mechanism for IPv4 and IPv6, respectively. 589 The PMTUD mechanism for IPv4 uses the Don't Fragment (DF) bit in the 590 IP header to dynamically discover the Path MTU. The basic idea 591 behind the PMTUD mechanism is that a source host assumes that the MTU 592 of the path is the MTU of its first hop, and sends all its datagrams 593 with the DF bit set. If any of the datagrams is too large to be 594 forwarded without fragmentation by some intermediate router, the 595 router will discard the corresponding datagram, and will return an 596 ICMP "Destination Unreacheable" (type 3) "fragmentation neeed and DF 597 set" (code 4) error message to sending host. This message will 598 report the MTU of the constricting hop, so that the sending host 599 reduces the assumed Path-MTU. 601 For IPv6, intermediate systems do not fragment packets. Thus, 602 there's an "implicit" DF bit set in every packet sent on a network. 603 If any of the datagrams is too large to be forwarded without 604 fragmentation by some intermediate router, the router will discard 605 the corresponding datagram, and will return an ICMPv6 "Packet Too 606 Big" (type 2, code 0) error message to sending host. This message 607 will report the MTU of the constricting hop, so that the sending host 608 can reduce the assumed Path-MTU accordingly. 610 As discussed in both [6] and [10], the PMTUD can be used to attack 611 TCP. An attacker could reduce the throughput of a TCP connection by 612 forging ICMP "Destination Unreachable, fragmentation needed and DF 613 set" packets (or their IPv6 counterpart), and making these packets 614 report a low MTU. 616 For IPv4, this reported Next-Hop MTU could be as low as 68 octets, as 618 [11] requires every internet module to be able to forward a datagram 619 of 68 octets without further fragmentation. For IPv6, the reported 620 Next-Hop MTU could be as low as 1280 octets (the minimum IPv6 MTU) 621 [9]. 623 Thus, this attack could considerably readuce the throughput that can 624 be achieved with the attacked TCP connection. 626 7.2.2 Attack-specific counter-measures 628 An analogous counter-measure to that described in Section 6.2.2 could 629 be implemented to greatly minimize the impact of this attack. 631 For IPv4, this would mean that upon receipt of an ICMP "fragmentation 632 needed and DF bit set" error message, TCP would just record this 633 information, and would honor it only when it had received a specified 634 number of ICMP "fragmentation needed and DF bit set" messages, and 635 provided the corresponding data had already been retransmitted a 636 specified number of times. 638 For IPv6, the same mechanism would be implemented ICMPv6 "Packet Too 639 Big" error messages. 641 Henceforth, we will refer to both ICMP "fragmentation needed and DF 642 bit set" and ICMPv6 "Packet Too Big" messages as "ICMP Packet Too 643 Big" messages. 645 To implement the proposed fix, two new parameters would be introduced 646 to TCP: MAXPKTTOOBIG, and MAXSEGREXMIT. MAXPKTTOOBIG would specify 647 the number of times an ICMP "Packet Too Big" must be received before 648 it can be honored to change the Path-MTU. MAXSEGREXMIT would specify 649 the number of times a given segment must be retransmitted before an 650 ICMP "Packet Too Big" error message can be honored. 652 Two variables would be needed to implement the proposed fix: 653 npkttoobig, and nsegrexmit. npkttoobig would be initialized to zero, 654 and would be incremented by one everytime a valid ICMP "Packet Too 655 Big" error message is received. It would be reset to zero everytime 656 an ICMP "Packet Too Big" error message is honored to change the 657 assumed Path-MTU for given internet path. nsegrexmit would be 658 initialized to zero, and would be incremented by one everytime the 659 corresponding segment is retransmitted. 661 Thus, the Path-MTU for a given internet path would be changed only 662 when a ICMP "Packet Too Big" is received, provided npkttoobig >= 663 MAXPKTTOOBIG and nsegrexmit >= MAXSEGREXMIT. 665 The rationale behind this proposed fix is that if there is progress 666 on the connection, ICMP "Packet Too Big" messages must be a false 667 claim. 669 MAXPKTTOOBIG and MAXSEGREXMIT might be a function of the Next-Hop MTU 670 claimed in the received ICMP "Packet Too Big" message. That is, 671 higher values for MAXPKTTOOBIG and MAXSEGREXMIT could be required 672 when the received ICMP "Packet Too Big" message claims a Next-Hop MTU 673 that is bellow some specified value. 675 As discussed in Section 7.2.1, hosts should impose lower limits in 676 the reported Next-Hop MTU values they honor. For example, for IPv4 677 this lower limit could be safely raised to 296 octets, the MTU for 678 Point-To-Point (low delay) links [6]. This lower limit could be 679 probably raised to a higher value, such as 500 octets. 681 A mechanism that allows hosts to determine the Path-MTU without the 682 use of ICMP has been is described in [24]. 684 8. Future work 686 The same considerations discussed in this document should be applied 687 to other similar protocols. 689 9. Security Considerations 691 This document describes the use of ICMP error messages to perform a 692 number of attacks against the TCP protocol, and proposes a number of 693 counter-measures that either eliminate or reduce the impact of these 694 attacks. 696 10. Acknowledgements 698 This document was inspired by Mika Liljeberg, while discussing some 699 issues related to [25] by private e-mail. The author would like to 700 thank James Carlson, Alan Cox, Juan Fraschini, Markus Friedl, 701 Guillermo Gont, Vivek Kakkar, Michael Kerrisk, Mika Liljeberg, David 702 Miller, Eloy Paris, Kacheong Poon, Andrew Powell, and Pekka Savola 703 for contributing many valuable comments. 705 The author wishes to express deep and heartfelt gratitude to Jorge 706 Oscar Gont and Nelida Garcia, for their precious motivation and 707 guidance. 709 11. References 711 11.1 Normative References 713 [1] Postel, J., "Transmission Control Protocol", STD 7, RFC 793, 714 September 1981. 716 [2] Postel, J., "Internet Control Message Protocol", STD 5, RFC 717 792, September 1981. 719 [3] Bradner, S., "Key words for use in RFCs to Indicate Requirement 720 Levels", BCP 14, RFC 2119, March 1997. 722 [4] Braden, R., "Requirements for Internet Hosts - Communication 723 Layers", STD 3, RFC 1122, October 1989. 725 [5] Baker, F., "Requirements for IP Version 4 Routers", RFC 1812, 726 June 1995. 728 [6] Mogul, J. and S. Deering, "Path MTU discovery", RFC 1191, 729 November 1990. 731 [7] Kent, S. and R. Atkinson, "Security Architecture for the 732 Internet Protocol", RFC 2401, November 1998. 734 [8] Conta, A. and S. Deering, "Internet Control Message Protocol 735 (ICMPv6) for the Internet Protocol Version 6 (IPv6) 736 Specification", RFC 2463, December 1998. 738 [9] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) 739 Specification", RFC 2460, December 1998. 741 [10] McCann, J., Deering, S. and J. Mogul, "Path MTU Discovery for 742 IP version 6", RFC 1981, August 1996. 744 [11] Postel, J., "Internet Protocol", STD 5, RFC 791, September 745 1981. 747 11.2 Informative References 749 [12] Watson, P., "Slipping in the Window: TCP Reset Attacks", 2004 750 CanSecWest Conference , 2004. 752 [13] Jacobson, V., Braden, B. and D. Borman, "TCP Extensions for 753 High Performance", RFC 1323, May 1992. 755 [14] Stewart, R., "Transmission Control Protocol security 756 considerations", draft-ietf-tcpm-tcpsecure-02 (work in 757 progress), November 2004. 759 [15] Touch, J., "ANONsec: Anonymous IPsec to Defend Against Spoofing 760 Attacks", draft-touch-anonsec-00 (work in progress), May 2004. 762 [16] Poon, K., "Use of TCP timestamp option to defend against blind 763 spoofing attack", draft-poon-tcp-tstamp-mod-01 (work in 764 progress), October 2004. 766 [17] Heffernan, A., "Protection of BGP Sessions via the TCP MD5 767 Signature Option", RFC 2385, August 1998. 769 [18] Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321, April 770 1992. 772 [19] Clark, D., "Fault isolation and recovery", RFC 816, July 1982. 774 [20] Gont, F., "Increasing the payload of ICMP error messages", 775 (work in progress) draft-gont-icmp-payload-00.txt, 2004. 777 [21] Allman, M., Paxson, V. and W. Stevens, "TCP Congestion 778 Control", RFC 2581, April 1999. 780 [22] Larsen, M., "Port Randomisation", 781 draft-larsen-tsvwg-port-randomisation-00 (work in progress), 782 October 2004. 784 [23] Shepard, T., "Reassign Port Number option for TCP", 785 draft-shepard-tcp-reassign-port-number-00 (work in progress), 786 July 2004. 788 [24] Mathis, M., "Path MTU Discovery", draft-ietf-pmtud-method-03 789 (work in progress), October 2004. 791 [25] Gont, F., "TCP's Reaction to Soft Errors", 792 draft-gont-tcpm-tcp-soft-errors-01 (work in progress), October 793 2004. 795 Author's Address 797 Fernando Gont 798 Universidad Tecnologica Nacional 799 Evaristo Carriego 2644 800 Haedo, Provincia de Buenos Aires 1706 801 Argentina 803 Phone: +54 11 4650 8472 804 EMail: fernando@gont.com.ar 806 Appendix A. Changes from draft-gont-tcpm-icmp-attacks-01 807 o The document was restructured for easier reading. 809 o A discussion of ICMPv6 was added in several sections of the 810 document 812 o Added Section 5.2 814 o Added Section 5.5 816 o Added Section 7.2 818 o Fixed typo in the ICMP types, in several places 820 o Fixed typo in the TCP sequence number check formula 822 o Miscellaneous editorial changes 824 Appendix B. Changes from draft-gont-tcpm-icmp-attacks-00 826 o Added Section ChangingHandling 828 o Added a summary of the relevant RFCs in several sections 830 o Miscellaneous editorial changes 832 Intellectual Property Statement 834 The IETF takes no position regarding the validity or scope of any 835 Intellectual Property Rights or other rights that might be claimed to 836 pertain to the implementation or use of the technology described in 837 this document or the extent to which any license under such rights 838 might or might not be available; nor does it represent that it has 839 made any independent effort to identify any such rights. Information 840 on the procedures with respect to rights in RFC documents can be 841 found in BCP 78 and BCP 79. 843 Copies of IPR disclosures made to the IETF Secretariat and any 844 assurances of licenses to be made available, or the result of an 845 attempt made to obtain a general license or permission for the use of 846 such proprietary rights by implementers or users of this 847 specification can be obtained from the IETF on-line IPR repository at 848 http://www.ietf.org/ipr. 850 The IETF invites any interested party to bring to its attention any 851 copyrights, patents or patent applications, or other proprietary 852 rights that may cover technology that may be required to implement 853 this standard. Please address the information to the IETF at 854 ietf-ipr@ietf.org. 856 Disclaimer of Validity 858 This document and the information contained herein are provided on an 859 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 860 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 861 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 862 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 863 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 864 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 866 Copyright Statement 868 Copyright (C) The Internet Society (2004). This document is subject 869 to the rights, licenses and restrictions contained in BCP 78, and 870 except as set forth therein, the authors retain all their rights. 872 Acknowledgment 874 Funding for the RFC Editor function is currently provided by the 875 Internet Society.