idnits 2.17.1 draft-ietf-tcpm-icmp-attacks-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 16. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 1770. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1781. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1788. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1794. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The 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.) == There are 1 instance of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust 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 (May 4, 2007) is 6194 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- ** Obsolete normative reference: RFC 793 (Obsoleted by RFC 9293) ** Obsolete normative reference: RFC 1981 (Obsoleted by RFC 8201) ** Obsolete normative reference: RFC 2460 (Obsoleted by RFC 8200) == Outdated reference: A later version (-09) exists of draft-ietf-tcpm-tcp-soft-errors-05 == Outdated reference: A later version (-13) exists of draft-ietf-tcpm-tcpsecure-07 -- 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: 5 errors (**), 0 flaws (~~), 4 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 May 4, 2007 5 Intended status: Informational 6 Expires: November 5, 2007 8 ICMP attacks against TCP 9 draft-ietf-tcpm-icmp-attacks-02.txt 11 Status of this Memo 13 By submitting this Internet-Draft, each author represents that any 14 applicable patent or other IPR claims of which he or she is aware 15 have been or will be disclosed, and any of which he or she becomes 16 aware will be disclosed, in accordance with Section 6 of BCP 79. 18 Internet-Drafts are working documents of the Internet Engineering 19 Task Force (IETF), its areas, and its working groups. Note that 20 other groups may also distribute working documents as Internet- 21 Drafts. 23 Internet-Drafts are draft documents valid for a maximum of six months 24 and may be updated, replaced, or obsoleted by other documents at any 25 time. It is inappropriate to use Internet-Drafts as reference 26 material or to cite them other than as "work in progress." 28 The list of current Internet-Drafts can be accessed at 29 http://www.ietf.org/ietf/1id-abstracts.txt. 31 The list of Internet-Draft Shadow Directories can be accessed at 32 http://www.ietf.org/shadow.html. 34 This Internet-Draft will expire on November 5, 2007. 36 Copyright Notice 38 Copyright (C) The IETF Trust (2007). 40 Abstract 42 This document discusses the use of the Internet Control Message 43 Protocol (ICMP) to perform a variety of attacks against the 44 Transmission Control Protocol (TCP) and other similar protocols. It 45 proposes several counter-measures to eliminate or minimize the impact 46 of these attacks. 48 Table of Contents 50 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 51 2. Background . . . . . . . . . . . . . . . . . . . . . . . . . . 5 52 2.1. The Internet Control Message Protocol (ICMP) . . . . . . . 5 53 2.1.1. ICMP for IP version 4 (ICMP) . . . . . . . . . . . . . 5 54 2.1.2. ICMP for IP version 6 (ICMPv6) . . . . . . . . . . . . 6 55 2.2. Handling of ICMP error messages . . . . . . . . . . . . . 6 56 2.3. Handling of ICMP error messages in the context of IPSec . 7 57 3. Constraints in the possible solutions . . . . . . . . . . . . 8 58 4. General counter-measures against ICMP attacks . . . . . . . . 9 59 4.1. TCP sequence number checking . . . . . . . . . . . . . . . 9 60 4.2. Port randomization . . . . . . . . . . . . . . . . . . . . 10 61 4.3. Filtering ICMP error messages based on the ICMP payload . 10 62 5. Blind connection-reset attack . . . . . . . . . . . . . . . . 11 63 5.1. Description . . . . . . . . . . . . . . . . . . . . . . . 11 64 5.2. Attack-specific counter-measures . . . . . . . . . . . . . 12 65 5.2.1. Changing the reaction to hard errors . . . . . . . . . 12 66 5.2.2. Delaying the connection-reset . . . . . . . . . . . . 15 67 5.2.3. Possible drawbacks of the described solutions . . . . 16 68 6. Blind throughput-reduction attack . . . . . . . . . . . . . . 16 69 6.1. Description . . . . . . . . . . . . . . . . . . . . . . . 16 70 6.2. Attack-specific counter-measures . . . . . . . . . . . . . 17 71 7. Blind performance-degrading attack . . . . . . . . . . . . . . 17 72 7.1. Description . . . . . . . . . . . . . . . . . . . . . . . 17 73 7.2. Attack-specific counter-measures . . . . . . . . . . . . . 19 74 8. Security Considerations . . . . . . . . . . . . . . . . . . . 22 75 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 22 76 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 23 77 10.1. Normative References . . . . . . . . . . . . . . . . . . . 23 78 10.2. Informative References . . . . . . . . . . . . . . . . . . 24 79 Appendix A. The counter-measure for the PMTUD attack in action . 26 80 A.1. Normal operation for bulk transfers . . . . . . . . . . . 27 81 A.2. Operation during Path-MTU changes . . . . . . . . . . . . 28 82 A.3. Idle connection being attacked . . . . . . . . . . . . . . 29 83 A.4. Active connection being attacked after discovery of 84 the Path-MTU . . . . . . . . . . . . . . . . . . . . . . . 30 85 A.5. TCP peer attacked when sending small packets just 86 after the three-way handshake . . . . . . . . . . . . . . 31 87 Appendix B. Pseudo-code for the counter-measure for the blind 88 performance-degrading attack . . . . . . . . . . . . 32 89 Appendix C. Additional considerations for the validation of 90 ICMP error messages . . . . . . . . . . . . . . . . . 35 91 Appendix D. Advice and guidance to vendors . . . . . . . . . . . 36 92 Appendix E. Changes from previous versions of the draft (to 93 be removed by the RFC Editor before publishing 94 this document as an RFC) . . . . . . . . . . . . . . 36 95 E.1. Changes from draft-ietf-tcpm-icmp-attacks-01 . . . . . . . 36 96 E.2. Changes from draft-ietf-tcpm-icmp-attacks-00 . . . . . . . 36 97 E.3. Changes from draft-gont-tcpm-icmp-attacks-05 . . . . . . . 37 98 E.4. Changes from draft-gont-tcpm-icmp-attacks-04 . . . . . . . 37 99 E.5. Changes from draft-gont-tcpm-icmp-attacks-03 . . . . . . . 37 100 E.6. Changes from draft-gont-tcpm-icmp-attacks-02 . . . . . . . 38 101 E.7. Changes from draft-gont-tcpm-icmp-attacks-01 . . . . . . . 38 102 E.8. Changes from draft-gont-tcpm-icmp-attacks-00 . . . . . . . 38 103 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 38 104 Intellectual Property and Copyright Statements . . . . . . . . . . 40 106 1. Introduction 108 ICMP [RFC0792] is a fundamental part of the TCP/IP protocol suite, 109 and is used mainly for reporting network error conditions. However, 110 the current specifications do not recommend any kind of validation 111 checks on the received ICMP error messages, thus allowing variety of 112 attacks against TCP [RFC0793] by means of ICMP, which include blind 113 connection-reset, blind throughput-reduction, and blind performance- 114 degrading attacks. All of these attacks can be performed even being 115 off-path, without the need to sniff the packets that correspond to 116 the attacked TCP connection. 118 While the possible security implications of ICMP have been known in 119 the research community for a long time, there has never been an 120 official proposal on how to deal with these vulnerabiliies. Thus, 121 only a few implementations have implemented validation checks on the 122 received ICMP error messages to minimize the impact of these attacks. 124 Recently, a disclosure process has been carried out by the UK's 125 National Infrastructure Security Co-ordination Centre (NISCC), with 126 the collaboration of other computer emergency response teams. A 127 large number of implementations were found vulnerable to either all 128 or a subset of the attacks discussed in this document 129 [NISCC][US-CERT]. The affected systems ranged from TCP/IP 130 implementations meant for desktop computers, to TCP/IP 131 implementations meant for core Internet routers. 133 It is clear that implementations should be more cautious when 134 processing ICMP error messages, to eliminate or mitigate the use of 135 ICMP to perform attacks against TCP [I-D.iab-link-indications]. 137 This document aims to raise awareness of the use of ICMP to perform a 138 variety of attacks against TCP, and discusses several counter- 139 measures that eliminate or minimize the impact of these attacks. 140 Most of the these counter-measures can be implemented while still 141 remaining compliant with the current specifications, as they simply 142 suggest reasons for not taking the advice provided in the 143 specifications in terms of "SHOULDs", but still comply with the 144 requirements stated as "MUSTs". Section 5.2, Section 6.2, and 145 Section 7.2 include an explanation of the current requirements and 146 advice relevant to each of the attack-specific counter-measures 147 described in this document. 149 Section 2 provides background information on ICMP. Section 3 150 discusses the constraints in the general counter-measures that can be 151 implemented against the attacks described in this document. 152 Section 4 proposes several general validation checks and counter- 153 measures that can be implemented to mitigate any ICMP-based attack. 155 Finally, Section 5, Section 6, and Section 7, discuss a variety of 156 ICMP attacks that can be performed against TCP, and propose attack- 157 specific counter-measures that eliminate or greatly mitigate their 158 impact. 160 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 161 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 162 document are to be interpreted as described in RFC 2119 [RFC2119]. 164 2. Background 166 2.1. The Internet Control Message Protocol (ICMP) 168 The Internet Control Message Protocol (ICMP) is used in the Internet 169 Architecture mainly to perform the fault-isolation function, that is, 170 the group of actions that hosts and routers take to determine that 171 there is some network failure [RFC0816] 173 When an intermediate router detects a network problem while trying to 174 forward an IP packet, it will usually send an ICMP error message to 175 the source system, to raise awareness of the network problem taking 176 place. In the same way, there are a number of scenarios in which an 177 end-system may generate an ICMP error message if it finds a problem 178 while processing a datagram. The received ICMP errors are handed to 179 the corresponding transport-protocol instance, which will usually 180 perform a fault recovery function. 182 It is important to note that ICMP error messages are unreliable, and 183 may be discarded due to data corruption, network congestion or rate- 184 limiting. Thus, while they provide useful information, upper layer 185 protocols cannot depend on ICMP for correct operation. 187 2.1.1. ICMP for IP version 4 (ICMP) 189 [RFC0792] specifies the Internet Control Message Protocol (ICMP) to 190 be used with the Internet Protocol version 4 (IPv4). It defines, 191 among other things, a number of error messages that can be used by 192 end-systems and intermediate systems to report errors to the sending 193 system. The Host Requirements RFC [RFC1122] classifies ICMP error 194 messages into those that indicate "soft errors", and those that 195 indicate "hard errors", thus roughly defining the semantics of them. 197 The ICMP specification [RFC0792] also defines the ICMP Source Quench 198 message (type 4, code 0), which is meant to provide a mechanism for 199 flow control and congestion control. 201 [RFC1191] defines a mechanism called "Path MTU Discovery" (PMTUD), 202 which makes use of ICMP error messages of type 3 (Destination 203 Unreachable), code 4 (fragmentation needed and DF bit set) to allow 204 systems to determine the MTU of an arbitrary internet path. 206 Appendix D of [RFC4301] provides information about which ICMP error 207 messages are produced by hosts, intermediate routers, or both. 209 2.1.2. ICMP for IP version 6 (ICMPv6) 211 [RFC4443] specifies the Internet Control Message Protocol (ICMPv6) to 212 be used with the Internet Protocol version 6 (IPv6) [RFC2460]. 214 [RFC4443] defines the "Packet Too Big" (type 2, code 0) error 215 message, that is analogous to the ICMP "fragmentation needed and DF 216 bit set" (type 3, code 4) error message. [RFC1981] defines the Path 217 MTU Discovery mechanism for IP Version 6, that makes use of these 218 messages to determine the MTU of an arbitrary internet path. 220 Appendix D of [RFC4301] provides information about which ICMPv6 error 221 messages are produced by hosts, intermediate routers, or both. 223 2.2. Handling of ICMP error messages 225 The Host Requirements RFC [RFC1122] states in Section 4.2.3.9 that a 226 TCP MUST act on an ICMP error message passed up from the IP layer, 227 directing it to the connection that elicited the error. 229 In order to allow ICMP messages to be demultiplexed by the receiving 230 system, part of the original packet that elicited the message is 231 included in the payload of the ICMP error message. Thus, the 232 receiving system can use that information to match the ICMP error to 233 the transport protocol instance that elicited it. 235 Neither the Host Requirements RFC [RFC1122] nor the original TCP 236 specification [RFC0793] recommend any validation checks on the 237 received ICMP messages. Thus, as long as the ICMP payload contains 238 the information that identifies an existing communication instance, 239 it will be processed by the corresponding transport-protocol 240 instance, and the corresponding action will be performed. 242 Therefore, in the case of TCP, an attacker could send a forged ICMP 243 message to the attacked system, and, as long as he is able to guess 244 the four-tuple (i.e., Source IP Address, Source TCP port, Destination 245 IP Address, and Destination TCP port) that identifies the 246 communication instance to be attacked, he will be able to use ICMP to 247 perform a variety of attacks. 249 Generally, the four-tuple required to perform these attacks is not 250 known. However, as discussed in [Watson] and 251 [I-D.ietf-tcpm-tcp-antispoof], there are a number of scenarios 252 (notably that of TCP connections established between two BGP routers 253 [RFC4271]), in which an attacker may be able to know or guess the 254 four-tuple that identifies a TCP connection. In such a case, if we 255 assume the attacker knows the two systems involved in the TCP 256 connection to be attacked, both the client-side and the server-side 257 IP addresses could be known or be within a reasonable number of 258 possibilities. Furthermore, as most Internet services use the so- 259 called "well-known" ports, only the client port number might need to 260 be guessed. In such a scenario, an attacker would need to send, in 261 principle, at most 65536 packets to perform any of the attacks 262 described in this document. However, as most systems choose the port 263 numbers they use for outgoing connections from a subset of the whole 264 port number space, the amount of packets needed to successfully 265 perform any of the attacks discussed in this document could be 266 further reduced. 268 It is clear that TCP should be more cautious when processing received 269 ICMP error messages, in order to mitigate or eliminate the impact of 270 the attacks described in this document [I-D.iab-link-indications]. 272 2.3. Handling of ICMP error messages in the context of IPSec 274 Section 5.2 of [RFC4301] describes the processing inbound IP Traffic 275 in the case of "unprotected-to-protected". In the case of ICMP, when 276 an unprotected ICMP error message is received, it is matched to the 277 corresponding security association by means of the SPI (Security 278 Parameters Index) included in the payload of the ICMP error message. 279 Then, local policy is applied to determine whether to accept or 280 reject the message and, if accepted, what action to take as a result. 281 For example, if an ICMP unreachable message is received, the 282 implementation must decide whether to act on it, reject it, or act on 283 it with constraints. Section 8 ("Path MTU/DF processing") discusses 284 the processing of unauthenticated ICMP "fragmentation needed and DF 285 bit set" (type 3, code 3) and ICMPv6 "Packet Too Big" (type 2, code 286 0) messages when an IPsec implementation receives is configured to 287 process (vs. ignore) such messages. 289 Section 6.1.1 of [RFC4301] notes that processing of unauthenticated 290 ICMP error messages may result in denial or degradation of service, 291 and therefore it would be desirable to ignore such messages. 292 However, it also notes that in many cases ignoring these ICMP 293 messages can degrade service, e.g., because of a failure to process 294 PMTU message and redirection messages, and therefore there is also a 295 motivation for accepting and acting upon them. It finally states 296 that to accommodate both ends of this spectrum, a compliant IPsec 297 implementation MUST permit a local administrator to configure an 298 IPsec implementation to accept or reject unauthenticated ICMP 299 traffic, and that this control MUST be at the granularity of ICMP 300 type and MAY be at the granularity of ICMP type and code. 301 Additionally, an implementation SHOULD incorporate mechanisms and 302 parameters for dealing with such traffic. 304 Thus, the policy to apply for the processing of unprotected ICMP 305 error messages is left up to the implementation and administrator. 307 3. Constraints in the possible solutions 309 For ICMPv4, [RFC0792] states that the internet header plus the first 310 64 bits of the packet that elicited the ICMP message are to be 311 included in the payload of the ICMP error message. Thus, it is 312 assumed that all data needed to identify a transport protocol 313 instance and process the ICMP error message is contained in the first 314 64 bits of the transport protocol header. Section 3.2.2 of [RFC1122] 315 states that "the Internet header and at least the first 8 data octets 316 of the datagram that triggered the error" are to be included in the 317 payload of ICMP error messages, and that "more than 8 octets MAY be 318 sent", thus allowing implementations to include more data from the 319 original packet than those required by the original ICMP 320 specification. The Requirements for IP Version 4 Routers RFC 321 [RFC1812] states that ICMP error messages "SHOULD contain as much of 322 the original datagram as possible without the length of the ICMP 323 datagram exceeding 576 bytes". 325 Thus, for ICMP messages generated by hosts, we can only expect to get 326 the entire IP header of the original packet, plus the first 64 bits 327 of its payload. For TCP, this means that the only fields that will 328 be included in the ICMP payload are: the source port number, the 329 destination port number, and the 32-bit TCP sequence number. This 330 clearly imposes a constraint on the possible validation checks that 331 can be performed, as there is not much information avalable on which 332 to perform them. 334 This means, for example, that even if TCP were signing its segments 335 by means of the TCP MD5 signature option [RFC2385], this mechanism 336 could not be used as a counter-measure against ICMP-based attacks, 337 because, as ICMP messages include only a piece of the TCP segment 338 that elicited the error, the MD5 [RFC1321] signature could not be 339 recalculated. In the same way, even if the attacked peer were 340 authenticating its packets at the IP layer [RFC4301], because only a 341 part of the original IP packet would be available, the signature used 342 for authentication could not be recalculated, and thus this mechanism 343 could not be used as a counter-measure aganist ICMP-based attacks 344 against TCP. 346 For IPv6, the payload of ICMPv6 error messages includes as many 347 octets from the IPv6 packet that elicited the ICMPv6 error message as 348 will fit without making the resulting ICMPv6 packet exceed the 349 minimum IPv6 MTU (1280 octets) [RFC4443]. Thus, more information is 350 available than in the IPv4 case. 352 Hosts could require ICMP error messages to be authenticated 353 [RFC4301], in order to act upon them. However, while this 354 requirement could make sense for those ICMP error messages sent by 355 hosts, it would not be feasible for those ICMP error messages 356 generated by routers, as this would imply either that the attacked 357 system should have a security association [RFC4301] with every 358 existing intermediate system, or that it should be able to establish 359 one dynamically. Current levels of protocol deployment for dynamic 360 establishment of security associations makes this unfeasible. Also, 361 there may be some cases, such as embedded devices, in which the 362 processing power requirements of authentication could not allow IPSec 363 authentication to be implemented effectively. 365 Additional considerations for the validation of ICMP error messages 366 can be found in Appendix C 368 4. General counter-measures against ICMP attacks 370 There are a number of counter-measures that can be implemented to 371 eliminate or mitigate the impact of the attacks discussed in this 372 document. Rather than being alternative counter-measures, they can 373 be implemented together to increase the protection against these 374 attacks. In particular, all TCP implementations should perform the 375 TCP sequence number checking described in Section 4.1. 377 4.1. TCP sequence number checking 379 The current specifications do not impose any validity checks on the 380 TCP segment that is contained in the ICMP payload. For instance, no 381 checks are performed to verify that a received ICMP error message has 382 been elicited by a segment that was "in flight" to the destination. 383 Thus, even stale ICMP error messages will be acted upon. 385 TCP should check that the TCP sequence number contained in the 386 payload of the ICMP error message is within the range SND.UNA =< 387 SEG.SEQ < SND.NXT. This means that the sequence number should be 388 within the range of the data already sent but not yet acknowledged. 389 If an ICMP error message does not pass this check, it should be 390 discarded. 392 Even if an attacker were able to guess the four-tuple that identifies 393 the TCP connection, this additional check would reduce the 394 possibility of considering a spoofed ICMP packet as valid to 395 Flight_Size/2^^32 (where Flight_Size is the number of data bytes 396 already sent to the remote peer, but not yet acknowledged [RFC2581]). 397 For connections in the SYN-SENT or SYN-RECEIVED states, this would 398 reduce the possibility of considering a spoofed ICMP packet as valid 399 to 1/2^^32. For a TCP endpoint with no data "in flight", this would 400 completely eliminate the possibility of success of these attacks. 402 This validation check has been implemented in Linux [Linux] for many 403 years, in OpenBSD [OpenBSD] since 2004, and in FreeBSD [FreeBSD] and 404 NetBSD [NetBSD] since 2005. 406 It is important to note that while this check greatly increases the 407 number of packets required to perform any of the attacks discussed in 408 this document, this may not be enough in those scenarios in which 409 bandwidth is easily available, and/or large TCP windows [RFC1323] are 410 in use. Therefore, implementation of the attack-specific counter- 411 measures discussed in this document is strongly recommended. 413 A TCP that implements the TCP sequence number checking as the only 414 validation of ICMP error messages will have the same susceptibility 415 to attacks as the one TCP currently has in the case of TCP-based 416 attacks. Further information on this issue can be found in 417 [I-D.ietf-tcpm-tcp-antispoof]. 419 4.2. Port randomization 421 As discussed in the previous sections, in order to perform any of the 422 attacks described in this document, an attacker would need to guess 423 (or know) the four-tuple that identifies the connection to be 424 attacked. Increasing the port number range used for outgoing TCP 425 connections, and randomizing the port number chosen for each outgoing 426 TCP conenctions would make it harder for an attacker to perform any 427 of the attacks discussed in this document. 429 [I-D.larsen-tsvwg-port-randomisation] discusses a number of 430 algorithms to randomize the ephemeral ports used by clients. 432 4.3. Filtering ICMP error messages based on the ICMP payload 434 The source address of ICMP error messages does not need to be spoofed 435 to perform the attacks described in this document. Therefore, simple 436 filtering based on the source address of ICMP error messages does not 437 serve as a counter-measure against these attacks. However, a more 438 advanced packet filtering could be implemented in middlebox devices 439 such as firewalls and NATs as a counter-measure. Middleboxes 440 implementing such advanced filtering would look at the payload of the 441 ICMP error messages, and would perform ingress and egress packet 442 filtering based on the source IP address of the IP header contained 443 in the payload of the ICMP error message. As the source IP address 444 contained in the payload of the ICMP error message does need to be 445 spoofed to perform the attacks described in this document, this kind 446 of advanced filtering would serve as a counter-measure against these 447 attacks. As with traditional egress filtering [IP-filtering], egress 448 filtering based on the ICMP payload can help to prevent users of the 449 network being protected by the firewall from successfully performing 450 ICMP attacks against TCP connections established between external 451 systems. Additionally, ingress filtering based on the ICMP payload 452 can prevent TCP connections established between internal systems from 453 attacks performed by external systems. [ICMP-Filtering] provides 454 examples of ICMP filtering based on the ICMP payload. 456 This filtering has been implemented in OpenBSD's Packet Filter 457 [OpenBSD-PF], which has in turn been ported to a number of systems, 458 including FreeBSD [FreeBSD]. 460 5. Blind connection-reset attack 462 5.1. Description 464 When TCP is handed an ICMP error message, it will perform its fault 465 recovery function, as follows: 467 o If the network problem being reported is a hard error, TCP will 468 abort the corresponding connection. 470 o If the network problem being reported is a soft error, TCP will 471 just record this information, and repeatedly retransmit its data 472 until they either get acknowledged, or the connection times out. 474 The Host Requirements RFC [RFC1122] states (in Section 4.2.3.9) that 475 a host SHOULD abort the corresponding connection when receiving an 476 ICMP error message that indicates a "hard error", and states that 477 ICMP error messages of type 3 (Destination Unreachable) codes 2 478 (protocol unreachable), 3 (port unreachable), and 4 (fragmentation 479 needed and DF bit set) should be considered to indicate hard errors. 480 In the case of ICMP port unreachables, the specifications are 481 ambiguous, as Section 4.2.3.9 of [RFC1122] states that TCP SHOULD 482 abort the corresponding connection in response to them, but Section 483 3.2.2.1 of the same RFC ([RFC1122] states that TCP MUST abort the 484 connection in response to them. 486 While [RFC4443] did not exist when [RFC1122] was published, one could 487 extrapolate the concept of "hard errors" to ICMPv6 error messages of 488 type 1 (Destination unreachable) codes 1 (communication with 489 destination administratively prohibited), and 4 (port unreachable). 491 Thus, an attacker could use ICMP to perform a blind connection-reset 492 attack by sending any ICMP error message that indicates a "hard 493 error", to either of the two TCP endpoints of the connection. 494 Because of TCP's fault recovery policy, the connection would be 495 immediately aborted. 497 Some stacks are known to extrapolate ICMP hard errors across TCP 498 connections, increasing the impact of this attack, as a single ICMP 499 packet could bring down all the TCP connections between the 500 corresponding peers. 502 It is important to note that even if TCP itself were protected 503 against the blind connection-reset attack described in [Watson] and 504 [I-D.ietf-tcpm-tcpsecure], by means authentication at the network 505 layer [RFC4301], by means of the TCP MD5 signature option [RFC2385], 506 or by means of the mechanism proposed in [I-D.ietf-tcpm-tcpsecure], 507 the blind connection-reset attack described in this document would 508 still succeed. 510 5.2. Attack-specific counter-measures 512 The Host Requirements RFC [RFC1122] states in Section 4.2.3.9 that 513 TCP SHOULD abort the corresponding connection in response to ICMP 514 messages of type 3, codes 2 (protocol unreachable), 3 (port 515 unreachable), and 4 (fragmentation needed and DF bit set). However, 516 Section 3.2.2.1 states that TCP MUST accept an ICMP port unreachable 517 (type 3, code 3) for the same purpose as an RST. Therefore, for ICMP 518 messages of type 3 codes 2 and 4 there is room to go against the 519 advice provided in the existing specifications, while in the case of 520 ICMP messages of type 3 code 3 the ambiguity in the specification 521 also allows us to go against the advice provided by the existing 522 specifications, while still remaining compliant with them. Given the 523 hostile environments in which TCP currently operates in, and that 524 advice ICMP provides an attack vector that is easier to exploit than 525 others (such as those discussed in [I-D.ietf-tcpm-tcpsecure]), we 526 believe that the improvements in TCP's resistance to these attacks 527 justify not taking the advice provided by the "SHOULDs" in [RFC1122]. 529 5.2.1. Changing the reaction to hard errors 531 An analysis of the circumstances in which ICMP messages that indicate 532 hard errors may be received can shed some light to eliminate the 533 impact of ICMP-based blind connection-reset attacks. 535 ICMP type 3 (Destination Unreachable), code 2 (protocol unreachable) 537 This ICMP error message indicates that the host sending the ICMP 538 error message received a packet meant for a transport protocol it 539 does not support. For connection-oriented protocols such as TCP, 540 one could expect to receive such an error as the result of a 541 connection-establishment attempt. However, it would be strange to 542 get such an error during the life of a connection, as this would 543 indicate that support for that transport protocol has been removed 544 from the system sending the error message during the life of the 545 corresponding connection. Thus, it would be fair to treat ICMP 546 protocol unreachable error messages as soft errors if they are 547 meant for connections that are in synchronized states. For TCP, 548 this means TCP would treat ICMP protocol unreachable error 549 messages as soft errors if they are meant for connections that are 550 in any of the synchronized states (ESTABLISHED, FIN-WAIT-1, FIN- 551 WAIT-2, CLOSE-WAIT, CLOSING, LAST-ACK or TIME-WAIT). 553 ICMP type 3 (Destination Unreachable), code 3 (port unreachable) 555 This error message indicates that the system sending the ICMP 556 error message received a packet meant for a socket (IP address, 557 port number) on which there is no process listening. Those 558 transport protocols which have their own mechanisms for notifying 559 this condition should not be receiving these error messages, as 560 the protocol would signal the port unreachable condition by means 561 of its own messages. Assuming that once a connection is 562 established it is not usual for the transport protocol to change 563 (or be reloaded), it would be fair to treat ICMP port unreachable 564 messages as soft errors when they are meant for a TCP that is in 565 any of the synchronized states (ESTABLISHED, FIN-WAIT-1, 566 FIN-WAIT-2, CLOSE-WAIT, CLOSING, LAST-ACK or TIME-WAIT). 568 ICMP type 3 (Destination Unreachable), code 4 (fragmentation needed 569 and DF bit set) 571 This error message indicates that an intermediate node needed to 572 fragment a datagram, but the DF (Don't Fragment) bit in the IP 573 header was set. It is considered a soft error when TCP implements 574 PMTUD, and a hard error if TCP does not implement PMTUD. Those 575 systems that do not implement the PMTUD mechanism should not be 576 sending their IP packets with the DF bit set, and thus should not 577 be receiving these ICMP error messages. Thus, it would be fair 578 for TCPs in any of the synchronized states to treat this ICMP 579 error message as indicating a soft error, therefore not aborting 580 the corresponding connection when such an error message is 581 received. For obvious reasons, those systems implementing the 582 Path-MTU Discovery (PMTUD) mechanism [RFC1191] should not abort 583 the corresponding connection when such an ICMP error message is 584 received. 586 ICMPv6 type 1 (Destination Unreachable), code 1 (communication with 587 destination administratively prohibited) 589 This error message indicates that the destination is unreachable 590 because of an administrative policy. For connection-oriented 591 protocols such as TCP, one could expect to receive such an error 592 as the result of a connection-establishment attempt. Receiving 593 such an error for a connection in any of the synchronized states 594 would mean that the administrative policy changed during the life 595 of the connection. However, there is no reason to think that in 596 the same way this error condition appeared, it will not get solved 597 in the near term. Therefore, while it would be possible for a 598 firewall to be reconfigured during the life of a connection, it 599 would be fair, for security reasons, to treat these messages as 600 soft errors when they are meant for connections that are in any of 601 the synchronized states (ESTABLISHED, FIN-WAIT-1, FIN-WAIT-2, 602 CLOSE-WAIT, CLOSING, LAST-ACK or TIME-WAIT states). 604 ICMPv6 type 1 (Destination Unreachable), code 4 (port unreachable) 606 This error message is analogous to the ICMP type 3 (Destination 607 Unreachable), code 3 (Port unreachable) error message discussed 608 above. Therefore, the same considerations apply. 610 Therefore, when following the reasoning explained above, TCPs in 611 synchronized states would treat all of the above messages as 612 indicating "soft errors", rather than "hard errors", and thus would 613 not abort the corresponding connection upon receipt of them. This is 614 policy is based on the premise that TCP should be as robust as 615 possible. Reaction to these messages when they are meant for 616 connections in non-synchronized states could still remain as adviced 617 by [RFC1122], as we consider the attack window for connections in the 618 non-synchronized states is very small, and error messages received in 619 these states are more likely indicate that the connection was opened 620 improperly [RFC0816]. Additionally, for the sake of robustness and 621 security, those implementations following the reasoning explained in 622 this section would not extrapolate ICMP errors across TCP 623 connections. 625 In case the received message were legitimate, it would mean that the 626 error condition appeared during the life of the corresponding 627 connection. However, in many scenarios there is no reason to think 628 that in the same way this error condition appeared, it will not get 629 solved in the near term. Therefore, treating the received ICMP error 630 messages as "soft errors" would make TCP more robust, and could avoid 631 TCP from aborting a TCP connection unnecesarily. Aborting the 632 connection would be to ignore the valuable feature of the Internet 633 that for many internal failures it reconstructs its function without 634 any disruption of the end points [RFC0816]. 636 One scenario in which a host would benefit from treating the so- 637 called ICMP "hard errors" as "soft errors" would be that in which the 638 packets that correspond to a given TCP connection are routed along 639 multiple different paths. Some (but not all) of these paths may be 640 experiencing an error condition, and therefore generating the so- 641 called ICMP hard errors. However, communication should survive if 642 there is still a working path to the destination system [DClark]. 643 Thus, treating the so-called "hard errors" as "soft errors" when a 644 connection is in any of the synchronized states would make TCP 645 achieve this goal. 647 It is interesting to note that, as ICMP error messages are 648 unreliable, transport protocols should not depend on them for correct 649 functioning. In the event one of these messages were legitimate, the 650 corresponding connection would eventually time out. Also, 651 applications may still be notified asynchronously about the received 652 error messages, and thus may still abort their connections on their 653 own if they consider it appropriate. 655 This counter-measure has been implemented in BSD-derived TCP/IP 656 implementations (e.g., [FreeBSD], [NetBSD], and [OpenBSD]) for more 657 than ten years [Wright][McKusick]. The Linux kernel has also 658 implemented this policy for more than ten years [Linux]. 660 5.2.2. Delaying the connection-reset 662 An alternative counter-measure would be, in the case of connections 663 in any of the synchronized states, to honor the ICMP error messages 664 only if there is no progress on the connection. Rather than 665 immediately aborting a connection, a TCP would abort a connection 666 only after an ICMP error message indicating a hard error has been 667 received, and the corresponding data have already been retransmitted 668 more than some specified number of times. 670 The rationale behind this proposed fix is that if a host can make 671 forward progress on a connection, it can completely disregard the 672 "hard errors" being indicated by the received ICMP error messages. 674 While this counter-measure could be useful, we think that the 675 counter-measure discussed in Section 5.2.1 is easier to implement, 676 and provides increased protection against this type of attack. 678 5.2.3. Possible drawbacks of the described solutions 680 In scenarios such as that in which an intermediate system sets the DF 681 bit in the segments transmitted by a TCP that does not implement 682 PMTUD, or the TCP at one of the endpoints of the connection is 683 dynamically disabled, TCP would only abort the connection after a 684 USER TIMEOUT [RFC0793], losing responsiveness. However, we consider 685 these senarios very unlikely in production environments, and consider 686 that it is preferebable to potentially lose responsiveness for the 687 sake of robustness. It should also be noted that applications may 688 still be notified asynchronously about the received error messages, 689 and thus may still abort their connections on their own if they 690 consider it appropriate. 692 In scenarios of multipath routing or route changes, failures in some 693 (but not all) of the paths may elicit ICMP error messages that would 694 likely not cause a connection abort if any of the counter-measures 695 described in this section were implemented. However, as explained 696 above, aborting the connection would be to ignore the valuable 697 feature of the Internet that for many internal failures it 698 reconstructs its function without any disruption of the end points 699 [RFC0816]. Additionally, applications may still be notified 700 asynchronously about the received error messages, and thus may still 701 abort their connections on their own if they consider it appropriate. 703 6. Blind throughput-reduction attack 705 6.1. Description 707 The Host requirements RFC [RFC1122] states that hosts MUST react to 708 ICMP Source Quench messages by slowing transmission on the 709 connection. Thus, an attacker could send ICMP Source Quench (type 4, 710 code 0) messages to a TCP endpoint to make it reduce the rate at 711 which it sends data to the other end-point of the connection. 712 [RFC1122] further adds that the RECOMMENDED procedure is to put the 713 corresponding connection in the slow-start phase of TCP's congestion 714 control algorithm [RFC2581]. In the case of those implementations 715 that use an initial congestion window of one segment, a sustained 716 attack would reduce the throughput of the attacked connection to 717 about SMSS (Sender Maximum Segment Size) [RFC2581] bytes per RTT 718 (round-trip time). The throughput achieved during attack might be a 719 little higher if a larger initial congestion window is in use 720 [RFC3390]. 722 6.2. Attack-specific counter-measures 724 The Host Requirements RFC [RFC1122] states in Section 4.2.3.9 that 725 hosts MUST react to ICMP Source Quench messages by slowing 726 transmission on the connection. Therefore, the only counter-measures 727 for this attack that can be implemented while still remaining 728 compliant with the existing specifications are the ones discussed in 729 Section 4. 731 Nevertheless, it must be noted that, as discussed in the Requirements 732 for IP Version 4 Routers RFC [RFC1812], research seems to suggest 733 that ICMP Source Quench is an ineffective (and unfair) antidote for 734 congestion. [RFC1812] further states that routers SHOULD NOT send 735 ICMP Source Quench messages in response to congestion. On the other 736 hand, TCP implements its own congestion control mechanisms [RFC2581] 737 [RFC3168], that do not depend on ICMP Source Quench messages. 739 Based on this reasoning, a large number of implementations completely 740 ignore ICMP Source Quench messages meant for TCP connections. This 741 behavior has been implemented in, at least, Linux [Linux] since 2004, 742 and in FreeBSD [FreeBSD], NetBSD [NetBSD], and OpenBSD [OpenBSD] 743 since 2005. However, as explained earlier in this section, this 744 behaviour violates the requirement in [RFC1122] to react to ICMP 745 Source Quench messages by slowing transmission on the connection. 747 7. Blind performance-degrading attack 749 7.1. Description 751 When one IP system has a large amount of data to send to another 752 system, the data will be transmitted as a series of IP datagrams. It 753 is usually preferable that these datagrams be of the largest size 754 that does not require fragmentation anywhere along the path from the 755 source to the destination. This datagram size is referred to as the 756 Path MTU (PMTU), and is equal to the minimum of the MTUs of each hop 757 in the path. A technique called "Path MTU Discovery" (PMTUD) lets IP 758 systems determine the Path MTU of an arbitrary internet path. 759 [RFC1191] and [RFC1981] specify the PMTUD mechanism for IPv4 and 760 IPv6, respectively. 762 The PMTUD mechanism for IPv4 uses the Don't Fragment (DF) bit in the 763 IP header to dynamically discover the Path MTU. The basic idea 764 behind the PMTUD mechanism is that a source system assumes that the 765 MTU of the path is that of the first hop, and sends all its datagrams 766 with the DF bit set. If any of the datagrams is too large to be 767 forwarded without fragmentation by some intermediate router, the 768 router will discard the corresponding datagram, and will return an 769 ICMP "Destination Unreachable" (type 3) "fragmentation neeed and DF 770 set" (code 4) error message to the sending system. This message will 771 report the MTU of the constricting hop, so that the sending system 772 can reduce the assumed Path-MTU accordingly. 774 For IPv6, intermediate systems do not fragment packets. Thus, 775 there's an "implicit" DF bit set in every packet sent on a network. 776 If any of the datagrams is too large to be forwarded without 777 fragmentation by some intermediate router, the router will discard 778 the corresponding datagram, and will return an ICMPv6 "Packet Too 779 Big" (type 2, code 0) error message to sending system. This message 780 will report the MTU of the constricting hop, so that the sending 781 system can reduce the assumed Path-MTU accordingly. 783 As discussed in both [RFC1191] and [RFC1981], the Path-MTU Discovery 784 mechanism can be used to attack TCP. An attacker could send a forged 785 ICMP "Destination Unreachable, fragmentation needed and DF set" 786 packet (or their ICMPv6 counterpart) to the sending system, 787 advertising a small Next-Hop MTU. As a result, the attacked system 788 would reduce the size of the packets it sends for the corresponding 789 connection accordingly. 791 The effect of this attack is two-fold. On one hand, it will increase 792 the headers/data ratio, thus increasing the overhead needed to send 793 data to the remote TCP end-point. On the other hand, if the attacked 794 system wanted to keep the same throughput it was achieving before 795 being attacked, it would have to increase the packet rate. On 796 virtually all systems this will lead to an increase in the IRQ 797 (Interrrupt ReQuest) rate, thus increasing processor utilization, and 798 degrading the overall system performance. 800 A particular scenario that may take place is that in which an 801 attacker reports a Next-Hop MTU smaller than or equal to the amount 802 of bytes needed for headers (IP header, plus TCP header). For 803 example, if the attacker reports a Next-Hop MTU of 68 bytes, and the 804 amount of bytes used for headers (IP header, plus TCP header) is 805 larger than 68 bytes, the assumed Path-MTU will not even allow the 806 attacked system to send a single byte of application data without 807 fragmentation. This particular scenario might lead to unpredictable 808 results. Another posible scenario is that in which a TCP connection 809 is being secured by means of IPSec. If the Next-Hop MTU reported by 810 the attacker is smaller than the amount of bytes needed for headers 811 (IP and IPSec, in this case), the assumed Path-MTU will not even 812 allow the attacked system to send a single byte of the TCP header 813 without fragmentation. This is another scenario that may lead to 814 unpredictable results. 816 For IPv4, the reported Next-Hop MTU could be as low as 68 octets, as 818 [RFC0791] requires every internet module to be able to forward a 819 datagram of 68 octets without further fragmentation. For IPv6, the 820 reported Next-Hop MTU could be as low as 1280 octets (the minimum 821 IPv6 MTU) [RFC2460]. 823 7.2. Attack-specific counter-measures 825 This section describes a modification to the PMTUD mechanism 826 specified in [RFC1191] and [RFC1981] that has been implemented in a 827 variety of TCP implementations to improve TCP's resistance to the 828 blind performance-degrading attack described in Section 7.1. The 829 described mechanism basically disregards ICMP messages when a 830 connection makes progress. This modification does not violate any of 831 the requirements stated in [RFC1191] and [RFC1981]. 833 Henceforth, we will refer to both ICMP "fragmentation needed and DF 834 bit set" and ICMPv6 "Packet Too Big" messages as "ICMP Packet Too 835 Big" messages. 837 In addition to the general validation check described in Section 4.1, 838 a counter-measure similar to that described in Section 5.2.2 could be 839 implemented to greatly minimize the impact of this attack. 841 This would mean that upon receipt of an ICMP "Packet Too Big" error 842 message, TCP would just record this information, and would honor it 843 only when the corresponding data had already been retransmitted a 844 specified number of times. 846 While this policy would greatly mitigate the impact of the attack 847 against the PMTUD mechanism, it would also mean that it might take 848 TCP more time to discover the Path-MTU for a TCP connection. This 849 would be particularly annoying for connections that have just been 850 established, as it might take TCP several transmission attempts (and 851 the corresponding timeouts) before it discovers the PMTU for the 852 corresponding connection. Thus, this policy would increase the time 853 it takes for data to begin to be received at the destination host. 855 We would like to protect TCP from the attack against the PMTUD 856 mechanism, while still allowing TCP to quickly determine the initial 857 Path-MTU for a connection. 859 To achieve both goals, we can divide the traditional PMTUD mechanism 860 into two stages: Initial Path-MTU Discovery, and Path-MTU Update. 862 The Initial Path-MTU Discovery stage is when TCP tries to send 863 segments that are larger than the ones that have so far been sent and 864 acknowledged for this connection. That is, in the Initial Path-MTU 865 Discovery stage TCP has no record of these large segments getting to 866 the destination host, and thus it would be fair to believe the 867 network when it reports that these packets are too large to reach the 868 destination host without being fragmented. 870 The Path-MTU Update stage is when TCP tries to send segments that are 871 equal to or smaller than the ones that have already been sent and 872 acknowledged for this connection. During the Path-MTU Update stage, 873 TCP already has knowledge of the estimated Path-MTU for the given 874 connection. Thus, it would be fair to be more cautious with the 875 errors being reported by the network. 877 In order to allow TCP to distinguish segments between those 878 performing Initial Path-MTU Discovery and those performing Path-MTU 879 Update, two new variables should be introduced to TCP: maxsizeacked 880 and maxsizesent. 882 maxsizesent would hold the size (in octets) of the largest packet 883 that has so far been sent for this connection. It would be 884 initialized to 68 (the minimum IPv4 MTU) when the underlying internet 885 protocol is IPv4, and would be initialized to 1280 (the minimum IPv6 886 MTU) when the underlying internet protocol is IPv6. Whenever a 887 packet larger than maxsizesent octets is sent, maxsizesent should be 888 set to that value. 890 On the other hand, maxsizeacked would hold the size (in octets) of 891 the largest packet that has so far been acknowledged for this 892 connection. It would be initialized to 68 (the minimum IPv4 MTU) 893 when the underlying internet protocol is IPv4, and would be 894 initialized to 1280 (the minimum IPv6 MTU) when the underlying 895 internet protocol is IPv6. Whenever an acknowledgement for a packet 896 larger than maxsizeacked octets is received, maxsizeacked should be 897 set to the size of that acknowledged packet. 899 Upon receipt of an ICMP "Packet Too Big" error message, the Next-Hop 900 MTU claimed by the ICMP message (henceforth "claimedmtu") should be 901 compared with maxsizesent. If claimedmtu is equal to or larger than 902 maxsizesent, then the ICMP error message should be silently 903 discarded. The rationale for this is that the ICMP error message 904 cannot be legitimate if it claims to have been elicited by a packet 905 larger than the largest packet we have so far sent for this 906 connection. 908 If this check is passed, claimedmtu should be compared with 909 maxsizeacked. If claimedmtu is equal to or larger than maxsizeacked, 910 TCP is supposed to be at the Initial Path-MTU Discovery stage, and 911 thus the ICMP "Packet Too Big" error message should be honored 912 immediately. That is, the assumed Path-MTU should be updated 913 according to the Next-Hop MTU claimed in the ICMP error message. 915 Also, maxsizesent should be reset to the minimum MTU of the internet 916 protocol in use (68 for IPv4, and 1280 for IPv6). 918 On the other hand, if claimedmtu is smaller than maxsizeacked, TCP is 919 supposed to be in the Path-MTU Update stage. At this stage, we 920 should be more cautious with the errors being reported by the 921 network, and should therefore just record the received error message, 922 and delay the update of the assumed Path-MTU. 924 To perform this delay, one new variable and one new parameter should 925 be introduced to TCP: nsegrto and MAXSEGRTO. nsegrto will hold the 926 number of times a specified segment has timed out. It should be 927 initialized to zero, and should be incremented by one everytime the 928 corresponding segment times out. MAXSEGRRTO should specify the 929 number of times a given segment must timeout before an ICMP "Packet 930 Too Big" error message can be honored, and can be set, in principle, 931 to any value greater than or equal to 0. 933 Thus, if nsegrto is greater than or equal to MAXSEGRTO, and there's a 934 pending ICMP "Packet Too Big" error message, the correspoing error 935 message should be processed. At that point, maxsizeacked should be 936 set to claimedmtu, and maxsizesent should be set to 68 (for IPv4) or 937 1280 (for IPv6). 939 If while there is a pending ICMP "Packet Too Big" error message the 940 TCP SEQ claimed by the pending message is acknowledged (i.e., an ACK 941 that acknowledges that sequence number is received), then the 942 "pending error" condition should be cleared. 944 The rationale behind performing this delayed processing of ICMP 945 "Packet Too Big" messages is that if there is progress on the 946 connection, the ICMP "Packet Too Big" errors must be a false claim. 947 By checking for progress on the connection, rather than just for 948 staleness of the received ICMP messages, TCP is protected from attack 949 even if the offending ICMP messages are "in window", and as a 950 corollary, is made more robust to spurious ICMP messages elicited by, 951 for example, corrupted TCP segments. 953 MAXSEGRTO can be set, in principle, to any value greater than or 954 equal to 0. Setting MAXSEGRTO to 0 would make TCP perform the 955 traditional PMTUD mechanism defined in [RFC1191] and [RFC1981]. A 956 MAXSEGRTO of 1 should provide enough protection for most cases. In 957 any case, implementations are free to choose higher values for this 958 constant. MAXSEGRTO could be a function of the Next-Hop MTU claimed 959 in the received ICMP "Packet Too Big" message. That is, higher 960 values for MAXSEGRTO could be imposed when the received ICMP "Packet 961 Too Big" message claims a Next-Hop MTU that is smaller than some 962 specified value. 964 In the event a higher level of protection is desired at the expense 965 of a higher delay in the discovery of the Path-MTU, an implementation 966 could consider TCP to always be in the Path-MTU Update stage, thus 967 always delaying the update of the assumed Path-MTU. 969 Appendix A shows the proposed counter-measure in action. Appendix B 970 shows the proposed counter-measure in pseudo-code. 972 This behavior has been implemented in NetBSD [NetBSD] and OpenBSD 973 [OpenBSD] since 2005. 975 It is important to note that the mechanism proposed in this section 976 is an improvement to the current Path-MTU discovery mechanism, to 977 mitigate its security implications. The current PMTUD mechanism, as 978 specified by [RFC1191] and [RFC1981], still suffers from some 979 functionality problems [RFC2923] that this document does not aim to 980 address. A mechanism that addresses those issues is described in 981 [I-D.ietf-pmtud-method]. 983 8. Security Considerations 985 This document describes the use of ICMP error messages to perform a 986 number of attacks against the TCP protocol, and proposes a number of 987 counter-measures that either eliminate or reduce the impact of these 988 attacks. 990 9. Acknowledgements 992 This document was inspired by Mika Liljeberg, while discussing some 993 issues related to [I-D.ietf-tcpm-tcp-soft-errors] by private e-mail. 994 The author would like to thank Bora Akyol, Mark Allman, Ran Atkinson, 995 James Carlson, Alan Cox, Theo de Raadt, Ted Faber, Juan Fraschini, 996 Markus Friedl, Guillermo Gont, John Heffner, Vivek Kakkar, Michael 997 Kerrisk, Mika Liljeberg, Matt Mathis, David Miller, Miles Nordin, 998 Eloy Paris, Kacheong Poon, Andrew Powell, Pekka Savola, Pyda 999 Srisuresh, Fred Templin, Joe Touch, and Andres Trapanotto, for 1000 contributing many valuable comments. 1002 Juan Fraschini and the author of this document implemented freely- 1003 available audit tools to help vendors audit their systems by 1004 reproducing the attacks discussed in this document. 1006 Markus Friedl, Chad Loder, and the author of this document, produced 1007 and tested in OpenBSD [OpenBSD] the first implementation of the 1008 counter-measure described in Section 7.2. This first implementation 1009 helped to test the effectiveness of the ideas introduced in this 1010 document, and has served as a reference implementation for other 1011 operating systems. 1013 The author would like to thank the UK's National Infrastructure 1014 Security Co-ordination Centre (NISCC) for coordinating the disclosure 1015 of these issues with a large number of vendors and CSIRTs (Computer 1016 Security Incident Response Teams). 1018 The author wishes to express deep and heartfelt gratitude to Jorge 1019 Oscar Gont and Nelida Garcia, for their precious motivation and 1020 guidance. 1022 10. References 1024 10.1. Normative References 1026 [RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791, 1027 September 1981. 1029 [RFC0792] Postel, J., "Internet Control Message Protocol", STD 5, 1030 RFC 792, September 1981. 1032 [RFC0793] Postel, J., "Transmission Control Protocol", STD 7, 1033 RFC 793, September 1981. 1035 [RFC1122] Braden, R., "Requirements for Internet Hosts - 1036 Communication Layers", STD 3, RFC 1122, October 1989. 1038 [RFC1191] Mogul, J. and S. Deering, "Path MTU discovery", RFC 1191, 1039 November 1990. 1041 [RFC1812] Baker, F., "Requirements for IP Version 4 Routers", 1042 RFC 1812, June 1995. 1044 [RFC1981] McCann, J., Deering, S., and J. Mogul, "Path MTU Discovery 1045 for IP version 6", RFC 1981, August 1996. 1047 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1048 Requirement Levels", BCP 14, RFC 2119, March 1997. 1050 [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 1051 (IPv6) Specification", RFC 2460, December 1998. 1053 [RFC4301] Kent, S. and K. Seo, "Security Architecture for the 1054 Internet Protocol", RFC 4301, December 2005. 1056 [RFC4443] Conta, A., Deering, S., and M. Gupta, "Internet Control 1057 Message Protocol (ICMPv6) for the Internet Protocol 1058 Version 6 (IPv6) Specification", RFC 4443, March 2006. 1060 10.2. Informative References 1062 [DClark] Clark, D., "The Design Philosophy of the DARPA Internet 1063 Protocols", Computer Communication Review Vol. 18, No. 4, 1064 1988. 1066 [FreeBSD] The FreeBSD Project, "http://www.freebsd.org". 1068 [I-D.iab-link-indications] 1069 Aboba, B., "Architectural Implications of Link 1070 Indications", draft-iab-link-indications-10 (work in 1071 progress), March 2007. 1073 [I-D.ietf-pmtud-method] 1074 Mathis, M. and J. Heffner, "Packetization Layer Path MTU 1075 Discovery", draft-ietf-pmtud-method-11 (work in progress), 1076 December 2006. 1078 [I-D.ietf-tcpm-tcp-antispoof] 1079 Touch, J., "Defending TCP Against Spoofing Attacks", 1080 draft-ietf-tcpm-tcp-antispoof-06 (work in progress), 1081 February 2007. 1083 [I-D.ietf-tcpm-tcp-soft-errors] 1084 Gont, F., "TCP's Reaction to Soft Errors", 1085 draft-ietf-tcpm-tcp-soft-errors-05 (work in progress), 1086 April 2007. 1088 [I-D.ietf-tcpm-tcpsecure] 1089 Ramaiah, A., "Improving TCP's Robustness to Blind In- 1090 Window Attacks", draft-ietf-tcpm-tcpsecure-07 (work in 1091 progress), February 2007. 1093 [I-D.larsen-tsvwg-port-randomisation] 1094 Larsen, M., "Port Randomisation", 1095 draft-larsen-tsvwg-port-randomisation-00 (work in 1096 progress), October 2004. 1098 [ICMP-Filtering] 1099 Gont, F., "Filtering of ICMP error messages", http:// 1100 www.gont.com.ar/papers/filtering-icmp-error-messages.pdf. 1102 [IP-filtering] 1103 NISCC, "NISCC Technical Note 01/2006: Egress and Ingress 1104 Filtering", http://www.niscc.gov.uk/niscc/docs/ 1105 re-20060420-00294.pdf?lang=en, 2006. 1107 [Linux] The Linux Project, "http://www.kernel.org". 1109 [McKusick] 1110 McKusick, M., Bostic, K., Karels, M., and J. Quarterman, 1111 "The Design and Implementation of the 4.4BSD Operating 1112 System", Addison-Wesley , 1996. 1114 [NISCC] NISCC, "NISCC Vulnerability Advisory 532967/NISCC/ICMP: 1115 Vulnerability Issues in ICMP packets with TCP payloads", 1116 http://www.niscc.gov.uk/niscc/docs/ 1117 al-20050412-00308.html?lang=en, 2005. 1119 [NetBSD] The NetBSD Project, "http://www.netbsd.org". 1121 [OpenBSD] The OpenBSD Project, "http://www.openbsd.org". 1123 [OpenBSD-PF] 1124 The OpenBSD Packet Filter, 1125 "http://www.openbsd.org/faq/pf/". 1127 [RFC0816] Clark, D., "Fault isolation and recovery", RFC 816, 1128 July 1982. 1130 [RFC1321] Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321, 1131 April 1992. 1133 [RFC1323] Jacobson, V., Braden, B., and D. Borman, "TCP Extensions 1134 for High Performance", RFC 1323, May 1992. 1136 [RFC2385] Heffernan, A., "Protection of BGP Sessions via the TCP MD5 1137 Signature Option", RFC 2385, August 1998. 1139 [RFC2581] Allman, M., Paxson, V., and W. Stevens, "TCP Congestion 1140 Control", RFC 2581, April 1999. 1142 [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., 1143 Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext 1144 Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999. 1146 [RFC2821] Klensin, J., "Simple Mail Transfer Protocol", RFC 2821, 1147 April 2001. 1149 [RFC2923] Lahey, K., "TCP Problems with Path MTU Discovery", 1150 RFC 2923, September 2000. 1152 [RFC3168] Ramakrishnan, K., Floyd, S., and D. Black, "The Addition 1153 of Explicit Congestion Notification (ECN) to IP", 1154 RFC 3168, September 2001. 1156 [RFC3390] Allman, M., Floyd, S., and C. Partridge, "Increasing TCP's 1157 Initial Window", RFC 3390, October 2002. 1159 [RFC4271] Rekhter, Y., Li, T., and S. Hares, "A Border Gateway 1160 Protocol 4 (BGP-4)", RFC 4271, January 2006. 1162 [US-CERT] US-CERT, "US-CERT Vulnerability Note VU#222750: TCP/IP 1163 Implementations do not adequately validate ICMP error 1164 messages", http://www.kb.cert.org/vuls/id/222750, 2005. 1166 [Watson] Watson, P., "Slipping in the Window: TCP Reset Attacks", 1167 2004 CanSecWest Conference , 2004. 1169 [Wright] Wright, G. and W. Stevens, "TCP/IP Illustrated, Volume 2: 1170 The Implementation", Addison-Wesley , 1994. 1172 Appendix A. The counter-measure for the PMTUD attack in action 1174 This appendix shows the proposed counter-measure for the ICMP attack 1175 against the PMTUD mechanism in action. It shows both how the fix 1176 protects TCP from being attacked and how the counter-measure works in 1177 normal scenarios. As discussed in Section 7.2, this Appendix assumes 1178 the PMTUD-specific counter-measure is implemented in addition to the 1179 TCP sequence number checking described in Section 4.1. 1181 Figure 1 illustrates an hypothetical scenario in which two hosts are 1182 connected by means of three intermediate routers. It also shows the 1183 MTU of each hypothetical hop. All the following subsections assume 1184 the network setup of this figure. 1186 Also, for simplicity sake, all subsections assume an IP header of 20 1187 octets and a TCP header of 20 octets. Thus, for example, when the 1188 PMTU is assumed to be 1500 octets, TCP will send segments that 1189 contain, at most, 1460 octets of data. 1191 For simplicity sake, all the following subsections assume the TCP 1192 implementation at Host 1 has chosen a a MAXSEGRTO of 1. 1194 +----+ +----+ +----+ +----+ +----+ 1195 | H1 |--------| R1 |--------| R2 |--------| R3 |--------| H2 | 1196 +----+ +----+ +----+ +----+ +----+ 1197 MTU=4464 MTU=2048 MTU=1500 MTU=4464 1199 Figure 1: Hypothetical scenario 1201 A.1. Normal operation for bulk transfers 1203 This subsection shows the proposed counter-measure in normal 1204 operation, when a TCP connection is used for bulk transfers. That 1205 is, it shows how the proposed counter-measure works when there is no 1206 attack taking place, and a TCP connection is used for transferring 1207 large amounts of data. This section assumes that just after the 1208 connection is established, one of the TCP endpoints begins to 1209 transfer data in packets that are as large as possible. 1211 Host 1 Host 2 1213 1. --> --> 1214 2. <-- <-- 1215 3. --> --> 1216 4. --> --> 1217 5. <--- ICMP "Packet Too Big" MTU=2048, TCPseq#=101 <--- R1 1218 6. --> --> 1219 7. <--- ICMP "Packet Too Big" MTU=1500, TCPseq#=101 <--- R2 1220 8. --> --> 1221 9. <-- <-- 1223 Figure 2: Normal operation for bulk transfers 1225 nsegrto is initialized to zero. Both maxsizeacked and maxsizesent 1226 are initialized to the minimum MTU for the internet protocol being 1227 used (68 for IPv4, and 1280 for IPv6). 1229 In lines 1 to 3 the three-way handshake takes place, and the 1230 connection is established. In line 4, H1 tries to send a full-sized 1231 TCP segment. As described by [RFC1191] and [RFC1981], in this case 1232 TCP will try to send a segment with 4424 bytes of data, which will 1233 result in an IP packet of 4464 octets. Therefore, maxsizesent is set 1234 to 4464. When the packet reaches R1, it elicits an ICMP "Packet Too 1235 Big" error message. 1237 In line 5, H1 receives the ICMP error message, which reports a Next- 1238 Hop MTU of 2048 octets. After performing the TCP sequence number 1239 check described in Section 4.1, the Next-Hop MTU reported by the ICMP 1240 error message (claimedmtu) is compared with maxsizesent. As it is 1241 smaller than maxsizesent, it passes the check, and thus is then 1242 compared with maxsizeacked. As claimedmtu is larger than 1243 maxsizeacked, TCP assumes that the corresponding TCP segment was 1244 performing the Initial PMTU Discovery. Therefore, the TCP at H1 1245 honors the ICMP message by updating the assumed Path-MTU. maxsizesent 1246 is reset to the minimum MTU of the internet protocol in use (68 for 1247 IPv4, and 1280 for IPv6). 1249 In line 6, the TCP at H1 sends a segment with 2008 bytes of data, 1250 which results in an IP packet of 2048 octets. maxsizesent is thus set 1251 to 2008 bytes. When the packet reaches R2, it elicits an ICMP 1252 "Packet Too Big" error message. 1254 In line 7, H1 receives the ICMP error message, which reports a Next- 1255 Hop MTU of 1500 octets. After performing the TCP sequence number 1256 check, the Next-Hop MTU reported by the ICMP error message 1257 (claimedmtu) is compared with maxsizesent. As it is smaller than 1258 maxsizesent, it passes the check, and thus is then compared with 1259 maxsizeacked. As claimedmtu is larger than maxsizeacked, TCP assumes 1260 that the corresponding TCP segment was performing the Initial PMTU 1261 Discovery. Therefore, the TCP at H1 honors the ICMP message by 1262 updating the assumed Path-MTU. maxsizesent is reset to the minimum 1263 MTU of the internet protocol in use. 1265 In line 8, the TCP at H1 sends a segment with 1460 bytes of data, 1266 which results in an IP packet of 1500 octets. maxsizesent is thus set 1267 to 1500. This packet reaches H2, where it elicits an acknowledgement 1268 (ACK) segment. 1270 In line 9, H1 finally gets the acknowledgement for the data segment. 1271 As the corresponding packet was larger than maxsizeacked, TCP updates 1272 maxsizeacked, setting it to 1500. At this point TCP has discovered 1273 the Path-MTU for this TCP connection. 1275 A.2. Operation during Path-MTU changes 1277 Let us suppose a TCP connection between H1 and H2 has already been 1278 established, and that the PMTU for the connection has already been 1279 discovered to be 1500. At this point, both maxsizesent and 1280 maxsizeacked are equal to 1500, and nsegrto is equal to 0. Suppose 1281 some time later the PMTU decreases to 1492. For simplicity, let us 1282 suppose that the Path-MTU has decreased because the MTU of the link 1283 between R2 and R3 has decreased from 1500 to 1492. Figure 3 1284 illustrates how the proposed counter-measure would work in this 1285 scenario. 1287 Host 1 Host 2 1289 1. (Path-MTU decreases) 1290 2. --> --> 1291 3. <--- ICMP "Packet Too Big" MTU=1492, TCPseq#=100 <--- R2 1292 4. (Segment times out) 1293 5. --> --> 1294 6. <-- <-- 1296 Figure 3: Operation during Path-MTU changes 1298 In line 1, the Path-MTU for this connection decreases from 1500 to 1299 1492. In line 2, the TCP at H1, without being aware of the Path-MTU 1300 change, sends a 1500-byte packet to H2. When the packet reaches R2, 1301 it elicits an ICMP "Packet Too Big" error message. 1303 In line 3, H1 receives the ICMP error message, which reports a Next- 1304 Hop MTU of 1492 octets. After performing the TCP sequence number 1305 check, the Next-Hop MTU reported by the ICMP error message 1306 (claimedmtu) is compared with maxsizesent. As claimedmtu is smaller 1307 than maxsizesent, it is then compared with maxsizeacked. As 1308 claimedmtu is smaller than maxsizeacked (full-sized packets were 1309 getting to the remote end-point), this packet is assumed to be 1310 performing Path-MTU Update. And a "pending error" condition is 1311 recorded. 1313 In line 4, the segment times out. Thus, nsegrto is incremented by 1. 1314 As nsegrto is greater than or equal to MAXSEGRTO, the assumed Path- 1315 MTU is updated. nsegrto is reset to 0, and maxsizeacked is set to 1316 claimedmtu, and maxsizesent is set to the minimum MTU of the internet 1317 protocol in use. 1319 In line 5, H1 retransmits the data using the updated PMTU, and thus 1320 maxsizesent is set to 1492. The resulting packet reaches H2, where 1321 it elicits an acknowledgement (ACK) segment. 1323 In line 6, H1 finally gets the acknowledgement for the data segment. 1324 At this point TCP has discovered the new Path-MTU for this TCP 1325 connection. 1327 A.3. Idle connection being attacked 1329 Let us suppose a TCP connection between H1 and H2 has already been 1330 established, and the PMTU for the connection has already been 1331 discovered to be 1500. Figure 4 shows a sample time-line diagram 1332 that illustrates an idle connection being attacked. 1334 Host 1 Host 2 1336 1. --> --> 1337 2. <-- <-- 1338 3. <--- ICMP "Packet Too Big" MTU=68, TCPseq#=100 <--- 1339 4. <--- ICMP "Packet Too Big" MTU=68, TCPseq#=100 <--- 1340 5. <--- ICMP "Packet Too Big" MTU=68, TCPseq#=100 <--- 1342 Figure 4: Idle connection being attacked 1344 In line 1, H1 sends its last bunch of data. At line 2, H2 1345 acknowledges the receipt of these data. Then the connection becomes 1346 idle. In lines 3, 4, and 5, an attacker sends forged ICMP "Packet 1347 Too Big" error messages to H1. Regardless of how many packets it 1348 sends and the TCP sequence number each ICMP packet includes, none of 1349 these ICMP error messages will pass the TCP sequence number check 1350 described in Section 4.1, as H1 has no unacknowledged data in flight 1351 to H2. Therefore, the attack does not succeed. 1353 A.4. Active connection being attacked after discovery of the Path-MTU 1355 Let us suppose an attacker attacks a TCP connection for which the 1356 PMTU has already been discovered. In this case, as illustrated in 1357 Figure 1, the PMTU would be found to be 1500 bytes. Figure 5 shows a 1358 possible packet exchange. 1360 Host 1 Host 2 1362 1. --> --> 1363 2. --> --> 1364 3. --> --> 1365 4. --> --> 1366 5. <--- ICMP "Packet Too Big" MTU=68, TCPseq#=100 <--- 1367 6. <-- <-- 1369 Figure 5: Active connection being attacked after discovery of PMTU 1371 As we assume the PMTU has already been discovered, we also assume 1372 both maxsizesent and maxsizeacked are equal to 1500. We assume 1373 nsegrto is equal to zero, as there have been no segment timeouts. 1375 In lines 1, 2, 3, and 4, H1 sends four data segments to H2. In line 1376 5, an attacker sends a forged ICMP packet to H1. We assume the 1377 attacker is lucky enough to guess both the four-tuple that identifies 1378 the connection and a valid TCP sequence number. As the Next-Hop MTU 1379 claimed in the ICMP "Packet Too Big" message (claimedmtu) is smaller 1380 than maxsizeacked, this packet is assumed to be performing Path-MTU 1381 Update. Thus, the error message is recorded. 1383 In line 6, H1 receives an acknowledgement for the segment sent in 1384 line 1, before it times out. At this point, the "pending error" 1385 condition is cleared, and the recorded ICMP "Packet Too Big" error 1386 message is ignored. Therefore, the attack does not succeed. 1388 A.5. TCP peer attacked when sending small packets just after the three- 1389 way handshake 1391 This section analyzes an scenario in which a TCP peer that is sending 1392 small segments just after the connection has been established, is 1393 attacked. The connection could be being used by protocols such as 1394 SMTP [RFC2821] and HTTP [RFC2616], for example, which usually behave 1395 like this. 1397 Figure 6 shows a possible packet exchange for such scenario. 1399 Host 1 Host 2 1401 1. --> --> 1402 2. <-- <-- 1403 3. --> --> 1404 4. --> --> 1405 5. <-- <-- 1406 6. --> --> 1407 7. --> --> 1408 8. <--- ICMP "Packet Too Big" MTU=150, TCPseq#=101 <--- 1410 Figure 6: TCP peer attacked when sending small packets just after the 1411 three-way handshake 1413 nsegrto is initialized to zero. Both maxsizesent and maxsizeacked 1414 are initialized to the minimum MTU for the internet protocol being 1415 used (68 for IPv4, and 1280 for IPv6). 1417 In lines 1 to 3 the three-way handshake takes place, and the 1418 connection is established. At this point, the assumed Path-MTU for 1419 this connection is 4464. In line 4, H1 sends a small segment (which 1420 results in a 140-byte packet) to H2. maxsizesent is thus set to 140. 1421 In line 5 this segment is acknowledged, and thus maxsizeacked is set 1422 to 140. 1424 In lines 6 and 7, H1 sends two small segments to H2. In line 8, 1425 while the segments from lines 6 and 7 are still in flight to H2, an 1426 attacker sends a forged ICMP "Packet Too Big" error message to H1. 1427 Assuming the attacker is lucky enough to guess a valid TCP sequence 1428 number, this ICMP message will pass the TCP sequence number check. 1429 The Next-Hop MTU reported by the ICMP error message (claimedmtu) is 1430 then compared with maxsizesent. As claimedmtu is larger than 1431 maxsizesent, the ICMP error message is silently discarded. 1432 Therefore, the attack does not succeed. 1434 Appendix B. Pseudo-code for the counter-measure for the blind 1435 performance-degrading attack 1437 This section contains a pseudo-code version of the counter-measure 1438 described in Section 7.2 for the blind performance-degrading attack 1439 described in Section 7. It is meant as guidance for developers on 1440 how to implement this counter-measure. 1442 The pseudo-code makes use of the following variables, constants, and 1443 functions: 1445 ack 1446 Variable holding the acknowledgement number contained in the TCP 1447 segment that has just been received. 1449 acked_packet_size 1450 Variable holding the packet size (data, plus headers) the ACK that 1451 has just been received is acknowledging. 1453 adjust_mtu() 1454 Function that adjusts the MTU for this connection, according to 1455 the ICMP "Packet Too Big" that was last received. 1457 claimedmtu 1458 Variable holding the Next-Hop MTU advertised by the ICMP "Packet 1459 Too Big" error message. 1461 claimedtcpseq 1462 Variable holding the TCP sequence number contained in the payload 1463 of the ICMP "Packet Too Big" message that has just been received 1464 or was last recorded. 1466 current_mtu 1467 Variable holding the assumed Path-MTU for this connection. 1469 drop_message() 1470 Function that performs the necessary actions to drop the ICMP 1471 message being processed. 1473 initial_mtu 1474 Variable holding the MTU for new connections, as explained in 1475 [RFC1191] and [RFC1981]. 1477 maxsizeacked 1478 Variable holding the largest packet size (data, plus headers) that 1479 has so for been acked far this connection, as explained in 1480 Section 7.2 1482 maxsizesent 1483 Variable holding the largest packet size (data, plus headers) that 1484 has so for been sent far this connection, as explained in 1485 Section 7.2 1487 nsegrto 1488 Variable holding the number of times this segment has timed out, 1489 as explained in Section 7.2 1491 packet_size 1492 Variable holding the size of the IP datagram being sent 1494 pending_message 1495 Variable (flag) that indicates whether there is a pending ICMP 1496 "Packet Too Big" message to be processed. 1498 save_message() 1499 Function that records the ICMP "Packet Too Big" message that has 1500 just been received. 1502 MINIMUM_MTU 1503 Constant holding the minimum MTU for the internet protocol in use 1504 (68 for IPv4, and 1280 for IPv6). 1506 MAXSEGRTO 1507 Constant holding the number of times a given segment must timeout 1508 before an ICMP "Packet Too Big" error message can be honored. 1510 EVENT: New TCP connection 1512 current_mtu = initial_mtu; 1513 maxsizesent = MINIMUM_MTU; 1514 maxsizeacked = MINIMUM_MTU; 1515 nsegrto = 0; 1516 pending_message = 0; 1518 EVENT: Segment is sent 1519 if (packet_size > maxsizesent) 1520 maxsizesent = packet_size; 1522 EVENT: Segment is received 1524 if (acked_packet_size > maxsizeacked) 1525 maxsizeacked = acked_packet_size; 1527 if (pending_mesage) 1528 if (ack > claimedtcpseq){ 1529 pending_message = 0; 1530 nsegrto = 0; 1531 } 1533 EVENT: ICMP "Packet Too Big" message is received 1535 if (claimedtcpseq < SND.UNA || claimed_TCP_SEQ >= SND.NXT){ 1536 drop_message(); 1537 } 1539 else { 1540 if (claimedmtu >= maxsizesent || claimedmtu >= current_mtu) 1541 drop_message(); 1543 else { 1544 if (claimedmtu > maxsizeacked){ 1545 adjust_mtu(); 1546 current_mtu = claimedmtu; 1547 maxsizesent = MINIMUM_MTU; 1548 } 1550 else { 1551 pending_message = 1; 1552 save_message(); 1553 } 1554 } 1555 } 1557 EVENT: Segment times out 1559 nsegrto++; 1561 if (pending_message && nsegrto >= MAXSEGRTO){ 1562 adjust_mtu(); 1563 nsegrto = 0; 1564 pending_message = 0; 1565 maxsizeacked = claimedmtu; 1566 maxsizesent = MINIMUM_MTU; 1567 current_mtu = claimedmtu; 1568 } 1570 Notes: 1571 All comparisions between sequence numbers must be performed using 1572 sequence number arithmethic. 1573 The pseudo-code implements the mechanism described in Section 7.2, 1574 the TCP sequence number checking described in Section 4.1, and the 1575 validation check on the advertised Next-Hop MTU described in 1576 [RFC1191] and [RFC1981]. 1578 Appendix C. Additional considerations for the validation of ICMP error 1579 messages 1581 The checksum of the IP datagram contained in the ICMP payload should 1582 be checked to be valid. In case it is invalid, the ICMP error 1583 message should be silently dropped. 1585 If a full IP datagram is contained in the ICMP payload, and the IP 1586 datagram is authenticated [RFC4301], the signature should be 1587 recalculated for that packet. If it doesn't match the one already 1588 included in the ICMP payload, the ICMP error message should be 1589 silently dropped. 1591 If a full TCP segment is contained in the payload of the ICMP error 1592 message, then the first check that should be performed is that the 1593 TCP checksum is valid. Then, if a TCP MD5 option is present, the MD5 1594 signature should be recalculated for the encapsulated packet, and if 1595 it doesn't match the one contained in the TCP MD5 option, the ICMP 1596 error message should be silently dropped. 1598 Regardless of whether the received ICMP error message contains a full 1599 packet or not, if a TCP timestamp option is present, it should be 1600 used to validate the error message according to the rules specified 1601 in [RFC1323]. 1603 It must be noted that most of the checks discussed in this appendix 1604 imply that the ICMP error message contains more data than just the 1605 full IP header and the first 64 bits of the payload of the original 1606 datagram that elicited the error message. As discussed in Section 3, 1607 for obvious reasons one should not expect an attacker to include in 1608 the packets it sends more information than that required to by the 1609 current specifications. 1611 Appendix D. Advice and guidance to vendors 1613 Vendors are urged to contact NISCC (vulteam@niscc.gov.uk) if they 1614 think they may be affected by the issues described in this document. 1615 As the lead coordination center for these issues, NISCC is well 1616 placed to give advice and guidance as required. 1618 NISCC works extensively with government departments and agencies, 1619 commercial organizations and the academic community to research 1620 vulnerabilities and potential threats to IT systems especially where 1621 they may have an impact on Critical National Infrastructure's (CNI). 1623 Other ways to contact NISCC, plus NISCC's PGP public key, are 1624 available at http://www.uniras.gov.uk/vuls/ . 1626 Appendix E. Changes from previous versions of the draft (to be removed 1627 by the RFC Editor before publishing this document as an 1628 RFC) 1630 E.1. Changes from draft-ietf-tcpm-icmp-attacks-01 1632 o Fixed references to the antispoof documents (were hardcoded and 1633 missing in the References Section). 1635 o The draft had expired and thus is resubmitted with no further 1636 changes. 1638 E.2. Changes from draft-ietf-tcpm-icmp-attacks-00 1640 o Added references to the specific sections of each of the 1641 referenced specifications 1643 o Corrected the threat analysys 1645 o Added clarification about whether the counter-measures violate the 1646 current specifications or not. 1648 o Changed text so that the document fits better in the Informational 1649 path 1651 o Added an specific section on IPsec (Section 2.3) 1653 o Added clarification and references on the use of ICMP filtering 1654 based on the ICMP payload 1656 o Updated references to obsoleted RFCs 1657 o Added a discussion of multipath scenarios, and possible lose in 1658 responsiveness resulting from the reaction to hard errors as soft 1659 errors (in Section 5.2.3) 1661 o Miscellaneous editorial changes 1663 E.3. Changes from draft-gont-tcpm-icmp-attacks-05 1665 o Removed RFC 2119 wording to make the draft suitable for 1666 publication as an Informational RFC. 1668 o Added additional checks that should be performed on ICMP error 1669 messages (checksum of the IP header in the ICMP payload, and 1670 others). 1672 o Added clarification of the rationale behind each the TCP SEQ check 1674 o Miscellaneous editorial changes 1676 E.4. Changes from draft-gont-tcpm-icmp-attacks-04 1678 o Added Appendix C 1680 o Added reference to [I-D.iab-link-indications] 1682 o Added stress on the fact that ICMP error messages are unreliable 1684 o Miscellaneous editorial changes 1686 E.5. Changes from draft-gont-tcpm-icmp-attacks-03 1688 o Added references to existing implementations of the proposed 1689 counter-measures 1691 o The discussion in Section 4 was improved 1693 o The discussion in Section 5.2.1 was expanded and improved 1695 o The proposed counter-measure for the attack against the PMTUD was 1696 improved and simplified 1698 o Appendix B was added 1700 o Miscellaneous editorial changes 1702 E.6. Changes from draft-gont-tcpm-icmp-attacks-02 1704 o Fixed errors in Section 5.2.1 1706 o The proposed counter-measure for the attack against the PMTUD 1707 mechanism was refined to allow quick discovery of the Path-MTU 1709 o Appendix A was added so as to clarify the operation of the 1710 counter-measure for the attack against the PMTUD mechanism 1712 o Added Appendix D 1714 o Miscellaneous editorial changes 1716 E.7. Changes from draft-gont-tcpm-icmp-attacks-01 1718 o The document was restructured for easier reading 1720 o A discussion of ICMPv6 was added in several sections of the 1721 document 1723 o Added Section on Acknowledgement number checking"/> 1725 o Added Section 4.3 1727 o Added Section 7 1729 o Fixed typo in the ICMP types, in several places 1731 o Fixed typo in the TCP sequence number check formula 1733 o Miscellaneous editorial changes 1735 E.8. Changes from draft-gont-tcpm-icmp-attacks-00 1737 o Added a proposal to change the handling of the so-called ICMP hard 1738 errors during the synchronized states 1740 o Added a summary of the relevant RFCs in several sections 1742 o Miscellaneous editorial changes 1744 Author's Address 1746 Fernando Gont 1747 Universidad Tecnologica Nacional / Facultad Regional Haedo 1748 Evaristo Carriego 2644 1749 Haedo, Provincia de Buenos Aires 1706 1750 Argentina 1752 Phone: +54 11 4650 8472 1753 Email: fernando@gont.com.ar 1754 URI: http://www.gont.com.ar 1756 Full Copyright Statement 1758 Copyright (C) The IETF Trust (2007). 1760 This document is subject to the rights, licenses and restrictions 1761 contained in BCP 78, and except as set forth therein, the authors 1762 retain all their rights. 1764 This document and the information contained herein are provided on an 1765 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 1766 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 1767 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 1768 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 1769 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1770 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1772 Intellectual Property 1774 The IETF takes no position regarding the validity or scope of any 1775 Intellectual Property Rights or other rights that might be claimed to 1776 pertain to the implementation or use of the technology described in 1777 this document or the extent to which any license under such rights 1778 might or might not be available; nor does it represent that it has 1779 made any independent effort to identify any such rights. Information 1780 on the procedures with respect to rights in RFC documents can be 1781 found in BCP 78 and BCP 79. 1783 Copies of IPR disclosures made to the IETF Secretariat and any 1784 assurances of licenses to be made available, or the result of an 1785 attempt made to obtain a general license or permission for the use of 1786 such proprietary rights by implementers or users of this 1787 specification can be obtained from the IETF on-line IPR repository at 1788 http://www.ietf.org/ipr. 1790 The IETF invites any interested party to bring to its attention any 1791 copyrights, patents or patent applications, or other proprietary 1792 rights that may cover technology that may be required to implement 1793 this standard. Please address the information to the IETF at 1794 ietf-ipr@ietf.org. 1796 Acknowledgment 1798 Funding for the RFC Editor function is provided by the IETF 1799 Administrative Support Activity (IASA).