idnits 2.17.1 draft-ietf-tcpm-icmp-attacks-06.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** The document seems to lack a License Notice according IETF Trust Provisions of 28 Dec 2009, Section 6.b.i or Provisions of 12 Sep 2009 Section 6.b -- however, there's a paragraph with a matching beginning. Boilerplate error? (You're using the IETF Trust Provisions' Section 6.b License Notice from 12 Feb 2009 rather than one of the newer Notices. See https://trustee.ietf.org/license-info/.) 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 and authors 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 (August 24, 2009) is 5358 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 (-11) exists of draft-ietf-tcpm-tcp-auth-opt-05 == Outdated reference: A later version (-13) exists of draft-ietf-tcpm-tcpsecure-11 == Outdated reference: A later version (-09) exists of draft-ietf-tsvwg-port-randomization-04 -- 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 (~~), 5 warnings (==), 8 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 August 24, 2009 5 Intended status: Informational 6 Expires: February 25, 2010 8 ICMP attacks against TCP 9 draft-ietf-tcpm-icmp-attacks-06.txt 11 Status of this Memo 13 This Internet-Draft is submitted to IETF in full conformance with the 14 provisions of BCP 78 and BCP 79. 16 Internet-Drafts are working documents of the Internet Engineering 17 Task Force (IETF), its areas, and its working groups. Note that 18 other groups may also distribute working documents as Internet- 19 Drafts. 21 Internet-Drafts are draft documents valid for a maximum of six months 22 and may be updated, replaced, or obsoleted by other documents at any 23 time. It is inappropriate to use Internet-Drafts as reference 24 material or to cite them other than as "work in progress." 26 The list of current Internet-Drafts can be accessed at 27 http://www.ietf.org/ietf/1id-abstracts.txt. 29 The list of Internet-Draft Shadow Directories can be accessed at 30 http://www.ietf.org/shadow.html. 32 This Internet-Draft will expire on February 25, 2010. 34 Copyright Notice 36 Copyright (c) 2009 IETF Trust and the persons identified as the 37 document authors. All rights reserved. 39 This document is subject to BCP 78 and the IETF Trust's Legal 40 Provisions Relating to IETF Documents in effect on the date of 41 publication of this document (http://trustee.ietf.org/license-info). 42 Please review these documents carefully, as they describe your rights 43 and restrictions with respect to this document. 45 Abstract 47 This document discusses the use of the Internet Control Message 48 Protocol (ICMP) to perform a variety of attacks against the 49 Transmission Control Protocol (TCP) and other similar protocols. 50 Additionally, describes a number of widely implemented modifications 51 to TCP's handling of ICMP error messages that help to mitigate these 52 issues. 54 Table of Contents 56 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 57 2. Background . . . . . . . . . . . . . . . . . . . . . . . . . . 5 58 2.1. The Internet Control Message Protocol (ICMP) . . . . . . . 5 59 2.1.1. ICMP for IP version 4 (ICMP) . . . . . . . . . . . . . 5 60 2.1.2. ICMP for IP version 6 (ICMPv6) . . . . . . . . . . . . 6 61 2.2. Handling of ICMP error messages . . . . . . . . . . . . . 6 62 2.3. Handling of ICMP error messages in the context of IPsec . 7 63 3. Constraints in the possible solutions . . . . . . . . . . . . 8 64 4. General counter-measures against ICMP attacks . . . . . . . . 9 65 4.1. TCP sequence number checking . . . . . . . . . . . . . . . 9 66 4.2. Port randomization . . . . . . . . . . . . . . . . . . . . 10 67 4.3. Filtering ICMP error messages based on the ICMP payload . 10 68 5. Blind connection-reset attack . . . . . . . . . . . . . . . . 11 69 5.1. Description . . . . . . . . . . . . . . . . . . . . . . . 11 70 5.2. Attack-specific counter-measures . . . . . . . . . . . . . 12 71 6. Blind throughput-reduction attack . . . . . . . . . . . . . . 15 72 6.1. Description . . . . . . . . . . . . . . . . . . . . . . . 15 73 6.2. Attack-specific counter-measures . . . . . . . . . . . . . 15 74 7. Blind performance-degrading attack . . . . . . . . . . . . . . 15 75 7.1. Description . . . . . . . . . . . . . . . . . . . . . . . 15 76 7.2. Attack-specific counter-measures . . . . . . . . . . . . . 17 77 7.3. The counter-measure for the PMTUD attack in action . . . . 20 78 7.3.1. Normal operation for bulk transfers . . . . . . . . . 21 79 7.3.2. Operation during Path-MTU changes . . . . . . . . . . 23 80 7.3.3. Idle connection being attacked . . . . . . . . . . . . 24 81 7.3.4. Active connection being attacked after discovery 82 of the Path-MTU . . . . . . . . . . . . . . . . . . . 24 83 7.3.5. TCP peer attacked when sending small packets just 84 after the three-way handshake . . . . . . . . . . . . 25 85 7.4. Pseudo-code for the counter-measure for the blind 86 performance-degrading attack . . . . . . . . . . . . . . . 26 87 8. Security Considerations . . . . . . . . . . . . . . . . . . . 30 88 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 30 89 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 31 90 10.1. Normative References . . . . . . . . . . . . . . . . . . . 31 91 10.2. Informative References . . . . . . . . . . . . . . . . . . 31 92 Appendix A. Changes from previous versions of the draft (to 93 be removed by the RFC Editor before publishing 94 this document as an RFC) . . . . . . . . . . . . . . 34 95 A.1. Changes from draft-ietf-tcpm-icmp-attacks-05 . . . . . . . 34 96 A.2. Changes from draft-ietf-tcpm-icmp-attacks-04 . . . . . . . 34 97 A.3. Changes from draft-ietf-tcpm-icmp-attacks-03 . . . . . . . 34 98 A.4. Changes from draft-ietf-tcpm-icmp-attacks-02 . . . . . . . 34 99 A.5. Changes from draft-ietf-tcpm-icmp-attacks-01 . . . . . . . 35 100 A.6. Changes from draft-ietf-tcpm-icmp-attacks-00 . . . . . . . 35 101 A.7. Changes from draft-gont-tcpm-icmp-attacks-05 . . . . . . . 35 102 A.8. Changes from draft-gont-tcpm-icmp-attacks-04 . . . . . . . 36 103 A.9. Changes from draft-gont-tcpm-icmp-attacks-03 . . . . . . . 36 104 A.10. Changes from draft-gont-tcpm-icmp-attacks-02 . . . . . . . 36 105 A.11. Changes from draft-gont-tcpm-icmp-attacks-01 . . . . . . . 36 106 A.12. Changes from draft-gont-tcpm-icmp-attacks-00 . . . . . . . 37 107 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 37 109 1. Introduction 111 ICMP [RFC0792] is a fundamental part of the TCP/IP protocol suite, 112 and is used mainly for reporting network error conditions. However, 113 the current specifications do not recommend any kind of validation 114 checks on the received ICMP error messages, thus allowing variety of 115 attacks against TCP [RFC0793] by means of ICMP, which include blind 116 connection-reset, blind throughput-reduction, and blind performance- 117 degrading attacks. All of these attacks can be performed even being 118 off-path, without the need to sniff the packets that correspond to 119 the attacked TCP connection. 121 While the possible security implications of ICMP have been known in 122 the research community for a long time, there has never been an 123 official proposal on how to deal with these vulnerabiliies. In 2005, 124 a disclosure process was carried out by the UK's National 125 Infrastructure Security Co-ordination Centre (NISCC) (now CPNI, 126 Centre for the Protection of National Infrastructure), with the 127 collaboration of other computer emergency response teams. A large 128 number of implementations were found vulnerable to either all or a 129 subset of the attacks discussed in this document [NISCC][US-CERT]. 130 The affected systems ranged from TCP/IP implementations meant for 131 desktop computers, to TCP/IP implementations meant for core Internet 132 routers. 134 It is clear that implementations should be more cautious when 135 processing ICMP error messages, to eliminate or mitigate the use of 136 ICMP to perform attacks against TCP [RFC4907]. 138 This document aims to raise awareness of the use of ICMP to perform a 139 variety of attacks against TCP, and discusses several counter- 140 measures that eliminate or minimize the impact of these attacks. 141 Most of the these counter-measures can be implemented while still 142 remaining compliant with the current specifications, as they simply 143 describe reasons for not taking the advice provided in the 144 specifications in terms of "SHOULDs", but still comply with the 145 requirements stated as "MUSTs". 147 Section 2 provides background information on ICMP. Section 3 148 discusses the constraints in the general counter-measures that can be 149 implemented against the attacks described in this document. 150 Section 4 proposes several general validation checks that can be 151 implemented to mitigate any ICMP-based attack. Finally, Section 5, 152 Section 6, and Section 7, discuss a variety of ICMP attacks that can 153 be performed against TCP, and propose attack-specific counter- 154 measures that eliminate or greatly mitigate their impact. 156 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 157 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 158 document are to be interpreted as described in RFC 2119 [RFC2119]. 160 2. Background 162 2.1. The Internet Control Message Protocol (ICMP) 164 The Internet Control Message Protocol (ICMP) is used in the Internet 165 architecture mainly to perform the fault-isolation function, that is, 166 the group of actions that hosts and routers take to determine that 167 there is some network failure [RFC0816]. 169 When an intermediate router detects a network problem while trying to 170 forward an IP packet, it will usually send an ICMP error message to 171 the source system, to raise awareness of the network problem taking 172 place. In the same way, there are a number of scenarios in which an 173 end-system may generate an ICMP error message if it finds a problem 174 while processing a datagram. The received ICMP errors are handed to 175 the corresponding transport-protocol instance, which will usually 176 perform a fault recovery function. 178 It is important to note that ICMP error messages are unreliable, and 179 may be discarded due to data corruption, network congestion or rate- 180 limiting. Thus, while they provide useful information, upper layer 181 protocols cannot depend on ICMP for correct operation. 183 2.1.1. ICMP for IP version 4 (ICMP) 185 [RFC0792] specifies the Internet Control Message Protocol (ICMP) to 186 be used with the Internet Protocol version 4 (IPv4). It defines, 187 among other things, a number of error messages that can be used by 188 end-systems and intermediate systems to report errors to the sending 189 system. The Host Requirements RFC [RFC1122] classifies ICMP error 190 messages into those that indicate "soft errors", and those that 191 indicate "hard errors", thus roughly defining the semantics of them. 193 The ICMP specification [RFC0792] also defines the ICMP Source Quench 194 message (type 4, code 0), which is meant to provide a mechanism for 195 flow control and congestion control. 197 [RFC1191] defines a mechanism called "Path MTU Discovery" (PMTUD), 198 which makes use of ICMP error messages of type 3 (Destination 199 Unreachable), code 4 (fragmentation needed and DF bit set) to allow 200 systems to determine the MTU of an arbitrary internet path. 202 Appendix D of [RFC4301] provides information about which ICMP error 203 messages are produced by hosts, intermediate routers, or both. 205 2.1.2. ICMP for IP version 6 (ICMPv6) 207 [RFC4443] specifies the Internet Control Message Protocol (ICMPv6) to 208 be used with the Internet Protocol version 6 (IPv6) [RFC2460]. 210 [RFC4443] defines the "Packet Too Big" (type 2, code 0) error 211 message, that is analogous to the ICMP "fragmentation needed and DF 212 bit set" (type 3, code 4) error message. [RFC1981] defines the Path 213 MTU Discovery mechanism for IP Version 6, that makes use of these 214 messages to determine the MTU of an arbitrary internet path. 216 Appendix D of [RFC4301] provides information about which ICMPv6 error 217 messages are produced by hosts, intermediate routers, or both. 219 2.2. Handling of ICMP error messages 221 The Host Requirements RFC [RFC1122] states in Section 4.2.3.9 that a 222 TCP MUST act on an ICMP error message passed up from the IP layer, 223 directing it to the connection that elicited the error. 225 In order to allow ICMP messages to be demultiplexed by the receiving 226 system, part of the original packet that elicited the message is 227 included in the payload of the ICMP error message. Thus, the 228 receiving system can use that information to match the ICMP error to 229 the transport protocol instance that elicited it. 231 Neither the Host Requirements RFC [RFC1122] nor the original TCP 232 specification [RFC0793] recommend any validation checks on the 233 received ICMP messages. Thus, as long as the ICMP payload contains 234 the information that identifies an existing communication instance, 235 it will be processed by the corresponding transport-protocol 236 instance, and the corresponding action will be performed. 238 Therefore, in the case of TCP, an attacker could send a forged ICMP 239 message to the attacked system, and, as long as he is able to guess 240 the four-tuple (i.e., Source IP Address, Source TCP port, Destination 241 IP Address, and Destination TCP port) that identifies the 242 communication instance to be attacked, he will be able to use ICMP to 243 perform a variety of attacks. 245 Generally, the four-tuple required to perform these attacks is not 246 known. However, as discussed in [Watson] and [RFC4953], there are a 247 number of scenarios (notably that of TCP connections established 248 between two BGP routers [RFC4271]), in which an attacker may be able 249 to know or guess the four-tuple that identifies a TCP connection. In 250 such a case, if we assume the attacker knows the two systems involved 251 in the TCP connection to be attacked, both the client-side and the 252 server-side IP addresses could be known or be within a reasonable 253 number of possibilities. Furthermore, as most Internet services use 254 the so-called "well-known" ports, only the client port number might 255 need to be guessed. In such a scenario, an attacker would need to 256 send, in principle, at most 65536 packets to perform any of the 257 attacks described in this document. These issues are exacerbated by 258 the fact that most systems choose the port numbers they use for 259 outgoing connections from a subset of the whole port number space, 260 thus reducing the amount of work needed to successfully perform these 261 attacks. 263 The need to be more more cautious when processing received ICMP error 264 messages in order to mitigate or eliminate the impact of the attacks 265 described in this document has been documented by the Internet 266 Architecture Board (IAB) in [RFC4907]. 268 2.3. Handling of ICMP error messages in the context of IPsec 270 Section 5.2 of [RFC4301] describes the processing of inbound IP 271 Traffic in the case of "unprotected-to-protected". In the case of 272 ICMP, when an unprotected ICMP error message is received, it is 273 matched to the corresponding security association by means of the SPI 274 (Security Parameters Index) included in the payload of the ICMP error 275 message. Then, local policy is applied to determine whether to 276 accept or reject the message and, if accepted, what action to take as 277 a result. For example, if an ICMP unreachable message is received, 278 the implementation must decide whether to act on it, reject it, or 279 act on it with constraints. Section 8 ("Path MTU/DF processing") 280 discusses the processing of unauthenticated ICMP "fragmentation 281 needed and DF bit set" (type 3, code 3) and ICMPv6 "Packet Too Big" 282 (type 2, code 0) messages when an IPsec implementation is configured 283 to 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 PMTUD 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 IP header plus the first 64 306 bits of the packet that elicited the ICMP message are to be included 307 in the payload of the ICMP error message. Thus, it is assumed that 308 all data needed to identify a transport protocol instance and process 309 the ICMP error message is contained in the first 64 bits of the 310 transport protocol header. Section 3.2.2 of [RFC1122] states that 311 "the Internet header and at least the first 8 data octets of the 312 datagram that triggered the error" are to be included in the payload 313 of ICMP error messages, and that "more than 8 octets MAY be sent", 314 thus allowing implementations to include more data from the original 315 packet than those required by the original ICMP specification. The 316 Requirements for IP Version 4 Routers RFC [RFC1812] states that ICMP 317 error messages "SHOULD contain as much of the original datagram as 318 possible without the length of the ICMP datagram exceeding 576 319 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 the 339 authentication header in the original packet could not be used as a 340 counter-measure for ICMP-based attacks 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 error message 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 deployment of protocols for 356 dynamic establishment of security associations makes this unfeasible. 357 Additionally, this would require routers to use certificates with 358 paths compatible for all hosts on the network. Finally, there may be 359 some scenarios, such as embedded devices, in which the processing 360 power requirements of authentication might not allow IPSec 361 authentication to be implemented effectively. 363 4. General counter-measures against ICMP attacks 365 The following subsections describe a number of mitigation techniques 366 that help to eliminate or mitigate the impact of the attacks 367 discussed in this document. Rather than being alternative counter- 368 measures, they can be implemented together to increase the protection 369 against these attacks. 371 4.1. TCP sequence number checking 373 The current specifications do not impose any validity checks on the 374 TCP segment that is contained in the ICMP payload. For instance, no 375 checks are performed to verify that a received ICMP error message has 376 been elicited by a segment that was "in flight" to the destination. 377 Thus, even stale ICMP error messages will be acted upon. 379 Many TCP implementations have incorporated a validation check so 380 makes TCP react only to those ICMP error messages elicited by 381 segments that were "in-flight" to the destination system. These 382 implementations check that the TCP sequence number contained in the 383 payload of the ICMP error message is within the range SND.UNA =< 384 SEG.SEQ < SND.NXT. This means that they require that the sequence 385 number be within the range of the data already sent but not yet 386 acknowledged. If an ICMP error message does not pass this check, it 387 is discarded. 389 Even if an attacker were able to guess the four-tuple that identifies 390 the TCP connection, this additional check would reduce the 391 possibility of considering a spoofed ICMP packet as valid to 392 Flight_Size/2^^32 (where Flight_Size is the number of data bytes 393 already sent to the remote peer, but not yet acknowledged [RFC2581]). 394 For connections in the SYN-SENT or SYN-RECEIVED states, this would 395 reduce the possibility of considering a spoofed ICMP packet as valid 396 to 1/2^^32. For a TCP endpoint with no data "in flight", this would 397 completely eliminate the possibility of success of these attacks. 399 This validation check has been implemented in Linux [Linux] for many 400 years, in OpenBSD [OpenBSD] since 2004, and in FreeBSD [FreeBSD] and 401 NetBSD [NetBSD] since 2005. 403 It is important to note that while this check greatly increases the 404 number of packets required to perform any of the attacks discussed in 405 this document, this may not be enough in those scenarios in which 406 bandwidth is easily available, and/or large TCP windows [RFC1323] are 407 in use. Additionally, this validation check does not help to prevent 408 on-path attacks, that is, attacks performed in scenarios in which the 409 attacker can sniff the packets that correspond to the target TCP 410 connection. 412 It should be note that as there are no timeliness for ICMP error 413 messages, the TCP Sequence Number check described in this section 414 might cause legitimate ICMP error messages to be discarded. 416 4.2. Port randomization 418 As discussed in the previous sections, in order to perform any of the 419 attacks described in this document, an attacker would need to guess 420 (or know) the four-tuple that identifies the connection to be 421 attacked. Increasing the port number range used for outgoing TCP 422 connections, and randomizing the port number chosen for each outgoing 423 TCP conenctions would make it harder for an attacker to perform any 424 of the attacks discussed in this document. 426 [I-D.ietf-tsvwg-port-randomization] discusses a number of algorithms 427 to randomize the ephemeral ports used by clients. 429 4.3. Filtering ICMP error messages based on the ICMP payload 431 The source address of ICMP error messages does not need to be spoofed 432 to perform the attacks described in this document. Therefore, simple 433 filtering based on the source address of ICMP error messages does not 434 serve as a counter-measure against these attacks. However, a more 435 advanced packet filtering can be implemented in middlebox devices 436 such as firewalls and NATs. Middleboxes implementing such advanced 437 filtering look at the payload of the ICMP error messages, and perform 438 ingress and egress packet filtering based on the source IP address of 439 the IP header contained in the payload of the ICMP error message. As 440 the source IP address contained in the payload of the ICMP error 441 message does need to be spoofed to perform the attacks described in 442 this document, this kind of advanced filtering serves as a counter- 443 measure against these attacks. As with traditional egress filtering 444 [IP-filtering], egress filtering based on the ICMP payload can help 445 to prevent users of the network being protected by the firewall from 446 successfully performing ICMP attacks against TCP connections 447 established between external systems. Additionally, ingress 448 filtering based on the ICMP payload can prevent TCP connections 449 established between internal systems from attacks performed by 450 external systems. [ICMP-Filtering] provides examples of ICMP 451 filtering based on the ICMP payload. 453 This filtering technique has been implemented in OpenBSD's Packet 454 Filter [OpenBSD-PF], which has in turn been ported to a number of 455 systems, including FreeBSD [FreeBSD]. 457 5. Blind connection-reset attack 459 5.1. Description 461 When TCP is handed an ICMP error message, it will perform its fault 462 recovery function, as follows: 464 o If the network problem being reported is a hard error, TCP will 465 abort the corresponding connection. 467 o If the network problem being reported is a soft error, TCP will 468 just record this information, and repeatedly retransmit its data 469 until they either get acknowledged, or the connection times out. 471 The Host Requirements RFC [RFC1122] states (in Section 4.2.3.9) that 472 a host SHOULD abort the corresponding connection when receiving an 473 ICMP error message that indicates a "hard error", and states that 474 ICMP error messages of type 3 (Destination Unreachable) codes 2 475 (protocol unreachable), 3 (port unreachable), and 4 (fragmentation 476 needed and DF bit set) should be considered to indicate hard errors. 477 In the case of ICMP port unreachables, the specifications are 478 ambiguous, as Section 4.2.3.9 of [RFC1122] states that TCP SHOULD 479 abort the corresponding connection in response to them, but Section 480 3.2.2.1 of the same RFC ([RFC1122] states that TCP MUST abort the 481 connection in response to them. 483 While [RFC4443] did not exist when [RFC1122] was published, one could 484 extrapolate the concept of "hard errors" to ICMPv6 error messages of 485 type 1 (Destination unreachable) codes 1 (communication with 486 destination administratively prohibited), and 4 (port unreachable). 488 Thus, an attacker could use ICMP to perform a blind connection-reset 489 attack by sending any ICMP error message that indicates a "hard 490 error", to either of the two TCP endpoints of the connection. 491 Because of TCP's fault recovery policy, the connection would be 492 immediately aborted. 494 Some stacks are known to extrapolate ICMP hard errors across TCP 495 connections, increasing the impact of this attack, as a single ICMP 496 packet could bring down all the TCP connections between the 497 corresponding peers. 499 It is important to note that even if TCP itself were protected 500 against the blind connection-reset attack described in [Watson] and 501 [I-D.ietf-tcpm-tcpsecure], by means authentication at the network 502 layer [RFC4301], by means of the TCP MD5 signature option [RFC2385], 503 by means of the TCP-AO [I-D.ietf-tcpm-tcp-auth-opt], or by means of 504 the mechanism proposed in [I-D.ietf-tcpm-tcpsecure], the blind 505 connection-reset attack described in this document would still 506 succeed. 508 5.2. Attack-specific counter-measures 510 An analysis of the circumstances in which ICMP messages that indicate 511 hard errors may be received can shed some light to mitigate the 512 impact of ICMP-based blind connection-reset attacks. 514 ICMP type 3 (Destination Unreachable), code 2 (protocol unreachable) 516 This ICMP error message indicates that the host sending the ICMP 517 error message received a packet meant for a transport protocol it 518 does not support. For connection-oriented protocols such as TCP, 519 one could expect to receive such an error as the result of a 520 connection-establishment attempt. However, it would be strange to 521 get such an error during the life of a connection, as this would 522 indicate that support for that transport protocol has been removed 523 from the system sending the error message during the life of the 524 corresponding connection. 526 ICMP type 3 (Destination Unreachable), code 3 (port unreachable) 528 This error message indicates that the system sending the ICMP 529 error message received a packet meant for a socket (IP address, 530 port number) on which there is no process listening. Those 531 transport protocols which have their own mechanisms for notifying 532 this condition should not be receiving these error messages, as 533 the protocol would signal the port unreachable condition by means 534 of its own messages. Assuming that once a connection is 535 established it is not usual for the transport protocol to change 536 (or be reloaded), it should be unusual to get these error 537 messages. 539 ICMP type 3 (Destination Unreachable), code 4 (fragmentation needed 540 and DF bit set) 542 This error message indicates that an intermediate node needed to 543 fragment a datagram, but the DF (Don't Fragment) bit in the IP 544 header was set. It is considered a soft error when TCP implements 545 PMTUD, and a hard error if TCP does not implement PMTUD. Those 546 TCP/IP stacks that do not implement PMTUD (or have disabled it) 547 but support IP fragmentation/reassembly should not be sending 548 their IP packets with the DF bit set, and thus should not be 549 receiving these ICMP error messages. Some TCP/IP stacks that do 550 not implement PMTUD and that do not support IP fragmentation/ 551 reassembly are known to send their packets with the DF bit set, 552 and thus could legitimately receive these ICMP error messages. 554 ICMPv6 type 1 (Destination Unreachable), code 1 (communication with 555 destination administratively prohibited) 557 This error message indicates that the destination is unreachable 558 because of an administrative policy. For connection-oriented 559 protocols such as TCP, one could expect to receive such an error 560 as the result of a connection-establishment attempt. Receiving 561 such an error for a connection in any of the synchronized states 562 would mean that the administrative policy changed during the life 563 of the connection. However, in the same way this error condition 564 (which was not present when the conenction was established) 565 appeared, it could get solved solved in the near term. 567 ICMPv6 type 1 (Destination Unreachable), code 4 (port unreachable) 569 This error message is analogous to the ICMP type 3 (Destination 570 Unreachable), code 3 (Port unreachable) error message discussed 571 above. Therefore, the same considerations apply. 573 The Host Requirements RFC [RFC1122] states in Section 4.2.3.9 that 574 TCP SHOULD abort the corresponding connection in response to ICMP 575 messages of type 3, codes 2 (protocol unreachable), 3 (port 576 unreachable), and 4 (fragmentation needed and DF bit set). However, 577 Section 3.2.2.1 states that TCP MUST accept an ICMP port unreachable 578 (type 3, code 3) for the same purpose as an RST. Therefore, for ICMP 579 messages of type 3 codes 2 and 4 there is room to go against the 580 advice provided in the existing specifications, while in the case of 581 ICMP messages of type 3 code 3 there is ambiguity in the 582 specifications that may or may not provide some room to go against 583 that advice. 585 Based on this analysis, most popular TCP implementations treat all 586 ICMP "hard errors" received for connections in any of the 587 synchronized states (ESTABLISHED, FIN-WAIT-1, FIN-WAIT-2, CLOSE-WAIT, 588 CLOSING, LAST-ACK or TIME-WAIT)as "soft errors". That is, they do 589 not abort the corresponding connection upon receipt of them. 590 Additionally, they do not extrapolate ICMP errors across TCP 591 connections. This policy is based on the premise that TCP should be 592 as robust as possible. Aborting the connection would be to ignore 593 the valuable feature of the Internet that for many internal failures 594 it reconstructs its function without any disruption of the end points 595 [RFC0816]. 597 It is interesting to note that, as ICMP error messages are 598 unreliable, transport protocols should not depend on them for correct 599 functioning. In the event one of these messages were legitimate, the 600 corresponding connection would eventually time out. Also, 601 applications may still be notified asynchronously about the error 602 contition, and thus may still abort their connections on their own if 603 they consider it appropriate. 605 In scenarios such as that in which an intermediate system sets the DF 606 bit in the segments transmitted by a TCP that does not implement 607 PMTUD, or the TCP at one of the endpoints of the connection is 608 dynamically disabled, TCP would only abort the connection after a 609 USER TIMEOUT [RFC0793], losing responsiveness. However, these 610 scenarios are very unlikely in production environments, and it is 611 probably preferable to potentially lose responsiveness for the sake 612 of robustness. It should also be noted that applications may still 613 be notified asynchronously about the error condition, and thus may 614 still abort their connections on their own if they consider it 615 appropriate. 617 In scenarios of multipath routing or route changes, failures in some 618 (but not all) of the paths may elicit ICMP error messages that would 619 likely not cause a connection abort if any of the counter-measures 620 described in this section were implemented. However, aborting the 621 connection would be to ignore the valuable feature of the Internet 622 that for many internal failures it reconstructs its function without 623 any disruption of the end points [RFC0816]. That is, communication 624 should survive if there is still a working path to the destination 625 system [DClark]. Additionally, applications may still be notified 626 asynchronously about the error condition, and thus may still abort 627 their connections on their own if they consider it appropriate. 629 This counter-measure has been implemented in BSD-derived TCP/IP 630 implementations (e.g., [FreeBSD], [NetBSD], and [OpenBSD]) for more 631 than ten years [Wright][McKusick]. The Linux kernel has also 632 implemented this policy for more than ten years [Linux]. 634 6. Blind throughput-reduction attack 636 6.1. Description 638 The Host requirements RFC [RFC1122] states in Section 4.2.3.9 that 639 hosts MUST react to ICMP Source Quench messages by slowing 640 transmission on the connection. Thus, an attacker could send ICMP 641 Source Quench (type 4, code 0) messages to a TCP endpoint to make it 642 reduce the rate at which it sends data to the other end-point of the 643 connection. [RFC1122] further adds that the RECOMMENDED procedure is 644 to put the corresponding connection in the slow-start phase of TCP's 645 congestion control algorithm [RFC2581]. In the case of those 646 implementations that use an initial congestion window of one segment, 647 a sustained attack would reduce the throughput of the attacked 648 connection to about SMSS (Sender Maximum Segment Size) [RFC2581] 649 bytes per RTT (round-trip time). The throughput achieved during an 650 attack might be a little higher if a larger initial congestion window 651 is in use [RFC3390]. 653 6.2. Attack-specific counter-measures 655 As discussed in the Requirements for IP Version 4 Routers RFC 656 [RFC1812], research seems to suggest that ICMP Source Quench is an 657 ineffective (and unfair) antidote for congestion. [RFC1812] further 658 states that routers SHOULD NOT send ICMP Source Quench messages in 659 response to congestion. Furthermore, TCP implements its own 660 congestion control mechanisms [RFC2581] [RFC3168], that do not depend 661 on ICMP Source Quench messages. 663 Based on this reasoning, a large number of implementations completely 664 ignore ICMP Source Quench messages meant for TCP connections. This 665 behavior has been implemented in, at least, Linux [Linux] since 2004, 666 and in FreeBSD [FreeBSD], NetBSD [NetBSD], and OpenBSD [OpenBSD] 667 since 2005. However, it must be noted that this behaviour violates 668 the requirement in [RFC1122] to react to ICMP Source Quench messages 669 by slowing transmission on the connection. 671 7. Blind performance-degrading attack 673 7.1. Description 675 When one IP system has a large amount of data to send to another 676 system, the data will be transmitted as a series of IP datagrams. It 677 is usually preferable that these datagrams be of the largest size 678 that does not require fragmentation anywhere along the path from the 679 source to the destination. This datagram size is referred to as the 680 Path MTU (PMTU), and is equal to the minimum of the MTUs of each hop 681 in the path. A technique called "Path MTU Discovery" (PMTUD) lets IP 682 systems determine the Path MTU of an arbitrary internet path. 683 [RFC1191] and [RFC1981] specify the PMTUD mechanism for IPv4 and 684 IPv6, respectively. 686 The PMTUD mechanism for IPv4 uses the Don't Fragment (DF) bit in the 687 IP header to dynamically discover the Path MTU. The basic idea 688 behind the PMTUD mechanism is that a source system assumes that the 689 MTU of the path is that of the first hop, and sends all its datagrams 690 with the DF bit set. If any of the datagrams is too large to be 691 forwarded without fragmentation by some intermediate router, the 692 router will discard the corresponding datagram, and will return an 693 ICMP "Destination Unreachable" (type 3) "fragmentation neeed and DF 694 set" (code 4) error message to the sending system. This message will 695 report the MTU of the constricting hop, so that the sending system 696 can reduce the assumed Path-MTU accordingly. 698 For IPv6, intermediate systems do not fragment packets. Thus, 699 there's an "implicit" DF bit set in every packet sent on a network. 700 If any of the datagrams is too large to be forwarded without 701 fragmentation by some intermediate router, the router will discard 702 the corresponding datagram, and will return an ICMPv6 "Packet Too 703 Big" (type 2, code 0) error message to sending system. This message 704 will report the MTU of the constricting hop, so that the sending 705 system can reduce the assumed Path-MTU accordingly. 707 As discussed in both [RFC1191] and [RFC1981], the Path-MTU Discovery 708 mechanism can be used to attack TCP. An attacker could send a forged 709 ICMP "Destination Unreachable, fragmentation needed and DF set" 710 packet (or their ICMPv6 counterpart) to the sending system, 711 advertising a small Next-Hop MTU. As a result, the attacked system 712 would reduce the size of the packets it sends for the corresponding 713 connection accordingly. 715 The effect of this attack is two-fold. On one hand, it will increase 716 the headers/data ratio, thus increasing the overhead needed to send 717 data to the remote TCP end-point. On the other hand, if the attacked 718 system wanted to keep the same throughput it was achieving before 719 being attacked, it would have to increase the packet rate. On 720 virtually all systems this will lead to an increase in the IRQ 721 (Interrrupt ReQuest) rate and protocol processing time, thus 722 increasing processor utilization, and degrading the overall system 723 performance. 725 A particular scenario that may take place is that in which an 726 attacker reports a Next-Hop MTU smaller than or equal to the amount 727 of bytes needed for headers (IP header, plus TCP header). For 728 example, if the attacker reports a Next-Hop MTU of 68 bytes, and the 729 amount of bytes used for headers (IP header, plus TCP header) is 730 larger than 68 bytes, the assumed Path-MTU will not even allow the 731 attacked system to send a single byte of application data without 732 fragmentation. This particular scenario might lead to unpredictable 733 results. Another posible scenario is that in which a TCP connection 734 is being secured by means of IPSec. If the Next-Hop MTU reported by 735 the attacker is smaller than the amount of bytes needed for headers 736 (IP and IPSec, in this case), the assumed Path-MTU will not even 737 allow the attacked system to send a single byte of the TCP header 738 without fragmentation. This is another scenario that may lead to 739 unpredictable results. 741 For IPv4, the reported Next-Hop MTU could be as low as 68 octets, as 742 [RFC0791] requires every internet module to be able to forward a 743 datagram of 68 octets without further fragmentation. For IPv6, the 744 reported Next-Hop MTU could be as low as 1280 octets (the minimum 745 IPv6 MTU) [RFC2460]. 747 7.2. Attack-specific counter-measures 749 The IETF has standardized a Path-MTU Discuvery mechanism called 750 "Packetization Layer Path MTU Discovery" that does not depend on ICMP 751 error messages. Implementation of the aforementioned mechanism in 752 replacement of the traditional PMTUD (specified in [RFC1191] and 753 [RFC1981]) would eliminate this vulnerability. However, it might 754 also lead to an increase of the PMTUD convergence time. 756 This section describes a modification to the PMTUD mechanism 757 specified in [RFC1191] and [RFC1981] that has been implemented in a 758 variety of TCP implementations to improve TCP's resistance to the 759 blind performance-degrading attack described in Section 7.1. The 760 described mechanism basically disregards ICMP messages when a 761 connection makes progress. This modification does not violate any of 762 the requirements stated in [RFC1191] and [RFC1981]. 764 Henceforth, we will refer to both ICMP "fragmentation needed and DF 765 bit set" and ICMPv6 "Packet Too Big" messages as "ICMP Packet Too 766 Big" messages. 768 In addition to the general validation check described in Section 4.1, 769 these implementations include a modification to TCP's reaction to 770 ICMP "Packet Too Big" error messages that disregards them when a 771 connection makes progress, and honors them only after the 772 corresponding data have been retransmitted a specified number of 773 times. This means that upon receipt of an ICMP "Packet Too Big" 774 error message, TCP just records this information, and honors it only 775 when the corresponding data have already been retransmitted a 776 specified number of times. 778 While this basic policy would greatly mitigate the impact of the 779 attack against the PMTUD mechanism, it would also mean that it might 780 take TCP more time to discover the Path-MTU for a TCP connection. 781 This would be particularly annoying for connections that have just 782 been established, as it might take TCP several transmission attempts 783 (and the corresponding timeouts) before it discovers the PMTU for the 784 corresponding connection. Thus, this policy would increase the time 785 it takes for data to begin to be received at the destination host. 787 In order to protect TCP from the attack against the PMTUD mechanism, 788 while still allowing TCP to quickly determine the initial Path-MTU 789 for a connection, the aforementioned implementations have divided the 790 traditional PMTUD mechanism into two stages: Initial Path-MTU 791 Discovery, and Path-MTU Update. 793 The Initial Path-MTU Discovery stage is when TCP tries to send 794 segments that are larger than the ones that have so far been sent and 795 acknowledged for this connection. That is, in the Initial Path-MTU 796 Discovery stage TCP has no record of these large segments getting to 797 the destination host, and thus these implementations believe the 798 network when it reports that these packets are too large to reach the 799 destination host without being fragmented. 801 The Path-MTU Update stage is when TCP tries to send segments that are 802 equal to or smaller than the ones that have already been sent and 803 acknowledged for this connection. During the Path-MTU Update stage, 804 TCP already has knowledge of the estimated Path-MTU for the given 805 connection. Thus, in this case these implementations are more 806 cautious with the errors being reported by the network. 808 In order to allow TCP to distinguish segments between those 809 performing Initial Path-MTU Discovery and those performing Path-MTU 810 Update, two new variables are introduced to TCP: maxsizeacked and 811 maxsizesent. 813 maxsizesent holds the size (in octets) of the largest packet that has 814 so far been sent for this connection. It is initialized to 68 (the 815 minimum IPv4 MTU) when the underlying internet protocol is IPv4, and 816 is initialized to 1280 (the minimum IPv6 MTU) when the underlying 817 internet protocol is IPv6. Whenever a packet larger than maxsizesent 818 octets is sent, maxsizesent is set to that value. 820 On the other hand, maxsizeacked holds the size (in octets) of the 821 largest packet that has so far been acknowledged for this connection. 822 It is initialized to 68 (the minimum IPv4 MTU) when the underlying 823 internet protocol is IPv4, and is initialized to 1280 (the minimum 824 IPv6 MTU) when the underlying internet protocol is IPv6. Whenever an 825 acknowledgement for a packet larger than maxsizeacked octets is 826 received, maxsizeacked is set to the size of that acknowledged 827 packet. 829 Upon receipt of an ICMP "Packet Too Big" error message, the Next-Hop 830 MTU claimed by the ICMP message (henceforth "claimedmtu") is compared 831 with maxsizesent. If claimedmtu is equal to or larger than 832 maxsizesent, then the ICMP error message is silently discarded. The 833 rationale for this is that the ICMP error message cannot be 834 legitimate if it claims to have been elicited by a packet larger than 835 the largest packet we have so far sent for this connection. 837 If this check is passed, claimedmtu is compared with maxsizeacked. 838 If claimedmtu is equal to or larger than maxsizeacked, TCP is 839 supposed to be at the Initial Path-MTU Discovery stage, and thus the 840 ICMP "Packet Too Big" error message is honored immediately. That is, 841 the assumed Path-MTU is updated according to the Next-Hop MTU claimed 842 in the ICMP error message. Also, maxsizesent is reset to the minimum 843 MTU of the internet protocol in use (68 for IPv4, and 1280 for IPv6). 845 On the other hand, if claimedmtu is smaller than maxsizeacked, TCP is 846 supposed to be in the Path-MTU Update stage. At this stage, these 847 implementations are more cautious with the errors being reported by 848 the network, and therefore just record the received error message, 849 and delay the update of the assumed Path-MTU. 851 To perform this delay, one new variable and one new parameter is 852 introduced to TCP: nsegrto and MAXSEGRTO. nsegrto holds the number of 853 times a specified segment has timed out. It is initialized to zero, 854 and is incremented by one every time the corresponding segment times 855 out. MAXSEGRRTO specifies the number of times a given segment must 856 timeout before an ICMP "Packet Too Big" error message can be honored, 857 and can be set, in principle, to any value greater than or equal to 858 0. 860 Thus, if nsegrto is greater than or equal to MAXSEGRTO, and there's a 861 pending ICMP "Packet Too Big" error message, the corresponding error 862 message is processed. At that point, maxsizeacked is set to 863 claimedmtu, and maxsizesent is set to 68 (for IPv4) or 1280 (for 864 IPv6). 866 If while there is a pending ICMP "Packet Too Big" error message the 867 TCP SEQ claimed by the pending message is acknowledged (i.e., an ACK 868 that acknowledges that sequence number is received), then the 869 "pending error" condition is cleared. 871 The rationale behind performing this delayed processing of ICMP 872 "Packet Too Big" messages is that if there is progress on the 873 connection, the ICMP "Packet Too Big" errors must be a false claim. 875 By checking for progress on the connection, rather than just for 876 staleness of the received ICMP messages, TCP is protected from attack 877 even if the offending ICMP messages are "in window", and as a 878 corollary, is made more robust to spurious ICMP messages elicited by, 879 for example, corrupted TCP segments. 881 MAXSEGRTO can be set, in principle, to any value greater than or 882 equal to 0. Setting MAXSEGRTO to 0 would make TCP perform the 883 traditional PMTUD mechanism defined in [RFC1191] and [RFC1981]. A 884 MAXSEGRTO of 1 provides enough protection for most cases. In any 885 case, implementations are free to choose higher values for this 886 constant. MAXSEGRTO could be a function of the Next-Hop MTU claimed 887 in the received ICMP "Packet Too Big" message. That is, higher 888 values for MAXSEGRTO could be imposed when the received ICMP "Packet 889 Too Big" message claims a Next-Hop MTU that is smaller than some 890 specified value. 892 In the event a higher level of protection is desired at the expense 893 of a higher delay in the discovery of the Path-MTU, an implementation 894 could consider TCP to always be in the Path-MTU Update stage, thus 895 always delaying the update of the assumed Path-MTU. 897 Section 7.3 shows the proposed counter-measure in action. 898 Section 7.4 shows the proposed counter-measure in pseudo-code. 900 This behavior has been implemented in NetBSD [NetBSD] and OpenBSD 901 [OpenBSD] since 2005. 903 It is important to note that the mechanism proposed in this section 904 is an improvement to the current Path-MTU discovery mechanism, to 905 mitigate its security implications. The current PMTUD mechanism, as 906 specified by [RFC1191] and [RFC1981], still suffers from some 907 functionality problems [RFC2923] that this document does not aim to 908 address. A mechanism that addresses those issues is described in 909 [RFC4821]. 911 7.3. The counter-measure for the PMTUD attack in action 913 This SECTION shows the proposed counter-measure for the ICMP attack 914 against the PMTUD mechanism in action. It shows both how the fix 915 protects TCP from being attacked and how the counter-measure works in 916 normal scenarios. As discussed in Section 7.2, this section assumes 917 the PMTUD-specific counter-measure is implemented in addition to the 918 TCP sequence number checking described in Section 4.1. 920 Figure 1 illustrates an hypothetical scenario in which two hosts are 921 connected by means of three intermediate routers. It also shows the 922 MTU of each hypothetical hop. All the following subsections assume 923 the network setup of this figure. 925 Also, for simplicity sake, all subsections assume an IP header of 20 926 octets and a TCP header of 20 octets. Thus, for example, when the 927 PMTU is assumed to be 1500 octets, TCP will send segments that 928 contain, at most, 1460 octets of data. 930 For simplicity sake, all the following subsections assume the TCP 931 implementation at Host 1 has chosen a a MAXSEGRTO of 1. 933 +----+ +----+ +----+ +----+ +----+ 934 | H1 |--------| R1 |--------| R2 |--------| R3 |--------| H2 | 935 +----+ +----+ +----+ +----+ +----+ 936 MTU=4464 MTU=2048 MTU=1500 MTU=4464 938 Figure 1: Hypothetical scenario 940 7.3.1. Normal operation for bulk transfers 942 This subsection shows the proposed counter-measure in normal 943 operation, when a TCP connection is used for bulk transfers. That 944 is, it shows how the proposed counter-measure works when there is no 945 attack taking place, and a TCP connection is used for transferring 946 large amounts of data. This section assumes that just after the 947 connection is established, one of the TCP endpoints begins to 948 transfer data in packets that are as large as possible. 950 Host 1 Host 2 952 1. --> --> 953 2. <-- <-- 954 3. --> --> 955 4. --> --> 956 5. <--- ICMP "Packet Too Big" MTU=2048, TCPseq#=101 <--- R1 957 6. --> --> 958 7. <--- ICMP "Packet Too Big" MTU=1500, TCPseq#=101 <--- R2 959 8. --> --> 960 9. <-- <-- 962 Figure 2: Normal operation for bulk transfers 964 nsegrto is initialized to zero. Both maxsizeacked and maxsizesent 965 are initialized to the minimum MTU for the internet protocol being 966 used (68 for IPv4, and 1280 for IPv6). 968 In lines 1 to 3 the three-way handshake takes place, and the 969 connection is established. In line 4, H1 tries to send a full-sized 970 TCP segment. As described by [RFC1191] and [RFC1981], in this case 971 TCP will try to send a segment with 4424 bytes of data, which will 972 result in an IP packet of 4464 octets. Therefore, maxsizesent is set 973 to 4464. When the packet reaches R1, it elicits an ICMP "Packet Too 974 Big" error message. 976 In line 5, H1 receives the ICMP error message, which reports a Next- 977 Hop MTU of 2048 octets. After performing the TCP sequence number 978 check described in Section 4.1, the Next-Hop MTU reported by the ICMP 979 error message (claimedmtu) is compared with maxsizesent. As it is 980 smaller than maxsizesent, it passes the check, and thus is then 981 compared with maxsizeacked. As claimedmtu is larger than 982 maxsizeacked, TCP assumes that the corresponding TCP segment was 983 performing the Initial PMTU Discovery. Therefore, the TCP at H1 984 honors the ICMP message by updating the assumed Path-MTU. maxsizesent 985 is reset to the minimum MTU of the internet protocol in use (68 for 986 IPv4, and 1280 for IPv6). 988 In line 6, the TCP at H1 sends a segment with 2008 bytes of data, 989 which results in an IP packet of 2048 octets. maxsizesent is thus set 990 to 2008 bytes. When the packet reaches R2, it elicits an ICMP 991 "Packet Too Big" error message. 993 In line 7, H1 receives the ICMP error message, which reports a Next- 994 Hop MTU of 1500 octets. After performing the TCP sequence number 995 check, the Next-Hop MTU reported by the ICMP error message 996 (claimedmtu) is compared with maxsizesent. As it is smaller than 997 maxsizesent, it passes the check, and thus is then compared with 998 maxsizeacked. As claimedmtu is larger than maxsizeacked, TCP assumes 999 that the corresponding TCP segment was performing the Initial PMTU 1000 Discovery. Therefore, the TCP at H1 honors the ICMP message by 1001 updating the assumed Path-MTU. maxsizesent is reset to the minimum 1002 MTU of the internet protocol in use. 1004 In line 8, the TCP at H1 sends a segment with 1460 bytes of data, 1005 which results in an IP packet of 1500 octets. maxsizesent is thus set 1006 to 1500. This packet reaches H2, where it elicits an acknowledgement 1007 (ACK) segment. 1009 In line 9, H1 finally gets the acknowledgement for the data segment. 1010 As the corresponding packet was larger than maxsizeacked, TCP updates 1011 maxsizeacked, setting it to 1500. At this point TCP has discovered 1012 the Path-MTU for this TCP connection. 1014 7.3.2. Operation during Path-MTU changes 1016 Let us suppose a TCP connection between H1 and H2 has already been 1017 established, and that the PMTU for the connection has already been 1018 discovered to be 1500. At this point, both maxsizesent and 1019 maxsizeacked are equal to 1500, and nsegrto is equal to 0. Suppose 1020 some time later the PMTU decreases to 1492. For simplicity, let us 1021 suppose that the Path-MTU has decreased because the MTU of the link 1022 between R2 and R3 has decreased from 1500 to 1492. Figure 3 1023 illustrates how the proposed counter-measure would work in this 1024 scenario. 1026 Host 1 Host 2 1028 1. (Path-MTU decreases) 1029 2. --> --> 1030 3. <--- ICMP "Packet Too Big" MTU=1492, TCPseq#=100 <--- R2 1031 4. (Segment times out) 1032 5. --> --> 1033 6. <-- <-- 1035 Figure 3: Operation during Path-MTU changes 1037 In line 1, the Path-MTU for this connection decreases from 1500 to 1038 1492. In line 2, the TCP at H1, without being aware of the Path-MTU 1039 change, sends a 1500-byte packet to H2. When the packet reaches R2, 1040 it elicits an ICMP "Packet Too Big" error message. 1042 In line 3, H1 receives the ICMP error message, which reports a Next- 1043 Hop MTU of 1492 octets. After performing the TCP sequence number 1044 check, the Next-Hop MTU reported by the ICMP error message 1045 (claimedmtu) is compared with maxsizesent. As claimedmtu is smaller 1046 than maxsizesent, it is then compared with maxsizeacked. As 1047 claimedmtu is smaller than maxsizeacked (full-sized packets were 1048 getting to the remote end-point), this packet is assumed to be 1049 performing Path-MTU Update. And a "pending error" condition is 1050 recorded. 1052 In line 4, the segment times out. Thus, nsegrto is incremented by 1. 1053 As nsegrto is greater than or equal to MAXSEGRTO, the assumed Path- 1054 MTU is updated. nsegrto is reset to 0, and maxsizeacked is set to 1055 claimedmtu, and maxsizesent is set to the minimum MTU of the internet 1056 protocol in use. 1058 In line 5, H1 retransmits the data using the updated PMTU, and thus 1059 maxsizesent is set to 1492. The resulting packet reaches H2, where 1060 it elicits an acknowledgement (ACK) segment. 1062 In line 6, H1 finally gets the acknowledgement for the data segment. 1063 At this point TCP has discovered the new Path-MTU for this TCP 1064 connection. 1066 7.3.3. Idle connection being attacked 1068 Let us suppose a TCP connection between H1 and H2 has already been 1069 established, and the PMTU for the connection has already been 1070 discovered to be 1500. Figure 4 shows a sample time-line diagram 1071 that illustrates an idle connection being attacked. 1073 Host 1 Host 2 1075 1. --> --> 1076 2. <-- <-- 1077 3. <--- ICMP "Packet Too Big" MTU=68, TCPseq#=100 <--- 1078 4. <--- ICMP "Packet Too Big" MTU=68, TCPseq#=100 <--- 1079 5. <--- ICMP "Packet Too Big" MTU=68, TCPseq#=100 <--- 1081 Figure 4: Idle connection being attacked 1083 In line 1, H1 sends its last bunch of data. At line 2, H2 1084 acknowledges the receipt of these data. Then the connection becomes 1085 idle. In lines 3, 4, and 5, an attacker sends forged ICMP "Packet 1086 Too Big" error messages to H1. Regardless of how many packets it 1087 sends and the TCP sequence number each ICMP packet includes, none of 1088 these ICMP error messages will pass the TCP sequence number check 1089 described in Section 4.1, as H1 has no unacknowledged data in flight 1090 to H2. Therefore, the attack does not succeed. 1092 7.3.4. Active connection being attacked after discovery of the Path-MTU 1094 Let us suppose an attacker attacks a TCP connection for which the 1095 PMTU has already been discovered. In this case, as illustrated in 1096 Figure 1, the PMTU would be found to be 1500 bytes. Figure 5 shows a 1097 possible packet exchange. 1099 Host 1 Host 2 1101 1. --> --> 1102 2. --> --> 1103 3. --> --> 1104 4. --> --> 1105 5. <--- ICMP "Packet Too Big" MTU=68, TCPseq#=100 <--- 1106 6. <-- <-- 1108 Figure 5: Active connection being attacked after discovery of PMTU 1110 As we assume the PMTU has already been discovered, we also assume 1111 both maxsizesent and maxsizeacked are equal to 1500. We assume 1112 nsegrto is equal to zero, as there have been no segment timeouts. 1114 In lines 1, 2, 3, and 4, H1 sends four data segments to H2. In line 1115 5, an attacker sends a forged ICMP packet to H1. We assume the 1116 attacker is lucky enough to guess both the four-tuple that identifies 1117 the connection and a valid TCP sequence number. As the Next-Hop MTU 1118 claimed in the ICMP "Packet Too Big" message (claimedmtu) is smaller 1119 than maxsizeacked, this packet is assumed to be performing Path-MTU 1120 Update. Thus, the error message is recorded. 1122 In line 6, H1 receives an acknowledgement for the segment sent in 1123 line 1, before it times out. At this point, the "pending error" 1124 condition is cleared, and the recorded ICMP "Packet Too Big" error 1125 message is ignored. Therefore, the attack does not succeed. 1127 7.3.5. TCP peer attacked when sending small packets just after the 1128 three-way handshake 1130 This section analyzes an scenario in which a TCP peer that is sending 1131 small segments just after the connection has been established, is 1132 attacked. The connection could be being used by protocols such as 1133 SMTP [RFC2821] and HTTP [RFC2616], for example, which usually behave 1134 like this. 1136 Figure 6 shows a possible packet exchange for such scenario. 1138 Host 1 Host 2 1140 1. --> --> 1141 2. <-- <-- 1142 3. --> --> 1143 4. --> --> 1144 5. <-- <-- 1145 6. --> --> 1146 7. --> --> 1147 8. <--- ICMP "Packet Too Big" MTU=150, TCPseq#=101 <--- 1149 Figure 6: TCP peer attacked when sending small packets just after the 1150 three-way handshake 1152 nsegrto is initialized to zero. Both maxsizesent and maxsizeacked 1153 are initialized to the minimum MTU for the internet protocol being 1154 used (68 for IPv4, and 1280 for IPv6). 1156 In lines 1 to 3 the three-way handshake takes place, and the 1157 connection is established. At this point, the assumed Path-MTU for 1158 this connection is 4464. In line 4, H1 sends a small segment (which 1159 results in a 140-byte packet) to H2. maxsizesent is thus set to 140. 1160 In line 5 this segment is acknowledged, and thus maxsizeacked is set 1161 to 140. 1163 In lines 6 and 7, H1 sends two small segments to H2. In line 8, 1164 while the segments from lines 6 and 7 are still in flight to H2, an 1165 attacker sends a forged ICMP "Packet Too Big" error message to H1. 1166 Assuming the attacker is lucky enough to guess a valid TCP sequence 1167 number, this ICMP message will pass the TCP sequence number check. 1168 The Next-Hop MTU reported by the ICMP error message (claimedmtu) is 1169 then compared with maxsizesent. As claimedmtu is larger than 1170 maxsizesent, the ICMP error message is silently discarded. 1171 Therefore, the attack does not succeed. 1173 7.4. Pseudo-code for the counter-measure for the blind performance- 1174 degrading attack 1176 This section contains a pseudo-code version of the counter-measure 1177 described in Section 7.2 for the blind performance-degrading attack 1178 described in Section 7. It is meant as guidance for developers on 1179 how to implement this counter-measure. 1181 The pseudo-code makes use of the following variables, constants, and 1182 functions: 1184 ack 1185 Variable holding the acknowledgement number contained in the TCP 1186 segment that has just been received. 1188 acked_packet_size 1189 Variable holding the packet size (data, plus headers) the ACK that 1190 has just been received is acknowledging. 1192 adjust_mtu() 1193 Function that adjusts the MTU for this connection, according to 1194 the ICMP "Packet Too Big" that was last received. 1196 claimedmtu 1197 Variable holding the Next-Hop MTU advertised by the ICMP "Packet 1198 Too Big" error message. 1200 claimedtcpseq 1201 Variable holding the TCP sequence number contained in the payload 1202 of the ICMP "Packet Too Big" message that has just been received 1203 or was last recorded. 1205 current_mtu 1206 Variable holding the assumed Path-MTU for this connection. 1208 drop_message() 1209 Function that performs the necessary actions to drop the ICMP 1210 message being processed. 1212 initial_mtu 1213 Variable holding the MTU for new connections, as explained in 1214 [RFC1191] and [RFC1981]. 1216 maxsizeacked 1217 Variable holding the largest packet size (data, plus headers) that 1218 has so far been acked for this connection, as explained in 1219 Section 7.2. 1221 maxsizesent 1222 Variable holding the largest packet size (data, plus headers) that 1223 has so far been sent for this connection, as explained in 1224 Section 7.2. 1226 nsegrto 1227 Variable holding the number of times this segment has timed out, 1228 as explained in Section 7.2. 1230 packet_size 1231 Variable holding the size of the IP datagram being sent. 1233 pending_message 1234 Variable (flag) that indicates whether there is a pending ICMP 1235 "Packet Too Big" message to be processed. 1237 save_message() 1238 Function that records the ICMP "Packet Too Big" message that has 1239 just been received. 1241 MINIMUM_MTU 1242 Constant holding the minimum MTU for the internet protocol in use 1243 (68 for IPv4, and 1280 for IPv6). 1245 MAXSEGRTO 1246 Constant holding the number of times a given segment must timeout 1247 before an ICMP "Packet Too Big" error message can be honored. 1249 EVENT: New TCP connection 1251 current_mtu = initial_mtu; 1252 maxsizesent = MINIMUM_MTU; 1253 maxsizeacked = MINIMUM_MTU; 1254 nsegrto = 0; 1255 pending_message = 0; 1257 EVENT: Segment is sent 1258 if (packet_size > maxsizesent) 1259 maxsizesent = packet_size; 1261 EVENT: Segment is received 1263 if (acked_packet_size > maxsizeacked) 1264 maxsizeacked = acked_packet_size; 1266 if (pending_message) 1267 if (ack > claimedtcpseq){ 1268 pending_message = 0; 1269 nsegrto = 0; 1270 } 1272 EVENT: ICMP "Packet Too Big" message is received 1273 if (claimedtcpseq < SND.UNA || claimed_TCP_SEQ >= SND.NXT){ 1274 drop_message(); 1275 } 1277 else { 1278 if (claimedmtu >= maxsizesent || claimedmtu >= current_mtu) 1279 drop_message(); 1281 else { 1282 if (claimedmtu > maxsizeacked){ 1283 adjust_mtu(); 1284 current_mtu = claimedmtu; 1285 maxsizesent = MINIMUM_MTU; 1286 } 1288 else { 1289 pending_message = 1; 1290 save_message(); 1291 } 1292 } 1293 } 1295 EVENT: Segment times out 1297 nsegrto++; 1299 if (pending_message && nsegrto >= MAXSEGRTO){ 1300 adjust_mtu(); 1301 nsegrto = 0; 1302 pending_message = 0; 1303 maxsizeacked = claimedmtu; 1304 maxsizesent = MINIMUM_MTU; 1305 current_mtu = claimedmtu; 1306 } 1308 Notes: 1309 All comparisions between sequence numbers must be performed using 1310 sequence number arithmethic. 1311 The pseudo-code implements the mechanism described in Section 7.2, 1312 the TCP sequence number checking described in Section 4.1, and the 1313 validation check on the advertised Next-Hop MTU described in 1314 [RFC1191] and [RFC1981]. 1316 8. Security Considerations 1318 This document describes the use of ICMP error messages to perform a 1319 number of attacks against the TCP protocol, and describes a number of 1320 widely-implemented counter-measures that either eliminate or reduce 1321 the impact of these attacks when they are performed by off-path 1322 attackers. 1324 9. Acknowledgements 1326 This document was inspired by Mika Liljeberg, while discussing some 1327 issues related to [I-D.ietf-tcpm-tcp-soft-errors] by private e-mail. 1328 The author would like to thank (in alphabetical order): Bora Akyol, 1329 Mark Allman, Ran Atkinson, James Carlson, Alan Cox, Theo de Raadt, 1330 Wesley Eddy, Ted Faber, Juan Fraschini, Markus Friedl, Guillermo 1331 Gont, John Heffner, Alfred Hoenes, Vivek Kakkar, Michael Kerrisk, 1332 Mika Liljeberg, Matt Mathis, David Miller, Miles Nordin, Eloy Paris, 1333 Kacheong Poon, Andrew Powell, Pekka Savola, Pyda Srisuresh, Fred 1334 Templin, and Joe Touch for contributing many valuable comments. 1336 Juan Fraschini and the author of this document implemented freely- 1337 available audit tools to help vendors audit their systems by 1338 reproducing the attacks discussed in this document. This tools are 1339 available at http://www.gont.com.ar/tools/index.html . 1341 Markus Friedl, Chad Loder, and the author of this document, produced 1342 and tested in OpenBSD [OpenBSD] the first implementation of the 1343 counter-measure described in Section 7.2. This first implementation 1344 helped to test the effectiveness of the ideas introduced in this 1345 document, and has served as a reference implementation for other 1346 operating systems. 1348 The author would like to thank the UK's Centre for the Protection of 1349 National Infrastructure (CPNI) -- formerly National Infrastructure 1350 Security Co-ordination Centre (NISCC) -- for coordinating the 1351 disclosure of these issues with a large number of vendors and CSIRTs 1352 (Computer Security Incident Response Teams). 1354 The author wishes to express deep and heartfelt gratitude to Jorge 1355 Oscar Gont and Nelida Garcia, for their precious motivation and 1356 guidance. 1358 10. References 1359 10.1. Normative References 1361 [RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791, 1362 September 1981. 1364 [RFC0792] Postel, J., "Internet Control Message Protocol", STD 5, 1365 RFC 792, September 1981. 1367 [RFC0793] Postel, J., "Transmission Control Protocol", STD 7, 1368 RFC 793, September 1981. 1370 [RFC1122] Braden, R., "Requirements for Internet Hosts - 1371 Communication Layers", STD 3, RFC 1122, October 1989. 1373 [RFC1191] Mogul, J. and S. Deering, "Path MTU discovery", RFC 1191, 1374 November 1990. 1376 [RFC1812] Baker, F., "Requirements for IP Version 4 Routers", 1377 RFC 1812, June 1995. 1379 [RFC1981] McCann, J., Deering, S., and J. Mogul, "Path MTU Discovery 1380 for IP version 6", RFC 1981, August 1996. 1382 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1383 Requirement Levels", BCP 14, RFC 2119, March 1997. 1385 [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 1386 (IPv6) Specification", RFC 2460, December 1998. 1388 [RFC4301] Kent, S. and K. Seo, "Security Architecture for the 1389 Internet Protocol", RFC 4301, December 2005. 1391 [RFC4443] Conta, A., Deering, S., and M. Gupta, "Internet Control 1392 Message Protocol (ICMPv6) for the Internet Protocol 1393 Version 6 (IPv6) Specification", RFC 4443, March 2006. 1395 10.2. Informative References 1397 [DClark] Clark, D., "The Design Philosophy of the DARPA Internet 1398 Protocols", Computer Communication Review Vol. 18, No. 4, 1399 1988. 1401 [FreeBSD] The FreeBSD Project, "http://www.freebsd.org". 1403 [I-D.ietf-tcpm-tcp-auth-opt] 1404 Touch, J., Mankin, A., and R. Bonica, "The TCP 1405 Authentication Option", draft-ietf-tcpm-tcp-auth-opt-05 1406 (work in progress), July 2009. 1408 [I-D.ietf-tcpm-tcp-soft-errors] 1409 Gont, F., "TCP's Reaction to Soft Errors", 1410 draft-ietf-tcpm-tcp-soft-errors-09 (work in progress), 1411 November 2008. 1413 [I-D.ietf-tcpm-tcpsecure] 1414 Ramaiah, A., Stewart, R., and M. Dalal, "Improving TCP's 1415 Robustness to Blind In-Window Attacks", 1416 draft-ietf-tcpm-tcpsecure-11 (work in progress), 1417 November 2008. 1419 [I-D.ietf-tsvwg-port-randomization] 1420 Larsen, M. and F. Gont, "Port Randomization", 1421 draft-ietf-tsvwg-port-randomization-04 (work in progress), 1422 July 2009. 1424 [ICMP-Filtering] 1425 Gont, F., "Filtering of ICMP error messages", http:// 1426 www.gont.com.ar/papers/ 1427 filtering-of-icmp-error-messages.pdf. 1429 [IP-filtering] 1430 NISCC, "NISCC Technical Note 01/2006: Egress and Ingress 1431 Filtering", http://www.niscc.gov.uk/niscc/docs/ 1432 re-20060420-00294.pdf?lang=en, 2006. 1434 [Linux] The Linux Project, "http://www.kernel.org". 1436 [McKusick] 1437 McKusick, M., Bostic, K., Karels, M., and J. Quarterman, 1438 "The Design and Implementation of the 4.4BSD Operating 1439 System", Addison-Wesley , 1996. 1441 [NISCC] NISCC, "NISCC Vulnerability Advisory 532967/NISCC/ICMP: 1442 Vulnerability Issues in ICMP packets with TCP payloads", 1443 http://www.niscc.gov.uk/niscc/docs/ 1444 al-20050412-00308.html?lang=en, 2005. 1446 [NetBSD] The NetBSD Project, "http://www.netbsd.org". 1448 [OpenBSD] The OpenBSD Project, "http://www.openbsd.org". 1450 [OpenBSD-PF] 1451 The OpenBSD Packet Filter, 1452 "http://www.openbsd.org/faq/pf/". 1454 [RFC0816] Clark, D., "Fault isolation and recovery", RFC 816, 1455 July 1982. 1457 [RFC1321] Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321, 1458 April 1992. 1460 [RFC1323] Jacobson, V., Braden, B., and D. Borman, "TCP Extensions 1461 for High Performance", RFC 1323, May 1992. 1463 [RFC2385] Heffernan, A., "Protection of BGP Sessions via the TCP MD5 1464 Signature Option", RFC 2385, August 1998. 1466 [RFC2581] Allman, M., Paxson, V., and W. Stevens, "TCP Congestion 1467 Control", RFC 2581, April 1999. 1469 [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., 1470 Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext 1471 Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999. 1473 [RFC2821] Klensin, J., "Simple Mail Transfer Protocol", RFC 2821, 1474 April 2001. 1476 [RFC2923] Lahey, K., "TCP Problems with Path MTU Discovery", 1477 RFC 2923, September 2000. 1479 [RFC3168] Ramakrishnan, K., Floyd, S., and D. Black, "The Addition 1480 of Explicit Congestion Notification (ECN) to IP", 1481 RFC 3168, September 2001. 1483 [RFC3390] Allman, M., Floyd, S., and C. Partridge, "Increasing TCP's 1484 Initial Window", RFC 3390, October 2002. 1486 [RFC4271] Rekhter, Y., Li, T., and S. Hares, "A Border Gateway 1487 Protocol 4 (BGP-4)", RFC 4271, January 2006. 1489 [RFC4821] Mathis, M. and J. Heffner, "Packetization Layer Path MTU 1490 Discovery", RFC 4821, March 2007. 1492 [RFC4907] Aboba, B., "Architectural Implications of Link 1493 Indications", RFC 4907, June 2007. 1495 [RFC4953] Touch, J., "Defending TCP Against Spoofing Attacks", 1496 RFC 4953, July 2007. 1498 [US-CERT] US-CERT, "US-CERT Vulnerability Note VU#222750: TCP/IP 1499 Implementations do not adequately validate ICMP error 1500 messages", http://www.kb.cert.org/vuls/id/222750, 2005. 1502 [Watson] Watson, P., "Slipping in the Window: TCP Reset Attacks", 1503 2004 CanSecWest Conference , 2004. 1505 [Wright] Wright, G. and W. Stevens, "TCP/IP Illustrated, Volume 2: 1506 The Implementation", Addison-Wesley , 1994. 1508 Appendix A. Changes from previous versions of the draft (to be removed 1509 by the RFC Editor before publishing this document as an 1510 RFC) 1512 A.1. Changes from draft-ietf-tcpm-icmp-attacks-05 1514 o Addresses feedback submitted by Wes Eddy 1515 (http://www.ietf.org/mail-archive/web/tcpm/current/msg04573.html 1516 and 1517 http://www.ietf.org/mail-archive/web/tcpm/current/msg04574.html) 1518 and Joe Touch (on June 8th... couldn't find online ref, sorry) on 1519 the TCPM WG mailing-list. 1521 A.2. Changes from draft-ietf-tcpm-icmp-attacks-04 1523 o The draft had expired and thus is resubmitted with no further 1524 changes. Currently working on a rev of the document (Please send 1525 feedback!). 1527 A.3. Changes from draft-ietf-tcpm-icmp-attacks-03 1529 o The draft had expired and thus is resubmitted with no further 1530 changes. 1532 A.4. Changes from draft-ietf-tcpm-icmp-attacks-02 1534 o Added a disclaimer to indicate that this document does not update 1535 the current specifications. 1537 o Addresses feedback sent off-list by Alfred Hoenes. 1539 o The text (particulary that which describes the counter-measures) 1540 was reworded to document what current implementations are doing, 1541 rather than "proposing" the implementation of the counter- 1542 measures. 1544 o Some text has been removed: we're just documenting the problem, 1545 and what existing implementations have done. 1547 o Miscelaneous editorial changes. 1549 A.5. Changes from draft-ietf-tcpm-icmp-attacks-01 1551 o Fixed references to the antispoof documents (were hardcoded and 1552 missing in the References Section). 1554 o The draft had expired and thus is resubmitted with only a minor 1555 editorial change. 1557 A.6. Changes from draft-ietf-tcpm-icmp-attacks-00 1559 o Added references to the specific sections of each of the 1560 referenced specifications 1562 o Corrected the threat analysys 1564 o Added clarification about whether the counter-measures violate the 1565 current specifications or not. 1567 o Changed text so that the document fits better in the Informational 1568 path 1570 o Added a specific section on IPsec (Section 2.3) 1572 o Added clarification and references on the use of ICMP filtering 1573 based on the ICMP payload 1575 o Updated references to obsoleted RFCs 1577 o Added a discussion of multipath scenarios, and possible lose in 1578 responsiveness resulting from the reaction to hard errors as soft 1579 errors 1581 o Miscellaneous editorial changes 1583 A.7. Changes from draft-gont-tcpm-icmp-attacks-05 1585 o Removed RFC 2119 wording to make the draft suitable for 1586 publication as an Informational RFC. 1588 o Added additional checks that should be performed on ICMP error 1589 messages (checksum of the IP header in the ICMP payload, and 1590 others). 1592 o Added clarification of the rationale behind each the TCP SEQ check 1594 o Miscellaneous editorial changes 1596 A.8. Changes from draft-gont-tcpm-icmp-attacks-04 1598 o Added section on additional considerations for validating ICMP 1599 error messages 1601 o Added reference to (draft) [RFC4907] 1603 o Added stress on the fact that ICMP error messages are unreliable 1605 o Miscellaneous editorial changes 1607 A.9. Changes from draft-gont-tcpm-icmp-attacks-03 1609 o Added references to existing implementations of the proposed 1610 counter-measures 1612 o The discussion in Section 4 was improved 1614 o The discussion of the blind connection-reset vulnerability was 1615 expanded and improved 1617 o The proposed counter-measure for the attack against the PMTUD was 1618 improved and simplified 1620 o Section 7.4 was added 1622 o Miscellaneous editorial changes 1624 A.10. Changes from draft-gont-tcpm-icmp-attacks-02 1626 o Fixed errors in in the discussion of the blind connection-reset 1627 attack 1629 o The proposed counter-measure for the attack against the PMTUD 1630 mechanism was refined to allow quick discovery of the Path-MTU 1632 o Section 7.3 was added so as to clarify the operation of the 1633 counter-measure for the attack against the PMTUD mechanism 1635 o Added CPNI contact information. 1637 o Miscellaneous editorial changes 1639 A.11. Changes from draft-gont-tcpm-icmp-attacks-01 1641 o The document was restructured for easier reading 1642 o A discussion of ICMPv6 was added in several sections of the 1643 document 1645 o Added Section on Acknowledgement number checking 1647 o Added Section 4.3 1649 o Added Section 7 1651 o Fixed typo in the ICMP types, in several places 1653 o Fixed typo in the TCP sequence number check formula 1655 o Miscellaneous editorial changes 1657 A.12. Changes from draft-gont-tcpm-icmp-attacks-00 1659 o Added a proposal to change the handling of the so-called ICMP hard 1660 errors during the synchronized states 1662 o Added a summary of the relevant RFCs in several sections 1664 o Miscellaneous editorial changes 1666 Author's Address 1668 Fernando Gont 1669 Universidad Tecnologica Nacional / Facultad Regional Haedo 1670 Evaristo Carriego 2644 1671 Haedo, Provincia de Buenos Aires 1706 1672 Argentina 1674 Phone: +54 11 4650 8472 1675 Email: fernando@gont.com.ar 1676 URI: http://www.gont.com.ar