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