idnits 2.17.1 draft-ietf-tcpm-icmp-attacks-09.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** You're using the IETF Trust Provisions' Section 6.b License Notice from 12 Sep 2009 rather than the newer Notice from 28 Dec 2009. (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 : ---------------------------------------------------------------------------- == 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 contain a disclaimer for pre-RFC5378 work, and may have content which was first submitted before 10 November 2008. The disclaimer is necessary when there are original authors that you have been unable to contact, or if some do not wish to grant the BCP78 rights to the IETF Trust. If you are able to get all authors (current and original) to grant those rights, you can and should remove the disclaimer; otherwise, the disclaimer is needed and you can ignore this comment. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (January 19, 2010) is 5204 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-08 == Outdated reference: A later version (-03) exists of draft-ietf-tcpm-tcp-security-00 == Outdated reference: A later version (-13) exists of draft-ietf-tcpm-tcpsecure-12 == Outdated reference: A later version (-09) exists of draft-ietf-tsvwg-port-randomization-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 2616 (Obsoleted by RFC 7230, RFC 7231, RFC 7232, RFC 7233, RFC 7234, RFC 7235) Summary: 4 errors (**), 0 flaws (~~), 6 warnings (==), 6 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 January 19, 2010 5 Intended status: Informational 6 Expires: July 23, 2010 8 ICMP attacks against TCP 9 draft-ietf-tcpm-icmp-attacks-09.txt 11 Abstract 13 This document discusses the use of the Internet Control Message 14 Protocol (ICMP) to perform a variety of attacks against the 15 Transmission Control Protocol (TCP) and other similar protocols. 16 Additionally, describes a number of widely implemented modifications 17 to TCP's handling of ICMP error messages that help to mitigate these 18 issues. 20 Status of this Memo 22 This Internet-Draft is submitted to IETF in full conformance with the 23 provisions of BCP 78 and BCP 79. 25 Internet-Drafts are working documents of the Internet Engineering 26 Task Force (IETF), its areas, and its working groups. Note that 27 other groups may also distribute working documents as Internet- 28 Drafts. 30 Internet-Drafts are draft documents valid for a maximum of six months 31 and may be updated, replaced, or obsoleted by other documents at any 32 time. It is inappropriate to use Internet-Drafts as reference 33 material or to cite them other than as "work in progress." 35 The list of current Internet-Drafts can be accessed at 36 http://www.ietf.org/ietf/1id-abstracts.txt. 38 The list of Internet-Draft Shadow Directories can be accessed at 39 http://www.ietf.org/shadow.html. 41 This Internet-Draft will expire on July 23, 2010. 43 Copyright Notice 45 Copyright (c) 2010 IETF Trust and the persons identified as the 46 document authors. All rights reserved. 48 This document is subject to BCP 78 and the IETF Trust's Legal 49 Provisions Relating to IETF Documents 50 (http://trustee.ietf.org/license-info) in effect on the date of 51 publication of this document. Please review these documents 52 carefully, as they describe your rights and restrictions with respect 53 to this document. Code Components extracted from this document must 54 include Simplified BSD License text as described in Section 4.e of 55 the Trust Legal Provisions and are provided without warranty as 56 described in the BSD License. 58 This document may contain material from IETF Documents or IETF 59 Contributions published or made publicly available before November 60 10, 2008. The person(s) controlling the copyright in some of this 61 material may not have granted the IETF Trust the right to allow 62 modifications of such material outside the IETF Standards Process. 63 Without obtaining an adequate license from the person(s) controlling 64 the copyright in such materials, this document may not be modified 65 outside the IETF Standards Process, and derivative works of it may 66 not be created outside the IETF Standards Process, except to format 67 it for publication as an RFC or to translate it into languages other 68 than English. 70 Table of Contents 72 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 73 2. Background . . . . . . . . . . . . . . . . . . . . . . . . . . 5 74 2.1. The Internet Control Message Protocol (ICMP) . . . . . . . 5 75 2.1.1. ICMP for IP version 4 (ICMP) . . . . . . . . . . . . . 5 76 2.1.2. ICMP for IP version 6 (ICMPv6) . . . . . . . . . . . . 6 77 2.2. Handling of ICMP error messages . . . . . . . . . . . . . 6 78 2.3. Handling of ICMP error messages in the context of IPsec . 7 79 3. Constraints in the possible solutions . . . . . . . . . . . . 8 80 4. General counter-measures against ICMP attacks . . . . . . . . 9 81 4.1. TCP sequence number checking . . . . . . . . . . . . . . . 9 82 4.2. Port randomization . . . . . . . . . . . . . . . . . . . . 10 83 4.3. Filtering ICMP error messages based on the ICMP payload . 10 84 5. Blind connection-reset attack . . . . . . . . . . . . . . . . 11 85 5.1. Description . . . . . . . . . . . . . . . . . . . . . . . 11 86 5.2. Attack-specific counter-measures . . . . . . . . . . . . . 12 87 6. Blind throughput-reduction attack . . . . . . . . . . . . . . 15 88 6.1. Description . . . . . . . . . . . . . . . . . . . . . . . 15 89 6.2. Attack-specific counter-measures . . . . . . . . . . . . . 15 90 7. Blind performance-degrading attack . . . . . . . . . . . . . . 16 91 7.1. Description . . . . . . . . . . . . . . . . . . . . . . . 16 92 7.2. Attack-specific counter-measures . . . . . . . . . . . . . 17 93 7.3. The counter-measure for the PMTUD attack in action . . . . 21 94 7.3.1. Normal operation for bulk transfers . . . . . . . . . 21 95 7.3.2. Operation during Path-MTU changes . . . . . . . . . . 23 96 7.3.3. Idle connection being attacked . . . . . . . . . . . . 24 97 7.3.4. Active connection being attacked after discovery 98 of the Path-MTU . . . . . . . . . . . . . . . . . . . 25 99 7.3.5. TCP peer attacked when sending small packets just 100 after the three-way handshake . . . . . . . . . . . . 25 101 7.4. Pseudo-code for the counter-measure for the blind 102 performance-degrading attack . . . . . . . . . . . . . . . 26 103 8. Security Considerations . . . . . . . . . . . . . . . . . . . 30 104 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 31 105 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 31 106 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 32 107 11.1. Normative References . . . . . . . . . . . . . . . . . . . 32 108 11.2. Informative References . . . . . . . . . . . . . . . . . . 32 109 Appendix A. Changes from previous versions of the draft (to 110 be removed by the RFC Editor before publishing 111 this document as an RFC) . . . . . . . . . . . . . . 35 112 A.1. Changes from draft-ietf-tcpm-icmp-attacks-08 . . . . . . . 35 113 A.2. Changes from draft-ietf-tcpm-icmp-attacks-07 . . . . . . . 35 114 A.3. Changes from draft-ietf-tcpm-icmp-attacks-06 . . . . . . . 35 115 A.4. Changes from draft-ietf-tcpm-icmp-attacks-05 . . . . . . . 35 116 A.5. Changes from draft-ietf-tcpm-icmp-attacks-04 . . . . . . . 35 117 A.6. Changes from draft-ietf-tcpm-icmp-attacks-03 . . . . . . . 36 118 A.7. Changes from draft-ietf-tcpm-icmp-attacks-02 . . . . . . . 36 119 A.8. Changes from draft-ietf-tcpm-icmp-attacks-01 . . . . . . . 36 120 A.9. Changes from draft-ietf-tcpm-icmp-attacks-00 . . . . . . . 36 121 A.10. Changes from draft-gont-tcpm-icmp-attacks-05 . . . . . . . 37 122 A.11. Changes from draft-gont-tcpm-icmp-attacks-04 . . . . . . . 37 123 A.12. Changes from draft-gont-tcpm-icmp-attacks-03 . . . . . . . 37 124 A.13. Changes from draft-gont-tcpm-icmp-attacks-02 . . . . . . . 38 125 A.14. Changes from draft-gont-tcpm-icmp-attacks-01 . . . . . . . 38 126 A.15. Changes from draft-gont-tcpm-icmp-attacks-00 . . . . . . . 38 127 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 39 129 1. Introduction 131 ICMP [RFC0792] is a fundamental part of the TCP/IP protocol suite, 132 and is used mainly for reporting network error conditions. However, 133 the current specifications do not recommend any kind of validation 134 checks on the received ICMP error messages, thus allowing variety of 135 attacks against TCP [RFC0793] by means of ICMP, which include blind 136 connection-reset, blind throughput-reduction, and blind performance- 137 degrading attacks. All of these attacks can be performed even being 138 off-path, without the need to sniff the packets that correspond to 139 the attacked TCP connection. 141 While the possible security implications of ICMP have been known in 142 the research community for a long time, there has never been an 143 official proposal on how to deal with these vulnerabiliies. In 2005, 144 a disclosure process was carried out by the UK's National 145 Infrastructure Security Co-ordination Centre (NISCC) (now CPNI, 146 Centre for the Protection of National Infrastructure), with the 147 collaboration of other computer emergency response teams. A large 148 number of implementations were found vulnerable to either all or a 149 subset of the attacks discussed in this document [NISCC][US-CERT]. 150 The affected systems ranged from TCP/IP implementations meant for 151 desktop computers, to TCP/IP implementations meant for core Internet 152 routers. 154 It is clear that implementations should be more cautious when 155 processing ICMP error messages, to eliminate or mitigate the use of 156 ICMP to perform attacks against TCP [RFC4907]. 158 This document aims to raise awareness of the use of ICMP to perform a 159 variety of attacks against TCP, and discusses several counter- 160 measures that eliminate or minimize the impact of these attacks. 161 Most of the these counter-measures can be implemented while still 162 remaining compliant with the current specifications, as they simply 163 describe reasons for not taking the advice provided in the 164 specifications in terms of "SHOULDs", but still comply with the 165 requirements stated as "MUSTs". 167 Section 2 provides background information on ICMP. Section 3 168 discusses the constraints in the general counter-measures that can be 169 implemented against the attacks described in this document. 170 Section 4 proposes several general validation checks that can be 171 implemented to mitigate any ICMP-based attack. Finally, Section 5, 172 Section 6, and Section 7, discuss a variety of ICMP attacks that can 173 be performed against TCP, and propose attack-specific counter- 174 measures that eliminate or greatly mitigate their impact. 176 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 177 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 178 document are to be interpreted as described in RFC 2119 [RFC2119]. 180 2. Background 182 2.1. The Internet Control Message Protocol (ICMP) 184 The Internet Control Message Protocol (ICMP) is used in the Internet 185 architecture mainly to perform the fault-isolation function, that is, 186 the group of actions that hosts and routers take to determine that 187 there is some network failure [RFC0816]. 189 When an intermediate router detects a network problem while trying to 190 forward an IP packet, it will usually send an ICMP error message to 191 the source system, to raise awareness of the network problem taking 192 place. In the same way, there are a number of scenarios in which an 193 end-system may generate an ICMP error message if it finds a problem 194 while processing a datagram. The received ICMP errors are handed to 195 the corresponding transport-protocol instance, which will usually 196 perform a fault recovery function. 198 It is important to note that ICMP error messages are unreliable, and 199 may be discarded due to data corruption, network congestion or rate- 200 limiting. Thus, while they provide useful information, upper layer 201 protocols cannot depend on ICMP for correct operation. 203 It should be noted that are no timeliness requirements for ICMP error 204 messages. ICMP error messages could be delayed for various reasons, 205 and at least in theory could be received with an arbitrarily long 206 delay. For example, there are no existing requirements that a router 207 flushes any queued ICMP error messages when it is rebooted. 209 2.1.1. ICMP for IP version 4 (ICMP) 211 [RFC0792] specifies the Internet Control Message Protocol (ICMP) to 212 be used with the Internet Protocol version 4 (IPv4). It defines, 213 among other things, a number of error messages that can be used by 214 end-systems and intermediate systems to report errors to the sending 215 system. The Host Requirements RFC [RFC1122] classifies ICMP error 216 messages into those that indicate "soft errors", and those that 217 indicate "hard errors", thus roughly defining the semantics of them. 219 The ICMP specification [RFC0792] also defines the ICMP Source Quench 220 message (type 4, code 0), which is meant to provide a mechanism for 221 flow control and congestion control. 223 [RFC1191] defines a mechanism called "Path MTU Discovery" (PMTUD), 224 which makes use of ICMP error messages of type 3 (Destination 225 Unreachable), code 4 (fragmentation needed and DF bit set) to allow 226 systems to determine the MTU of an arbitrary internet path. 228 Appendix D of [RFC4301] provides information about which ICMP error 229 messages are produced by hosts, intermediate routers, or both. 231 2.1.2. ICMP for IP version 6 (ICMPv6) 233 [RFC4443] specifies the Internet Control Message Protocol (ICMPv6) to 234 be used with the Internet Protocol version 6 (IPv6) [RFC2460]. 236 [RFC4443] defines the "Packet Too Big" (type 2, code 0) error 237 message, that is analogous to the ICMP "fragmentation needed and DF 238 bit set" (type 3, code 4) error message. [RFC1981] defines the Path 239 MTU Discovery mechanism for IP Version 6, that makes use of these 240 messages to determine the MTU of an arbitrary internet path. 242 Appendix D of [RFC4301] provides information about which ICMPv6 error 243 messages are produced by hosts, intermediate routers, or both. 245 2.2. Handling of ICMP error messages 247 The Host Requirements RFC [RFC1122] states in Section 4.2.3.9 that a 248 TCP MUST act on an ICMP error message passed up from the IP layer, 249 directing it to the connection that elicited the error. 251 In order to allow ICMP messages to be demultiplexed by the receiving 252 system, part of the original packet that elicited the message is 253 included in the payload of the ICMP error message. Thus, the 254 receiving system can use that information to match the ICMP error to 255 the transport protocol instance that elicited it. 257 Neither the Host Requirements RFC [RFC1122] nor the original TCP 258 specification [RFC0793] recommend any validation checks on the 259 received ICMP messages. Thus, as long as the ICMP payload contains 260 the information that identifies an existing communication instance, 261 it will be processed by the corresponding transport-protocol 262 instance, and the corresponding action will be performed. 264 Therefore, in the case of TCP, an attacker could send a crafted ICMP 265 error message to the attacked system, and, as long as he is able to 266 guess the four-tuple (i.e., Source IP Address, Source TCP port, 267 Destination IP Address, and Destination TCP port) that identifies the 268 communication instance to be attacked, he will be able to use ICMP to 269 perform a variety of attacks. 271 Generally, the four-tuple required to perform these attacks is not 272 known. However, as discussed in [Watson] and [RFC4953], there are a 273 number of scenarios (notably that of TCP connections established 274 between two BGP routers [RFC4271]), in which an attacker may be able 275 to know or guess the four-tuple that identifies a TCP connection. In 276 such a case, if we assume the attacker knows the two systems involved 277 in the TCP connection to be attacked, both the client-side and the 278 server-side IP addresses could be known or be within a reasonable 279 number of possibilities. Furthermore, as most Internet services use 280 the so-called "well-known" ports, only the client port number might 281 need to be guessed. In such a scenario, an attacker would need to 282 send, in principle, at most 65536 packets to perform any of the 283 attacks described in this document. These issues are exacerbated by 284 the fact that most systems choose the port numbers they use for 285 outgoing connections from a subset of the whole port number space, 286 thus reducing the amount of work needed to successfully perform these 287 attacks. 289 The need to be more cautious when processing received ICMP error 290 messages in order to mitigate or eliminate the impact of the attacks 291 described in this document has been documented by the Internet 292 Architecture Board (IAB) in [RFC4907]. 294 2.3. Handling of ICMP error messages in the context of IPsec 296 Section 5.2 of [RFC4301] describes the processing of inbound IP 297 Traffic in the case of "unprotected-to-protected". In the case of 298 ICMP, when an unprotected ICMP error message is received, it is 299 matched to the corresponding security association by means of the SPI 300 (Security Parameters Index) included in the payload of the ICMP error 301 message. Then, local policy is applied to determine whether to 302 accept or reject the message and, if accepted, what action to take as 303 a result. For example, if an ICMP unreachable message is received, 304 the implementation must decide whether to act on it, reject it, or 305 act on it with constraints. Section 8 ("Path MTU/DF processing") 306 discusses the processing of unauthenticated ICMP "fragmentation 307 needed and DF bit set" (type 3, code 3) and ICMPv6 "Packet Too Big" 308 (type 2, code 0) messages when an IPsec implementation is configured 309 to process (vs. ignore) such messages. 311 Section 6.1.1 of [RFC4301] notes that processing of unauthenticated 312 ICMP error messages may result in denial or degradation of service, 313 and therefore it would be desirable to ignore such messages. 314 However, it also notes that in many cases ignoring these ICMP 315 messages can degrade service, e.g., because of a failure to process 316 PMTUD and redirection messages, and therefore there is also a 317 motivation for accepting and acting upon them. It finally states 318 that to accommodate both ends of this spectrum, a compliant IPsec 319 implementation MUST permit a local administrator to configure an 320 IPsec implementation to accept or reject unauthenticated ICMP 321 traffic, and that this control MUST be at the granularity of ICMP 322 type and MAY be at the granularity of ICMP type and code. 323 Additionally, an implementation SHOULD incorporate mechanisms and 324 parameters for dealing with such traffic. 326 Thus, the policy to apply for the processing of unprotected ICMP 327 error messages is left up to the implementation and administrator. 329 3. Constraints in the possible solutions 331 For ICMPv4, [RFC0792] states that the IP header plus the first 64 332 bits of the packet that elicited the ICMP message are to be included 333 in the payload of the ICMP error message. Thus, it is assumed that 334 all data needed to identify a transport protocol instance and process 335 the ICMP error message is contained in the first 64 bits of the 336 transport protocol header. Section 3.2.2 of [RFC1122] states that 337 "the Internet header and at least the first 8 data octets of the 338 datagram that triggered the error" are to be included in the payload 339 of ICMP error messages, and that "more than 8 octets MAY be sent", 340 thus allowing implementations to include more data from the original 341 packet than those required by the original ICMP specification. The 342 Requirements for IP Version 4 Routers RFC [RFC1812] states that ICMP 343 error messages "SHOULD contain as much of the original datagram as 344 possible without the length of the ICMP datagram exceeding 576 345 bytes". 347 Thus, for ICMP messages generated by hosts, we can only expect to get 348 the entire IP header of the original packet, plus the first 64 bits 349 of its payload. For TCP, this means that the only fields that will 350 be included in the ICMP payload are: the source port number, the 351 destination port number, and the 32-bit TCP sequence number. This 352 clearly imposes a constraint on the possible validation checks that 353 can be performed, as there is not much information avalable on which 354 to perform them. 356 This means, for example, that even if TCP were signing its segments 357 by means of the TCP MD5 signature option [RFC2385], this mechanism 358 could not be used as a counter-measure against ICMP-based attacks, 359 because, as ICMP messages include only a piece of the TCP segment 360 that elicited the error, the MD5 [RFC1321] signature could not be 361 recalculated. In the same way, even if the attacked peer were 362 authenticating its packets at the IP layer [RFC4301], because only a 363 part of the original IP packet would be available, the signature used 364 for authentication could not be recalculated, and thus the 365 authentication header in the original packet could not be used as a 366 counter-measure for ICMP-based attacks against TCP. 368 For IPv6, the payload of ICMPv6 error messages includes as many 369 octets from the IPv6 packet that elicited the ICMPv6 error message as 370 will fit without making the resulting ICMPv6 error message exceed the 371 minimum IPv6 MTU (1280 octets) [RFC4443]. Thus, more information is 372 available than in the IPv4 case. 374 Hosts could require ICMP error messages to be authenticated 375 [RFC4301], in order to act upon them. However, while this 376 requirement could make sense for those ICMP error messages sent by 377 hosts, it would not be feasible for those ICMP error messages 378 generated by routers, as this would imply either that the attacked 379 system should have a security association [RFC4301] with every 380 existing intermediate system, or that it should be able to establish 381 one dynamically. Current levels of deployment of protocols for 382 dynamic establishment of security associations makes this unfeasible. 383 Additionally, this would require routers to use certificates with 384 paths compatible for all hosts on the network. Finally, there may be 385 some scenarios, such as embedded devices, in which the processing 386 power requirements of authentication might not allow IPSec 387 authentication to be implemented effectively. 389 4. General counter-measures against ICMP attacks 391 The following subsections describe a number of mitigation techniques 392 that help to eliminate or mitigate the impact of the attacks 393 discussed in this document. Rather than being alternative counter- 394 measures, they can be implemented together to increase the protection 395 against these attacks. 397 4.1. TCP sequence number checking 399 The current specifications do not impose any validity checks on the 400 TCP segment that is contained in the ICMP payload. For instance, no 401 checks are performed to verify that a received ICMP error message has 402 been elicited by a segment that was "in flight" to the destination. 403 Thus, even stale ICMP error messages will be acted upon. 405 Many TCP implementations have incorporated a validation check such 406 that they react only to those ICMP error messages that appear to 407 relate to segments currently "in-flight" to the destination system. 408 These implementations check that the TCP sequence number contained in 409 the payload of the ICMP error message is within the range SND.UNA =< 410 SEG.SEQ < SND.NXT. This means that they require that the sequence 411 number be within the range of the data already sent but not yet 412 acknowledged. If an ICMP error message does not pass this check, it 413 is discarded. 415 Even if an attacker were able to guess the four-tuple that identifies 416 the TCP connection, this additional check would reduce the 417 possibility of considering a spoofed ICMP packet as valid to 418 Flight_Size/2^^32 (where Flight_Size is the number of data bytes 419 already sent to the remote peer, but not yet acknowledged [RFC5681]). 420 For connections in the SYN-SENT or SYN-RECEIVED states, this would 421 reduce the possibility of considering a spoofed ICMP packet as valid 422 to 1/2^^32. For a TCP endpoint with no data "in flight", this would 423 completely eliminate the possibility of success of these attacks. 425 This validation check has been implemented in Linux [Linux] for many 426 years, in OpenBSD [OpenBSD] since 2004, and in FreeBSD [FreeBSD] and 427 NetBSD [NetBSD] since 2005. 429 It is important to note that while this check greatly increases the 430 number of packets required to perform any of the attacks discussed in 431 this document, this may not be enough in those scenarios in which 432 bandwidth is easily available, and/or large TCP windows [RFC1323] are 433 in use. Additionally, this validation check does not help to prevent 434 on-path attacks, that is, attacks performed in scenarios in which the 435 attacker can sniff the packets that correspond to the target TCP 436 connection. 438 It should be noted that as there are no timeliness requirements for 439 ICMP error messages, the TCP Sequence Number check described in this 440 section might cause legitimate ICMP error messages to be discarded. 441 Also, even if this check is enforced, TCP might end up responding to 442 stale ICMP error messages (e.g., if the Sequence Number for the 443 corresponding direction of the data transfer wrap around). 445 4.2. Port randomization 447 As discussed in the previous sections, in order to perform any of the 448 attacks described in this document, an attacker would need to guess 449 (or know) the four-tuple that identifies the connection to be 450 attacked. Increasing the port number range used for outgoing TCP 451 connections, and randomizing the port number chosen for each outgoing 452 TCP connections would make it harder for an attacker to perform any 453 of the attacks discussed in this document. 455 [I-D.ietf-tsvwg-port-randomization] discusses a number of algorithms 456 to randomize the ephemeral ports used by clients. 458 4.3. Filtering ICMP error messages based on the ICMP payload 460 The source address of ICMP error messages does not need to be spoofed 461 to perform the attacks described in this document, as the ICMP error 462 messages might legitimately come from an intermediate system. 464 Therefore, simple filtering based on the source address of ICMP error 465 messages does not serve as a counter-measure against these attacks. 466 However, a more advanced packet filtering can be implemented in 467 middlebox devices such as firewalls and NATs. Middleboxes 468 implementing such advanced filtering look at the payload of the ICMP 469 error messages, and perform ingress and egress packet filtering based 470 on the source IP address of the IP header contained in the payload of 471 the ICMP error message. As the source IP address contained in the 472 payload of the ICMP error message does need to be spoofed to perform 473 the attacks described in this document, this kind of advanced 474 filtering serves as a counter-measure against these attacks. As with 475 traditional egress filtering [IP-filtering], egress filtering based 476 on the ICMP payload can help to prevent users of the network being 477 protected by the firewall from successfully performing ICMP attacks 478 against TCP connections established between external systems. 479 Additionally, ingress filtering based on the ICMP payload can prevent 480 TCP connections established between internal systems from attacks 481 performed by external systems. [ICMP-Filtering] provides examples of 482 ICMP filtering based on the ICMP payload. 484 This filtering technique has been implemented in OpenBSD's Packet 485 Filter [OpenBSD-PF], which has in turn been ported to a number of 486 systems, including FreeBSD [FreeBSD]. 488 5. Blind connection-reset attack 490 5.1. Description 492 When TCP is handed an ICMP error message, it will perform its fault 493 recovery function, as follows: 495 o If the network problem being reported is a hard error, TCP will 496 abort the corresponding connection. 498 o If the network problem being reported is a soft error, TCP will 499 just record this information, and repeatedly retransmit its data 500 until they either get acknowledged, or the connection times out. 502 The Host Requirements RFC [RFC1122] states (in Section 4.2.3.9) that 503 a host SHOULD abort the corresponding connection when receiving an 504 ICMP error message that indicates a "hard error", and states that 505 ICMP error messages of type 3 (Destination Unreachable) codes 2 506 (protocol unreachable), 3 (port unreachable), and 4 (fragmentation 507 needed and DF bit set) should be considered to indicate hard errors. 508 In the case of ICMP port unreachables, the specifications are 509 ambiguous, as Section 4.2.3.9 of [RFC1122] states that TCP SHOULD 510 abort the corresponding connection in response to them, but Section 511 3.2.2.1 of the same RFC ([RFC1122] states that TCP MUST abort the 512 connection in response to them. 514 While [RFC4443] did not exist when [RFC1122] was published, one could 515 extrapolate the concept of "hard errors" to ICMPv6 error messages of 516 type 1 (Destination unreachable) codes 1 (communication with 517 destination administratively prohibited), and 4 (port unreachable). 519 Thus, an attacker could use ICMP to perform a blind connection-reset 520 attack by sending any ICMP error message that indicates a "hard 521 error", to either of the two TCP endpoints of the connection. 522 Because of TCP's fault recovery policy, the connection would be 523 immediately aborted. 525 Some stacks are known to extrapolate ICMP hard errors across TCP 526 connections, increasing the impact of this attack, as a single ICMP 527 packet could bring down all the TCP connections between the 528 corresponding peers. 530 It is important to note that even if TCP itself were protected 531 against the blind connection-reset attack described in [Watson] and 532 [I-D.ietf-tcpm-tcpsecure], by means authentication at the network 533 layer [RFC4301], by means of the TCP MD5 signature option [RFC2385], 534 by means of the TCP-AO [I-D.ietf-tcpm-tcp-auth-opt], or by means of 535 the mechanism proposed in [I-D.ietf-tcpm-tcpsecure], the blind 536 connection-reset attack described in this document would still 537 succeed. 539 5.2. Attack-specific counter-measures 541 An analysis of the circumstances in which ICMP messages that indicate 542 hard errors may be received can shed some light to mitigate the 543 impact of ICMP-based blind connection-reset attacks. 545 ICMP type 3 (Destination Unreachable), code 2 (protocol unreachable) 547 This ICMP error message indicates that the host sending the ICMP 548 error message received a packet meant for a transport protocol it 549 does not support. For connection-oriented protocols such as TCP, 550 one could expect to receive such an error as the result of a 551 connection-establishment attempt. However, it would be strange to 552 get such an error during the life of a connection, as this would 553 indicate that support for that transport protocol has been removed 554 from the system sending the error message during the life of the 555 corresponding connection. 557 ICMP type 3 (Destination Unreachable), code 3 (port unreachable) 559 This error message indicates that the system sending the ICMP 560 error message received a packet meant for a socket (IP address, 561 port number) on which there is no process listening. Those 562 transport protocols which have their own mechanisms for notifying 563 this condition should not be receiving these error messages, as 564 the protocol would signal the port unreachable condition by means 565 of its own messages. Assuming that once a connection is 566 established it is not usual for the transport protocol to change 567 (or be reloaded), it should be unusual to get these error 568 messages. 570 ICMP type 3 (Destination Unreachable), code 4 (fragmentation needed 571 and DF bit set) 573 This error message indicates that an intermediate node needed to 574 fragment a datagram, but the DF (Don't Fragment) bit in the IP 575 header was set. It is considered a soft error when TCP implements 576 PMTUD, and a hard error if TCP does not implement PMTUD. Those 577 TCP/IP stacks that do not implement PMTUD (or have disabled it) 578 but support IP fragmentation/reassembly should not be sending 579 their IP packets with the DF bit set, and thus should not be 580 receiving these ICMP error messages. Some TCP/IP stacks that do 581 not implement PMTUD and that do not support IP fragmentation/ 582 reassembly are known to send their packets with the DF bit set, 583 and thus could legitimately receive these ICMP error messages. 585 ICMPv6 type 1 (Destination Unreachable), code 1 (communication with 586 destination administratively prohibited) 588 This error message indicates that the destination is unreachable 589 because of an administrative policy. For connection-oriented 590 protocols such as TCP, one could expect to receive such an error 591 as the result of a connection-establishment attempt. Receiving 592 such an error for a connection in any of the synchronized states 593 would mean that the administrative policy changed during the life 594 of the connection. However, in the same way this error condition 595 (which was not present when the connection was established) 596 appeared, it could get solved in the near term. 598 ICMPv6 type 1 (Destination Unreachable), code 4 (port unreachable) 600 This error message is analogous to the ICMP type 3 (Destination 601 Unreachable), code 3 (Port unreachable) error message discussed 602 above. Therefore, the same considerations apply. 604 The Host Requirements RFC [RFC1122] states in Section 4.2.3.9 that 605 TCP SHOULD abort the corresponding connection in response to ICMP 606 messages of type 3, codes 2 (protocol unreachable), 3 (port 607 unreachable), and 4 (fragmentation needed and DF bit set). However, 608 Section 3.2.2.1 states that TCP MUST accept an ICMP port unreachable 609 (type 3, code 3) for the same purpose as an RST. Therefore, for ICMP 610 messages of type 3 codes 2 and 4 there is room to go against the 611 advice provided in the existing specifications, while in the case of 612 ICMP messages of type 3 code 3 there is ambiguity in the 613 specifications that may or may not provide some room to go against 614 that advice. 616 Based on this analysis, most popular TCP implementations treat all 617 ICMP "hard errors" received for connections in any of the 618 synchronized states (ESTABLISHED, FIN-WAIT-1, FIN-WAIT-2, CLOSE-WAIT, 619 CLOSING, LAST-ACK or TIME-WAIT) as "soft errors". That is, they do 620 not abort the corresponding connection upon receipt of them. 621 Additionally, they do not extrapolate ICMP errors across TCP 622 connections. This policy is based on the premise that TCP should be 623 as robust as possible. Aborting the connection would be to ignore 624 the valuable feature of the Internet that for many internal failures 625 it reconstructs its function without any disruption of the end points 626 [RFC0816]. 628 It is interesting to note that, as ICMP error messages are 629 unreliable, transport protocols should not depend on them for correct 630 functioning. In the event one of these messages were legitimate, the 631 corresponding connection would eventually time out. Also, 632 applications may still be notified asynchronously about the error 633 contition, and thus may still abort their connections on their own if 634 they consider it appropriate. 636 In scenarios such as that in which an intermediate system sets the DF 637 bit in the segments transmitted by a TCP that does not implement 638 PMTUD, or the TCP at one of the endpoints of the connection is 639 dynamically disabled, TCP would only abort the connection after a 640 USER TIMEOUT [RFC0793], losing responsiveness. However, these 641 scenarios are very unlikely in production environments, and it is 642 probably preferable to potentially lose responsiveness for the sake 643 of robustness. It should also be noted that applications may still 644 be notified asynchronously about the error condition, and thus may 645 still abort their connections on their own if they consider it 646 appropriate. 648 In scenarios of multipath routing or route changes, failures in some 649 (but not all) of the paths may elicit ICMP error messages that would 650 likely not cause a connection abort if any of the counter-measures 651 described in this section were implemented. However, aborting the 652 connection would be to ignore the valuable feature of the Internet 653 that for many internal failures it reconstructs its function without 654 any disruption of the end points [RFC0816]. That is, communication 655 should survive if there is still a working path to the destination 656 system [DClark]. Additionally, applications may still be notified 657 asynchronously about the error condition, and thus may still abort 658 their connections on their own if they consider it appropriate. 660 This counter-measure has been implemented in BSD-derived TCP/IP 661 implementations (e.g., [FreeBSD], [NetBSD], and [OpenBSD]) for more 662 than ten years [Wright][McKusick]. The Linux kernel has also 663 implemented this policy for more than ten years [Linux]. 665 6. Blind throughput-reduction attack 667 6.1. Description 669 The Host requirements RFC [RFC1122] states in Section 4.2.3.9 that 670 hosts MUST react to ICMP Source Quench messages by slowing 671 transmission on the connection. Thus, an attacker could send ICMP 672 Source Quench (type 4, code 0) messages to a TCP endpoint to make it 673 reduce the rate at which it sends data to the other end-point of the 674 connection. [RFC1122] further adds that the RECOMMENDED procedure is 675 to put the corresponding connection in the slow-start phase of TCP's 676 congestion control algorithm [RFC5681]. In the case of those 677 implementations that use an initial congestion window of one segment, 678 a sustained attack would reduce the throughput of the attacked 679 connection to about SMSS (Sender Maximum Segment Size) [RFC5681] 680 bytes per RTT (round-trip time). The throughput achieved during an 681 attack might be a little higher if a larger initial congestion window 682 is in use [RFC3390]. 684 6.2. Attack-specific counter-measures 686 As discussed in the Requirements for IP Version 4 Routers RFC 687 [RFC1812], research seems to suggest that ICMP Source Quench is an 688 ineffective (and unfair) antidote for congestion. [RFC1812] further 689 states that routers SHOULD NOT send ICMP Source Quench messages in 690 response to congestion. Furthermore, TCP implements its own 691 congestion control mechanisms [RFC5681] [RFC3168], that do not depend 692 on ICMP Source Quench messages. 694 Based on this reasoning, a large number of implementations completely 695 ignore ICMP Source Quench messages meant for TCP connections. This 696 behavior has been implemented in, at least, Linux [Linux] since 2004, 697 and in FreeBSD [FreeBSD], NetBSD [NetBSD], and OpenBSD [OpenBSD] 698 since 2005. However, it must be noted that this behaviour violates 699 the requirement in [RFC1122] to react to ICMP Source Quench messages 700 by slowing transmission on the connection. 702 7. Blind performance-degrading attack 704 7.1. Description 706 When one IP system has a large amount of data to send to another 707 system, the data will be transmitted as a series of IP datagrams. It 708 is usually preferable that these datagrams be of the largest size 709 that does not require fragmentation anywhere along the path from the 710 source to the destination. This datagram size is referred to as the 711 Path MTU (PMTU), and is equal to the minimum of the MTUs of each hop 712 in the path. A technique called "Path MTU Discovery" (PMTUD) lets IP 713 systems determine the Path MTU of an arbitrary internet path. 714 [RFC1191] and [RFC1981] specify the PMTUD mechanism for IPv4 and 715 IPv6, respectively. 717 The PMTUD mechanism for IPv4 uses the Don't Fragment (DF) bit in the 718 IP header to dynamically discover the Path MTU. The basic idea 719 behind the PMTUD mechanism is that a source system assumes that the 720 MTU of the path is that of the first hop, and sends all its datagrams 721 with the DF bit set. If any of the datagrams is too large to be 722 forwarded without fragmentation by some intermediate router, the 723 router will discard the corresponding datagram, and will return an 724 ICMP "Destination Unreachable" (type 3) "fragmentation needed and DF 725 set" (code 4) error message to the sending system. This message will 726 report the MTU of the constricting hop, so that the sending system 727 can reduce the assumed Path-MTU accordingly. 729 For IPv6, intermediate systems do not fragment packets. Thus, 730 there's an "implicit" DF bit set in every packet sent on a network. 731 If any of the datagrams is too large to be forwarded without 732 fragmentation by some intermediate router, the router will discard 733 the corresponding datagram, and will return an ICMPv6 "Packet Too 734 Big" (type 2, code 0) error message to sending system. This message 735 will report the MTU of the constricting hop, so that the sending 736 system can reduce the assumed Path-MTU accordingly. 738 As discussed in both [RFC1191] and [RFC1981], the Path-MTU Discovery 739 mechanism can be used to attack TCP. An attacker could send a 740 crafted ICMP "Destination Unreachable, fragmentation needed and DF 741 set" packet (or their ICMPv6 counterpart) to the sending system, 742 advertising a small Next-Hop MTU. As a result, the attacked system 743 would reduce the size of the packets it sends for the corresponding 744 connection accordingly. 746 The effect of this attack is two-fold. On one hand, it will increase 747 the headers/data ratio, thus increasing the overhead needed to send 748 data to the remote TCP end-point. On the other hand, if the attacked 749 system wanted to keep the same throughput it was achieving before 750 being attacked, it would have to increase the packet rate. On 751 virtually all systems this will lead to an increase in the IRQ 752 (Interrrupt ReQuest) rate and protocol processing time, thus 753 increasing processor utilization, and degrading the overall system 754 performance. 756 A particular scenario that may take place is that in which an 757 attacker reports a Next-Hop MTU smaller than or equal to the amount 758 of bytes needed for headers (IP header, plus TCP header). For 759 example, if the attacker reports a Next-Hop MTU of 68 bytes, and the 760 amount of bytes used for headers (IP header, plus TCP header) is 761 larger than 68 bytes, the assumed Path-MTU will not even allow the 762 attacked system to send a single byte of application data without 763 fragmentation. This particular scenario might lead to unpredictable 764 results. Another posible scenario is that in which a TCP connection 765 is being secured by means of IPSec. If the Next-Hop MTU reported by 766 the attacker is smaller than the amount of bytes needed for headers 767 (IP and IPSec, in this case), the assumed Path-MTU will not even 768 allow the attacked system to send a single byte of the TCP header 769 without fragmentation. This is another scenario that may lead to 770 unpredictable results. 772 For IPv4, the reported Next-Hop MTU could be as low as 68 octets, as 773 [RFC0791] requires every internet module to be able to forward a 774 datagram of 68 octets without further fragmentation. For IPv6, the 775 reported Next-Hop MTU could be as low as 1280 octets (the minimum 776 IPv6 MTU) [RFC2460]. 778 7.2. Attack-specific counter-measures 780 The IETF has standardized a Path-MTU Discovery mechanism called 781 "Packetization Layer Path MTU Discovery" that does not depend on ICMP 782 error messages. Implementation of the aforementioned mechanism in 783 replacement of the traditional PMTUD (specified in [RFC1191] and 784 [RFC1981]) would eliminate this vulnerability. However, it might 785 also lead to an increase of the PMTUD convergence time. 787 This section describes a modification to the PMTUD mechanism 788 specified in [RFC1191] and [RFC1981] that has been implemented in a 789 variety of TCP implementations to improve TCP's resistance to the 790 blind performance-degrading attack described in Section 7.1. The 791 described mechanism basically disregards ICMP messages when a 792 connection makes progress. This modification does not violate any of 793 the requirements stated in [RFC1191] and [RFC1981]. 795 Henceforth, we will refer to both ICMP "fragmentation needed and DF 796 bit set" and ICMPv6 "Packet Too Big" messages as "ICMP Packet Too 797 Big" messages. 799 In addition to the general validation check described in Section 4.1, 800 these implementations include a modification to TCP's reaction to 801 ICMP "Packet Too Big" error messages that disregards them when a 802 connection makes progress, and honors them only after the 803 corresponding data have been retransmitted a specified number of 804 times. This means that upon receipt of an ICMP "Packet Too Big" 805 error message, TCP just records this information, and honors it only 806 when the corresponding data have already been retransmitted a 807 specified number of times. 809 While this basic policy would greatly mitigate the impact of the 810 attack against the PMTUD mechanism, it would also mean that it might 811 take TCP more time to discover the Path-MTU for a TCP connection. 812 This would be particularly annoying for connections that have just 813 been established, as it might take TCP several transmission attempts 814 (and the corresponding timeouts) before it discovers the PMTU for the 815 corresponding connection. Thus, this policy would increase the time 816 it takes for data to begin to be received at the destination host. 818 In order to protect TCP from the attack against the PMTUD mechanism, 819 while still allowing TCP to quickly determine the initial Path-MTU 820 for a connection, the aforementioned implementations have divided the 821 traditional PMTUD mechanism into two stages: Initial Path-MTU 822 Discovery, and Path-MTU Update. 824 The Initial Path-MTU Discovery stage is when TCP tries to send 825 segments that are larger than the ones that have so far been sent and 826 acknowledged for this connection. That is, in the Initial Path-MTU 827 Discovery stage TCP has no record of these large segments getting to 828 the destination host, and thus these implementations believe the 829 network when it reports that these packets are too large to reach the 830 destination host without being fragmented. 832 The Path-MTU Update stage is when TCP tries to send segments that are 833 equal to or smaller than the ones that have already been sent and 834 acknowledged for this connection. During the Path-MTU Update stage, 835 TCP already has knowledge of the estimated Path-MTU for the given 836 connection. Thus, in this case these implementations are more 837 cautious with the errors being reported by the network. 839 In order to allow TCP to distinguish segments between those 840 performing Initial Path-MTU Discovery and those performing Path-MTU 841 Update, two new variables are introduced to TCP: maxsizeacked and 842 maxsizesent. 844 maxsizesent holds the size (in octets) of the largest packet that has 845 so far been sent for this connection. It is initialized to 68 (the 846 minimum IPv4 MTU) when the underlying internet protocol is IPv4, and 847 is initialized to 1280 (the minimum IPv6 MTU) when the underlying 848 internet protocol is IPv6. Whenever a packet larger than maxsizesent 849 octets is sent, maxsizesent is set to that value. 851 On the other hand, maxsizeacked holds the size (in octets) of the 852 largest packet that has so far been acknowledged for this connection. 853 It is initialized to 68 (the minimum IPv4 MTU) when the underlying 854 internet protocol is IPv4, and is initialized to 1280 (the minimum 855 IPv6 MTU) when the underlying internet protocol is IPv6. Whenever an 856 acknowledgement for a packet larger than maxsizeacked octets is 857 received, maxsizeacked is set to the size of that acknowledged 858 packet. 860 Upon receipt of an ICMP "Packet Too Big" error message, the Next-Hop 861 MTU claimed by the ICMP message (henceforth "claimedmtu") is compared 862 with maxsizesent. If claimedmtu is larger than maxsizesent, then the 863 ICMP error message is silently discarded. The rationale for this is 864 that the ICMP error message cannot be legitimate if it claims to have 865 been elicited by a packet larger than the largest packet we have so 866 far sent for this connection. 868 If this check is passed, claimedmtu is compared with maxsizeacked. 869 If claimedmtu is equal to or larger than maxsizeacked, TCP is 870 supposed to be at the Initial Path-MTU Discovery stage, and thus the 871 ICMP "Packet Too Big" error message is honored immediately. That is, 872 the assumed Path-MTU is updated according to the Next-Hop MTU claimed 873 in the ICMP error message. Also, maxsizesent is reset to the minimum 874 MTU of the internet protocol in use (68 for IPv4, and 1280 for IPv6). 876 On the other hand, if claimedmtu is smaller than maxsizeacked, TCP is 877 supposed to be in the Path-MTU Update stage. At this stage, these 878 implementations are more cautious with the errors being reported by 879 the network, and therefore just record the received error message, 880 and delay the update of the assumed Path-MTU. 882 To perform this delay, one new variable and one new parameter is 883 introduced to TCP: nsegrto and MAXSEGRTO. nsegrto holds the number of 884 times a specified segment has timed out. It is initialized to zero, 885 and is incremented by one every time the corresponding segment times 886 out. MAXSEGRRTO specifies the number of times a given segment must 887 timeout before an ICMP "Packet Too Big" error message can be honored, 888 and can be set, in principle, to any value greater than or equal to 889 0. 891 Thus, if nsegrto is greater than or equal to MAXSEGRTO, and there's a 892 pending ICMP "Packet Too Big" error message, the corresponding error 893 message is processed. At that point, maxsizeacked is set to 894 claimedmtu, and maxsizesent is set to 68 (for IPv4) or 1280 (for 895 IPv6). 897 If while there is a pending ICMP "Packet Too Big" error message the 898 TCP SEQ claimed by the pending message is acknowledged (i.e., an ACK 899 that acknowledges that sequence number is received), then the 900 "pending error" condition is cleared. 902 The rationale behind performing this delayed processing of ICMP 903 "Packet Too Big" messages is that if there is progress on the 904 connection, the ICMP "Packet Too Big" errors must be a false claim. 905 By checking for progress on the connection, rather than just for 906 staleness of the received ICMP messages, TCP is protected from attack 907 even if the offending ICMP messages are "in window", and as a 908 corollary, is made more robust to spurious ICMP messages elicited by, 909 for example, corrupted TCP segments. 911 MAXSEGRTO can be set, in principle, to any value greater than or 912 equal to 0. Setting MAXSEGRTO to 0 would make TCP perform the 913 traditional PMTUD mechanism defined in [RFC1191] and [RFC1981]. A 914 MAXSEGRTO of 1 provides enough protection for most cases. In any 915 case, implementations are free to choose higher values for this 916 constant. MAXSEGRTO could be a function of the Next-Hop MTU claimed 917 in the received ICMP "Packet Too Big" message. That is, higher 918 values for MAXSEGRTO could be imposed when the received ICMP "Packet 919 Too Big" message claims a Next-Hop MTU that is smaller than some 920 specified value. 922 In the event a higher level of protection is desired at the expense 923 of a higher delay in the discovery of the Path-MTU, an implementation 924 could consider TCP to always be in the Path-MTU Update stage, thus 925 always delaying the update of the assumed Path-MTU. 927 Section 7.3 shows the proposed counter-measure in action. 928 Section 7.4 shows the proposed counter-measure in pseudo-code. 930 This behavior has been implemented in NetBSD [NetBSD] and OpenBSD 931 [OpenBSD] since 2005. 933 It is important to note that the mechanism proposed in this section 934 is an improvement to the current Path-MTU discovery mechanism, to 935 mitigate its security implications. The current PMTUD mechanism, as 936 specified by [RFC1191] and [RFC1981], still suffers from some 937 functionality problems [RFC2923] that this document does not aim to 938 address. A mechanism that addresses those issues is described in 939 [RFC4821]. 941 7.3. The counter-measure for the PMTUD attack in action 943 This SECTION shows the proposed counter-measure for the ICMP attack 944 against the PMTUD mechanism in action. It shows both how the fix 945 protects TCP from being attacked and how the counter-measure works in 946 normal scenarios. As discussed in Section 7.2, this section assumes 947 the PMTUD-specific counter-measure is implemented in addition to the 948 TCP sequence number checking described in Section 4.1. 950 Figure 1 illustrates an hypothetical scenario in which two hosts are 951 connected by means of three intermediate routers. It also shows the 952 MTU of each hypothetical hop. All the following subsections assume 953 the network setup of this figure. 955 Also, for simplicity sake, all subsections assume an IP header of 20 956 octets and a TCP header of 20 octets. Thus, for example, when the 957 PMTU is assumed to be 1500 octets, TCP will send segments that 958 contain, at most, 1460 octets of data. 960 For simplicity sake, all the following subsections assume the TCP 961 implementation at Host 1 has chosen a a MAXSEGRTO of 1. 963 +----+ +----+ +----+ +----+ +----+ 964 | H1 |--------| R1 |--------| R2 |--------| R3 |--------| H2 | 965 +----+ +----+ +----+ +----+ +----+ 966 MTU=4464 MTU=2048 MTU=1500 MTU=4464 968 Figure 1: Hypothetical scenario 970 7.3.1. Normal operation for bulk transfers 972 This subsection shows the proposed counter-measure in normal 973 operation, when a TCP connection is used for bulk transfers. That 974 is, it shows how the proposed counter-measure works when there is no 975 attack taking place, and a TCP connection is used for transferring 976 large amounts of data. This section assumes that just after the 977 connection is established, one of the TCP endpoints begins to 978 transfer data in packets that are as large as possible. 980 Host 1 Host 2 982 1. --> --> 983 2. <-- <-- 984 3. --> --> 985 4. --> --> 986 5. <--- ICMP "Packet Too Big" MTU=2048, TCPseq#=101 <--- R1 987 6. --> --> 988 7. <--- ICMP "Packet Too Big" MTU=1500, TCPseq#=101 <--- R2 989 8. --> --> 990 9. <-- <-- 992 Figure 2: Normal operation for bulk transfers 994 nsegrto is initialized to zero. Both maxsizeacked and maxsizesent 995 are initialized to the minimum MTU for the internet protocol being 996 used (68 for IPv4, and 1280 for IPv6). 998 In lines 1 to 3 the three-way handshake takes place, and the 999 connection is established. In line 4, H1 tries to send a full-sized 1000 TCP segment. As described by [RFC1191] and [RFC1981], in this case 1001 TCP will try to send a segment with 4424 bytes of data, which will 1002 result in an IP packet of 4464 octets. Therefore, maxsizesent is set 1003 to 4464. When the packet reaches R1, it elicits an ICMP "Packet Too 1004 Big" error message. 1006 In line 5, H1 receives the ICMP error message, which reports a Next- 1007 Hop MTU of 2048 octets. After performing the TCP sequence number 1008 check described in Section 4.1, the Next-Hop MTU reported by the ICMP 1009 error message (claimedmtu) is compared with maxsizesent. As it is 1010 smaller than maxsizesent, it passes the check, and thus is then 1011 compared with maxsizeacked. As claimedmtu is larger than 1012 maxsizeacked, TCP assumes that the corresponding TCP segment was 1013 performing the Initial PMTU Discovery. Therefore, the TCP at H1 1014 honors the ICMP message by updating the assumed Path-MTU. maxsizesent 1015 is reset to the minimum MTU of the internet protocol in use (68 for 1016 IPv4, and 1280 for IPv6). 1018 In line 6, the TCP at H1 sends a segment with 2008 bytes of data, 1019 which results in an IP packet of 2048 octets. maxsizesent is thus set 1020 to 2008 bytes. When the packet reaches R2, it elicits an ICMP 1021 "Packet Too Big" error message. 1023 In line 7, H1 receives the ICMP error message, which reports a Next- 1024 Hop MTU of 1500 octets. After performing the TCP sequence number 1025 check, the Next-Hop MTU reported by the ICMP error message 1026 (claimedmtu) is compared with maxsizesent. As it is smaller than 1027 maxsizesent, it passes the check, and thus is then compared with 1028 maxsizeacked. As claimedmtu is larger than maxsizeacked, TCP assumes 1029 that the corresponding TCP segment was performing the Initial PMTU 1030 Discovery. Therefore, the TCP at H1 honors the ICMP message by 1031 updating the assumed Path-MTU. maxsizesent is reset to the minimum 1032 MTU of the internet protocol in use. 1034 In line 8, the TCP at H1 sends a segment with 1460 bytes of data, 1035 which results in an IP packet of 1500 octets. maxsizesent is thus set 1036 to 1500. This packet reaches H2, where it elicits an acknowledgement 1037 (ACK) segment. 1039 In line 9, H1 finally gets the acknowledgement for the data segment. 1040 As the corresponding packet was larger than maxsizeacked, TCP updates 1041 maxsizeacked, setting it to 1500. At this point TCP has discovered 1042 the Path-MTU for this TCP connection. 1044 7.3.2. Operation during Path-MTU changes 1046 Let us suppose a TCP connection between H1 and H2 has already been 1047 established, and that the PMTU for the connection has already been 1048 discovered to be 1500. At this point, both maxsizesent and 1049 maxsizeacked are equal to 1500, and nsegrto is equal to 0. Suppose 1050 some time later the PMTU decreases to 1492. For simplicity, let us 1051 suppose that the Path-MTU has decreased because the MTU of the link 1052 between R2 and R3 has decreased from 1500 to 1492. Figure 3 1053 illustrates how the proposed counter-measure would work in this 1054 scenario. 1056 Host 1 Host 2 1058 1. (Path-MTU decreases) 1059 2. --> --> 1060 3. <--- ICMP "Packet Too Big" MTU=1492, TCPseq#=100 <--- R2 1061 4. (Segment times out) 1062 5. --> --> 1063 6. <-- <-- 1065 Figure 3: Operation during Path-MTU changes 1067 In line 1, the Path-MTU for this connection decreases from 1500 to 1068 1492. In line 2, the TCP at H1, without being aware of the Path-MTU 1069 change, sends a 1500-byte packet to H2. When the packet reaches R2, 1070 it elicits an ICMP "Packet Too Big" error message. 1072 In line 3, H1 receives the ICMP error message, which reports a Next- 1073 Hop MTU of 1492 octets. After performing the TCP sequence number 1074 check, the Next-Hop MTU reported by the ICMP error message 1075 (claimedmtu) is compared with maxsizesent. As claimedmtu is smaller 1076 than maxsizesent, it is then compared with maxsizeacked. As 1077 claimedmtu is smaller than maxsizeacked (full-sized packets were 1078 getting to the remote end-point), this packet is assumed to be 1079 performing Path-MTU Update. And a "pending error" condition is 1080 recorded. 1082 In line 4, the segment times out. Thus, nsegrto is incremented by 1. 1083 As nsegrto is greater than or equal to MAXSEGRTO, the assumed Path- 1084 MTU is updated. nsegrto is reset to 0, and maxsizeacked is set to 1085 claimedmtu, and maxsizesent is set to the minimum MTU of the internet 1086 protocol in use. 1088 In line 5, H1 retransmits the data using the updated PMTU, and thus 1089 maxsizesent is set to 1492. The resulting packet reaches H2, where 1090 it elicits an acknowledgement (ACK) segment. 1092 In line 6, H1 finally gets the acknowledgement for the data segment. 1093 At this point TCP has discovered the new Path-MTU for this TCP 1094 connection. 1096 7.3.3. Idle connection being attacked 1098 Let us suppose a TCP connection between H1 and H2 has already been 1099 established, and the PMTU for the connection has already been 1100 discovered to be 1500. Figure 4 shows a sample time-line diagram 1101 that illustrates an idle connection being attacked. 1103 Host 1 Host 2 1105 1. --> --> 1106 2. <-- <-- 1107 3. <--- ICMP "Packet Too Big" MTU=68, TCPseq#=100 <--- 1108 4. <--- ICMP "Packet Too Big" MTU=68, TCPseq#=100 <--- 1109 5. <--- ICMP "Packet Too Big" MTU=68, TCPseq#=100 <--- 1111 Figure 4: Idle connection being attacked 1113 In line 1, H1 sends its last bunch of data. At line 2, H2 1114 acknowledges the receipt of these data. Then the connection becomes 1115 idle. In lines 3, 4, and 5, an attacker sends forged ICMP "Packet 1116 Too Big" error messages to H1. Regardless of how many packets it 1117 sends and the TCP sequence number each ICMP packet includes, none of 1118 these ICMP error messages will pass the TCP sequence number check 1119 described in Section 4.1, as H1 has no unacknowledged data in flight 1120 to H2. Therefore, the attack does not succeed. 1122 7.3.4. Active connection being attacked after discovery of the Path-MTU 1124 Let us suppose an attacker attacks a TCP connection for which the 1125 PMTU has already been discovered. In this case, as illustrated in 1126 Figure 1, the PMTU would be found to be 1500 bytes. Figure 5 shows a 1127 possible packet exchange. 1129 Host 1 Host 2 1131 1. --> --> 1132 2. --> --> 1133 3. --> --> 1134 4. --> --> 1135 5. <--- ICMP "Packet Too Big" MTU=68, TCPseq#=100 <--- 1136 6. <-- <-- 1138 Figure 5: Active connection being attacked after discovery of PMTU 1140 As we assume the PMTU has already been discovered, we also assume 1141 both maxsizesent and maxsizeacked are equal to 1500. We assume 1142 nsegrto is equal to zero, as there have been no segment timeouts. 1144 In lines 1, 2, 3, and 4, H1 sends four data segments to H2. In line 1145 5, an attacker sends a forged ICMP packet to H1. We assume the 1146 attacker is lucky enough to guess both the four-tuple that identifies 1147 the connection and a valid TCP sequence number. As the Next-Hop MTU 1148 claimed in the ICMP "Packet Too Big" message (claimedmtu) is smaller 1149 than maxsizeacked, this packet is assumed to be performing Path-MTU 1150 Update. Thus, the error message is recorded. 1152 In line 6, H1 receives an acknowledgement for the segment sent in 1153 line 1, before it times out. At this point, the "pending error" 1154 condition is cleared, and the recorded ICMP "Packet Too Big" error 1155 message is ignored. Therefore, the attack does not succeed. 1157 7.3.5. TCP peer attacked when sending small packets just after the 1158 three-way handshake 1160 This section analyzes an scenario in which a TCP peer that is sending 1161 small segments just after the connection has been established, is 1162 attacked. The connection could be being used by protocols such as 1163 SMTP [RFC5321] and HTTP [RFC2616], for example, which usually behave 1164 like this. 1166 Figure 6 shows a possible packet exchange for such scenario. 1168 Host 1 Host 2 1170 1. --> --> 1171 2. <-- <-- 1172 3. --> --> 1173 4. --> --> 1174 5. <-- <-- 1175 6. --> --> 1176 7. --> --> 1177 8. <--- ICMP "Packet Too Big" MTU=150, TCPseq#=101 <--- 1179 Figure 6: TCP peer attacked when sending small packets just after the 1180 three-way handshake 1182 nsegrto is initialized to zero. Both maxsizesent and maxsizeacked 1183 are initialized to the minimum MTU for the internet protocol being 1184 used (68 for IPv4, and 1280 for IPv6). 1186 In lines 1 to 3 the three-way handshake takes place, and the 1187 connection is established. At this point, the assumed Path-MTU for 1188 this connection is 4464. In line 4, H1 sends a small segment (which 1189 results in a 140-byte packet) to H2. maxsizesent is thus set to 140. 1190 In line 5 this segment is acknowledged, and thus maxsizeacked is set 1191 to 140. 1193 In lines 6 and 7, H1 sends two small segments to H2. In line 8, 1194 while the segments from lines 6 and 7 are still in flight to H2, an 1195 attacker sends a forged ICMP "Packet Too Big" error message to H1. 1196 Assuming the attacker is lucky enough to guess a valid TCP sequence 1197 number, this ICMP message will pass the TCP sequence number check. 1198 The Next-Hop MTU reported by the ICMP error message (claimedmtu) is 1199 then compared with maxsizesent. As claimedmtu is larger than 1200 maxsizesent, the ICMP error message is silently discarded. 1201 Therefore, the attack does not succeed. 1203 7.4. Pseudo-code for the counter-measure for the blind performance- 1204 degrading attack 1206 This section contains a pseudo-code version of the counter-measure 1207 described in Section 7.2 for the blind performance-degrading attack 1208 described in Section 7. It is meant as guidance for developers on 1209 how to implement this counter-measure. 1211 The pseudo-code makes use of the following variables, constants, and 1212 functions: 1214 ack 1215 Variable holding the acknowledgement number contained in the TCP 1216 segment that has just been received. 1218 acked_packet_size 1219 Variable holding the packet size (data, plus headers) the ACK that 1220 has just been received is acknowledging. 1222 adjust_mtu() 1223 Function that adjusts the MTU for this connection, according to 1224 the ICMP "Packet Too Big" that was last received. 1226 claimedmtu 1227 Variable holding the Next-Hop MTU advertised by the ICMP "Packet 1228 Too Big" error message. 1230 claimedtcpseq 1231 Variable holding the TCP sequence number contained in the payload 1232 of the ICMP "Packet Too Big" message that has just been received 1233 or was last recorded. 1235 current_mtu 1236 Variable holding the assumed Path-MTU for this connection. 1238 drop_message() 1239 Function that performs the necessary actions to drop the ICMP 1240 message being processed. 1242 initial_mtu 1243 Variable holding the MTU for new connections, as explained in 1244 [RFC1191] and [RFC1981]. 1246 maxsizeacked 1247 Variable holding the largest packet size (data, plus headers) that 1248 has so far been acked for this connection, as explained in 1249 Section 7.2. 1251 maxsizesent 1252 Variable holding the largest packet size (data, plus headers) that 1253 has so far been sent for this connection, as explained in 1254 Section 7.2. 1256 nsegrto 1257 Variable holding the number of times this segment has timed out, 1258 as explained in Section 7.2. 1260 packet_size 1261 Variable holding the size of the IP datagram being sent. 1263 pending_message 1264 Variable (flag) that indicates whether there is a pending ICMP 1265 "Packet Too Big" message to be processed. 1267 save_message() 1268 Function that records the ICMP "Packet Too Big" message that has 1269 just been received. 1271 MINIMUM_MTU 1272 Constant holding the minimum MTU for the internet protocol in use 1273 (68 for IPv4, and 1280 for IPv6). 1275 MAXSEGRTO 1276 Constant holding the number of times a given segment must timeout 1277 before an ICMP "Packet Too Big" error message can be honored. 1279 EVENT: New TCP connection 1281 current_mtu = initial_mtu; 1282 maxsizesent = MINIMUM_MTU; 1283 maxsizeacked = MINIMUM_MTU; 1284 nsegrto = 0; 1285 pending_message = 0; 1287 EVENT: Segment is sent 1288 if (packet_size > maxsizesent) 1289 maxsizesent = packet_size; 1291 EVENT: Segment is received 1293 if (acked_packet_size > maxsizeacked) 1294 maxsizeacked = acked_packet_size; 1296 if (pending_message) 1297 if (ack > claimedtcpseq){ 1298 pending_message = 0; 1299 nsegrto = 0; 1300 } 1302 EVENT: ICMP "Packet Too Big" message is received 1303 if (claimedmtu <= MINIMUM_MTU) 1304 drop_message(); 1306 if (claimedtcpseq < SND.UNA || claimed_TCP_SEQ >= SND.NXT){ 1307 drop_message(); 1308 } 1310 else { 1311 if (claimedmtu > maxsizesent || claimedmtu >= current_mtu) 1312 drop_message(); 1314 else { 1315 if (claimedmtu > maxsizeacked){ 1316 adjust_mtu(); 1317 current_mtu = claimedmtu; 1318 maxsizesent = MINIMUM_MTU; 1319 } 1321 else { 1322 pending_message = 1; 1323 save_message(); 1324 } 1325 } 1326 } 1328 EVENT: Segment times out 1330 nsegrto++; 1332 if (pending_message && nsegrto >= MAXSEGRTO){ 1333 adjust_mtu(); 1334 nsegrto = 0; 1335 pending_message = 0; 1336 maxsizeacked = claimedmtu; 1337 maxsizesent = MINIMUM_MTU; 1338 current_mtu = claimedmtu; 1339 } 1341 Notes: 1342 All comparisions between sequence numbers must be performed using 1343 sequence number arithmethic. 1344 The pseudo-code implements the mechanism described in Section 7.2, 1345 the TCP sequence number checking described in Section 4.1, and the 1346 validation check on the advertised Next-Hop MTU described in 1347 [RFC1191] and [RFC1981]. 1349 8. Security Considerations 1351 This document describes the use of ICMP error messages to perform a 1352 number of attacks against the TCP protocol, and describes a number of 1353 widely-implemented counter-measures that either eliminate or reduce 1354 the impact of these attacks when they are performed by off-path 1355 attackers. 1357 Section 4.1 describes a validation check that could be enforced on 1358 ICMP error messages, such that TCP reacts only to those ICMP error 1359 messages that appear to relate to segments currently "in-flight" to 1360 the destination system. This requires more effort on the side of an 1361 off-path attacker at the expense of possible reduced responsiveness 1362 to network errors. 1364 Section 4.2 describes how obfuscation of TCP ephemeral ports require 1365 more effort on the side of the attacker to successfully exploit any 1366 of the attacks described in this document. 1368 Section 4.3 describes how ICMP error messages could possibly be 1369 filtered based on their payload, to prevent users of the local 1370 network from successfully performing attacks against third-party 1371 connections. This is analogous to ingress filtering and egress 1372 filtering of IP packets [IP-filtering]. 1374 Section 5.2 describes an attack-specific counter-measure for the 1375 blind connection-reset attack. It describes the processing of ICMP 1376 "hard errors" as "soft errors" when they are received for connections 1377 in any of the synchronized states. This countermeasure eliminates 1378 the aforementioned vulnerability in synchronized connections at the 1379 expense of a possible reduced responsiveness in some network 1380 scenarios. 1382 Section 6.2 describes an attack-specific counter-measure for the 1383 blind throughput-reduction attack. It suggests that the 1384 aforementioned vulnerability can be eliminated by ignoring ICMP 1385 Source Quench messages meant for TCP connections. This is in 1386 accordance with research results that indicate that ICMP Source 1387 Quench messages are ineffective and unfair antidote for congestion. 1389 Finally, Section 7.2 describes an attack-specific countermeasure for 1390 the blind performance-degrading attack. It consists of the 1391 validation check described in Section 4.1, with a modification that 1392 makes TCP react to ICMP "Packet Too Big" error messages such that 1393 they are processed when an outstanding TCP segment times out. This 1394 countermeasures parallels the Packetization Layer Path MTU Discovery 1395 (PLPMTUD) mechanism [RFC4821]. 1397 A discussion of these and other attack vectors for performing similar 1398 attacks against TCP (along with possible counter-measures) can be 1399 found in [CPNI-TCP] and [I-D.ietf-tcpm-tcp-security]. 1401 9. IANA Considerations 1403 This document has no actions for IANA. The RFC-Editor can remove 1404 this section before publication of this document as an RFC. 1406 10. Acknowledgements 1408 This document was inspired by Mika Liljeberg, while discussing some 1409 issues related to [RFC5461] by private e-mail. The author would like 1410 to thank (in alphabetical order): Bora Akyol, Mark Allman, Ran 1411 Atkinson, James Carlson, Alan Cox, Theo de Raadt, Wesley Eddy, Ted 1412 Faber, Juan Fraschini, Markus Friedl, Guillermo Gont, John Heffner, 1413 Alfred Hoenes, Vivek Kakkar, Michael Kerrisk, Mika Liljeberg, Matt 1414 Mathis, David Miller, Toby Moncaster, Miles Nordin, Eloy Paris, 1415 Kacheong Poon, Andrew Powell, Pekka Savola, Donald Smith, Pyda 1416 Srisuresh, Fred Templin, and Joe Touch for contributing many valuable 1417 comments. 1419 Juan Fraschini and the author of this document implemented freely- 1420 available audit tools to help vendors audit their systems by 1421 reproducing the attacks discussed in this document. This tools are 1422 available at http://www.gont.com.ar/tools/index.html . 1424 Markus Friedl, Chad Loder, and the author of this document, produced 1425 and tested in OpenBSD [OpenBSD] the first implementation of the 1426 counter-measure described in Section 7.2. This first implementation 1427 helped to test the effectiveness of the ideas introduced in this 1428 document, and has served as a reference implementation for other 1429 operating systems. 1431 The author would like to thank the UK's Centre for the Protection of 1432 National Infrastructure (CPNI) -- formerly National Infrastructure 1433 Security Co-ordination Centre (NISCC) -- for coordinating the 1434 disclosure of these issues with a large number of vendors and CSIRTs 1435 (Computer Security Incident Response Teams). 1437 The author wishes to express deep and heartfelt gratitude to Jorge 1438 Oscar Gont and Nelida Garcia, for their precious motivation and 1439 guidance. 1441 11. References 1442 11.1. Normative References 1444 [RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791, 1445 September 1981. 1447 [RFC0792] Postel, J., "Internet Control Message Protocol", STD 5, 1448 RFC 792, September 1981. 1450 [RFC0793] Postel, J., "Transmission Control Protocol", STD 7, 1451 RFC 793, September 1981. 1453 [RFC1122] Braden, R., "Requirements for Internet Hosts - 1454 Communication Layers", STD 3, RFC 1122, October 1989. 1456 [RFC1191] Mogul, J. and S. Deering, "Path MTU discovery", RFC 1191, 1457 November 1990. 1459 [RFC1812] Baker, F., "Requirements for IP Version 4 Routers", 1460 RFC 1812, June 1995. 1462 [RFC1981] McCann, J., Deering, S., and J. Mogul, "Path MTU Discovery 1463 for IP version 6", RFC 1981, August 1996. 1465 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1466 Requirement Levels", BCP 14, RFC 2119, March 1997. 1468 [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 1469 (IPv6) Specification", RFC 2460, December 1998. 1471 [RFC4301] Kent, S. and K. Seo, "Security Architecture for the 1472 Internet Protocol", RFC 4301, December 2005. 1474 [RFC4443] Conta, A., Deering, S., and M. Gupta, "Internet Control 1475 Message Protocol (ICMPv6) for the Internet Protocol 1476 Version 6 (IPv6) Specification", RFC 4443, March 2006. 1478 11.2. Informative References 1480 [CPNI-TCP] 1481 CPNI, "Security Assessment of the Transmission Control 1482 Protocol (TCP)", http://www.cpni.gov.uk/Docs/ 1483 tn-03-09-security-assessment-TCP.pdf, 2009. 1485 [DClark] Clark, D., "The Design Philosophy of the DARPA Internet 1486 Protocols", Computer Communication Review Vol. 18, No. 4, 1487 1988. 1489 [FreeBSD] The FreeBSD Project, "http://www.freebsd.org". 1491 [I-D.ietf-tcpm-tcp-auth-opt] 1492 Touch, J., Mankin, A., and R. Bonica, "The TCP 1493 Authentication Option", draft-ietf-tcpm-tcp-auth-opt-08 1494 (work in progress), October 2009. 1496 [I-D.ietf-tcpm-tcp-security] 1497 Gont, F., "Security Assessment of the Transmission Control 1498 Protocol (TCP)", draft-ietf-tcpm-tcp-security-00 (work in 1499 progress), August 2009. 1501 [I-D.ietf-tcpm-tcpsecure] 1502 Ramaiah, A., Stewart, R., and M. Dalal, "Improving TCP's 1503 Robustness to Blind In-Window Attacks", 1504 draft-ietf-tcpm-tcpsecure-12 (work in progress), 1505 September 2009. 1507 [I-D.ietf-tsvwg-port-randomization] 1508 Larsen, M. and F. Gont, "Port Randomization", 1509 draft-ietf-tsvwg-port-randomization-05 (work in progress), 1510 November 2009. 1512 [ICMP-Filtering] 1513 Gont, F., "Filtering of ICMP error messages", http:// 1514 www.gont.com.ar/papers/ 1515 filtering-of-icmp-error-messages.pdf. 1517 [IP-filtering] 1518 NISCC, "NISCC Technical Note 01/2006: Egress and Ingress 1519 Filtering", http://www.niscc.gov.uk/niscc/docs/ 1520 re-20060420-00294.pdf?lang=en, 2006. 1522 [Linux] The Linux Project, "http://www.kernel.org". 1524 [McKusick] 1525 McKusick, M., Bostic, K., Karels, M., and J. Quarterman, 1526 "The Design and Implementation of the 4.4BSD Operating 1527 System", Addison-Wesley , 1996. 1529 [NISCC] NISCC, "NISCC Vulnerability Advisory 532967/NISCC/ICMP: 1530 Vulnerability Issues in ICMP packets with TCP payloads", 1531 http://www.niscc.gov.uk/niscc/docs/ 1532 al-20050412-00308.html?lang=en, 2005. 1534 [NetBSD] The NetBSD Project, "http://www.netbsd.org". 1536 [OpenBSD] The OpenBSD Project, "http://www.openbsd.org". 1538 [OpenBSD-PF] 1539 The OpenBSD Packet Filter, 1540 "http://www.openbsd.org/faq/pf/". 1542 [RFC0816] Clark, D., "Fault isolation and recovery", RFC 816, 1543 July 1982. 1545 [RFC1321] Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321, 1546 April 1992. 1548 [RFC1323] Jacobson, V., Braden, B., and D. Borman, "TCP Extensions 1549 for High Performance", RFC 1323, May 1992. 1551 [RFC2385] Heffernan, A., "Protection of BGP Sessions via the TCP MD5 1552 Signature Option", RFC 2385, August 1998. 1554 [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., 1555 Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext 1556 Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999. 1558 [RFC2923] Lahey, K., "TCP Problems with Path MTU Discovery", 1559 RFC 2923, September 2000. 1561 [RFC3168] Ramakrishnan, K., Floyd, S., and D. Black, "The Addition 1562 of Explicit Congestion Notification (ECN) to IP", 1563 RFC 3168, September 2001. 1565 [RFC3390] Allman, M., Floyd, S., and C. Partridge, "Increasing TCP's 1566 Initial Window", RFC 3390, October 2002. 1568 [RFC4271] Rekhter, Y., Li, T., and S. Hares, "A Border Gateway 1569 Protocol 4 (BGP-4)", RFC 4271, January 2006. 1571 [RFC4821] Mathis, M. and J. Heffner, "Packetization Layer Path MTU 1572 Discovery", RFC 4821, March 2007. 1574 [RFC4907] Aboba, B., "Architectural Implications of Link 1575 Indications", RFC 4907, June 2007. 1577 [RFC4953] Touch, J., "Defending TCP Against Spoofing Attacks", 1578 RFC 4953, July 2007. 1580 [RFC5321] Klensin, J., "Simple Mail Transfer Protocol", RFC 5321, 1581 October 2008. 1583 [RFC5461] Gont, F., "TCP's Reaction to Soft Errors", RFC 5461, 1584 February 2009. 1586 [RFC5681] Allman, M., Paxson, V., and E. Blanton, "TCP Congestion 1587 Control", RFC 5681, September 2009. 1589 [US-CERT] US-CERT, "US-CERT Vulnerability Note VU#222750: TCP/IP 1590 Implementations do not adequately validate ICMP error 1591 messages", http://www.kb.cert.org/vuls/id/222750, 2005. 1593 [Watson] Watson, P., "Slipping in the Window: TCP Reset Attacks", 1594 2004 CanSecWest Conference , 2004. 1596 [Wright] Wright, G. and W. Stevens, "TCP/IP Illustrated, Volume 2: 1597 The Implementation", Addison-Wesley , 1994. 1599 Appendix A. Changes from previous versions of the draft (to be removed 1600 by the RFC Editor before publishing this document as an 1601 RFC) 1603 A.1. Changes from draft-ietf-tcpm-icmp-attacks-08 1605 o Fixes a couple of nits found by... Alfred!. Thanks! (again, and 1606 again, and again....). 1608 A.2. Changes from draft-ietf-tcpm-icmp-attacks-07 1610 o Addresses some remaining WGLC feedback sent off-list by Donald 1611 Smith and Guillermo Gont. 1613 A.3. Changes from draft-ietf-tcpm-icmp-attacks-06 1615 o Addresses WGLC feedback by Joe Touch and Donald Smith. 1617 A.4. Changes from draft-ietf-tcpm-icmp-attacks-05 1619 o Addresses feedback submitted by Wes Eddy 1620 (http://www.ietf.org/mail-archive/web/tcpm/current/msg04573.html 1621 and 1622 http://www.ietf.org/mail-archive/web/tcpm/current/msg04574.html) 1623 and Joe Touch (on June 8th... couldn't find online ref, sorry) on 1624 the TCPM WG mailing-list. 1626 A.5. Changes from draft-ietf-tcpm-icmp-attacks-04 1628 o The draft had expired and thus is resubmitted with no further 1629 changes. Currently working on a rev of the document (Please send 1630 feedback!). 1632 A.6. Changes from draft-ietf-tcpm-icmp-attacks-03 1634 o The draft had expired and thus is resubmitted with no further 1635 changes. 1637 A.7. Changes from draft-ietf-tcpm-icmp-attacks-02 1639 o Added a disclaimer to indicate that this document does not update 1640 the current specifications. 1642 o Addresses feedback sent off-list by Alfred Hoenes. 1644 o The text (particulary that which describes the counter-measures) 1645 was reworded to document what current implementations are doing, 1646 rather than "proposing" the implementation of the counter- 1647 measures. 1649 o Some text has been removed: we're just documenting the problem, 1650 and what existing implementations have done. 1652 o Miscelaneous editorial changes. 1654 A.8. Changes from draft-ietf-tcpm-icmp-attacks-01 1656 o Fixed references to the antispoof documents (were hardcoded and 1657 missing in the References Section). 1659 o The draft had expired and thus is resubmitted with only a minor 1660 editorial change. 1662 A.9. Changes from draft-ietf-tcpm-icmp-attacks-00 1664 o Added references to the specific sections of each of the 1665 referenced specifications 1667 o Corrected the threat analysys 1669 o Added clarification about whether the counter-measures violate the 1670 current specifications or not. 1672 o Changed text so that the document fits better in the Informational 1673 path 1675 o Added a specific section on IPsec (Section 2.3) 1677 o Added clarification and references on the use of ICMP filtering 1678 based on the ICMP payload 1680 o Updated references to obsoleted RFCs 1682 o Added a discussion of multipath scenarios, and possible lose in 1683 responsiveness resulting from the reaction to hard errors as soft 1684 errors 1686 o Miscellaneous editorial changes 1688 A.10. Changes from draft-gont-tcpm-icmp-attacks-05 1690 o Removed RFC 2119 wording to make the draft suitable for 1691 publication as an Informational RFC. 1693 o Added additional checks that should be performed on ICMP error 1694 messages (checksum of the IP header in the ICMP payload, and 1695 others). 1697 o Added clarification of the rationale behind each the TCP SEQ check 1699 o Miscellaneous editorial changes 1701 A.11. Changes from draft-gont-tcpm-icmp-attacks-04 1703 o Added section on additional considerations for validating ICMP 1704 error messages 1706 o Added reference to (draft) [RFC4907] 1708 o Added stress on the fact that ICMP error messages are unreliable 1710 o Miscellaneous editorial changes 1712 A.12. Changes from draft-gont-tcpm-icmp-attacks-03 1714 o Added references to existing implementations of the proposed 1715 counter-measures 1717 o The discussion in Section 4 was improved 1719 o The discussion of the blind connection-reset vulnerability was 1720 expanded and improved 1722 o The proposed counter-measure for the attack against the PMTUD was 1723 improved and simplified 1725 o Section 7.4 was added 1726 o Miscellaneous editorial changes 1728 A.13. Changes from draft-gont-tcpm-icmp-attacks-02 1730 o Fixed errors in in the discussion of the blind connection-reset 1731 attack 1733 o The proposed counter-measure for the attack against the PMTUD 1734 mechanism was refined to allow quick discovery of the Path-MTU 1736 o Section 7.3 was added so as to clarify the operation of the 1737 counter-measure for the attack against the PMTUD mechanism 1739 o Added CPNI contact information. 1741 o Miscellaneous editorial changes 1743 A.14. Changes from draft-gont-tcpm-icmp-attacks-01 1745 o The document was restructured for easier reading 1747 o A discussion of ICMPv6 was added in several sections of the 1748 document 1750 o Added Section on Acknowledgement number checking 1752 o Added Section 4.3 1754 o Added Section 7 1756 o Fixed typo in the ICMP types, in several places 1758 o Fixed typo in the TCP sequence number check formula 1760 o Miscellaneous editorial changes 1762 A.15. Changes from draft-gont-tcpm-icmp-attacks-00 1764 o Added a proposal to change the handling of the so-called ICMP hard 1765 errors during the synchronized states 1767 o Added a summary of the relevant RFCs in several sections 1769 o Miscellaneous editorial changes 1771 Author's Address 1773 Fernando Gont 1774 Universidad Tecnologica Nacional / Facultad Regional Haedo 1775 Evaristo Carriego 2644 1776 Haedo, Provincia de Buenos Aires 1706 1777 Argentina 1779 Phone: +54 11 4650 8472 1780 Email: fernando@gont.com.ar 1781 URI: http://www.gont.com.ar