idnits 2.14.01 /var/www/.idnits tmp/draft-gont-tcpm-icmp-attacks-05.txt: Attempted to download rfc0791 state... The downloaded file seems to be corrupt, proceeding with outdated information. Attempted to download rfc0792 state... The downloaded file seems to be corrupt, proceeding with outdated information. Attempted to download rfc0793 state... The downloaded file seems to be corrupt, proceeding with outdated information. Attempted to download rfc0816 state... Failure fetching the file, proceeding without it. Attempted to download rfc201 state... Failure fetching the file, proceeding without it. Attempted to download rfc8472 state... Failure fetching the file, proceeding without it. Checking boilerplate required by RFC 5378 and the IETF Trust (see http://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 http://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 1555. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1532. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1539. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1545. ** 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 http://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to http://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of http://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 http://trustee.ietf.org/license-info for more information.) -- The document date (October 24, 2005) is 4183 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 2401 (Obsoleted by RFC 4301) ** Obsolete normative reference: RFC 2463 (Obsoleted by RFC 4443) == Outdated reference: draft-iab-link-indications has been published as RFC 4907 == Outdated reference: draft-ietf-pmtud-method has been published as RFC 4821 == Outdated reference: draft-ietf-tcpm-tcpsecure has been published as RFC 5961 -- Obsolete informational reference (is this intentional?): RFC 816 (Obsoleted by RFC 7805) -- Obsolete informational reference (is this intentional?): RFC 1323 (Obsoleted by RFC 7323) -- Obsolete informational reference (is this intentional?): RFC 2385 (Obsoleted by RFC 5925) -- Obsolete informational reference (is this intentional?): RFC 2581 (Obsoleted by RFC 5681) -- Obsolete informational reference (is this intentional?): RFC 2616 (Obsoleted by RFC 7230, RFC 7231, RFC 7232, RFC 7233, RFC 7234, RFC 7235) -- Obsolete informational reference (is this intentional?): RFC 2821 (Obsoleted by RFC 5321) Summary: 6 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 October 24, 2005 5 Expires: April 27, 2006 7 ICMP attacks against TCP 8 draft-gont-tcpm-icmp-attacks-05.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 April 27, 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 . . . . . . . . . . . . . . . . . . . . . . . . . 4 53 2. Background . . . . . . . . . . . . . . . . . . . . . . . . . . 5 54 2.1. The Internet Control Message Protocol (ICMP) . . . . . . . 5 55 2.1.1. ICMP for IP version 4 (ICMP) . . . . . . . . . . . . . 5 56 2.1.2. ICMP for IP version 6 (ICMPv6) . . . . . . . . . . . . 6 57 2.2. Handling of ICMP error messages . . . . . . . . . . . . . 6 58 3. Constraints in the possible solutions . . . . . . . . . . . . 7 59 4. General counter-measures against ICMP attacks . . . . . . . . 8 60 4.1. TCP sequence number checking . . . . . . . . . . . . . . . 8 61 4.2. Port randomization . . . . . . . . . . . . . . . . . . . . 9 62 4.3. Filtering ICMP error messages based on the ICMP payload . 9 63 5. Blind connection-reset attack . . . . . . . . . . . . . . . . 9 64 5.1. Description . . . . . . . . . . . . . . . . . . . . . . . 10 65 5.2. Attack-specific counter-measures . . . . . . . . . . . . . 11 66 5.2.1. Changing the reaction to hard errors . . . . . . . . . 11 67 5.2.2. Delaying the connection-reset . . . . . . . . . . . . 13 68 6. Blind throughput-reduction attack . . . . . . . . . . . . . . 13 69 6.1. Description . . . . . . . . . . . . . . . . . . . . . . . 14 70 6.2. Attack-specific counter-measures . . . . . . . . . . . . . 14 71 7. Blind performance-degrading attack . . . . . . . . . . . . . . 14 72 7.1. Description . . . . . . . . . . . . . . . . . . . . . . . 14 73 7.2. Attack-specific counter-measures . . . . . . . . . . . . . 16 74 8. Security Considerations . . . . . . . . . . . . . . . . . . . 19 75 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 19 76 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 20 77 10.1. Normative References . . . . . . . . . . . . . . . . . . . 20 78 10.2. Informative References . . . . . . . . . . . . . . . . . . 21 79 Appendix A. The counter-measure for the PMTUD attack in action . 22 80 A.1. Normal operation for bulk transfers . . . . . . . . . . . 23 81 A.2. Operation during Path-MTU changes . . . . . . . . . . . . 25 82 A.3. Idle connection being attacked . . . . . . . . . . . . . . 26 83 A.4. Active connection being attacked after discovery of 84 the Path-MTU . . . . . . . . . . . . . . . . . . . . . . . 27 85 A.5. TCP peer attacked when sending small packets just 86 after the three-way handshake . . . . . . . . . . . . . . 27 87 Appendix B. Pseudo-code for the counter-measure for the blind 88 performance-degrading attack . . . . . . . . . . . . 28 89 Appendix C. Additional considerations for the validation of 90 ICMP error messages . . . . . . . . . . . . . . . . . 32 91 Appendix D. Advice and guidance to vendors . . . . . . . . . . . 32 92 Appendix E. Changes from previous versions of the draft . . . . . 32 93 E.1. Changes from draft-gont-tcpm-icmp-attacks-04 . . . . . . . 32 94 E.2. Changes from draft-gont-tcpm-icmp-attacks-03 . . . . . . . 33 95 E.3. Changes from draft-gont-tcpm-icmp-attacks-02 . . . . . . . 33 96 E.4. Changes from draft-gont-tcpm-icmp-attacks-01 . . . . . . . 33 97 E.5. Changes from draft-gont-tcpm-icmp-attacks-00 . . . . . . . 34 99 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 35 100 Intellectual Property and Copyright Statements . . . . . . . . . . 36 102 1. Introduction 104 ICMP [RFC0792] is a fundamental part of the TCP/IP protocol suite, 105 and is used mainly for reporting network error conditions. However, 106 the current specifications do not recommend any kind of validation 107 checks on the received ICMP error messages, thus leaving the door 108 open to a variety of attacks that can be performed against TCP 109 [RFC0793] by means of ICMP, which include blind connection-reset, 110 blind throughput-reduction, and blind performance-degrading attacks. 111 All of these attacks can be performed even being off-path, without 112 the need to sniff the packets that correspond to the attacked TCP 113 connection. 115 While the security implications of ICMP have been known in the 116 research community for a long time, there has never been an official 117 proposal on how to deal with these vulnerabiliies. Thus, only a few 118 implementations have implemented validation checks on the received 119 ICMP error messages to minimize the impact of these attacks. 121 Recently, a disclosure process has been carried out by the UK's 122 National Infrastructure Security Co-ordination Centre (NISCC), with 123 the collaboration of other computer emergency response teams. A 124 large number of implementations were found vulnerable to either all 125 or a subset of the attacks discussed in this document [NISCC][US- 126 CERT]. The affected systems ranged from TCP/IP implementations meant 127 for desktop computers, to TCP/IP implementations meant for core 128 Internet routers. 130 It is clear that implementations should be more cautious when 131 processing ICMP error messages, to eliminate or mitigate the use of 132 ICMP to perform attacks against TCP [I-D.iab-link-indications]. 134 This document aims to raise awareness of the use of ICMP to perform a 135 variety of attacks against TCP, and proposes several counter-measures 136 that eliminate or minimize the impact of these attacks. 138 Section 2 provides background information on ICMP. Section 3 139 discusses the constraints in the general counter-measures that can be 140 implemented against the attacks described in this document. 141 Section 4 proposes several general validation checks and counter- 142 measures that can be implemented to mitigate any ICMP-based attack. 143 Finally, Section 5, Section 6, and Section 7, discuss a variety of 144 ICMP attacks that can be performed against TCP, and propose attack- 145 specific counter-measures that eliminate or greatly mitigate their 146 impact. 148 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 149 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 150 document are to be interpreted as described in RFC 2119 [RFC2119]. 152 2. Background 154 2.1. The Internet Control Message Protocol (ICMP) 156 The Internet Control Message Protocol (ICMP) is used in the Internet 157 Architecture mainly to perform the fault-isolation function, that is, 158 the group of actions that hosts and routers take to determine that 159 there is some network failure [RFC0816] 161 When an intermediate router detects a network problem while trying to 162 forward an IP packet, it will usually send an ICMP error message to 163 the source host, to raise awareness of the network problem taking 164 place. In the same way, there are a number of scenarios in which an 165 end-system may generate an ICMP error message if it finds a problem 166 while processing a datagram. The received ICMP errors are handled to 167 the corresponding transport-protocol instance, which will usually 168 perform a fault recovery function. 170 It is important to note that ICMP error messages are unreliable, and 171 may be discarded due to data corruption, network congestion and rate- 172 limiting. Thus, while they provide useful information, upper layer 173 protocols cannot depend on ICMP for correct operation. 175 2.1.1. ICMP for IP version 4 (ICMP) 177 [RFC0792] specifies the Internet Control Message Protocol (ICMP) to 178 be used with the Internet Protocol version 4 (IPv4). It defines, 179 among other things, a number of error messages that can be used by 180 end-systems and intermediate systems to report network errors to the 181 sending host. The Host Requirements RFC [RFC1122] classifies ICMP 182 error messages into those that indicate "soft errors", and those that 183 indicate "hard errors", thus roughly defining the semantics of them. 185 The ICMP specification [RFC0792] also defines the ICMP Source Quench 186 message (type 4, code 0), which is meant to provide a mechanism for 187 flow control and congestion control. 189 [RFC1191] defines a mechanism called "Path MTU Discovery" (PMTUD), 190 which makes use of ICMP error messages of type 3 (Destination 191 Unreachable), code 4 (fragmentation needed and DF bit set) to allow 192 hosts to determine the MTU of an arbitrary internet path. 194 Appendix D of [RFC2401] provides information about which ICMP error 195 messages are produced by hosts, intermediate routers, or both. 197 2.1.2. ICMP for IP version 6 (ICMPv6) 199 [RFC2463] specifies the Internet Control Message Protocol (ICMPv6) to 200 be used with the Internet Protocol version 6 (IPv6) [RFC2460]. 202 [RFC2463] defines the "Packet Too Big" (type 2, code 0) error 203 message, that is analogous to the ICMP "fragmentation needed and DF 204 bit set" (type 3, code 4) error message. [RFC1981] defines the Path 205 MTU Discovery mechanism for IP Version 6, that makes use of these 206 messages to determine the MTU of an arbitrary internet path. 208 Appendix D of [RFC2401] provides information about which ICMPv6 error 209 messages are produced by hosts, intermediate routers, or both. 211 2.2. Handling of ICMP error messages 213 The Host Requirements RFC [RFC1122] states that a TCP MUST act on an 214 ICMP error message passed up from the IP layer, directing it to the 215 connection that elicited the error. 217 In order to allow ICMP messages to be demultiplexed by the receiving 218 host, part of the original packet that elicited the message is 219 included in the payload of the ICMP error message. Thus, the 220 receiving host can use that information to match the ICMP error to 221 the transport protocol instance that elicited it. 223 Neither the Host Requirements RFC [RFC1122] nor the original TCP 224 specification [RFC0793] recommend any validation checks on the 225 received ICMP messages. Thus, as long as the ICMP payload contains 226 the information that identifies an existing communication instance, 227 it will be processed by the corresponding transport-protocol 228 instance, and the corresponding action will be performed. 230 Therefore, in the case of TCP, an attacker could send a forged ICMP 231 message to the attacked host, and, as long as he is able to guess the 232 four-tuple that identifies the communication instance to be attacked, 233 he will be able to use ICMP to perform a variety of attacks. 235 As discussed in [Watson], there are a number of scenarios in which an 236 attacker may be able to know or guess the four-tuple that identifies 237 a TCP connection. If we assume the attacker knows the two systems 238 involved in the TCP connection to be attacked, both the client-side 239 and the server-side IP addresses will be known. Furthermore, as most 240 Internet services use the so-called "well-known" ports, only the 241 client port number would need to be guessed. This means that an 242 attacker would need to send, in principle, at most 65536 packets to 243 perform any of the attacks described in this document. However, most 244 systems choose the port numbers they use for outgoing connections 245 from a subset of the whole port number space. Thus, in practice, 246 fewer packets are needed to perform any of the attacks discussed in 247 this document. 249 It is clear that TCP should be more cautious when processing received 250 ICMP error messages, in order to mitigate or eliminate the impact of 251 the attacks described in this document [I-D.iab-link-indications]. 253 3. Constraints in the possible solutions 255 For ICMPv4, [RFC0792] states that the internet header plus the first 256 64 bits of the packet that elicited the ICMP message are to be 257 included in the payload of the ICMP error message. Thus, it is 258 assumed that all data needed to identify a transport protocol 259 instance and process the ICMP error message is contained in the first 260 64 bits of the transport protocol header. [RFC1122] states that "the 261 Internet header and at least the first 8 data octets of the datagram 262 that triggered the error" are to be included in the payload of ICMP 263 error messages, and that "more than 8 octets MAY be sent", thus 264 allowing implementations to include more data from the original 265 packet than those required by the original ICMP specification. The 266 Requirements for IP Version 4 Routers RFC [RFC1812] states that ICMP 267 error messages "SHOULD contain as much of the original datagram as 268 possible without the length of the ICMP datagram exceeding 576 269 bytes". 271 Thus, for ICMP messages generated by hosts, we can only expect to get 272 the entire IP header of the original packet, plus the first 64 bits 273 of its payload. For TCP, this means that the only fields that will 274 be included in the ICMP payload are: the source port number, the 275 destination port number, and the 32-bit TCP sequence number. This 276 clearly imposes a constraint on the possible validation checks that 277 can be performed, as there is not much information avalable on which 278 to perform them. 280 This means, for example, that even if TCP were signing its segments 281 by means of the TCP MD5 signature option [RFC2385], this mechanism 282 could not be used as a counter-measure against ICMP-based attacks, 283 because, as ICMP messages include only a piece of the TCP segment 284 that elicited the error, the MD5 [RFC1321] signature could not be 285 recalculated. In the same way, even if the attacked peer were 286 authenticating its packets at the IP layer [RFC2401], because only a 287 part of the original IP packet would be available, the signature used 288 for authentication could not be recalculated, and thus this mechanism 289 could not be used as a counter-measure aganist ICMP-based attacks 290 against TCP. 292 For IPv6, the payload of ICMPv6 error messages includes as many 293 octets from the IPv6 packet that elicited the ICMPv6 error message as 294 will fit without making the resulting ICMPv6 packet exceed the 295 minimum IPv6 MTU (1280 octets) [RFC2463]. Thus, more information is 296 available than in the IPv4 case. 298 Hosts could require ICMP error messages to be authenticated 299 [RFC2401], in order to act upon them. However, while this 300 requirement could make sense for those ICMP error messages sent by 301 hosts, it would not be feasible for those ICMP error messages 302 generated by routers, as this would imply either that the attacked 303 host should have a security asociation [RFC2401] with every existing 304 intermediate system, or that it should be able to establish one 305 dynamically. Current levels of deployment of protocols for dynamic 306 establishment of security associations makes this unfeasible. Also, 307 there may be some cases, such as embedded devices, in which the 308 processing power requirements of authentication could not allow IPSec 309 authentication to be implemented effectively. 311 Additional considerations for the validation of ICMP error messages 312 can be found in Appendix C 314 4. General counter-measures against ICMP attacks 316 There are a number of counter-measures that can be implemented to 317 eliminate or mitigate the impact of the attacks discussed in this 318 document. Rather than being alternative counter-measures, they can 319 be implemented together to increase the protection against these 320 attacks. In particular, all TCP implementations SHOULD perform the 321 TCP sequence number checking described in Section 4.1. 323 4.1. TCP sequence number checking 325 TCP SHOULD check that the TCP sequence number contained in the 326 payload of the ICMP error message is within the range SND.UNA =< 327 SEG.SEQ < SND.NXT. This means that the sequence number should be 328 within the range of the data already sent but not yet acknowledged. 329 If an ICMP error message does not pass this check, it SHOULD be 330 discarded. 332 Even if an attacker were able to guess the four-tuple that identifies 333 the TCP connection, this additional check would reduce the 334 possibility of considering a spoofed ICMP packet as valid to 335 Flight_Size/2^^32 (where Flight_Size is the number of data bytes 336 already sent to the remote peer, but not yet acknowledged [RFC2581]). 337 For connections in the SYN-SENT or SYN-RECEIVED states, this would 338 reduce the possibility of considering a spoofed ICMP packet as valid 339 to 1/2^^32. For a TCP endpoint with no data "in flight", this would 340 completely eliminate the possibility of success of these attacks. 342 This validation check has been implemented in Linux [Linux] for many 343 years, in OpenBSD [OpenBSD] since 2004, and in FreeBSD [FreeBSD] and 344 NetBSD [NetBSD] since 2005. 346 It is important to note that while this check greatly increases the 347 number of packets required to perform any of the attacks discussed in 348 this document, this may not be enough in those scenarios in which 349 bandwidth is easily available, and/or large TCP windows [RFC1323] are 350 in use. Therefore, implementation of the attack-specific counter- 351 measures discussed in this document is strongly RECOMMENDED. 353 4.2. Port randomization 355 As discussed in the previous sections, in order to perform any of the 356 attacks described in this document, an attacker would need to guess 357 (or know) the four-tuple that identifies the connection to be 358 attacked. Increasing the port number range used for outgoing TCP 359 connections, and randomizing the port number chosen for each outgoing 360 TCP conenctions would make it harder for an attacker to perform any 361 of the attacks discussed in this document. 363 [I-D.larsen-tsvwg-port-randomisation] discusses a number of 364 algorithms to randomize the ephemeral ports used by clients. 366 4.3. Filtering ICMP error messages based on the ICMP payload 368 The source address of ICMP error messages does not need to be spoofed 369 to perform the attacks described in this document. Therefore, simple 370 filtering based on the source address of ICMP error messages does not 371 serve as a counter-measure against these attacks. However, a more 372 advanced packet filtering could be implemented in firewalls as a 373 counter-measure. Firewalls implementing such advanced filtering 374 would look at the payload of the ICMP error messages, and would 375 perform ingress and egress packet filtering based on the source IP 376 address of the IP header contained in the payload of the ICMP error 377 message. As the source IP address contained in the payload of the 378 ICMP error message does need to be spoofed to perform the attacks 379 described in this document, this kind of advanced filtering would 380 serve as a counter-measure against these attacks. 382 5. Blind connection-reset attack 383 5.1. Description 385 When TCP is handled an ICMP error message, it will perform its fault 386 recovery function, as follows: 388 o If the network problem being reported is a hard error, TCP will 389 abort the corresponding connection. 391 o If the network problem being reported is a soft error, TCP will 392 just record this information, and repeatedly retransmit its data 393 until they either get acknowledged, or the connection times out. 395 The Host Requirements RFC [RFC1122] states that a host SHOULD abort 396 the corresponding connection when receiving an ICMP error message 397 that indicates a "hard error", and states that ICMP error messages of 398 type 3 (Destination Unreachable) codes 2 (protocol unreachable), 3 399 (port unreachable), and 4 (fragmentation needed and DF bit set) 400 should be considered to indicate hard errors. While [RFC2463] did 401 not exist when [RFC1122] was published, one could extrapolate the 402 concept of "hard errors" to ICMPv6 error messages of type 1 403 (Destination unreachable) codes 1 (communication with destination 404 administratively prohibited), and 4 (port unreachable). 406 Thus, an attacker could use ICMP to perform a blind connection-reset 407 attack. That is, even being off-path, an attacker could reset any 408 TCP connection taking place. In order to perform such an attack, an 409 attacker would send any ICMP error message that indicates a "hard 410 error", to either of the two TCP endpoints of the connection. 411 Because of TCP's fault recovery policy, the connection would be 412 immediately aborted. 414 As discussed in Section 2.2, all an attacker needs to know to perform 415 such an attack is the socket pair that identifies the TCP connection 416 to be attacked. In some scenarios, the IP addresses and port numbers 417 in use may be easily guessed or known to the attacker [Watson]. 419 Some stacks are known to extrapolate ICMP errors across TCP 420 connections, increasing the impact of this attack, as a single ICMP 421 packet could bring down all the TCP connections between the 422 corresponding peers. 424 It is important to note that even if TCP itself were protected 425 against the blind connection-reset attack described in [Watson] and 426 [I-D.ietf-tcpm-tcpsecure], by means authentication at the network 427 layer [RFC2401], by means of the TCP MD5 signature option [RFC2385], 428 or by means of the mechanism proposed in [I-D.ietf-tcpm-tcpsecure], 429 the blind connection-reset attack described in this document would 430 still succeed. 432 5.2. Attack-specific counter-measures 434 5.2.1. Changing the reaction to hard errors 436 An analysis of the circumstances in which ICMP messages that indicate 437 hard errors may be received can shed some light to eliminate the 438 impact of ICMP-based blind connection-reset attacks. 440 ICMP type 3 (Destination Unreachable), code 2 (protocol unreachable) 442 This ICMP error message indicates that the host sending the ICMP 443 error message received a packet meant for a transport protocol it 444 does not support. For connection-oriented protocols such as TCP, 445 one could expect to receive such an error as the result of a 446 connection-establishment attempt. However, it would be strange to 447 get such an error during the life of a connection, as this would 448 indicate that support for that transport protocol has been removed 449 from the host sending the error message during the life of the 450 corresponding connection. Thus, it would be fair to treat ICMP 451 protocol unreachable error messages as soft errors (or completely 452 ignore them) if they are meant for connections that are in 453 synchronized states. For TCP, this means TCP should treat ICMP 454 protocol unreachable error messages as soft errors (or completely 455 ignore them) if they are meant for connections that are in the 456 ESTABLISHED, FIN-WAIT-1, FIN-WAIT-2, CLOSE-WAIT, CLOSING, LAST-ACK 457 or TIME-WAIT states. 459 ICMP type 3 (Destination Unreachable), code 3 (port unreachable) 461 This error message indicates that the host sending the ICMP error 462 message received a packet meant for a socket (IP address, port 463 number) on which there is no process listening. Those transport 464 protocols which have their own mechanisms for notifying this 465 condition should not be receiving these error messages. However, 466 the Host Requirements RFC [RFC1122] states that even those 467 transport protocols that have their own mechanism for notifying 468 the sender that a port is unreachable MUST nevertheless accept an 469 ICMP Port Unreachable for the same purpose. For security reasons, 470 it would be fair to treat ICMP port unreachable messages as soft 471 errors (or completely ignore them) when they are meant for 472 protocols that have their own mechanism for reporting this error 473 condition. 475 ICMP type 3 (Destination Unreachable), code 4 (fragmentation needed 476 and DF bit set) 478 This error message indicates that an intermediate node needed to 479 fragment a datagram, but the DF (Don't Fragment) bit in the IP 480 header was set. Those systems that do not implement the PMTUD 481 mechanism should not be sending their IP packets with the DF bit 482 set, and thus should not be receiving these ICMP error messages. 483 Thus, it would be fair for them to treat this ICMP error message 484 as indicating a soft error, therefore not aborting the 485 corresponding connection when such an error message is received. 486 On the other hand, and for obvious reasons, those systems 487 implementing the Path-MTU Discovery (PMTUD) mechanism [RFC1191] 488 should not abort the corresponding connection when such an ICMP 489 error message is received. 491 ICMPv6 type 1 (Destination Unreachable), code 1 (communication with 492 destination administratively prohibited) 494 This error message indicates that the destination is unreachable 495 because of an administrative policy. For connection-oriented 496 protocols such as TCP, one could expect to receive such an error 497 as the result of a connection-establishment attempt. Receiving 498 such an error for a connection in any of the synchronized states 499 would mean that the administrative policy changed during the life 500 of the connection. Therefore, while it would be possible for a 501 firewall to be reconfigured during the life of a connection, it 502 would be fair, for security reasons, to ignore these messages for 503 connections that are in the ESTABLISHED, FIN-WAIT-1, FIN-WAIT-2, 504 CLOSE-WAIT, CLOSING, LAST-ACK or TIME-WAIT states. 506 ICMPv6 type 1 (Destination Unreachable), code 4 (port unreachable) 508 This error message is analogous to the ICMP type 3 (Destination 509 Unreachable), code 3 (Port unreachable) error message discussed 510 above. Therefore, the same considerations apply. 512 Therefore, TCP SHOULD treat all of the above messages as indicating 513 "soft errors", rather than "hard errors", and thus SHOULD NOT abort 514 the corresponding connection upon receipt of them. This is policy is 515 based on the premise that TCP should be as robust as possible. Also, 516 as discussed in Section 5.1, hosts SHOULD NOT extrapolate ICMP errors 517 across TCP connections. 519 In case the received message were legitimate, it would mean that the 520 "hard error" condition appeared during the life of the connection. 521 However, there is no reason to think that in the same way this error 522 condition appeared, it won't get solved in the near term. Therefore, 523 treating the received ICMP error messages as "soft errors" would make 524 TCP more robust, and could avoid TCP from aborting a TCP connection 525 unnecesarily. Aborting the connection would be to ignore the 526 valuable feature of the Internet that for many internal failures it 527 reconstructs its function without any disruption of the end points 529 [RFC0816]. 531 Also, it is important to note that the current specifications allow 532 this recommended counter-measure. 534 One scenario in which a host would benefit from treating the so- 535 called ICMP "hard errors" as "soft errors" would be that in which the 536 packets that correspond to a given TCP connection are routed along 537 multiple different paths. Some (but not all) of these paths may be 538 experiencing an error condition, and therefore generating the so- 539 called ICMP hard errors. However, communication should survive if 540 there is still a working path to the destination host [DClark]. 541 Thus, treating the so-called "hard errors" as "soft errors" when a 542 connection is in any of the synchronized states would make TCP 543 achieve this goal. 545 It is interesting to note that, as ICMP error messages are 546 unreliable, transport protocols should not depend on them for correct 547 functioning. In the event one of these messages were legitimate, the 548 corresponding connection would eventually time out. Also, 549 applications may still be notified asynchronously about the received 550 error messages, and thus may still abort their connections on their 551 own if they consider it appropriate. 553 This counter-measure has been implemented in BSD-derived TCP/IP 554 implementations (e.g., [FreeBSD], [NetBSD], and [OpenBSD]) for more 555 than ten years [TCPv2][McKusick]. The Linux kernel has implemented 556 this policy for more than ten years, too [Linux]. 558 5.2.2. Delaying the connection-reset 560 An alternative counter-measure could be to delay the connection 561 reset. Rather than immediately aborting a connection, a TCP would 562 abort a connection only after an ICMP error message indicating a hard 563 error has been received, and the corresponding data have already been 564 retransmitted more than some specified number of times. 566 The rationale behind this proposed fix is that if a host can make 567 forward progress on a connection, it can completely disregard the 568 "hard errors" being indicated by the received ICMP error messages. 570 While this counter-measure could be useful, we think that the 571 counter-measure discussed in Section 5.2.1 is easier to implement, 572 and provides increased protection against this type of attack. 574 6. Blind throughput-reduction attack 575 6.1. Description 577 The Host requirements RFC [RFC1122] states that hosts MUST react to 578 ICMP Source Quench messages by slowing transmission on the 579 connection. Thus, an attacker could send ICMP Source Quench (type 4, 580 code 0) messages to a TCP endpoint to make it reduce the rate at 581 which it sends data to the other end-point of the connection. 582 [RFC1122] further adds that the RECOMMENDED procedure is to put the 583 corresponding connection in the slow-start phase of TCP's congestion 584 control algorithm [RFC2581]. In the case of those implementations 585 that use an initial congestion window of one segment, a sustained 586 attack would reduce the throughput of the attacked connection to 587 about SMSS (Sender Maximum Segment Size) [RFC2581] bytes per RTT 588 (round-trip time). The throughput achieved during attack might be a 589 little higher if a larger initial congestion window is in use 590 [RFC3390]. 592 6.2. Attack-specific counter-measures 594 The Host Requirements RFC [RFC1122] states that hosts MUST react to 595 ICMP Source Quench messages by slowing transmission on the 596 connection. However, as discussed in the Requirements for IP Version 597 4 Routers RFC [RFC1812], research seems to suggest ICMP Source Quench 598 is an ineffective (and unfair) antidote for congestion. [RFC1812] 599 further states that routers SHOULD NOT send ICMP Source Quench 600 messages in response to congestion. On the other hand, TCP 601 implements its own congestion control mechanisms [RFC2581] [RFC3168], 602 that do not depend on ICMP Source Quench messages. Thus, hosts 603 SHOULD completely ignore ICMP Source Quench messages meant for TCP 604 connections. 606 This behavior has been implemented in Linux [Linux] since 2004, and 607 in FreeBSD [FreeBSD], NetBSD [NetBSD], and OpenBSD [OpenBSD] since 608 2005. 610 7. Blind performance-degrading attack 612 7.1. Description 614 When one IP host has a large amount of data to send to another host, 615 the data will be transmitted as a series of IP datagrams. It is 616 usually preferable that these datagrams be of the largest size that 617 does not require fragmentation anywhere along the path from the 618 source to the destination. This datagram size is referred to as the 619 Path MTU (PMTU), and is equal to the minimum of the MTUs of each hop 620 in the path [RFC1191]. 622 A technique called "Path MTU Discovery" (PMTUD) mechanism lets IP 623 hosts determine the Path MTU of an arbitrary internet path. 624 [RFC1191] and [RFC1981] specify the PMTUD mechanism for IPv4 and 625 IPv6, respectively. 627 The PMTUD mechanism for IPv4 uses the Don't Fragment (DF) bit in the 628 IP header to dynamically discover the Path MTU. The basic idea 629 behind the PMTUD mechanism is that a source host assumes that the MTU 630 of the path is that of the first hop, and sends all its datagrams 631 with the DF bit set. If any of the datagrams is too large to be 632 forwarded without fragmentation by some intermediate router, the 633 router will discard the corresponding datagram, and will return an 634 ICMP "Destination Unreachable" (type 3) "fragmentation neeed and DF 635 set" (code 4) error message to sending host. This message will 636 report the MTU of the constricting hop, so that the sending host can 637 reduce the assumed Path-MTU accordingly. 639 For IPv6, intermediate systems do not fragment packets. Thus, 640 there's an "implicit" DF bit set in every packet sent on a network. 641 If any of the datagrams is too large to be forwarded without 642 fragmentation by some intermediate router, the router will discard 643 the corresponding datagram, and will return an ICMPv6 "Packet Too 644 Big" (type 2, code 0) error message to sending host. This message 645 will report the MTU of the constricting hop, so that the sending host 646 can reduce the assumed Path-MTU accordingly. 648 As discussed in both [RFC1191] and [RFC1981], the Path-MTU Discovery 649 mechanism can be used to attack TCP. An attacker could send a forged 650 ICMP "Destination Unreachable, fragmentation needed and DF set" 651 packet (or their ICMPv6 counterpart) to the sending host, advertising 652 a small Next-Hop MTU. As a result, the attacked system would reduce 653 the size of the packets it sends for the corresponding connection 654 accordingly. 656 The effect of this attack is two-fold. On one hand, it will increase 657 the headers/data ratio, thus increasing the overhead needed to send 658 data to the remote TCP end-point. On the other hand, if the attacked 659 system wanted to keep the same throughput it was achieving before 660 being attacked, it would have to increase the packet rate. On 661 virtually all systems this will lead to an increase in the IRQ 662 (Interrrupt ReQuest) rate, thus increasing processor utilization, and 663 degrading the overall system performance. 665 A particular scenario that may take place is that in which an 666 attacker reports a Next-Hop MTU smaller than or equal to the amount 667 of bytes needed for headers (IP header, plus TCP header). For 668 example, if the attacker reports a Next-Hop MTU of 68 bytes, and the 669 amount of bytes used for headers (IP header, plus TCP header) is 670 larger than 68 bytes, the assumed Path-MTU will not even allow the 671 attacked host to send a single byte of application data without 672 fragmentation. This particular scenario might lead to unpredictable 673 results. Another posible scenario is that in which a TCP connection 674 is being secured by means of IPSec. If the Next-Hop MTU reported by 675 the attacker is smaller than the amount of bytes needed for headers 676 (IP and IPSec, in this case), the assumed Path-MTU will not even 677 allow the attacked host to send a single byte of the TCP header 678 without fragmentation. This is another scenario that may lead to 679 unpredictable results. 681 For IPv4, the reported Next-Hop MTU could be as low as 68 octets, as 682 [RFC0791] requires every internet module to be able to forward a 683 datagram of 68 octets without further fragmentation. For IPv6, the 684 reported Next-Hop MTU could be as low as 1280 octets (the minimum 685 IPv6 MTU) [RFC2460]. 687 7.2. Attack-specific counter-measures 689 Henceforth, we will refer to both ICMP "fragmentation needed and DF 690 bit set" and ICMPv6 "Packet Too Big" messages as "ICMP Packet Too 691 Big" messages. 693 In addition to the general validation check described in Section 4.1, 694 a counter-measure similar to that described in Section 5.2.2 could be 695 implemented to greatly minimize the impact of this attack. 697 This would mean that upon receipt of an ICMP "Packet Too Big" error 698 message, TCP would just record this information, and would honor it 699 only when the corresponding data had already been retransmitted a 700 specified number of times. 702 While this policy would greatly mitigate the impact of the attack 703 against the PMTUD mechanism, it would also mean that it might take 704 TCP more time to discover the Path-MTU for a TCP connection. This 705 would be particularly annoying for connections that have just been 706 established, as it might take TCP several transmission attempts (and 707 the corresponding timeouts) before it discovers the PMTU for the 708 corresponding connection. Thus, this policy would increase the time 709 it takes for data to begin to be received at the destination host. 711 We would like to protect TCP from the attack against the PMTUD 712 mechanism, while still allowing TCP to quickly determine the initial 713 Path-MTU for a connection. 715 To achieve both goals, we can divide the traditional PMTUD mechanism 716 into two stages: Initial Path-MTU Discovery, and Path-MTU Update. 718 The Initial Path-MTU Discovery stage is when TCP tries to send 719 segments that are larger than the ones that have so far been sent and 720 acknowledged for this connection. That is, in the Initial Path-MTU 721 Discovery stage TCP has no record of these large segments getting to 722 the destination host, and thus it would be fair to believe the 723 network when it reports that these packets are too large to reach the 724 destination host without being fragmented. 726 The Path-MTU Update stage is when TCP tries to send segments that are 727 equal to or smaller than the ones that have already been sent and 728 acknowledged for this connection. During the Path-MTU Update stage, 729 TCP already has knowledge of the estimated Path-MTU for the given 730 connection. Thus, it would be fair to be more cautious with the 731 errors being reported by the network. 733 In order to allow TCP to distinguish segments between those 734 performing Initial Path-MTU Discovery and those performing Path-MTU 735 Update, two new variables should be introduced to TCP: maxsizeacked 736 and maxsizesent. 738 maxsizesent would hold the size (in octets) of the largest packet 739 that has so far been sent for this connection. It would be 740 initialized to 68 (the minimum IPv4 MTU) when the underlying internet 741 protocol is IPv4, and would be initialized to 1280 (the minimum IPv6 742 MTU) when the underlying internet protocol is IPv6. Whenever a 743 packet larger than maxsizesent octets is sent, maxsizesent should be 744 set to that value. 746 On the other hand, maxsizeacked would hold the size (in octets) of 747 the largest packet that has so far been acknowledged for this 748 connection. It would be initialized to 68 (the minimum IPv4 MTU) 749 when the underlying internet protocol is IPv4, and would be 750 initialized to 1280 (the minimum IPv6 MTU) when the underlying 751 internet protocol is IPv6. Whenever an acknowledgement for a packet 752 larger than maxsizeacked octets is received, maxsizeacked should be 753 set to the size of that acknowledged packet. 755 Upon receipt of an ICMP "Packet Too Big" error message, the Next-Hop 756 MTU claimed by the ICMP message (henceforth "claimedmtu") should be 757 compared with maxsizesent. If claimedmtu is equal to or larger than 758 maxsizesent, then the ICMP error message should be silently 759 discarded. The rationale for this is that the ICMP error message 760 cannot be legitimate if it claims to have been elicited by a packet 761 larger than the largest packet we have so far sent for this 762 connection. 764 If this check is passed, claimedmtu should be compared with 765 maxsizeacked. If claimedmtu is equal to or larger than maxsizeacked, 766 TCP is supposed to be at the Initial Path-MTU Discovery stage, and 767 thus the ICMP "Packet Too Big" error message should be honored 768 immediately. That is, the assumed Path-MTU should be updated 769 according to the Next-Hop MTU claimed in the ICMP error message. 770 Also, maxsizesent should be reset to the minimum MTU of the internet 771 protocol in use (68 for IPv4, and 1280 for IPv6). 773 On the other hand, if claimedmtu is smaller than maxsizeacked, TCP is 774 supposed to be in the Path-MTU Update stage. At this stage, we 775 should be more cautious with the errors being reported by the 776 network, and should therefore just record the received error message, 777 and delay the update of the assumed Path-MTU. 779 To perform this delay, one new variable and one new parameter should 780 be introduced to TCP: nsegrto and MAXSEGRTO. nsegrto will hold the 781 number of times a specified segment has timed out. It should be 782 initialized to zero, and should be incremented by one everytime the 783 corresponding segment times out. MAXSEGRRTO should specify the 784 number of times a given segment must timeout before an ICMP "Packet 785 Too Big" error message can be honored, and can be set, in principle, 786 to any value greater than or equal to 0. 788 Thus, if nsegrto is greater than or equal to MAXSEGRTO, and there's a 789 pending ICMP "Packet Too Big" error message, the correspoing error 790 message should be processed. At that point, maxsizeacked should be 791 set to claimedmtu, and maxsizesent should be set to 68 (for IPv4) or 792 1280 (for IPv6). 794 If while there is a pending ICMP "Packet Too Big" error message the 795 TCP SEQ claimed by the pending message is acknowledged (i.e., an ACK 796 that acknowledges that sequence number is received), then the 797 "pending error" condition should be cleared. 799 The rationale behind performing this delayed processing of ICMP 800 "Packet Too Big" messages is that if there is progress on the 801 connection, the ICMP "Packet Too Big" errors must be a false claim. 803 MAXSEGRTO can be set, in principle, to any value greater than or 804 equal to 0. Setting MAXSEGRTO to 0 would make TCP perform the 805 traditional PMTUD mechanism defined in [RFC1191] and [RFC1981]. A 806 MAXSEGRTO of 1 should provide enough protection for most cases. In 807 any case, implementations are free to choose higher values for this 808 constant. MAXSEGRTO could be a function of the Next-Hop MTU claimed 809 in the received ICMP "Packet Too Big" message. That is, higher 810 values for MAXSEGRTO could be imposed when the received ICMP "Packet 811 Too Big" message claims a Next-Hop MTU that is smaller than some 812 specified value. 814 In the event a higher level of protection is desired at the expense 815 of a higher delay in the discovery of the Path-MTU, an implementation 816 could consider TCP to always be in the Path-MTU Update stage, thus 817 always delaying the update of the assumed Path-MTU. 819 Appendix A shows the proposed counter-measure in action. Appendix B 820 shows the proposed counter-measure in pseudo-code. 822 This behavior has been implemented in NetBSD [NetBSD] and OpenBSD 823 [OpenBSD] since 2005. 825 It is important to note that the mechanism proposed in this section 826 is an improvement to the current Path-MTU discovery mechanism, to 827 mitigate its security implications. The current PMTUD mechanism, as 828 specified by [RFC1191] and [RFC1981], still suffers from some 829 functionality problems [RFC2923] that this document does not aim to 830 address. Thus, it does not aleviate the need for other improvements 831 to the current PMTUD mechanism or the introduction of an alternative 832 PMTUD that replaces the current one, to solve the remaining issues. 834 A mechanism that aims to address those remaining issues is described 835 in [I-D.ietf-pmtud-method]. 837 8. Security Considerations 839 This document describes the use of ICMP error messages to perform a 840 number of attacks against the TCP protocol, and proposes a number of 841 counter-measures that either eliminate or reduce the impact of these 842 attacks. 844 9. Acknowledgements 846 This document was inspired by Mika Liljeberg, while discussing some 847 issues related to [I-D.gont-tcpm-tcp-soft-errors] by private e-mail. 848 The author would like to thank Ran Atkinson, James Carlson, Alan Cox, 849 Theo de Raadt, Ted Faber, Juan Fraschini, Markus Friedl, Guillermo 850 Gont, John Heffner, Vivek Kakkar, Michael Kerrisk, Mika Liljeberg, 851 David Miller, Miles Nordin, Eloy Paris, Kacheong Poon, Andrew Powell, 852 Pekka Savola, Joe Touch, and Andres Trapanotto, for contributing many 853 valuable comments. 855 Markus Friedl, Chad Loder, and the author of this document, produced 856 and tested in OpenBSD [OpenBSD] the first implementation of the 857 counter-measure described in Section 7.2. This first implementation 858 helped to test the effectiveness of the ideas introduced in this 859 document, and has served as a reference implementation for other 860 operating systems. 862 The author would like to thank the UK's National Infrastructure 863 Security Co-ordination Centre (NISCC) for coordinating the disclosure 864 of these issues with a large number of vendors and CSIRTs (Computer 865 Security Incident Response Teams). 867 The author wishes to express deep and heartfelt gratitude to Jorge 868 Oscar Gont and Nelida Garcia, for their precious motivation and 869 guidance. 871 10. References 873 10.1. Normative References 875 [RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791, 876 September 1981. 878 [RFC0792] Postel, J., "Internet Control Message Protocol", STD 5, 879 RFC 792, September 1981. 881 [RFC0793] Postel, J., "Transmission Control Protocol", STD 7, 882 RFC 793, September 1981. 884 [RFC1122] Braden, R., "Requirements for Internet Hosts - 885 Communication Layers", STD 3, RFC 1122, October 1989. 887 [RFC1191] Mogul, J. and S. Deering, "Path MTU discovery", RFC 1191, 888 November 1990. 890 [RFC1812] Baker, F., "Requirements for IP Version 4 Routers", 891 RFC 1812, June 1995. 893 [RFC1981] McCann, J., Deering, S., and J. Mogul, "Path MTU Discovery 894 for IP version 6", RFC 1981, August 1996. 896 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 897 Requirement Levels", BCP 14, RFC 2119, March 1997. 899 [RFC2401] Kent, S. and R. Atkinson, "Security Architecture for the 900 Internet Protocol", RFC 2401, November 1998. 902 [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 903 (IPv6) Specification", RFC 2460, December 1998. 905 [RFC2463] Conta, A. and S. Deering, "Internet Control Message 906 Protocol (ICMPv6) for the Internet Protocol Version 6 907 (IPv6) Specification", RFC 2463, December 1998. 909 10.2. Informative References 911 [DClark] Clark, D., "The Design Philosophy of the DARPA Internet 912 Protocols", Computer Communication Review Vol. 18, No. 4, 913 1988. 915 [FreeBSD] The FreeBSD Project, "http://www.freebsd.org". 917 [I-D.gont-tcpm-tcp-soft-errors] 918 Gont, F., "TCP's Reaction to Soft Errors", 919 draft-gont-tcpm-tcp-soft-errors-02 (work in progress), 920 September 2005. 922 [I-D.iab-link-indications] 923 Aboba, B., "Architectural Implications of Link 924 Indications", draft-iab-link-indications-03 (work in 925 progress), August 2005. 927 [I-D.ietf-pmtud-method] 928 Mathis, M., "Path MTU Discovery", 929 draft-ietf-pmtud-method-04 (work in progress), 930 February 2005. 932 [I-D.ietf-tcpm-tcpsecure] 933 Dalal, M., "Improving TCP's Robustness to Blind In-Window 934 Attacks", draft-ietf-tcpm-tcpsecure-03 (work in progress), 935 May 2005. 937 [I-D.larsen-tsvwg-port-randomisation] 938 Larsen, M., "Port Randomisation", 939 draft-larsen-tsvwg-port-randomisation-00 (work in 940 progress), October 2004. 942 [Linux] The Linux Project, "http://www.kernel.org". 944 [McKusick] 945 McKusick, M., Bostic, K., Karels, M., and J. Quarterman, 946 "The Design and Implementation of the 4.4BSD Operating 947 System", Addison-Wesley , 1996. 949 [NISCC] NISCC, "NISCC Vulnerability Advisory 532967/NISCC/ICMP: 950 Vulnerability Issues in ICMP packets with TCP payloads", 951 http://www.niscc.gov.uk/niscc/docs/ 952 al-20050412-00308.html?lang=en, 2005. 954 [NetBSD] The NetBSD Project, "http://www.netbsd.org". 956 [OpenBSD] The OpenBSD Project, "http://www.openbsd.org". 958 [RFC0816] Clark, D., "Fault isolation and recovery", RFC 816, 959 July 1982. 961 [RFC1321] Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321, 962 April 1992. 964 [RFC1323] Jacobson, V., Braden, B., and D. Borman, "TCP Extensions 965 for High Performance", RFC 1323, May 1992. 967 [RFC2385] Heffernan, A., "Protection of BGP Sessions via the TCP MD5 968 Signature Option", RFC 2385, August 1998. 970 [RFC2581] Allman, M., Paxson, V., and W. Stevens, "TCP Congestion 971 Control", RFC 2581, April 1999. 973 [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., 974 Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext 975 Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999. 977 [RFC2821] Klensin, J., "Simple Mail Transfer Protocol", RFC 2821, 978 April 2001. 980 [RFC2923] Lahey, K., "TCP Problems with Path MTU Discovery", 981 RFC 2923, September 2000. 983 [RFC3168] Ramakrishnan, K., Floyd, S., and D. Black, "The Addition 984 of Explicit Congestion Notification (ECN) to IP", 985 RFC 3168, September 2001. 987 [RFC3390] Allman, M., Floyd, S., and C. Partridge, "Increasing TCP's 988 Initial Window", RFC 3390, October 2002. 990 [TCPv2] Wright, G. and W. Stevens, "TCP/IP Illustrated, Volume 2: 991 The Implementation", Addison-Wesley , 1994. 993 [US-CERT] US-CERT, "US-CERT Vulnerability Note VU#222750: TCP/IP 994 Implementations do not adequately validate ICMP error 995 messages", http://www.kb.cert.org/vuls/id/222750, 2005. 997 [Watson] Watson, P., "Slipping in the Window: TCP Reset Attacks", 998 2004 CanSecWest Conference , 2004. 1000 Appendix A. The counter-measure for the PMTUD attack in action 1002 This appendix shows the proposed counter-measure for the ICMP attack 1003 against the PMTUD mechanism in action. It shows both how the fix 1004 protects TCP from being attacked and how the counter-measure works in 1005 normal scenarios. As discussed in Section 7.2, this Appendix assumes 1006 the PMTUD-specific counter-measure is implemented in addition to the 1007 TCP sequence number checking described in Section 4.1. 1009 Figure 1 illustrates an hypothetical scenario in which two hosts are 1010 connected by means of three intermediate routers. It also shows the 1011 MTU of each hypothetical hop. All the following subsections assume 1012 the network setup of this figure. 1014 Also, for simplicity sake, all subsections assume an IP header of 20 1015 octets and a TCP header of 20 octets. Thus, for example, when the 1016 PMTU is assumed to be 1500 octets, TCP will send segments that 1017 contain, at most, 1460 octets of data. 1019 For simplicity sake, all the following subsections assume the TCP 1020 implementation at Host 1 has chosen a a MAXSEGRTO of 1. 1022 +----+ +----+ +----+ +----+ +----+ 1023 | H1 |--------| R1 |--------| R2 |--------| R3 |--------| H2 | 1024 +----+ +----+ +----+ +----+ +----+ 1025 MTU=4464 MTU=2048 MTU=1500 MTU=4464 1027 Figure 1: Hypothetical scenario 1029 A.1. Normal operation for bulk transfers 1031 This subsection shows the proposed counter-measure in normal 1032 operation, when a TCP connection is used for bulk transfers. That 1033 is, it shows how the proposed counter-measure works when there is no 1034 attack taking place, and a TCP connection is used for transferring 1035 large amounts of data. This section assumes that just after the 1036 connection is established, one of the TCP endpoints begins to 1037 transfer data in packets that are as large as possible. 1039 Host 1 Host 2 1041 1. --> --> 1042 2. <-- <-- 1043 3. --> --> 1044 4. --> --> 1045 5. <--- ICMP "Packet Too Big" MTU=2048, TCPseq#=101 <--- R1 1046 6. --> --> 1047 7. <--- ICMP "Packet Too Big" MTU=1500, TCPseq#=101 <--- R2 1048 8. --> --> 1049 9. <-- <-- 1051 Figure 2: Normal operation for bulk transfers 1053 nsegrto is initialized to zero. Both maxsizeacked and maxsizesent 1054 are initialized to the minimum MTU for the internet protocol being 1055 used (68 for IPv4, and 1280 for IPv6). 1057 In lines 1 to 3 the three-way handshake takes place, and the 1058 connection is established. In line 4, H1 tries to send a full-sized 1059 TCP segment. As described by [RFC1191] and [RFC1981], in this case 1060 TCP will try to send a segment with 4424 bytes of data, which will 1061 result in an IP packet of 4464 octets. Therefore, maxsizesent is set 1062 to 4464. When the packet reaches R1, it elicits an ICMP "Packet Too 1063 Big" error message. 1065 In line 5, H1 receives the ICMP error message, which reports a Next- 1066 Hop MTU of 2048 octets. After performing the TCP sequence number 1067 check described in Section 4.1, the Next-Hop MTU reported by the ICMP 1068 error message (claimedmtu) is compared with maxsizesent. As it is 1069 smaller than maxsizesent, it passes the check, and thus is then 1070 compared with maxsizeacked. As claimedmtu is larger than 1071 maxsizeacked, TCP assumes that the corresponding TCP segment was 1072 performing the Initial PMTU Discovery. Therefore, the TCP at H1 1073 honors the ICMP message by updating the assumed Path-MTU. maxsizesent 1074 is reset to the minimum MTU of the internet protocol in use (68 for 1075 IPv4, and 1280 for IPv6). 1077 In line 6, the TCP at H1 sends a segment with 2008 bytes of data, 1078 which results in an IP packet of 2048 octets. maxsizesent is thus set 1079 to 2008 bytes. When the packet reaches R2, it elicits an ICMP 1080 "Packet Too Big" error message. 1082 In line 7, H1 receives the ICMP error message, which reports a Next- 1083 Hop MTU of 1500 octets. After performing the TCP sequence number 1084 check, the Next-Hop MTU reported by the ICMP error message 1085 (claimedmtu) is compared with maxsizesent. As it is smaller than 1086 maxsizesent, it passes the check, and thus is then compared with 1087 maxsizeacked. As claimedmtu is larger than maxsizeacked, TCP assumes 1088 that the corresponding TCP segment was performing the Initial PMTU 1089 Discovery. Therefore, the TCP at H1 honors the ICMP message by 1090 updating the assumed Path-MTU. maxsizesent is reset to the minimum 1091 MTU of the internet protocol in use. 1093 In line 8, the TCP at H1 sends a segment with 1460 bytes of data, 1094 which results in an IP packet of 1500 octets. maxsizesent is thus set 1095 to 1500. This packet reaches H2, where it elicits an acknowledgement 1096 (ACK) segment. 1098 In line 9, H1 finally gets the acknowledgement for the data segment. 1099 As the corresponding packet was larger than maxsizeacked, TCP updates 1100 maxsizeacked, setting it to 1500. At this point TCP has discovered 1101 the Path-MTU for this TCP connection. 1103 A.2. Operation during Path-MTU changes 1105 Let us suppose a TCP connection between H1 and H2 has already been 1106 established, and that the PMTU for the connection has already been 1107 discovered to be 1500. At this point, both maxsizesent and 1108 maxsizeacked are equal to 1500, and nsegrto is equal to 0. Suppose 1109 some time later the PMTU decreases to 1492. For simplicity, let us 1110 suppose that the Path-MTU has decreased because the MTU of the link 1111 between R2 and R3 has decreased from 1500 to 1492. Figure 3 1112 illustrates how the proposed counter-measure would work in this 1113 scenario. 1115 Host 1 Host 2 1117 1. (Path-MTU decreases) 1118 2. --> --> 1119 3. <--- ICMP "Packet Too Big" MTU=1492, TCPseq#=100 <--- R2 1120 4. (Segment times out) 1121 5. --> --> 1122 6. <-- <-- 1124 Figure 3: Operation during Path-MTU changes 1126 In line 1, the Path-MTU for this connection decreases from 1500 to 1127 1492. In line 2, the TCP at H1, without being aware of the Path-MTU 1128 change, sends a 1500-byte packet to H2. When the packet reaches R2, 1129 it elicits an ICMP "Packet Too Big" error message. 1131 In line 3, H1 receives the ICMP error message, which reports a Next- 1132 Hop MTU of 1492 octets. After performing the TCP sequence number 1133 check, the Next-Hop MTU reported by the ICMP error message 1134 (claimedmtu) is compared with maxsizesent. As claimedmtu is smaller 1135 than maxsizesent, it is then compared with maxsizeacked. As 1136 claimedmtu is smaller than maxsizeacked (full-sized packets were 1137 getting to the remote end-point), this packet is assumed to be 1138 performing Path-MTU Update. And a "pending error" condition is 1139 recorded. 1141 In line 4, the segment times out. Thus, nsegrto is incremented by 1. 1142 As nsegrto is greater than or equal to MAXSEGRTO, the assumed Path- 1143 MTU is updated. nsegrto is reset to 0, and maxsizeacked is set to 1144 claimedmtu, and maxsizesent is set to the minimum MTU of the internet 1145 protocol in use. 1147 In line 5, H1 retransmits the data using the updated PMTU, and thus 1148 maxsizesent is set to 1492. The resulting packet reaches H2, where 1149 it elicits an acknowledgement (ACK) segment. 1151 In line 6, H1 finally gets the acknowledgement for the data segment. 1152 At this point TCP has discovered the new Path-MTU for this TCP 1153 connection. 1155 A.3. Idle connection being attacked 1157 Let us suppose a TCP connection between H1 and H2 has already been 1158 established, and the PMTU for the connection has already been 1159 discovered to be 1500. Figure 4 shows a sample time-line diagram 1160 that illustrates an idle connection being attacked. 1162 Host 1 Host 2 1164 1. --> --> 1165 2. <-- <-- 1166 3. <--- ICMP "Packet Too Big" MTU=68, TCPseq#=100 <--- 1167 4. <--- ICMP "Packet Too Big" MTU=68, TCPseq#=100 <--- 1168 5. <--- ICMP "Packet Too Big" MTU=68, TCPseq#=100 <--- 1170 Figure 4: Idle connection being attacked 1172 In line 1, H1 sends its last bunch of data. At line 2, H2 1173 acknowledges the receipt of these data. Then the connection becomes 1174 idle. In lines 3, 4, and 5, an attacker sends forged ICMP "Packet 1175 Too Big" error messages to H1. Regardless of how many packets it 1176 sends and the TCP sequence number each ICMP packet includes, none of 1177 these ICMP error messages will pass the TCP sequence number check 1178 described in Section 4.1, as H1 has no unacknowledged data in flight 1179 to H2. Therefore, the attack does not succeed. 1181 A.4. Active connection being attacked after discovery of the Path-MTU 1183 Let us suppose an attacker attacks a TCP connection for which the 1184 PMTU has already been discovered. In this case, as illustrated in 1185 Figure 1, the PMTU would be found to be 1500 bytes. Figure 5 shows a 1186 possible packet exchange. 1188 Host 1 Host 2 1190 1. --> --> 1191 2. --> --> 1192 3. --> --> 1193 4. --> --> 1194 5. <--- ICMP "Packet Too Big" MTU=68, TCPseq#=100 <--- 1195 6. <-- <-- 1197 Figure 5: Active connection being attacked after discovery of PMTU 1199 As we assume the PMTU has already been discovered, we also assume 1200 both maxsizesent and maxsizeacked are equal to 1500. We assume 1201 nsegrto is equal to zero, as there have been no segment timeouts. 1203 In lines 1, 2, 3, and 4, H1 sends four data segments to H2. In line 1204 5, an attacker sends a forged ICMP packet to H1. We assume the 1205 attacker is lucky enough to guess both the four-tuple that identifies 1206 the connection and a valid TCP sequence number. As the Next-Hop MTU 1207 claimed in the ICMP "Packet Too Big" message (claimedmtu) is smaller 1208 than maxsizeacked, this packet is assumed to be performing Path-MTU 1209 Update. Thus, the error message is recorded. 1211 In line 6, H1 receives an acknowledgement for the segment sent in 1212 line 1, before it times out. At this point, the "pending error" 1213 condition is cleared, and the recorded ICMP "Packet Too Big" error 1214 message is ignored. Therefore, the attack does not succeed. 1216 A.5. TCP peer attacked when sending small packets just after the three- 1217 way handshake 1219 This section analyzes an scenario in which a TCP peer that is sending 1220 small segments just after the connection has been established, is 1221 attacked. The connection could be being used by protocols such as 1222 SMTP [RFC2821] and HTTP [RFC2616], for example, which usually behave 1223 like this. 1225 Figure 6 shows a possible packet exchange for such scenario. 1227 Host 1 Host 2 1229 1. --> --> 1230 2. <-- <-- 1231 3. --> --> 1232 4. --> --> 1233 5. <-- <-- 1234 6. --> --> 1235 7. --> --> 1236 8. <--- ICMP "Packet Too Big" MTU=150, TCPseq#=101 <--- 1238 Figure 6: TCP peer attacked when sending small packets just after the 1239 three-way handshake 1241 nsegrto is initialized to zero. Both maxsizesent and maxsizeacked 1242 are initialized to the minimum MTU for the internet protocol being 1243 used (68 for IPv4, and 1280 for IPv6). 1245 In lines 1 to 3 the three-way handshake takes place, and the 1246 connection is established. At this point, the assumed Path-MTU for 1247 this connection is 4464. In line 4, H1 sends a small segment (which 1248 results in a 140-byte packet) to H2. maxsizesent is thus set to 140. 1249 In line 5 this segment is acknowledged, and thus maxsizeacked is set 1250 to 140. 1252 In lines 6 and 7, H1 sends two small segments to H2. In line 8, 1253 while the segments from lines 6 and 7 are still in flight to H2, an 1254 attacker sends a forged ICMP "Packet Too Big" error message to H1. 1255 Assuming the attacker is lucky enough to guess a valid TCP sequence 1256 number, this ICMP message will pass the TCP sequence number check. 1257 The Next-Hop MTU reported by the ICMP error message (claimedmtu) is 1258 then compared with maxsizesent. As claimedmtu is larger than 1259 maxsizesent, the ICMP error message is silently discarded. 1260 Therefore, the attack does not succeed. 1262 Appendix B. Pseudo-code for the counter-measure for the blind 1263 performance-degrading attack 1265 This section contains a pseudo-code version of the counter-measure 1266 described in Section 7.2 for the blind performance-degrading attack 1267 described in Section 7. It is meant as guidance for developers on 1268 how to implement this counter-measure. 1270 The pseudo-code makes use of the following variables, constants, and 1271 functions: 1273 ack 1274 Variable holding the acknowledgement number contained in the TCP 1275 segment that has just been received. 1277 acked_packet_size 1278 Variable holding the packet size (data, plus headers) the ACK that 1279 has just been received is acknowledging. 1281 adjust_mtu() 1282 Function that adjusts the MTU for this connection, according to 1283 the ICMP "Packet Too Big" that was last received. 1285 claimedmtu 1286 Variable holding the Next-Hop MTU advertised by the ICMP "Packet 1287 Too Big" error message. 1289 claimedtcpseq 1290 Variable holding the TCP sequence number contained in the payload 1291 of the ICMP "Packet Too Big" message that has just been received 1292 or was last recorded. 1294 current_mtu 1295 Variable holding the assumed Path-MTU for this connection. 1297 drop_message() 1298 Function that performs the necessary actions to drop the ICMP 1299 message being processed. 1301 initial_mtu 1302 Variable holding the MTU for new connections, as explained in 1303 [RFC1191] and [RFC1981]. 1305 maxsizeacked 1306 Variable holding the largest packet size (data, plus headers) that 1307 has so for been acked for this connection, as explained in 1308 Section 7.2 1310 maxsizesent 1311 Variable holding the largest packet size (data, plus headers) that 1312 has so for been sent for this connection, as explained in 1313 Section 7.2 1315 nsegrto 1316 Variable holding the number of times this segment has timed out, 1317 as explained in Section 7.2 1319 packet_size 1320 Variable holding the size of the IP datagram being sent 1322 pending_message 1323 Variable (flag) that indicates whether there is a pending ICMP 1324 "Packet Too Big" message to be processed. 1326 save_message() 1327 Function that records the ICMP "Packet Too Big" message that has 1328 just been received. 1330 MINIMUM_MTU 1331 Constant holding the minimum MTU for the internet protocol in use 1332 (68 for IPv4, and 1280 for IPv6. 1334 MAXSEGRTO 1335 Constant holding the number of times a given segment must timeout 1336 before an ICMP "Packet Too Big" error message can be honored. 1338 EVENT: New TCP connection 1340 current_mtu = initial_mtu; 1341 maxsizesent = MINIMUM_MTU; 1342 maxsizeacked = MINIMUM_MTU; 1343 nsegrto = 0; 1344 pending_message = 0; 1346 EVENT: Segment is sent 1347 if (packet_size > maxsizesent) 1348 maxsizesent = packet_size; 1350 EVENT: Segment is received 1352 if (acked_packet_size > maxsizeacked) 1353 maxsizeacked = acked_packet_size; 1355 if (pending_mesage) 1356 if (ack > claimedtcpseq){ 1357 pending_message = 0; 1358 nsegrto = 0; 1359 } 1361 EVENT: ICMP "Packet Too Big" message is received 1363 if (claimedtcpseq < SND.UNA || claimed_TCP_SEQ >= SND.NXT){ 1364 drop_message(); 1365 } 1367 else { 1368 if (claimedmtu >= maxsizesent || claimedmtu >= current_mtu) 1369 drop_message(); 1371 else { 1372 if (claimedmtu > maxsizeacked){ 1373 adjust_mtu(); 1374 current_mtu = claimedmtu; 1375 maxsizesent = MINIMUM_MTU; 1376 } 1378 else { 1379 pending_message = 1; 1380 save_message(); 1381 } 1382 } 1383 } 1385 EVENT: Segment times out 1387 nsegrto++; 1389 if (pending_message && nsegrto >= MAXSEGRTO){ 1390 adjust_mtu(); 1391 nsegrto = 0; 1392 pending_message = 0; 1393 maxsizeacked = claimedmtu; 1394 maxsizesent = MINIMUM_MTU; 1395 current_mtu = claimedmtu; 1396 } 1398 Notes: 1399 All comparisions between sequence numbers must be performed using 1400 sequence number arithmethic. 1401 The pseudo-code implements the mechanism described in Section 7.2, 1402 the TCP sequence number checking described in Section 4.1, and the 1403 validation check on the advertised Next-Hop MTU described in 1404 [RFC1191] and [RFC1981]. 1406 Appendix C. Additional considerations for the validation of ICMP error 1407 messages 1409 If a full TCP segment is contained in the payload of the ICMP error 1410 message, then the first check that must be performed is that the TCP 1411 checksum is valid. Then, if a TCP MD5 option is present, the MD5 1412 signature should be recalculated for the encapsulated packet, and if 1413 doesn't match the one contained in the TCP MD5 option, the packet 1414 should be dropped. 1416 Regardless of whether the received ICMP error message contains a full 1417 packet or not, if a TCP timestamp option is present, it should be 1418 used to validate the error message according to the rules specified 1419 in [RFC1323]. 1421 It must be noted that all the checks discussed in this appendix imply 1422 that the ICMP error message contains more data than just the full IP 1423 header and the first 64 bits of the payload of the original datagram 1424 that elicited the error message. As discussed in Section 3, for 1425 obvious reasons one should not expect an attacker to include in the 1426 packets it sends more information than that required to by the 1427 current specifications. 1429 Appendix D. Advice and guidance to vendors 1431 Vendors are urged to contact NISCC (vulteam@niscc.gov.uk) if they 1432 think they may be affected by the issues described in this document. 1433 As the lead coordination center for these issues, NISCC is well 1434 placed to give advice and guidance as required. 1436 NISCC works extensively with government departments and agencies, 1437 commercial organizations and the academic community to research 1438 vulnerabilities and potential threats to IT systems especially where 1439 they may have an impact on Critical National Infrastructure's (CNI). 1441 Other ways to contact NISCC, plus NISCC's PGP public key, are 1442 available at http://www.uniras.gov.uk/vuls/ . 1444 Appendix E. Changes from previous versions of the draft 1446 E.1. Changes from draft-gont-tcpm-icmp-attacks-04 1448 o Added Appendix C 1450 o Added reference to [I-D.iab-link-indications] 1451 o Added stress on the fact that ICMP error messages are unreliable 1453 o Miscellaneous editorial changes 1455 E.2. Changes from draft-gont-tcpm-icmp-attacks-03 1457 o Added references to existing implementations of the proposed 1458 counter-measures 1460 o The discussion in Section 4 was improved 1462 o The discussion in Section 5.2.1 was expanded and improved 1464 o The proposed counter-measure for the attack against the PMTUD was 1465 improved and simplified 1467 o Appendix B was added 1469 o Miscellaneous editorial changes 1471 E.3. Changes from draft-gont-tcpm-icmp-attacks-02 1473 o Fixed errors in Section 5.2.1 1475 o The proposed counter-measure for the attack against the PMTUD 1476 mechanism was refined to allow quick discovery of the Path-MTU 1478 o Appendix A was added so as to clarify the operation of the 1479 counter-measure for the attack against the PMTUD mechanism 1481 o Added Appendix D 1483 o Miscellaneous editorial changes 1485 E.4. Changes from draft-gont-tcpm-icmp-attacks-01 1487 o The document was restructured for easier reading 1489 o A discussion of ICMPv6 was added in several sections of the 1490 document 1492 o Added Section on Acknowledgement number checking"/> 1494 o Added Section 4.3 1496 o Added Section 7 1497 o Fixed typo in the ICMP types, in several places 1499 o Fixed typo in the TCP sequence number check formula 1501 o Miscellaneous editorial changes 1503 E.5. Changes from draft-gont-tcpm-icmp-attacks-00 1505 o Added a proposal to change the handling of the so-called ICMP hard 1506 errors during the synchronized states 1508 o Added a summary of the relevant RFCs in several sections 1510 o Miscellaneous editorial changes 1512 Author's Address 1514 Fernando Gont 1515 Universidad Tecnologica Nacional 1516 Evaristo Carriego 2644 1517 Haedo, Provincia de Buenos Aires 1706 1518 Argentina 1520 Phone: +54 11 4650 8472 1521 Email: fernando@gont.com.ar 1523 Intellectual Property Statement 1525 The IETF takes no position regarding the validity or scope of any 1526 Intellectual Property Rights or other rights that might be claimed to 1527 pertain to the implementation or use of the technology described in 1528 this document or the extent to which any license under such rights 1529 might or might not be available; nor does it represent that it has 1530 made any independent effort to identify any such rights. Information 1531 on the procedures with respect to rights in RFC documents can be 1532 found in BCP 78 and BCP 79. 1534 Copies of IPR disclosures made to the IETF Secretariat and any 1535 assurances of licenses to be made available, or the result of an 1536 attempt made to obtain a general license or permission for the use of 1537 such proprietary rights by implementers or users of this 1538 specification can be obtained from the IETF on-line IPR repository at 1539 http://www.ietf.org/ipr. 1541 The IETF invites any interested party to bring to its attention any 1542 copyrights, patents or patent applications, or other proprietary 1543 rights that may cover technology that may be required to implement 1544 this standard. Please address the information to the IETF at 1545 ietf-ipr@ietf.org. 1547 Disclaimer of Validity 1549 This document and the information contained herein are provided on an 1550 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 1551 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 1552 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 1553 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 1554 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1555 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1557 Copyright Statement 1559 Copyright (C) The Internet Society (2005). This document is subject 1560 to the rights, licenses and restrictions contained in BCP 78, and 1561 except as set forth therein, the authors retain all their rights. 1563 Acknowledgment 1565 Funding for the RFC Editor function is currently provided by the 1566 Internet Society.