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