idnits 2.17.1 draft-gont-tcpm-icmp-attacks-04.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 18. -- Found old boilerplate from RFC 3978, Section 5.5 on line 1456. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1433. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1440. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1446. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No '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 document has an RFC 3978 Section 5.2(a) Derivative Works Limitation clause. == 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 (September 5, 2005) is 6800 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. '2') (Obsoleted by RFC 9293) ** Obsolete normative reference: RFC 2401 (ref. '6') (Obsoleted by RFC 4301) ** Obsolete normative reference: RFC 2463 (ref. '7') (Obsoleted by RFC 4443) ** Obsolete normative reference: RFC 2460 (ref. '8') (Obsoleted by RFC 8200) ** Obsolete normative reference: RFC 1981 (ref. '9') (Obsoleted by RFC 8201) -- Obsolete informational reference (is this intentional?): RFC 816 (ref. '14') (Obsoleted by RFC 7805) -- Obsolete informational reference (is this intentional?): RFC 2385 (ref. '16') (Obsoleted by RFC 5925) -- Obsolete informational reference (is this intentional?): RFC 2581 (ref. '18') (Obsoleted by RFC 5681) -- Obsolete informational reference (is this intentional?): RFC 1323 (ref. '23') (Obsoleted by RFC 7323) == Outdated reference: A later version (-13) exists of draft-ietf-tcpm-tcpsecure-03 == Outdated reference: A later version (-11) exists of draft-ietf-pmtud-method-04 == Outdated reference: A later version (-02) exists of draft-gont-tcpm-tcp-soft-errors-01 -- Obsolete informational reference (is this intentional?): RFC 2821 (ref. '34') (Obsoleted by RFC 5321) -- Obsolete informational reference (is this intentional?): RFC 2616 (ref. '35') (Obsoleted by RFC 7230, RFC 7231, RFC 7232, RFC 7233, RFC 7234, RFC 7235) Summary: 9 errors (**), 0 flaws (~~), 5 warnings (==), 13 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 September 5, 2005 5 Expires: March 9, 2006 7 ICMP attacks against TCP 8 draft-gont-tcpm-icmp-attacks-04.txt 10 Status of this Memo 12 By submitting this Internet-Draft, each author represents that any 13 applicable patent or other IPR claims of which he or she is aware 14 have been or will be disclosed, and any of which he or she becomes 15 aware will be disclosed, in accordance with Section 6 of BCP 79. 16 This document may not be modified, and derivative works of it may not 17 be created, except to publish it as an RFC and to translate it into 18 languages other than English. 20 Internet-Drafts are working documents of the Internet Engineering 21 Task Force (IETF), its areas, and its working groups. Note that 22 other groups may also distribute working documents as Internet- 23 Drafts. 25 Internet-Drafts are draft documents valid for a maximum of six months 26 and may be updated, replaced, or obsoleted by other documents at any 27 time. It is inappropriate to use Internet-Drafts as reference 28 material or to cite them other than as "work in progress." 30 The list of current Internet-Drafts can be accessed at 31 http://www.ietf.org/ietf/1id-abstracts.txt. 33 The list of Internet-Draft Shadow Directories can be accessed at 34 http://www.ietf.org/shadow.html. 36 This Internet-Draft will expire on March 9, 2006. 38 Copyright Notice 40 Copyright (C) The Internet Society (2005). 42 Abstract 44 This document discusses the use of the Internet Control Message 45 Protocol (ICMP) to perform a variety of attacks against the 46 Transmission Control Protocol (TCP) and other similar protocols. It 47 proposes several counter-measures to eliminate or minimize the impact 48 of these attacks. 50 Table of Contents 52 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 53 2. Background . . . . . . . . . . . . . . . . . . . . . . . . . . 3 54 2.1. The Internet Control Message Protocol (ICMP) . . . . . . . 4 55 2.1.1. ICMP for IP version 4 (ICMP) . . . . . . . . . . . . . 4 56 2.1.2. ICMP for IP version 6 (ICMPv6) . . . . . . . . . . . . 4 57 2.2. Handling of ICMP error messages . . . . . . . . . . . . . 5 58 3. Constraints in the possible solutions . . . . . . . . . . . . 5 59 4. General counter-measures against ICMP attacks . . . . . . . . 7 60 4.1. TCP sequence number checking . . . . . . . . . . . . . . . 7 61 4.2. Port randomization . . . . . . . . . . . . . . . . . . . . 8 62 4.3. Filtering ICMP error messages based on the ICMP payload . 8 63 5. Blind connection-reset attack . . . . . . . . . . . . . . . . 8 64 5.1. Description . . . . . . . . . . . . . . . . . . . . . . . 8 65 5.2. Attack-specific counter-measures . . . . . . . . . . . . . 9 66 5.2.1. Changing the reaction to hard errors . . . . . . . . . 9 67 5.2.2. Delaying the connection-reset . . . . . . . . . . . . 12 68 6. Blind throughput-reduction attack . . . . . . . . . . . . . . 12 69 6.1. Description . . . . . . . . . . . . . . . . . . . . . . . 12 70 6.2. Attack-specific counter-measures . . . . . . . . . . . . . 12 71 7. Blind performance-degrading attack . . . . . . . . . . . . . . 13 72 7.1. Description . . . . . . . . . . . . . . . . . . . . . . . 13 73 7.2. Attack-specific counter-measures . . . . . . . . . . . . . 14 74 8. Security Considerations . . . . . . . . . . . . . . . . . . . 17 75 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 17 76 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 18 77 10.1. Normative References . . . . . . . . . . . . . . . . . . . 18 78 10.2. Informative References . . . . . . . . . . . . . . . . . . 19 79 Appendix A. The counter-measure for the PMTUD attack in action . 20 80 A.1. Normal operation for bulk transfers . . . . . . . . . . . 21 81 A.2. Operation during Path-MTU changes . . . . . . . . . . . . 22 82 A.3. Idle connection being attacked . . . . . . . . . . . . . . 24 83 A.4. Active connection being attacked after discovery of 84 the Path-MTU . . . . . . . . . . . . . . . . . . . . . . . 24 85 A.5. TCP peer attacked when sending small packets just 86 after the three-way handshake . . . . . . . . . . . . . . 25 87 Appendix B. Pseudo-code for the counter-measure for the blind 88 performance-degrading attack . . . . . . . . . . . . 26 89 Appendix C. Advice and guidance to vendors . . . . . . . . . . . 30 90 Appendix D. Changes from previous versions of the draft . . . . . 30 91 D.1. Changes from draft-gont-tcpm-icmp-attacks-03 . . . . . . . 30 92 D.2. Changes from draft-gont-tcpm-icmp-attacks-02 . . . . . . . 30 93 D.3. Changes from draft-gont-tcpm-icmp-attacks-01 . . . . . . . 31 94 D.4. Changes from draft-gont-tcpm-icmp-attacks-00 . . . . . . . 31 95 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 32 96 Intellectual Property and Copyright Statements . . . . . . . . . . 33 98 1. Introduction 100 ICMP [1] is a fundamental part of the TCP/IP protocol suite, and is 101 used mainly for reporting network error conditions. However, the 102 current specifications do not recommend any kind of validation checks 103 on the received ICMP error messages, thus leaving the door open to a 104 variety of attacks that can be performed against TCP [2] by means of 105 ICMP, which include blind connection-reset, blind throughput- 106 reduction, and blind performance-degrading attacks. All these 107 attacks can be performed even being off-path, without the need to 108 sniff the packets that correspond to the attacked TCP connection. 110 While the security implications of ICMP have been known in the 111 research community for a long time, there has never been an official 112 proposal on how to deal with these attacks. Thus, only a few 113 implementations have implemented validation checks on the received 114 ICMP error messages to minimize the impact of these attacks. 116 Recently, a disclosure process has been carried out by the UK's 117 National Infrastructure Security Co-ordination Centre (NISCC), with 118 the collaboration of other computer emergency response teams. A 119 large number of implementations were found vulnerable to either all 120 or a subset of the attacks discussed in this document [12][13]. The 121 affected systems ranged from TCP/IP implementations meant for desktop 122 computers, to TCP/IP implementations meant for core Internet routers. 124 This document aims to raise awareness of the use of ICMP to perform a 125 variety of attacks against TCP, and proposes several counter-measures 126 that eliminate or minimize the impact of these attacks. 128 Section 2 provides background information on ICMP. Section 3 of this 129 document discusses the constraints in the general counter-measures 130 that can be implemented against the attacks described in this 131 document. Section 4 proposes several general validation checks and 132 counter-measures that can be implemented to mitigate any ICMP-based 133 attack. Finally, Section 5, Section 6, and Section 7, discuss a 134 variety of ICMP attacks that can be performed against TCP, and 135 propose attack-specific counter-measures that eliminate or greatly 136 mitigate their impact. 138 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 139 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 140 document are to be interpreted as described in RFC 2119 [3]. 142 2. Background 143 2.1. The Internet Control Message Protocol (ICMP) 145 The Internet Control Message Protocol (ICMP) is used in the Internet 146 Architecture mainly to perform the fault-isolation function, that is, 147 the group of actions that hosts and routers take to determine that 148 there is some network failure [14]. 150 When an intermediate router detects a network problem while trying to 151 forward an IP packet, it will usually send an ICMP error message to 152 the source host, to raise awareness of the network problem taking 153 place. In the same way, there are a number of scenarios in which an 154 end-system may generate an ICMP error message if it finds a problem 155 while processing a datagram. The received ICMP errors are handled to 156 the corresponding transport-protocol instance, which will usually 157 perform a fault recovery function. 159 2.1.1. ICMP for IP version 4 (ICMP) 161 [1] specifies the Internet Control Message Protocol (ICMP) to be used 162 with the Internet Protocol version 4 (IPv4). It defines, among other 163 things, a number of error messages that can be used by end-systems 164 and intermediate systems to report network errors to the sending 165 host. The Host Requirements RFC [4] classifies ICMP error messages 166 into those that indicate "soft errors", and those that indicate "hard 167 errors", thus roughly defining the semantics of them. 169 The ICMP specification [1] also defines the ICMP Source Quench 170 message (type 4, code 0), which is meant to provide a mechanism for 171 flow control and congestion control. 173 [5] defines a mechanism called "Path MTU Discovery" (PMTUD), which 174 makes use of ICMP error messages of type 3 (Destination Unreachable), 175 code 4 (fragmentation needed and DF bit set) to allow hosts to 176 determine the MTU of an arbitrary internet path. 178 Appendix D of [6] provides information about which ICMP error 179 messages are produced by hosts, intermediate routers, or both. 181 2.1.2. ICMP for IP version 6 (ICMPv6) 183 [7] specifies the Internet Control Message Protocol (ICMPv6) to be 184 used with the Internet Protocol version 6 (IPv6) [8]. 186 ICMPv6 defines the "Packet Too Big" (type 2, code 0) error message, 187 that is analogous to the ICMP "fragmentation needed and DF bit set" 188 (type 3, code 4) error message. [9] defines the Path MTU Discovery 189 mechanism for IP Version 6, that makes use of these messages to 190 determined the MTU of an arbitrary internet path. 192 Appendix D of [6] provides information about which ICMPv6 error 193 messages are produced by hosts, intermediate routers, or both. 195 2.2. Handling of ICMP error messages 197 The Host Requirements RFC [4] states that a TCP MUST act on an ICMP 198 error message passed up from the IP layer, directing it to the 199 connection that elicited the error. 201 In order to allow ICMP messages to be demultiplexed by the receiving 202 host, part of the original packet that elicited the message is 203 included in the payload of the ICMP error message. Thus, the 204 receiving host can use that information to match the ICMP error to 205 the transport protocol instance that elicited it. 207 Neither the Host Requirements RFC [4] nor the original TCP 208 specification [2] recommend any validation checks on the received 209 ICMP messages. Thus, as long as the ICMP payload contains the 210 information that identifies an existing communication instance, it 211 will be processed by the corresponding transport-protocol instance, 212 and the corresponding action will be performed. 214 Therefore, in the case of TCP, an attacker could send a forged ICMP 215 message to the attacked host, and, as long as he is able to guess the 216 four-tuple that identifies the communication instance to be attacked, 217 he will be able to use ICMP to perform a variety of attacks. 219 As discussed in [15], there are a number of scenarios in which an 220 attacker may be able to know or guess the four-tuple that identifies 221 a TCP connection. If we assume the attacker knows the two systems 222 involved in the TCP connection to be attacked, both the client-side 223 and the server-side IP addresses will be known. Furthermore, as most 224 Internet services use the so-called "well-known" ports, only the 225 client port number would need to be guessed. This means that an 226 attacker would need to send, in principle, at most 65536 packets to 227 perform any of the attacks described in this document. However, most 228 systems choose the port numbers they use for outgoing connections 229 from a subset of the whole port number space. Thus, in practice, 230 fewer packets are needed to perform any of the attacks discussed in 231 this document. 233 It is clear that security checks should be performed on the received 234 ICMP error messages, to mitigate or eliminate the impact of the 235 attacks described in this document. 237 3. Constraints in the possible solutions 238 For ICMPv4, [1] states that the internet header plus the first 64 239 bits of the packet that elicited the ICMP message are to be included 240 in the payload of the ICMP error message. Thus, it is assumed that 241 all data needed to identify a transport protocol instance and process 242 the ICMP error message is contained in the first 64 bits of the 243 transport protocol header. [4] states that "the Internet header and 244 at least the first 8 data octets of the datagram that triggered the 245 error" are to be included in the payload of ICMP error messages, and 246 that "more than 8 octets MAY be sent", thus allowing implementations 247 to include more data from the original packet than those required by 248 the original ICMP specification. The Requirements for IP Version 4 249 Routers RFC [10] states that ICMP error messages "SHOULD contain as 250 much of the original datagram as possible without the length of the 251 ICMP datagram exceeding 576 bytes". 253 Thus, for ICMP messages generated by hosts, we can only expect to get 254 the entire IP header of the original packet, plus the first 64 bits 255 of its payload. For TCP, this means that the only fields that will 256 be included in the ICMP payload are: the source port number, the 257 destination port number, and the 32-bit TCP sequence number. This 258 clearly imposes a constraint on the possible validation checks that 259 can be performed, as there is not much information avalable on which 260 to perform them. 262 This means, for example, that even if TCP were signing its segments 263 by means of the TCP MD5 signature option [16], this mechanism could 264 not be used as a counter-measure against ICMP-based attacks, because, 265 as ICMP messages include only a piece of the TCP segment that 266 elicited the error, the MD5 [17] signature could not be recalculated. 267 In the same way, even if the attacked peer were authenticating its 268 packets at the IP layer [6], because only a part of the original IP 269 packet would be available, the signature used for authentication 270 could not be recalculated, and thus this mechanism could not be used 271 as a counter-measure aganist ICMP-based attacks against TCP. 273 For IPv6, the payload of ICMPv6 error messages includes as many 274 octets from the IPv6 packet that elicited the ICMPv6 error message as 275 will fit without making the resulting ICMPv6 packet exceed the 276 minimum IPv6 MTU (1280 octets) [7]. Thus, more information is 277 available than in the IPv4 case. 279 Hosts could require ICMP error messages to be authenticated [6], in 280 order to act upon them. However, while this requirement could make 281 sense for those ICMP error messages sent by hosts, it would not be 282 feasible for those ICMP error messages generated by routers, as this 283 would imply either that the attacked host should have a security 284 asociation [6] with every existing intermediate system, or that it 285 should be able to establish one dynamically. Current levels of 286 deployment of protocols for dynamic establishment of security 287 associations makes this unfeasible. Also, there may be some cases, 288 such as embedded devices, in which the processing power requirements 289 of authentication could not allow IPSec authentication to be 290 implemented effectively. 292 4. General counter-measures against ICMP attacks 294 There are a number of counter-measures that can be implemented to 295 eliminate or mitigate the impact of the attacks discussed in this 296 document. Rather than being alternative counter-measures, they can 297 be implemented together to increase the protection against these 298 attacks. In particular, all TCP implementations SHOULD perform the 299 TCP sequence number checking described in Section 4.1. 301 4.1. TCP sequence number checking 303 TCP SHOULD check that the TCP sequence number contained in the 304 payload of the ICMP error message is within the range SND.UNA =< 305 SEG.SEQ < SND.NXT. This means that the sequence number should be 306 within the range of the data already sent but not yet acknowledged. 307 If an ICMP error message does not pass this check, it SHOULD be 308 discarded. 310 Even if an attacker were able to guess the four-tuple that identifies 311 the TCP connection, this additional check would reduce the 312 possibility of considering a spoofed ICMP packet as valid to 313 Flight_Size/2^^32 (where Flight_Size is the number of data bytes 314 already sent to the remote peer, but not yet acknowledged [18]). For 315 connections in the SYN-SENT or SYN-RECEIVED states, this would reduce 316 the possibility of considering a spoofed ICMP packet as valid to 317 1/2^^32. For a TCP endpoint with no data "in flight", this would 318 completely eliminate the possibility of success of these attacks. 320 This counter-measure has been implemented in Linux [19] for many 321 years, in OpenBSD [20] since 2004, and in FreeBSD [21] and NetBSD 322 [22] since 2005. 324 It is important to note that while this check greatly increases the 325 number of packets required to perform any of the attacks discussed in 326 this document, this may not be enough in those scenarios in which 327 bandwidth is easily available, and/or large TCP windows [23] are 328 used. Therefore, implementation of the attack-specific counter- 329 measures discussed in this document is strongly RECOMMENDED. 331 4.2. Port randomization 333 As discussed in the previous sections, in order to perform any of the 334 attacks described in this document, an attacker would need to guess 335 (or know) the four-tuple that identifies the connection to be 336 attacked. Increasing the port number range used for outgoing TCP 337 connections, and randomizing the port number chosen for each outgoing 338 TCP conenctions would make it harder for an attacker to perform any 339 of the attacks discussed in this document. 341 [24] discusses a number of algorithms to randomize the ephemeral 342 ports used by clients. 344 4.3. Filtering ICMP error messages based on the ICMP payload 346 The source address of ICMP error messages does not need to be spoofed 347 to perform the attacks described in this document. Therefore, simple 348 filtering based on the source address of ICMP error messages does not 349 serve as a counter-measure against these attacks. However, a more 350 advanced packet filtering could be implemented in firewalls as a 351 counter-measure. Firewalls implementing such advanced filtering 352 would look at the payload of the ICMP error messages, and would 353 perform ingress and egress packet filtering based on the source IP 354 address of the IP header contained in the payload of the ICMP error 355 message. As the source IP address contained in the payload of the 356 ICMP error message does need to be spoofed to perform the attacks 357 described in this document, this kind of advanced filtering would 358 serve as a counter-measure against these attacks. 360 5. Blind connection-reset attack 362 5.1. Description 364 When TCP is handled an ICMP error message, it will perform its fault 365 recovery function, as follows: 367 o If the network problem being reported is a hard error, TCP will 368 abort the corresponding connection. 370 o If the network problem being reported is a soft error, TCP will 371 just record this information, and repeatedly retransmit its data 372 until they either get acknowledged, or the connection times out. 374 The Host Requirements RFC [4] states that a host SHOULD abort the 375 corresponding connection when receiving an ICMP error message that 376 indicates a "hard error", and states that ICMP error messages of type 377 3 (Destination Unreachable) codes 2 (protocol unreachable), 3 (port 378 unreachable), and 4 (fragmentation needed and DF bit set) should be 379 considered to indicate hard errors. While [7] did not exist when [4] 380 was published, one could extrapolate the concept of "hard errors" to 381 ICMPv6 error messages of type 1 (Destination unreachable) codes 1 382 (communication with destination administratively prohibited), and 4 383 (port unreachable). 385 Thus, an attacker could use ICMP to perform a blind connection-reset 386 attack. That is, even being off-path, an attacker could reset any 387 TCP connection taking place. In order to perform such an attack, an 388 attacker would send any ICMP error message that indicates a "hard 389 error", to either of the two TCP endpoints of the connection. 390 Because of TCP's fault recovery policy, the connection would be 391 immediately aborted. 393 As discussed in Section 2.2, all an attacker needs to know to perform 394 such an attack is the socket pair that identifies the TCP connection 395 to be attacked. In some scenarios, the IP addresses and port numbers 396 in use may be easily guessed or known to the attacker [15]. 398 Some stacks are known to extrapolate ICMP errors across TCP 399 connections, increasing the impact of this attack, as a single ICMP 400 packet could bring down all the TCP connections between the 401 corresponding peers. 403 It is important to note that even if TCP itself were protected 404 against the blind connection-reset attack described in [15] and [25], 405 by means authentication at the network layer [6], by means of the TCP 406 MD5 signature option [16], or by means of the mechanism proposed in 407 [25], the blind connection-reset attack described in this document 408 would still succeed. 410 5.2. Attack-specific counter-measures 412 5.2.1. Changing the reaction to hard errors 414 An analysis of the circumstances in which ICMP messages that indicate 415 hard errors may be received can shed some light to eliminate the 416 impact of ICMP-based blind connection-reset attacks. 418 ICMP type 3 (Destination Unreachable), code 2 (protocol unreachable) 420 This ICMP error message indicates that the host sending the ICMP 421 error message received a packet meant for a transport protocol it 422 does not support. For connection-oriented protocols such as TCP, 423 one could expect to receive such an error as the result of a 424 connection-establishment attempt. However, it would be strange to 425 get such an error during the life of a connection, as this would 426 indicate that support for that transport protocol has been removed 427 from the host sending the error message during the life of the 428 corresponding connection. Thus, it would be fair to treat ICMP 429 protocol unreachable error messages as soft errors (or completely 430 ignore them) if they are meant for connections that are in 431 synchronized states. For TCP, this means TCP should treat ICMP 432 protocol unreachable error messages as soft errors (or completely 433 ignore them) if they are meant for connections that are in the 434 ESTABLISHED, FIN-WAIT-1, FIN-WAIT-2, CLOSE-WAIT, CLOSING, LAST-ACK 435 or TIME-WAIT states. 437 ICMP type 3 (Destination Unreachable), code 3 (port unreachable) 439 This error message indicates that the host sending the ICMP error 440 message received a packet meant for a socket (IP address, port 441 number) on which there is no process listening. Those transport 442 protocols which have their own mechanisms for notifying this 443 condition should not be receiving these error messages. However, 444 the Host Requirements RFC [4] states that even those transport 445 protocols that have their own mechanism for notifying the sender 446 that a port is unreachable MUST nevertheless accept an ICMP Port 447 Unreachable for the same purpose. For security reasons, it would 448 be fair to treat ICMP port unreachable messages as soft errors (or 449 completely ignore them) when they are meant for protocols that 450 have their own mechanism for reporting this error condition. 452 ICMP type 3 (Destination Unreachable), code 4 (fragmentation needed 453 and DF bit set) 455 This error message indicates that an intermediate node needed to 456 fragment a datagram, but the DF (Don't Fragment) bit in the IP 457 header was set. Those systems that do not implement the PMTUD 458 mechanism should not be sending their IP packets with the DF bit 459 set, and thus should not be receiving these ICMP error messages. 460 Thus, it would be fair for them to treat this ICMP error message 461 as indicating a soft error, therefore not aborting the 462 corresponding connection when such an error message is received. 463 On the other hand, and for obvious reasons, those systems 464 implementing the Path-MTU Discovery (PMTUD) mechanism [5] should 465 not abort the corresponding connection when such an ICMP error 466 message is received. 468 ICMPv6 type 1 (Destination Unreachable), code 1 (communication with 469 destination administratively prohibited) 471 This error message indicates that the destination is unreachable 472 because of an administrative policy. For connection-oriented 473 protocols such as TCP, one could expect to receive such an error 474 as the result of a connection-establishment attempt. Receiving 475 such an error for a connection in any of the synchronized states 476 would mean that the administrative policy changed during the life 477 of the connection. Therefore, while it would be possible for a 478 firewall to be reconfigured during the life of a connection, it 479 would be fair, for security reasons, to ignore these messages for 480 connections that are in the ESTABLISHED, FIN-WAIT-1, FIN-WAIT-2, 481 CLOSE-WAIT, CLOSING, LAST-ACK or TIME-WAIT states. 483 ICMPv6 type 1 (Destination Unreachable), code 4 (port unreachable) 485 This error message is analogous to the ICMP type 3 (Destination 486 Unreachable), code 3 (Port unreachable) error message discussed 487 above. Therefore, the same considerations apply. 489 Therefore, TCP SHOULD treat all of the above messages as indicating 490 "soft errors", rather than "hard errors", and thus SHOULD NOT abort 491 the corresponding connection upon receipt of them. This is policy is 492 based on the premise that TCP should be as robust as possible. Also, 493 as discussed in Section 5.1, hosts SHOULD NOT extrapolate ICMP errors 494 across TCP connections. 496 In case the received message were legitimate, it would mean that the 497 "hard error" condition appeared during the life of the connection. 498 However, there is no reason to think that in the same way this error 499 condition appeared, it won't get solved in the near term. Therefore, 500 treating the received ICMP error messages as "soft errors" would make 501 TCP more robust, and could avoid TCP from aborting a TCP connection 502 unnecesarily. 504 One scenario in which a host would benefit from treating the so- 505 called ICMP "hard errors" as "soft errors" would be that in which the 506 packets that correspond to a given TCP connection are routed along 507 multiple different paths. Some (but not all) of these paths may be 508 experiencing an error condition, and therefore generating the so- 509 called ICMP hard errors. However, communication should survive if 510 there is still a working path to the destination host [26]. Thus, 511 treating the so-called "hard errors" as "soft errors" when a 512 connection is in any of the synchronized states would make TCP 513 achieve this goal. 515 It is interesting to note that, as ICMP error messages are 516 unreliable, transport protocols should not depend on them for correct 517 functioning. In the event one of these messages were legitimate, the 518 corresponding connection should eventually time out. 520 This counter-measure has been implemented in BSD-derived TCP/IP 521 implementations (e.g., [21], [22], and [20]) for more than ten years 523 [27][28]. The Linux kernel has implemented this policy for more than 524 ten years, too [19]. 526 5.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 would 530 abort a connection only after an ICMP error message indicating a hard 531 error has been received, and the corresponding data have already been 532 retransmitted more than some specified number of times. 534 The rationale behind this proposed fix is that if a host can make 535 forward progress on a connection, it can completely disregard the 536 "hard errors" being indicated by the received ICMP error messages. 538 While this counter-measure could be useful, we think that the 539 counter-measure discussed in Section 5.2.1 is easier to implement, 540 and provides increased protection against this type of attack. 542 6. Blind throughput-reduction attack 544 6.1. Description 546 The Host requirements RFC [4] states that hosts MUST react to ICMP 547 Source Quench messages by slowing transmission on the connection. 548 Thus, an attacker could send ICMP Source Quench (type 4, code 0) 549 messages to a TCP endpoint to make it reduce the rate at which it 550 sends data to the other end-point of the connection. [4] further adds 551 that the RECOMMENDED procedure is to put the corresponding connection 552 in the slow-start phase of TCP's congestion control algorithm [18]. 553 In the case of those implementations that use an initial congestion 554 window of one segment, a sustained attack would reduce the throughput 555 of the attacked connection to about SMSS (Sender Maximum Segment 556 Size) [18] bytes per RTT (round-trip time). The throughput achieved 557 during attack might be a little higher if a larger initial congestion 558 window is in use [29]. 560 6.2. Attack-specific counter-measures 562 The Host Requirements RFC [4] states that hosts MUST react to ICMP 563 Source Quench messages by slowing transmission on the connection. 564 However, as discussed in the Requirements for IP Version 4 Routers 565 RFC [10], research seems to suggest ICMP Source Quench is an 566 ineffective (and unfair) antidote for congestion. [10] further states 567 that routers SHOULD NOT send ICMP Source Quench messages in response 568 to congestion. On the other hand, TCP implements its own congestion 569 control mechanisms [18] [30]. Thus, hosts SHOULD completely ignore 570 ICMP Source Quench messages meant for TCP connections. 572 This behavior has been implemented in Linux [19] since 2004, and in 573 FreeBSD [21], NetBSD [22], and OpenBSD [20] since 2005. 575 7. Blind performance-degrading attack 577 7.1. Description 579 When one IP host has a large amount of data to send to another host, 580 the data will be transmitted as a series of IP datagrams. It is 581 usually preferable that these datagrams be of the largest size that 582 does not require fragmentation anywhere along the path from the 583 source to the destination. This datagram size is referred to as the 584 Path MTU (PMTU), and is equal to the minimum of the MTUs of each hop 585 in the path [5]. 587 A technique called "Path MTU Discovery" (PMTUD) mechanism lets IP 588 hosts determine the Path MTU of an arbitrary internet path. [5] and 589 [9] specify the PMTUD mechanism for IPv4 and IPv6, respectively. 591 The PMTUD mechanism for IPv4 uses the Don't Fragment (DF) bit in the 592 IP header to dynamically discover the Path MTU. The basic idea 593 behind the PMTUD mechanism is that a source host assumes that the MTU 594 of the path is that of the first hop, and sends all its datagrams 595 with the DF bit set. If any of the datagrams is too large to be 596 forwarded without fragmentation by some intermediate router, the 597 router will discard the corresponding datagram, and will return an 598 ICMP "Destination Unreachable" (type 3) "fragmentation neeed and DF 599 set" (code 4) error message to sending host. This message will 600 report the MTU of the constricting hop, so that the sending host 601 reduces the assumed Path-MTU accordingly. 603 For IPv6, intermediate systems do not fragment packets. Thus, 604 there's an "implicit" DF bit set in every packet sent on a network. 605 If any of the datagrams is too large to be forwarded without 606 fragmentation by some intermediate router, the router will discard 607 the corresponding datagram, and will return an ICMPv6 "Packet Too 608 Big" (type 2, code 0) error message to sending host. This message 609 will report the MTU of the constricting hop, so that the sending host 610 can reduce the assumed Path-MTU accordingly. 612 As discussed in both [5] and [9], the Path-MTU Discovery mechanism 613 can be used to attack TCP. An attacker could send a forged ICMP 614 "Destination Unreachable, fragmentation needed and DF set" packet (or 615 their IPv6 counterpart) to the sending host, making it advertise a 616 low Next-Hop MTU. As a result, the attacked system would reduce the 617 size of the packets it sends for the corresponding connection 618 accordingly. 620 The effect of this attack is two-fold. On one hand, it will increase 621 the headers/data ratio, thus increasing the overhead needed to send 622 data to the remote TCP end-point. On the other hand, if the attacked 623 system wanted to keep the same throughput it was achieving before 624 being attacked, it would have to increase the packet rate. On 625 virtually all systems this will lead to an increase in the IRQ 626 (Interrrupt ReQuest) rate, thus increasing processor utilization, and 627 degrading the overall system performance. 629 For IPv4, the reported Next-Hop MTU could be as low as 68 octets, as 630 [11] requires every internet module to be able to forward a datagram 631 of 68 octets without further fragmentation. For IPv6, the reported 632 Next-Hop MTU could be as low as 1280 octets (the minimum IPv6 MTU) 633 [8]. 635 7.2. Attack-specific counter-measures 637 Henceforth, we will refer to both ICMP "fragmentation needed and DF 638 bit set" and ICMPv6 "Packet Too Big" messages as "ICMP Packet Too 639 Big" messages. 641 In addition to the general validation check described in Section 4.1, 642 a counter-measure similar to that described in Section 5.2.2 could be 643 implemented to greatly minimize the impact of this attack. 645 This would mean that upon receipt of an ICMP "Packet Too Big" error 646 message, TCP would just record this information, and would honor it 647 only when the corresponding data had already been retransmitted a 648 specified number of times. 650 While this policy would greatly mitigate the impact of the attack 651 against the PMTUD mechanism, it would also mean that it might take 652 TCP more time to discover the Path-MTU for a TCP connection. This 653 would be particularly annoying for connections that have just been 654 established, as it might take TCP several transmission attempts (and 655 the corresponding timeouts) before it discovers the PMTU for the 656 corresponding connection. Thus, this policy would increase the time 657 it takes for data to begin to be received at the destination host. 659 We would like to protect TCP from the attack against the PMTUD 660 mechanism, while still allowing TCP to quickly determine the initial 661 Path-MTU for a connection. 663 To achieve both goals, we can divide the traditional PMTUD mechanism 664 into two stages: Initial Path-MTU Discovery, and Path-MTU Update. 666 The Initial Path-MTU Discovery stage is when TCP tries to send 667 segments that are larger than the ones that have so far been sent and 668 acknowledged for this connection. That is, in the Initial Path-MTU 669 Discovery stage TCP has no record of these large segments getting to 670 the destination host, and thus it would be fair to believe the 671 network when it reports that these packets are too large to reach the 672 destination host without being fragmented. 674 The Path-MTU Update stage is when TCP tries to send segments that are 675 equal to or smaller than the ones that have already been sent and 676 acknowledged for this connection. During the Path-MTU Update stage, 677 TCP already has knowledge of the estimated Path-MTU for the given 678 connection. Thus, it would be fair to be more cautious with the 679 errors being reported by the network. 681 In order to allow TCP to distinguish segments between those 682 performing Initial Path-MTU Discovery and those performing Path-MTU 683 Update, two new variables should be introduced to TCP: maxsizeacked 684 and maxsizesent. 686 maxsizesent would hold the size (in octets) of the largest packet 687 that has so far been sent for this connection. It would be 688 initialized to 68 (the minimum IPv4 MTU) when the underlying internet 689 protocol is IPv4, and would be initialized to 1280 (the minimum IPv6 690 MTU) when the underlying internet protocol is IPv6. Whenever a 691 packet larger than maxsizesent octets is sent, maxsizesent should be 692 set to that value. 694 On the other hand, maxsizeacked would hold the size (in octets) of 695 the largest packet that has so far been acknowledged for this 696 connection. It would be initialized to 68 (the minimum IPv4 MTU) 697 when the underlying internet protocol is IPv4, and would be 698 initialized to 1280 (the minimum IPv6 MTU) when the underlying 699 internet protocol is IPv6. Whenever an acknowledgement for a packet 700 larger than maxsizeacked octets is received, maxsizeacked should be 701 set to the size of that acknowledged packet. 703 Upon receipt of an ICMP "Packet Too Big" error message, the Next-Hop 704 MTU claimed by the ICMP message (henceforth "claimedmtu") should be 705 compared with maxsizesent. If claimedmtu is equal to or larger than 706 maxsizesent, then the ICMP error message should be silently 707 discarded. The rationale for this is that the ICMP error message 708 cannot be legitimate if it claims to have been elicited by a packet 709 larger than the largest packet we have so far sent for this 710 connection. 712 If this check is passed, claimedmtu should be compared with 713 maxsizeacked. If claimedmtu is equal to or larger than maxsizeacked, 714 TCP is supposed to be at the Initial Path-MTU Discovery stage, and 715 thus the ICMP "Packet Too Big" error message should be honored 716 immediately. That is, the assumed Path-MTU should be updated 717 according to the Next-Hop MTU claimed in the ICMP error message. 718 Also, maxsizesent should be reset to the minimum MTU of the internet 719 protocol in use (68 for IPv4, and 1280 for IPv6). 721 On the other hand, if claimedmtu is smaller than maxsizeacked, TCP is 722 supposed to be in the Path-MTU Update stage. At this stage, we 723 should be more cautious with the errors being reported by the 724 network, and should therefore just record the received error message, 725 and delay the update of the assumed Path-MTU. 727 To perform this delay, one new variable and one new parameter should 728 be introduced to TCP: nsegrto and MAXSEGRTO. nsegrto will hold the 729 number of times a specified segment has timed out. It should be 730 initialized to zero, and should be incremented by one everytime the 731 corresponding segment times out. MAXSEGRRTO should specify the 732 number of times a given segment must timeout before an ICMP "Packet 733 Too Big" error message can be honored, and can be set, in principle, 734 to any value greater than or equal to 0. 736 Thus, if nsegrto is greater than or equal to MAXSEGRTO, and there's a 737 pending ICMP "Packet Too Big" error message, the correspoing error 738 message should be processed. At that point, maxsizeacked should be 739 set to claimedmtu, and maxsizesent should be set to 68 (for IPv4) or 740 1280 (for IPv6). 742 If while there is a pending ICMP "Packet Too Big" error message the 743 TCP SEQ claimed by the pending message is acknowledged (i.e., an ACK 744 that acknowledges that sequence number is received), then the 745 "pending error" condition should be cleared. 747 The rationale behind performing this delayed processing of ICMP 748 "Packet Too Big" messages is that if there is progress on the 749 connection, the ICMP "Packet Too Big" errors must be a false claim. 751 MAXSEGRTO can be set, in principle, to any value greater than or 752 equal to 0. Setting MAXSEGRTO to 0 would make TCP perform the 753 traditional PMTUD mechanism defined in [5] and [9]. A MAXSEGRTO of 1 754 should provide enough protection for most cases. In any case, 755 implementations are free to choose higher values for this constant. 756 MAXSEGRTO could be a function of the Next-Hop MTU claimed in the 757 received ICMP "Packet Too Big" message. That is, higher values for 758 MAXSEGRTO could be imposed when the received ICMP "Packet Too Big" 759 message claims a Next-Hop MTU that is smaller than some specified 760 value. 762 In the event a higher level of protection is desired at the expense 763 of a higher delay in the discovery of the Path-MTU, an implementation 764 could consider TCP to always be in the Path-MTU Update stage, thus 765 always delaying the update of the assumed Path-MTU. 767 Appendix B shows the proposed counter-measure in pseudo-code. 768 Appendix A shows the proposed counter-measure in action. 770 This behavior has been implemented in NetBSD [22] and OpenBSD [20] 771 since 2005. 773 It is important to note that the mechanism proposed in this section 774 is an improvement to the current Path-MTU discovery mechanism, to 775 mitigate its security implications. The current PMTUD mechanism, as 776 specified by [5] and [9], still suffers from some functionality 777 problems [31] that this document does not aim to address. Thus, it 778 does not aleviate the need for other improvements to the current 779 PMTUD mechanism or the introduction of an alternative PMTUD that 780 replaces the current one, to solve the remaining issues. 782 A mechanism that aims to address those remaining issues is described 783 in [32]. 785 8. Security Considerations 787 This document describes the use of ICMP error messages to perform a 788 number of attacks against the TCP protocol, and proposes a number of 789 counter-measures that either eliminate or reduce the impact of these 790 attacks. 792 9. Acknowledgements 794 This document was inspired by Mika Liljeberg, while discussing some 795 issues related to [33] by private e-mail. The author would like to 796 thank James Carlson, Alan Cox, Theo de Raadt, Ted Faber, Juan 797 Fraschini, Markus Friedl, Guillermo Gont, Vivek Kakkar, Michael 798 Kerrisk, Mika Liljeberg, David Miller, Miles Nordin, Eloy Paris, 799 Kacheong Poon, Andrew Powell, Pekka Savola, and Joe Touch, for 800 contributing many valuable comments. 802 Markus Friedl, Chad Loder, and the author of this document, produced 803 and tested in OpenBSD [20] the first implementation of the counter- 804 measure described in Section 7.2. This first implementation helped 805 to test the effectiveness of the ideas introduced in this document, 806 and has served as a reference implementation for other operating 807 systems. 809 The author would like to thank the UK's National Infrastructure 810 Security Co-ordination Centre (NISCC) for coordinating the disclosure 811 of these issues with a large number of vendors and CSIRTs (Computer 812 Security Incident Response Teams). 814 The author wishes to express deep and heartfelt gratitude to Jorge 815 Oscar Gont and Nelida Garcia, for their precious motivation and 816 guidance. 818 10. References 820 10.1. Normative References 822 [1] Postel, J., "Internet Control Message Protocol", STD 5, 823 RFC 792, September 1981. 825 [2] Postel, J., "Transmission Control Protocol", STD 7, RFC 793, 826 September 1981. 828 [3] Bradner, S., "Key words for use in RFCs to Indicate Requirement 829 Levels", BCP 14, RFC 2119, March 1997. 831 [4] Braden, R., "Requirements for Internet Hosts - Communication 832 Layers", STD 3, RFC 1122, October 1989. 834 [5] Mogul, J. and S. Deering, "Path MTU discovery", RFC 1191, 835 November 1990. 837 [6] Kent, S. and R. Atkinson, "Security Architecture for the 838 Internet Protocol", RFC 2401, November 1998. 840 [7] Conta, A. and S. Deering, "Internet Control Message Protocol 841 (ICMPv6) for the Internet Protocol Version 6 (IPv6) 842 Specification", RFC 2463, December 1998. 844 [8] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) 845 Specification", RFC 2460, December 1998. 847 [9] McCann, J., Deering, S., and J. Mogul, "Path MTU Discovery for 848 IP version 6", RFC 1981, August 1996. 850 [10] Baker, F., "Requirements for IP Version 4 Routers", RFC 1812, 851 June 1995. 853 [11] Postel, J., "Internet Protocol", STD 5, RFC 791, 854 September 1981. 856 10.2. Informative References 858 [12] NISCC, "NISCC Vulnerability Advisory 532967/NISCC/ICMP: 859 Vulnerability Issues in ICMP packets with TCP payloads", http: 860 //www.niscc.gov.uk/niscc/docs/al-20050412-00308.html?lang=en, 861 2005. 863 [13] US-CERT, "US-CERT Vulnerability Note VU#222750: TCP/IP 864 Implementations do not adequately validate ICMP error 865 messages", http://www.kb.cert.org/vuls/id/222750, 2005. 867 [14] Clark, D., "Fault isolation and recovery", RFC 816, July 1982. 869 [15] Watson, P., "Slipping in the Window: TCP Reset Attacks", 2004 870 CanSecWest Conference , 2004. 872 [16] Heffernan, A., "Protection of BGP Sessions via the TCP MD5 873 Signature Option", RFC 2385, August 1998. 875 [17] Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321, 876 April 1992. 878 [18] Allman, M., Paxson, V., and W. Stevens, "TCP Congestion 879 Control", RFC 2581, April 1999. 881 [19] The Linux Project, "http://www.kernel.org". 883 [20] The OpenBSD Project, "http://www.openbsd.org". 885 [21] The FreeBSD Project, "http://www.freebsd.org". 887 [22] The NetBSD Project, "http://www.netbsd.org". 889 [23] Jacobson, V., Braden, B., and D. Borman, "TCP Extensions for 890 High Performance", RFC 1323, May 1992. 892 [24] Larsen, M., "Port Randomisation", 893 draft-larsen-tsvwg-port-randomisation-00 (work in progress), 894 October 2004. 896 [25] Dalal, M., "Improving TCP's Robustness to Blind In-Window 897 Attacks", draft-ietf-tcpm-tcpsecure-03 (work in progress), 898 May 2005. 900 [26] Clark, D., "The Design Philosophy of the DARPA Internet 901 Protocols", Computer Communication Review Vol. 18, No. 4, 1988. 903 [27] Wright, G. and W. Stevens, "TCP/IP Illustrated, Volume 2: The 904 Implementation", Addison-Wesley , 1994. 906 [28] McKusick, M., Bostic, K., Karels, M., and J. Quarterman, "The 907 Design and Implementation of the 4.4BSD Operating System", 908 Addison-Wesley , 1996. 910 [29] Allman, M., Floyd, S., and C. Partridge, "Increasing TCP's 911 Initial Window", RFC 3390, October 2002. 913 [30] Ramakrishnan, K., Floyd, S., and D. Black, "The Addition of 914 Explicit Congestion Notification (ECN) to IP", RFC 3168, 915 September 2001. 917 [31] Lahey, K., "TCP Problems with Path MTU Discovery", RFC 2923, 918 September 2000. 920 [32] Mathis, M., "Path MTU Discovery", draft-ietf-pmtud-method-04 921 (work in progress), February 2005. 923 [33] Gont, F., "TCP's Reaction to Soft Errors", 924 draft-gont-tcpm-tcp-soft-errors-01 (work in progress), 925 October 2004. 927 [34] Klensin, J., "Simple Mail Transfer Protocol", RFC 2821, 928 April 2001. 930 [35] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., Masinter, L., 931 Leach, P., and T. Berners-Lee, "Hypertext Transfer Protocol -- 932 HTTP/1.1", RFC 2616, June 1999. 934 Appendix A. The counter-measure for the PMTUD attack in action 936 This appendix shows the proposed counter-measure for the ICMP attack 937 against the PMTUD mechanism in action. It shows both how the fix 938 protects TCP from being attacked and how the counter-measure works in 939 normal scenarios. As discussed in Section 7.2, this Appendix assumes 940 the PMTUD-specific counter-measure is implemented in addition to the 941 TCP sequence number checking described in Section 4.1. 943 Figure 1 illustrates an hypothetical scenario in which two hosts are 944 connected by means of three intermediate routers. It also shows the 945 MTU of each hypothetical hop. All the following subsections assume 946 the network setup of this figure. 948 Also, for simplicity sake, all subsections assume an IP header of 20 949 octets and a TCP header of 20 octets. Thus, for example, when the 950 PMTU is assumed to be 1500 octets, TCP will send segments that 951 contain, at most, 1460 octets of data. 953 For simplicity sake, all the following subsections assume the TCP 954 implementation at Host 1 has chosen a a MAXSEGRTO of 1. 956 +----+ +----+ +----+ +----+ +----+ 957 | H1 |--------| R1 |--------| R2 |--------| R3 |--------| H2 | 958 +----+ +----+ +----+ +----+ +----+ 959 MTU=4464 MTU=2048 MTU=1500 MTU=4464 961 Figure 1: Hypothetical scenario 963 A.1. Normal operation for bulk transfers 965 This subsection shows the proposed counter-measure in normal 966 operation, when a TCP connection is used for bulk transfers. That 967 is, it shows how the proposed counter-measure works when there is no 968 attack taking place, and a TCP connection is used for transferring 969 large amounts of data. This section assumes that just after the 970 connection is established, one of the TCP endpoints begins to 971 transfer data in packets that are as large as possible. 973 Host 1 Host 2 975 1. --> --> 976 2. <-- <-- 977 3. --> --> 978 4. --> --> 979 5. <--- ICMP "Packet Too Big" MTU=2048, TCPseq#=101 <--- R1 980 6. --> --> 981 7. <--- ICMP "Packet Too Big" MTU=1500, TCPseq#=101 <--- R2 982 8. --> --> 983 9. <-- <-- 985 Figure 2: Normal operation for bulk transfers 987 nsegrto is initialized to zero. Both maxsizeacked and maxsizesent 988 are initialized to the minimum MTU for the internet protocol being 989 used (68 for IPv4, and 1280 for IPv6). 991 In lines 1 to 3 the three-way handshake takes place, and the 992 connection is established. In line 4, H1 tries to send a full-sized 993 TCP segment. As described by [5] and [9], in this case TCP will try 994 to send a segment with 4424 bytes of data, which will result in an IP 995 packet of 4464 octets. Therefore, maxsizesent is set to 4464. When 996 the packet reaches R1, it elicits an ICMP "Packet Too Big" error 997 message. 999 In line 5, H1 receives the ICMP error message, which reports a Next- 1000 Hop MTU of 2048 octets. After performing the TCP sequence number 1001 check described in Section 4.1, the Next-Hop MTU reported by the ICMP 1002 error message (claimedmtu) is compared with maxsizesent. As it is 1003 smaller than maxsizesent, it passes the check, and thus is then 1004 compared with maxsizeacked. As claimedmtu is larger than 1005 maxsizeacked, TCP assumes that the corresponding TCP segment was 1006 performing the Initial PMTU Discovery. Therefore, the TCP at H1 1007 honors the ICMP message by updating the assumed Path-MTU. maxsizesent 1008 is reset to the minimum MTU of the internet protocol in use (68 for 1009 IPv4, and 1280 for IPv6). 1011 In line 6, the TCP at H1 sends a segment with 2008 bytes of data, 1012 which results in an IP packet of 2048 octets. maxsizesent is thus set 1013 to 2008 bytes. When the packet reaches R2, it elicits an ICMP 1014 "Packet Too Big" error message. 1016 In line 7, H1 receives the ICMP error message, which reports a Next- 1017 Hop MTU of 1500 octets. After performing the TCP sequence number 1018 check, the Next-Hop MTU reported by the ICMP error message 1019 (claimedmtu) is compared with maxsizesent. As it is smaller than 1020 maxsizesent, it passes the check, and thus is then compared with 1021 maxsizeacked. As claimedmtu is larger than maxsizeacked, TCP assumes 1022 that the corresponding TCP segment was performing the Initial PMTU 1023 Discovery. Therefore, the TCP at H1 honors the ICMP message by 1024 updating the assumed Path-MTU. maxsizesent is reset to the minimum 1025 MTU of the internet protocol in use. 1027 In line 8, the TCP at H1 sends a segment with 1460 bytes of data, 1028 which results in an IP packet of 1500 octets. maxsizesent is thus set 1029 to 1500. This packet reaches H2, where it elicits an acknowledgement 1030 (ACK) segment. 1032 In line 9, H1 finally gets the acknowledgement for the data segment. 1033 As the corresponding packet was larger than maxsizeacked, TCP updates 1034 maxsizeacked, setting it to 1500. At this point TCP has discovered 1035 the Path-MTU for this TCP connection. 1037 A.2. Operation during Path-MTU changes 1039 Let us suppose a TCP connection between H1 and H2 has already been 1040 established, and that the PMTU for the connection has already been 1041 discovered to be 1500. At this point, both maxsizesent and 1042 maxsizeacked are equal to 1500, and nsegrto is equal to 0. Suppose 1043 some time later the PMTU decreases to 1492. For simplicity, let us 1044 suppose that the Path-MTU has decreased because the MTU of the link 1045 between R2 and R3 has decreased from 1500 to 1492. Figure 3 1046 illustrates how the proposed counter-measure would work in this 1047 scenario. 1049 Host 1 Host 2 1051 1. (Path-MTU decreases) 1052 2. --> --> 1053 3. <--- ICMP "Packet Too Big" MTU=1492, TCPseq#=100 <--- R2 1054 4. (Segment times out) 1055 5. --> --> 1056 6. <-- <-- 1058 Figure 3: Operation during Path-MTU changes 1060 In line 1, the Path-MTU for this connection decreases from 1500 to 1061 1492. In line 2, the TCP at H1, without being aware of the Path-MTU 1062 change, sends a 1500-byte packet to H2. When the packet reaches R2, 1063 it elicits an ICMP "Packet Too Big" error message. 1065 In line 3, H1 receives the ICMP error message, which reports a Next- 1066 Hop MTU of 1492 octets. After performing the TCP sequence number 1067 check, the Next-Hop MTU reported by the ICMP error message 1068 (claimedmtu) is compared with maxsizesent. As claimedmtu is smaller 1069 than maxsizesent, it is then compared with maxsizeacked. As 1070 claimedmtu is smaller than maxsizeacked (full-sized packets were 1071 getting to the remote end-point), this packet is assumed to be 1072 performing Path-MTU Update. And a "pending error" condition is 1073 recorded. 1075 In line 4, the segment times out. Thus, nsegrto is incremented by 1. 1076 As nsegrto is greater than or equal to MAXSEGRTO, the assumed Path- 1077 MTU is updated. nsegrto is reset to 0, and maxsizeacked is set to 1078 claimedmtu, and maxsizesent is set to the minimum MTU of the internet 1079 protocol in use. 1081 In line 5, H1 retransmits the data using the updated PMTU, and thus 1082 maxsizesent is set to 1492. The resulting packet reaches H2, where 1083 it elicits an acknowledgement (ACK) segment. 1085 In line 6, H1 finally gets the acknowledgement for the data segment. 1086 At this point TCP has discovered the new Path-MTU for this TCP 1087 connection. 1089 A.3. Idle connection being attacked 1091 Let us suppose a TCP connection between H1 and H2 has already been 1092 established, and the PMTU for the connection has already been 1093 discovered to be 1500. Figure 4 shows a sample time-line diagram 1094 that illustrates an idle connection being attacked. 1096 Host 1 Host 2 1098 1. --> --> 1099 2. <-- <-- 1100 3. <--- ICMP "Packet Too Big" MTU=68, TCPseq#=100 <--- 1101 4. <--- ICMP "Packet Too Big" MTU=68, TCPseq#=100 <--- 1102 5. <--- ICMP "Packet Too Big" MTU=68, TCPseq#=100 <--- 1104 Figure 4: Idle connection being attacked 1106 In line 1, H1 sends its last bunch of data. At line 2, H2 1107 acknowledges the receipt of these data. Then the connection becomes 1108 idle. In lines 3, 4, and 5, an attacker sends forged ICMP "Packet 1109 Too Big" error messages to H1. Regardless of how many packets it 1110 sends and the TCP sequence number each ICMP packet includes, none of 1111 these ICMP error messages will pass the TCP sequence number check 1112 described in Section 4.1, as H1 has no unacknowledged data in flight 1113 to H2. Therefore, the attack does not succeed. 1115 A.4. Active connection being attacked after discovery of the Path-MTU 1117 Let us suppose an attacker attacks a TCP connection for which the 1118 PMTU has already been discovered. In this case, as illustrated in 1119 Figure 1, the PMTU would be found to be 1500 bytes. Figure 5 shows a 1120 possible packet exchange. 1122 Host 1 Host 2 1124 1. --> --> 1125 2. --> --> 1126 3. --> --> 1127 4. --> --> 1128 5. <--- ICMP "Packet Too Big" MTU=68, TCPseq#=100 <--- 1129 6. <-- <-- 1131 Figure 5: Active connection being attacked after discovery of PMTU 1133 As we assume the PMTU has already been discovered, we also assume 1134 both maxsizesent and maxsizeacked are equal to 1500. We assume 1135 nsegrto is equal to zero, as there have been no segment timeouts. 1137 In lines 1, 2, 3, and 4, H1 sends four data segments to H2. In line 1138 5, an attacker sends a forged ICMP packet to H1. We assume the 1139 attacker is lucky enough to guess both the four-tuple that identifies 1140 the connection and a valid TCP sequence number. As the Next-Hop MTU 1141 claimed in the ICMP "Packet Too Big" message (claimedmtu) is smaller 1142 than maxsizeacked, this packet is assumed to be performing Path-MTU 1143 Update. Thus, the error message is recorded. 1145 In line 6, H1 receives an acknowledgement for the segment sent in 1146 line 1, before it times out. At this point, the "pending error" 1147 condition is cleared, and the recorded ICMP "Packet Too Big" error 1148 message is ignored. Therefore, the attack does not succeed. 1150 A.5. TCP peer attacked when sending small packets just after the three- 1151 way handshake 1153 This section analyzes an scenario in which a TCP peer that is sending 1154 small segments just after the connection has been established, is 1155 attacked. The connection could be being used by protocols such as 1156 SMTP [34] and HTTP [35], for example, which usually behave like this. 1158 Figure 6 shows a possible packet exchange for such scenario. 1160 Host 1 Host 2 1162 1. --> --> 1163 2. <-- <-- 1164 3. --> --> 1165 4. --> --> 1166 5. <-- <-- 1167 6. --> --> 1168 7. --> --> 1169 8. <--- ICMP "Packet Too Big" MTU=150, TCPseq#=101 <--- 1171 Figure 6: TCP peer attacked when sending small packets just after the 1172 three-way handshake 1174 nsegrto is initialized to zero. Both maxsizesent and maxsizeacked 1175 are initialized to the minimum MTU for the internet protocol being 1176 used (68 for IPv4, and 1280 for IPv6). 1178 In lines 1 to 3 the three-way handshake takes place, and the 1179 connection is established. At this point, the assumed Path-MTU for 1180 this connection is 4464. In line 4, H1 sends a small segment (which 1181 results in a 140-byte packet) to H2. maxsizesent is thus set to 140. 1182 In line 5 this segment is acknowledged, and thus maxsizeacked is set 1183 to 140. 1185 In lines 6 and 7, H1 sends two small segments to H2. In line 8, 1186 while the segments from lines 6 and 7 are still in flight to H2, an 1187 attacker sends a forged ICMP "Packet Too Big" error message to H1. 1188 Assuming the attacker is lucky enough to guess a valid TCP sequence 1189 number, this ICMP message will pass the TCP sequence number check. 1190 The Next-Hop MTU reported by the ICMP error message (claimedmtu) is 1191 then compared with maxsizesent. As claimedmtu is larger than 1192 maxsizesent, the ICMP error message is silently discarded. 1193 Therefore, the attack does not succeed. 1195 Appendix B. Pseudo-code for the counter-measure for the blind 1196 performance-degrading attack 1198 This section contains a pseudo-code version of the counter-measure 1199 described in Section 7.2 for the blind performance-degrading attack 1200 described in Section 7. It is meant as guidance for developers on 1201 how to implement this counter-measure. 1203 The pseudo-code makes use of the following variables, constants, and 1204 functions: 1206 ack 1207 Variable holding the acknowledgement number contained in the TCP 1208 segment that has just been received. 1210 acked_packet_size 1211 Variable holding the packet size (data, plus headers) the ACK that 1212 has just been received is acknowledging. 1214 adjust_mtu() 1215 Function that adjusts the MTU for this connection, according to 1216 the ICMP "Packet Too Big" that was last received. 1218 claimedmtu 1219 Variable holding the Next-Hop MTU advertised by the ICMP "Packet 1220 Too Big" error message. 1222 claimedtcpseq 1223 Variable holding the TCP sequence number contained in the payload 1224 of the ICMP "Packet Too Big" message that has just been received 1225 or was last recorded. 1227 current_mtu 1228 Variable holding the assumed Path-MTU for this connection. 1230 drop_message() 1231 Function that performs the necessary actions to drop the ICMP 1232 message being processed. 1234 initial_mtu 1235 Variable holding the MTU for new connections, as explained in [5] 1236 and [9]. 1238 maxsizeacked 1239 Variable holding the largest packet size (data, plus headers) that 1240 has so for been acked for this connection, as explained in 1241 Section 7.2 1243 maxsizesent 1244 Variable holding the largest packet size (data, plus headers) that 1245 has so for been sent for this connection, as explained in 1246 Section 7.2 1248 nsegrto 1249 Variable holding the number of times this segment has timed out, 1250 as explained in Section 7.2 1252 packet_size 1253 Variable holding the size of the IP datagram being sent 1255 pending_message 1256 Variable (flag) that indicates whether there is a pending ICMP 1257 "Packet Too Big" message to be processed. 1259 save_message() 1260 Function that records the ICMP "Packet Too Big" message that has 1261 just been received. 1263 MINIMUM_MTU 1264 Constant holding the minimum MTU for the internet protocol in use 1265 (68 for IPv4, ad 1280 for IPv6. 1267 MAXSEGRTO 1268 Constant holding the number of times a given segment must timeout 1269 before an ICMP "Packet Too Big" error message can be honored. 1271 EVENT: New TCP connection 1273 current_mtu = initial_mtu; 1274 maxsizesent = MINIMUM_MTU; 1275 maxsizeacked = MINIMUM_MTU; 1276 nsegrto = 0; 1277 pending_message = 0; 1279 EVENT: Segment is sent 1280 if (packet_size > maxsizesent) 1281 maxsizesent = packet_size; 1283 EVENT: Segment is received 1285 if (acked_packet_size > maxsizeacked) 1286 maxsizeacked = acked_packet_size; 1288 if (pending_mesage) 1289 if (ack > claimedtcpseq){ 1290 pending_message = 0; 1291 nsegrto = 0; 1292 } 1294 EVENT: ICMP "Packet Too Big" message is received 1295 if (claimedtcpseq < SND.UNA || claimed_TCP_SEQ >= SND.NXT){ 1296 drop_message(); 1297 } 1299 else { 1300 if (claimedmtu >= maxsizesent || claimedmtu >= current_mtu) 1301 drop_message(); 1303 else { 1304 if (claimedmtu > maxsizeacked){ 1305 adjust_mtu(); 1306 current_mtu = claimedmtu; 1307 maxsizesent = MINIMUM_MTU; 1308 } 1310 else { 1311 pending_message = 1; 1312 save_message(); 1313 } 1314 } 1315 } 1317 EVENT: Segment times out 1319 nsegrto++; 1321 if (pending_message && nsegrto >= MAXSEGRTO){ 1322 adjust_mtu(); 1323 nsegrto = 0; 1324 pending_message = 0; 1325 maxsizeacked = claimedmtu; 1326 maxsizesent = MINIMUM_MTU; 1327 current_mtu = claimedmtu; 1328 } 1330 Notes: 1331 All comparisions between sequence numbers must be performed using 1332 sequence number arithmethic. 1333 The pseudo-code implements the mechanism described in Section 7.2, 1334 the TCP sequence number checking described in Section 4.1, and the 1335 validation check on the advertised Next-Hop MTU described in [5] 1336 and [9]. 1338 Appendix C. Advice and guidance to vendors 1340 Vendors are urged to contact NISCC (vulteam@niscc.gov.uk) if they 1341 think they may be affected by the issues described in this document. 1342 As the lead coordination center for these issues, NISCC is well 1343 placed to give advice and guidance as required. 1345 NISCC works extensively with government departments and agencies, 1346 commercial organizations and the academic community to research 1347 vulnerabilities and potential threats to IT systems especially where 1348 they may have an impact on Critical National Infrastructure's (CNI). 1350 Other ways to contact NISCC, plus NISCC's PGP public key, are 1351 available at http://www.uniras.gov.uk/vuls/ . 1353 Appendix D. Changes from previous versions of the draft 1355 D.1. Changes from draft-gont-tcpm-icmp-attacks-03 1357 o Added references to existing implementations of the proposed 1358 counter-measures 1360 o The discussion in Section 4 was improved 1362 o The discussion in Section 5.2.1 was expanded and improved 1364 o The proposed counter-measure for the attack against the PMTUD was 1365 improved and simplified 1367 o Appendix B was added 1369 o Miscellaneous editorial changes 1371 D.2. Changes from draft-gont-tcpm-icmp-attacks-02 1373 o Fixed errors in Section 5.2.1 1375 o The proposed counter-measure for the attack against the PMTUD 1376 mechanism was refined to allow quick discovery of the Path-MTU 1378 o Appendix A was added so as to clarify the operation of the 1379 counter-measure for the attack against the PMTUD mechanism 1381 o Added Appendix C 1383 o Miscellaneous editorial changes 1385 D.3. Changes from draft-gont-tcpm-icmp-attacks-01 1387 o The document was restructured for easier reading 1389 o A discussion of ICMPv6 was added in several sections of the 1390 document 1392 o Added Section on Acknowledgement number checking"/> 1394 o Added Section 4.3 1396 o Added Section 7 1398 o Fixed typo in the ICMP types, in several places 1400 o Fixed typo in the TCP sequence number check formula 1402 o Miscellaneous editorial changes 1404 D.4. Changes from draft-gont-tcpm-icmp-attacks-00 1406 o Added a proposal to change the handling of the so-called ICMP hard 1407 errors during the synchronized states 1409 o Added a summary of the relevant RFCs in several sections 1411 o Miscellaneous editorial changes 1413 Author's Address 1415 Fernando Gont 1416 Universidad Tecnologica Nacional 1417 Evaristo Carriego 2644 1418 Haedo, Provincia de Buenos Aires 1706 1419 Argentina 1421 Phone: +54 11 4650 8472 1422 Email: fernando@gont.com.ar 1424 Intellectual Property Statement 1426 The IETF takes no position regarding the validity or scope of any 1427 Intellectual Property Rights or other rights that might be claimed to 1428 pertain to the implementation or use of the technology described in 1429 this document or the extent to which any license under such rights 1430 might or might not be available; nor does it represent that it has 1431 made any independent effort to identify any such rights. Information 1432 on the procedures with respect to rights in RFC documents can be 1433 found in BCP 78 and BCP 79. 1435 Copies of IPR disclosures made to the IETF Secretariat and any 1436 assurances of licenses to be made available, or the result of an 1437 attempt made to obtain a general license or permission for the use of 1438 such proprietary rights by implementers or users of this 1439 specification can be obtained from the IETF on-line IPR repository at 1440 http://www.ietf.org/ipr. 1442 The IETF invites any interested party to bring to its attention any 1443 copyrights, patents or patent applications, or other proprietary 1444 rights that may cover technology that may be required to implement 1445 this standard. Please address the information to the IETF at 1446 ietf-ipr@ietf.org. 1448 Disclaimer of Validity 1450 This document and the information contained herein are provided on an 1451 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 1452 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 1453 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 1454 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 1455 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1456 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1458 Copyright Statement 1460 Copyright (C) The Internet Society (2005). This document is subject 1461 to the rights, licenses and restrictions contained in BCP 78, and 1462 except as set forth therein, the authors retain all their rights. 1464 Acknowledgment 1466 Funding for the RFC Editor function is currently provided by the 1467 Internet Society.