idnits 2.17.1 draft-ietf-tcpm-icmp-attacks-04.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 16. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 1662. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1673. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1680. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1686. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) == There are 1 instance of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust Copyright Line does not match the current year -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (October 27, 2008) is 5657 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- ** Obsolete normative reference: RFC 793 (Obsoleted by RFC 9293) ** Obsolete normative reference: RFC 1981 (Obsoleted by RFC 8201) ** Obsolete normative reference: RFC 2460 (Obsoleted by RFC 8200) == Outdated reference: A later version (-09) exists of draft-ietf-tcpm-tcp-soft-errors-08 == Outdated reference: A later version (-13) exists of draft-ietf-tcpm-tcpsecure-10 == Outdated reference: A later version (-09) exists of draft-ietf-tsvwg-port-randomization-02 -- Obsolete informational reference (is this intentional?): RFC 816 (Obsoleted by RFC 7805) -- Obsolete informational reference (is this intentional?): RFC 1323 (Obsoleted by RFC 7323) -- Obsolete informational reference (is this intentional?): RFC 2385 (Obsoleted by RFC 5925) -- Obsolete informational reference (is this intentional?): RFC 2581 (Obsoleted by RFC 5681) -- Obsolete informational reference (is this intentional?): RFC 2616 (Obsoleted by RFC 7230, RFC 7231, RFC 7232, RFC 7233, RFC 7234, RFC 7235) -- Obsolete informational reference (is this intentional?): RFC 2821 (Obsoleted by RFC 5321) Summary: 5 errors (**), 0 flaws (~~), 5 warnings (==), 13 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 TCP Maintenance and Minor F. Gont 3 Extensions (tcpm) UTN/FRH 4 Internet-Draft October 27, 2008 5 Intended status: Informational 6 Expires: April 30, 2009 8 ICMP attacks against TCP 9 draft-ietf-tcpm-icmp-attacks-04.txt 11 Status of this Memo 13 By submitting this Internet-Draft, each author represents that any 14 applicable patent or other IPR claims of which he or she is aware 15 have been or will be disclosed, and any of which he or she becomes 16 aware will be disclosed, in accordance with Section 6 of BCP 79. 18 Internet-Drafts are working documents of the Internet Engineering 19 Task Force (IETF), its areas, and its working groups. Note that 20 other groups may also distribute working documents as Internet- 21 Drafts. 23 Internet-Drafts are draft documents valid for a maximum of six months 24 and may be updated, replaced, or obsoleted by other documents at any 25 time. It is inappropriate to use Internet-Drafts as reference 26 material or to cite them other than as "work in progress." 28 The list of current Internet-Drafts can be accessed at 29 http://www.ietf.org/ietf/1id-abstracts.txt. 31 The list of Internet-Draft Shadow Directories can be accessed at 32 http://www.ietf.org/shadow.html. 34 This Internet-Draft will expire on April 30, 2009. 36 Abstract 38 This document discusses the use of the Internet Control Message 39 Protocol (ICMP) to perform a variety of attacks against the 40 Transmission Control Protocol (TCP) and other similar protocols. 41 Additionally, describes a number of widely implemented modifications 42 to TCP's handling of ICMP error messages that help to mitigate these 43 issues. 45 Table of Contents 47 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 48 2. Background . . . . . . . . . . . . . . . . . . . . . . . . . . 5 49 2.1. The Internet Control Message Protocol (ICMP) . . . . . . . 5 50 2.1.1. ICMP for IP version 4 (ICMP) . . . . . . . . . . . . . 5 51 2.1.2. ICMP for IP version 6 (ICMPv6) . . . . . . . . . . . . 6 52 2.2. Handling of ICMP error messages . . . . . . . . . . . . . 6 53 2.3. Handling of ICMP error messages in the context of IPsec . 7 54 3. Constraints in the possible solutions . . . . . . . . . . . . 8 55 4. General counter-measures against ICMP attacks . . . . . . . . 9 56 4.1. TCP sequence number checking . . . . . . . . . . . . . . . 9 57 4.2. Port randomization . . . . . . . . . . . . . . . . . . . . 10 58 4.3. Filtering ICMP error messages based on the ICMP payload . 10 59 5. Blind connection-reset attack . . . . . . . . . . . . . . . . 11 60 5.1. Description . . . . . . . . . . . . . . . . . . . . . . . 11 61 5.2. Attack-specific counter-measures . . . . . . . . . . . . . 12 62 6. Blind throughput-reduction attack . . . . . . . . . . . . . . 13 63 6.1. Description . . . . . . . . . . . . . . . . . . . . . . . 13 64 6.2. Attack-specific counter-measures . . . . . . . . . . . . . 13 65 7. Blind performance-degrading attack . . . . . . . . . . . . . . 14 66 7.1. Description . . . . . . . . . . . . . . . . . . . . . . . 14 67 7.2. Attack-specific counter-measures . . . . . . . . . . . . . 15 68 7.3. The counter-measure for the PMTUD attack in action . . . . 19 69 7.3.1. Normal operation for bulk transfers . . . . . . . . . 19 70 7.3.2. Operation during Path-MTU changes . . . . . . . . . . 21 71 7.3.3. Idle connection being attacked . . . . . . . . . . . . 22 72 7.3.4. Active connection being attacked after discovery 73 of the Path-MTU . . . . . . . . . . . . . . . . . . . 23 74 7.3.5. TCP peer attacked when sending small packets just 75 after the three-way handshake . . . . . . . . . . . . 23 76 7.4. Pseudo-code for the counter-measure for the blind 77 performance-degrading attack . . . . . . . . . . . . . . . 24 78 8. Security Considerations . . . . . . . . . . . . . . . . . . . 28 79 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 28 80 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 29 81 10.1. Normative References . . . . . . . . . . . . . . . . . . . 29 82 10.2. Informative References . . . . . . . . . . . . . . . . . . 29 83 Appendix A. An analysis of ICMP hard errors . . . . . . . . . . . 32 84 Appendix B. Advice and guidance to vendors . . . . . . . . . . . 33 85 Appendix C. Changes from previous versions of the draft (to 86 be removed by the RFC Editor before publishing 87 this document as an RFC) . . . . . . . . . . . . . . 33 88 C.1. Changes from draft-ietf-tcpm-icmp-attacks-03 . . . . . . . 33 89 C.2. Changes from draft-ietf-tcpm-icmp-attacks-02 . . . . . . . 34 90 C.3. Changes from draft-ietf-tcpm-icmp-attacks-01 . . . . . . . 34 91 C.4. Changes from draft-ietf-tcpm-icmp-attacks-00 . . . . . . . 34 92 C.5. Changes from draft-gont-tcpm-icmp-attacks-05 . . . . . . . 35 93 C.6. Changes from draft-gont-tcpm-icmp-attacks-04 . . . . . . . 35 94 C.7. Changes from draft-gont-tcpm-icmp-attacks-03 . . . . . . . 35 95 C.8. Changes from draft-gont-tcpm-icmp-attacks-02 . . . . . . . 36 96 C.9. Changes from draft-gont-tcpm-icmp-attacks-01 . . . . . . . 36 97 C.10. Changes from draft-gont-tcpm-icmp-attacks-00 . . . . . . . 36 98 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 36 99 Intellectual Property and Copyright Statements . . . . . . . . . . 38 101 1. Introduction 103 ICMP [RFC0792] is a fundamental part of the TCP/IP protocol suite, 104 and is used mainly for reporting network error conditions. However, 105 the current specifications do not recommend any kind of validation 106 checks on the received ICMP error messages, thus allowing variety of 107 attacks against TCP [RFC0793] by means of ICMP, which include blind 108 connection-reset, blind throughput-reduction, and blind performance- 109 degrading attacks. All of these attacks can be performed even being 110 off-path, without the need to sniff the packets that correspond to 111 the attacked TCP connection. 113 While the possible security implications of ICMP have been known in 114 the research community for a long time, there has never been an 115 official proposal on how to deal with these vulnerabiliies. In 2005, 116 a disclosure process was carried out by the UK's National 117 Infrastructure Security Co-ordination Centre (NISCC) (now CPNI, 118 Centre for the Protection of National Infrastructure), with the 119 collaboration of other computer emergency response teams. A large 120 number of implementations were found vulnerable to either all or a 121 subset of the attacks discussed in this document [NISCC][US-CERT]. 122 The affected systems ranged from TCP/IP implementations meant for 123 desktop computers, to TCP/IP implementations meant for core Internet 124 routers. 126 It is clear that implementations should be more cautious when 127 processing ICMP error messages, to eliminate or mitigate the use of 128 ICMP to perform attacks against TCP [RFC4907]. 130 This document aims to raise awareness of the use of ICMP to perform a 131 variety of attacks against TCP, and discusses several counter- 132 measures that eliminate or minimize the impact of these attacks. 133 Most of the these counter-measures can be implemented while still 134 remaining compliant with the current specifications, as they simply 135 describe reasons for not taking the advice provided in the 136 specifications in terms of "SHOULDs", but still comply with the 137 requirements stated as "MUSTs". 139 Section 2 provides background information on ICMP. Section 3 140 discusses the constraints in the general counter-measures that can be 141 implemented against the attacks described in this document. 142 Section 4 proposes several general validation checks that can be 143 implemented to mitigate any ICMP-based attack. Finally, Section 5, 144 Section 6, and Section 7, discuss a variety of ICMP attacks that can 145 be performed against TCP, and propose attack-specific counter- 146 measures that eliminate or greatly mitigate their impact. 148 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 149 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 150 document are to be interpreted as described in RFC 2119 [RFC2119]. 152 2. Background 154 2.1. The Internet Control Message Protocol (ICMP) 156 The Internet Control Message Protocol (ICMP) is used in the Internet 157 Architecture mainly to perform the fault-isolation function, that is, 158 the group of actions that hosts and routers take to determine that 159 there is some network failure [RFC0816]. 161 When an intermediate router detects a network problem while trying to 162 forward an IP packet, it will usually send an ICMP error message to 163 the source system, to raise awareness of the network problem taking 164 place. In the same way, there are a number of scenarios in which an 165 end-system may generate an ICMP error message if it finds a problem 166 while processing a datagram. The received ICMP errors are handed to 167 the corresponding transport-protocol instance, which will usually 168 perform a fault recovery function. 170 It is important to note that ICMP error messages are unreliable, and 171 may be discarded due to data corruption, network congestion or rate- 172 limiting. Thus, while they provide useful information, upper layer 173 protocols cannot depend on ICMP for correct operation. 175 2.1.1. ICMP for IP version 4 (ICMP) 177 [RFC0792] specifies the Internet Control Message Protocol (ICMP) to 178 be used with the Internet Protocol version 4 (IPv4). It defines, 179 among other things, a number of error messages that can be used by 180 end-systems and intermediate systems to report errors to the sending 181 system. The Host Requirements RFC [RFC1122] classifies ICMP error 182 messages into those that indicate "soft errors", and those that 183 indicate "hard errors", thus roughly defining the semantics of them. 185 The ICMP specification [RFC0792] also defines the ICMP Source Quench 186 message (type 4, code 0), which is meant to provide a mechanism for 187 flow control and congestion control. 189 [RFC1191] defines a mechanism called "Path MTU Discovery" (PMTUD), 190 which makes use of ICMP error messages of type 3 (Destination 191 Unreachable), code 4 (fragmentation needed and DF bit set) to allow 192 systems to determine the MTU of an arbitrary internet path. 194 Appendix D of [RFC4301] provides information about which ICMP error 195 messages are produced by hosts, intermediate routers, or both. 197 2.1.2. ICMP for IP version 6 (ICMPv6) 199 [RFC4443] specifies the Internet Control Message Protocol (ICMPv6) to 200 be used with the Internet Protocol version 6 (IPv6) [RFC2460]. 202 [RFC4443] defines the "Packet Too Big" (type 2, code 0) error 203 message, that is analogous to the ICMP "fragmentation needed and DF 204 bit set" (type 3, code 4) error message. [RFC1981] defines the Path 205 MTU Discovery mechanism for IP Version 6, that makes use of these 206 messages to determine the MTU of an arbitrary internet path. 208 Appendix D of [RFC4301] provides information about which ICMPv6 error 209 messages are produced by hosts, intermediate routers, or both. 211 2.2. Handling of ICMP error messages 213 The Host Requirements RFC [RFC1122] states in Section 4.2.3.9 that a 214 TCP MUST act on an ICMP error message passed up from the IP layer, 215 directing it to the connection that elicited the error. 217 In order to allow ICMP messages to be demultiplexed by the receiving 218 system, part of the original packet that elicited the message is 219 included in the payload of the ICMP error message. Thus, the 220 receiving system can use that information to match the ICMP error to 221 the transport protocol instance that elicited it. 223 Neither the Host Requirements RFC [RFC1122] nor the original TCP 224 specification [RFC0793] recommend any validation checks on the 225 received ICMP messages. Thus, as long as the ICMP payload contains 226 the information that identifies an existing communication instance, 227 it will be processed by the corresponding transport-protocol 228 instance, and the corresponding action will be performed. 230 Therefore, in the case of TCP, an attacker could send a forged ICMP 231 message to the attacked system, and, as long as he is able to guess 232 the four-tuple (i.e., Source IP Address, Source TCP port, Destination 233 IP Address, and Destination TCP port) that identifies the 234 communication instance to be attacked, he will be able to use ICMP to 235 perform a variety of attacks. 237 Generally, the four-tuple required to perform these attacks is not 238 known. However, as discussed in [Watson] and [RFC4953], there are a 239 number of scenarios (notably that of TCP connections established 240 between two BGP routers [RFC4271]), in which an attacker may be able 241 to know or guess the four-tuple that identifies a TCP connection. In 242 such a case, if we assume the attacker knows the two systems involved 243 in the TCP connection to be attacked, both the client-side and the 244 server-side IP addresses could be known or be within a reasonable 245 number of possibilities. Furthermore, as most Internet services use 246 the so-called "well-known" ports, only the client port number might 247 need to be guessed. In such a scenario, an attacker would need to 248 send, in principle, at most 65536 packets to perform any of the 249 attacks described in this document. These issues are exacerbated by 250 the fact that most systems choose the port numbers they use for 251 outgoing connections from a subset of the whole port number space, 252 thus reducing the amount of work needed to successfully perform these 253 attacks. 255 The need to be more more cautious when processing received ICMP error 256 messages in order to mitigate or eliminate the impact of the attacks 257 described in this document has been documented by the Internet 258 Architecture Board (IAB) in [RFC4907]. 260 2.3. Handling of ICMP error messages in the context of IPsec 262 Section 5.2 of [RFC4301] describes the processing of inbound IP 263 Traffic in the case of "unprotected-to-protected". In the case of 264 ICMP, when an unprotected ICMP error message is received, it is 265 matched to the corresponding security association by means of the SPI 266 (Security Parameters Index) included in the payload of the ICMP error 267 message. Then, local policy is applied to determine whether to 268 accept or reject the message and, if accepted, what action to take as 269 a result. For example, if an ICMP unreachable message is received, 270 the implementation must decide whether to act on it, reject it, or 271 act on it with constraints. Section 8 ("Path MTU/DF processing") 272 discusses the processing of unauthenticated ICMP "fragmentation 273 needed and DF bit set" (type 3, code 3) and ICMPv6 "Packet Too Big" 274 (type 2, code 0) messages when an IPsec implementation is configured 275 to process (vs. ignore) such messages. 277 Section 6.1.1 of [RFC4301] notes that processing of unauthenticated 278 ICMP error messages may result in denial or degradation of service, 279 and therefore it would be desirable to ignore such messages. 280 However, it also notes that in many cases ignoring these ICMP 281 messages can degrade service, e.g., because of a failure to process 282 PMTUD and redirection messages, and therefore there is also a 283 motivation for accepting and acting upon them. It finally states 284 that to accommodate both ends of this spectrum, a compliant IPsec 285 implementation MUST permit a local administrator to configure an 286 IPsec implementation to accept or reject unauthenticated ICMP 287 traffic, and that this control MUST be at the granularity of ICMP 288 type and MAY be at the granularity of ICMP type and code. 289 Additionally, an implementation SHOULD incorporate mechanisms and 290 parameters for dealing with such traffic. 292 Thus, the policy to apply for the processing of unprotected ICMP 293 error messages is left up to the implementation and administrator. 295 3. Constraints in the possible solutions 297 For ICMPv4, [RFC0792] states that the internet header plus the first 298 64 bits of the packet that elicited the ICMP message are to be 299 included in the payload of the ICMP error message. Thus, it is 300 assumed that all data needed to identify a transport protocol 301 instance and process the ICMP error message is contained in the first 302 64 bits of the transport protocol header. Section 3.2.2 of [RFC1122] 303 states that "the Internet header and at least the first 8 data octets 304 of the datagram that triggered the error" are to be included in the 305 payload of ICMP error messages, and that "more than 8 octets MAY be 306 sent", thus allowing implementations to include more data from the 307 original packet than those required by the original ICMP 308 specification. The Requirements for IP Version 4 Routers RFC 309 [RFC1812] states that ICMP error messages "SHOULD contain as much of 310 the original datagram as possible without the length of the ICMP 311 datagram exceeding 576 bytes". 313 Thus, for ICMP messages generated by hosts, we can only expect to get 314 the entire IP header of the original packet, plus the first 64 bits 315 of its payload. For TCP, this means that the only fields that will 316 be included in the ICMP payload are: the source port number, the 317 destination port number, and the 32-bit TCP sequence number. This 318 clearly imposes a constraint on the possible validation checks that 319 can be performed, as there is not much information avalable on which 320 to perform them. 322 This means, for example, that even if TCP were signing its segments 323 by means of the TCP MD5 signature option [RFC2385], this mechanism 324 could not be used as a counter-measure against ICMP-based attacks, 325 because, as ICMP messages include only a piece of the TCP segment 326 that elicited the error, the MD5 [RFC1321] signature could not be 327 recalculated. In the same way, even if the attacked peer were 328 authenticating its packets at the IP layer [RFC4301], because only a 329 part of the original IP packet would be available, the signature used 330 for authentication could not be recalculated, and thus the 331 authentication header in the original packet could not be used as a 332 counter-measure for ICMP-based attacks against TCP. 334 For IPv6, the payload of ICMPv6 error messages includes as many 335 octets from the IPv6 packet that elicited the ICMPv6 error message as 336 will fit without making the resulting ICMPv6 error message exceed the 337 minimum IPv6 MTU (1280 octets) [RFC4443]. Thus, more information is 338 available than in the IPv4 case. 340 Hosts could require ICMP error messages to be authenticated 341 [RFC4301], in order to act upon them. However, while this 342 requirement could make sense for those ICMP error messages sent by 343 hosts, it would not be feasible for those ICMP error messages 344 generated by routers, as this would imply either that the attacked 345 system should have a security association [RFC4301] with every 346 existing intermediate system, or that it should be able to establish 347 one dynamically. Current levels of deployment of protocols for 348 dynamic establishment of security associations makes this unfeasible. 349 Also, there may be some scenarios, such as embedded devices, in which 350 the processing power requirements of authentication might not allow 351 IPSec authentication to be implemented effectively. 353 4. General counter-measures against ICMP attacks 355 The following subsections describe a number of mitigation techniques 356 that help to eliminate or mitigate the impact of the attacks 357 discussed in this document. Rather than being alternative counter- 358 measures, they can be implemented together to increase the protection 359 against these attacks. 361 4.1. TCP sequence number checking 363 The current specifications do not impose any validity checks on the 364 TCP segment that is contained in the ICMP payload. For instance, no 365 checks are performed to verify that a received ICMP error message has 366 been elicited by a segment that was "in flight" to the destination. 367 Thus, even stale ICMP error messages will be acted upon. 369 Many TCP implementations have incorporated a validation check so 370 makes TCP react only to those ICMP error messages elicited by 371 segments that were "in-flight" to the destination system. These 372 implementations check that the TCP sequence number contained in the 373 payload of the ICMP error message is within the range SND.UNA =< 374 SEG.SEQ < SND.NXT. This means that they require that the sequence 375 number be within the range of the data already sent but not yet 376 acknowledged. If an ICMP error message does not pass this check, it 377 is discarded. 379 Even if an attacker were able to guess the four-tuple that identifies 380 the TCP connection, this additional check would reduce the 381 possibility of considering a spoofed ICMP packet as valid to 382 Flight_Size/2^^32 (where Flight_Size is the number of data bytes 383 already sent to the remote peer, but not yet acknowledged [RFC2581]). 384 For connections in the SYN-SENT or SYN-RECEIVED states, this would 385 reduce the possibility of considering a spoofed ICMP packet as valid 386 to 1/2^^32. For a TCP endpoint with no data "in flight", this would 387 completely eliminate the possibility of success of these attacks. 389 This validation check has been implemented in Linux [Linux] for many 390 years, in OpenBSD [OpenBSD] since 2004, and in FreeBSD [FreeBSD] and 391 NetBSD [NetBSD] since 2005. 393 It is important to note that while this check greatly increases the 394 number of packets required to perform any of the attacks discussed in 395 this document, this may not be enough in those scenarios in which 396 bandwidth is easily available, and/or large TCP windows [RFC1323] are 397 in use. Additionally, this validation check does not help to prevent 398 on-path attacks, that is, attacks performed in scenarios in which the 399 attacker can sniff the packets that correspond to the target TCP 400 connection. 402 4.2. Port randomization 404 As discussed in the previous sections, in order to perform any of the 405 attacks described in this document, an attacker would need to guess 406 (or know) the four-tuple that identifies the connection to be 407 attacked. Increasing the port number range used for outgoing TCP 408 connections, and randomizing the port number chosen for each outgoing 409 TCP conenctions would make it harder for an attacker to perform any 410 of the attacks discussed in this document. 412 [I-D.ietf-tsvwg-port-randomization] discusses a number of algorithms 413 to randomize the ephemeral ports used by clients. 415 4.3. Filtering ICMP error messages based on the ICMP payload 417 The source address of ICMP error messages does not need to be spoofed 418 to perform the attacks described in this document. Therefore, simple 419 filtering based on the source address of ICMP error messages does not 420 serve as a counter-measure against these attacks. However, a more 421 advanced packet filtering can be implemented in middlebox devices 422 such as firewalls and NATs. Middleboxes implementing such advanced 423 filtering look at the payload of the ICMP error messages, and perform 424 ingress and egress packet filtering based on the source IP address of 425 the IP header contained in the payload of the ICMP error message. As 426 the source IP address contained in the payload of the ICMP error 427 message does need to be spoofed to perform the attacks described in 428 this document, this kind of advanced filtering serves as a counter- 429 measure against these attacks. As with traditional egress filtering 430 [IP-filtering], egress filtering based on the ICMP payload can help 431 to prevent users of the network being protected by the firewall from 432 successfully performing ICMP attacks against TCP connections 433 established between external systems. Additionally, ingress 434 filtering based on the ICMP payload can prevent TCP connections 435 established between internal systems from attacks performed by 436 external systems. [ICMP-Filtering] provides examples of ICMP 437 filtering based on the ICMP payload. 439 This filtering technique has been implemented in OpenBSD's Packet 440 Filter [OpenBSD-PF], which has in turn been ported to a number of 441 systems, including FreeBSD [FreeBSD]. 443 5. Blind connection-reset attack 445 5.1. Description 447 When TCP is handed an ICMP error message, it will perform its fault 448 recovery function, as follows: 450 o If the network problem being reported is a hard error, TCP will 451 abort the corresponding connection. 453 o If the network problem being reported is a soft error, TCP will 454 just record this information, and repeatedly retransmit its data 455 until they either get acknowledged, or the connection times out. 457 The Host Requirements RFC [RFC1122] states (in Section 4.2.3.9) that 458 a host SHOULD abort the corresponding connection when receiving an 459 ICMP error message that indicates a "hard error", and states that 460 ICMP error messages of type 3 (Destination Unreachable) codes 2 461 (protocol unreachable), 3 (port unreachable), and 4 (fragmentation 462 needed and DF bit set) should be considered to indicate hard errors. 463 In the case of ICMP port unreachables, the specifications are 464 ambiguous, as Section 4.2.3.9 of [RFC1122] states that TCP SHOULD 465 abort the corresponding connection in response to them, but Section 466 3.2.2.1 of the same RFC ([RFC1122] states that TCP MUST abort the 467 connection in response to them. 469 While [RFC4443] did not exist when [RFC1122] was published, one could 470 extrapolate the concept of "hard errors" to ICMPv6 error messages of 471 type 1 (Destination unreachable) codes 1 (communication with 472 destination administratively prohibited), and 4 (port unreachable). 474 Thus, an attacker could use ICMP to perform a blind connection-reset 475 attack by sending any ICMP error message that indicates a "hard 476 error", to either of the two TCP endpoints of the connection. 477 Because of TCP's fault recovery policy, the connection would be 478 immediately aborted. 480 Some stacks are known to extrapolate ICMP hard errors across TCP 481 connections, increasing the impact of this attack, as a single ICMP 482 packet could bring down all the TCP connections between the 483 corresponding peers. 485 It is important to note that even if TCP itself were protected 486 against the blind connection-reset attack described in [Watson] and 487 [I-D.ietf-tcpm-tcpsecure], by means authentication at the network 488 layer [RFC4301], by means of the TCP MD5 signature option [RFC2385], 489 or by means of the mechanism proposed in [I-D.ietf-tcpm-tcpsecure], 490 the blind connection-reset attack described in this document would 491 still succeed. 493 5.2. Attack-specific counter-measures 495 This section describes a modification to TCP's reaction to ICMP hard 496 errors that has been incorporated in a large number of TCP 497 implementations. An analysis of each of the different ICMP "hard 498 error" messages is included in Appendix A. 500 TCPs implementing this modification treat all ICMP "hard errors" 501 received for connections in any of the synchronized states 502 (ESTABLISHED, FIN-WAIT-1, FIN-WAIT-2, CLOSE-WAIT, CLOSING, LAST-ACK 503 or TIME-WAIT)as "soft errors". Therefore, they do not abort the 504 corresponding connection upon receipt of them. Additionally, they do 505 not extrapolate ICMP errors across TCP connections. This policy is 506 based on the premise that TCP should be as robust as possible. 507 Aborting the connection would be to ignore the valuable feature of 508 the Internet that for many internal failures it reconstructs its 509 function without any disruption of the end points [RFC0816]. 511 It is interesting to note that, as ICMP error messages are 512 unreliable, transport protocols should not depend on them for correct 513 functioning. In the event one of these messages were legitimate, the 514 corresponding connection would eventually time out. Also, 515 applications may still be notified asynchronously about the error 516 contition, and thus may still abort their connections on their own if 517 they consider it appropriate. 519 In scenarios such as that in which an intermediate system sets the DF 520 bit in the segments transmitted by a TCP that does not implement 521 PMTUD, or the TCP at one of the endpoints of the connection is 522 dynamically disabled, TCP would only abort the connection after a 523 USER TIMEOUT [RFC0793], losing responsiveness. However, these 524 scenarios are very unlikely in production environments, and it is 525 probably preferebable to potentially lose responsiveness for the sake 526 of robustness. It should also be noted that applications may still 527 be notified asynchronously about the error condition, and thus may 528 still abort their connections on their own if they consider it 529 appropriate. 531 In scenarios of multipath routing or route changes, failures in some 532 (but not all) of the paths may elicit ICMP error messages that would 533 likely not cause a connection abort if any of the counter-measures 534 described in this section were implemented. However, aborting the 535 connection would be to ignore the valuable feature of the Internet 536 that for many internal failures it reconstructs its function without 537 any disruption of the end points [RFC0816]. That is, communication 538 should survive if there is still a working path to the destination 539 system [DClark]. Additionally, applications may still be notified 540 asynchronously about the error condition, and thus may still abort 541 their connections on their own if they consider it appropriate. 543 This counter-measure has been implemented in BSD-derived TCP/IP 544 implementations (e.g., [FreeBSD], [NetBSD], and [OpenBSD]) for more 545 than ten years [Wright][McKusick]. The Linux kernel has also 546 implemented this policy for more than ten years [Linux]. 548 6. Blind throughput-reduction attack 550 6.1. Description 552 The Host requirements RFC [RFC1122] states in Section 4.2.3.9 that 553 hosts MUST react to ICMP Source Quench messages by slowing 554 transmission on the connection. Thus, an attacker could send ICMP 555 Source Quench (type 4, code 0) messages to a TCP endpoint to make it 556 reduce the rate at which it sends data to the other end-point of the 557 connection. [RFC1122] further adds that the RECOMMENDED procedure is 558 to put the corresponding connection in the slow-start phase of TCP's 559 congestion control algorithm [RFC2581]. In the case of those 560 implementations that use an initial congestion window of one segment, 561 a sustained attack would reduce the throughput of the attacked 562 connection to about SMSS (Sender Maximum Segment Size) [RFC2581] 563 bytes per RTT (round-trip time). The throughput achieved during an 564 attack might be a little higher if a larger initial congestion window 565 is in use [RFC3390]. 567 6.2. Attack-specific counter-measures 569 As discussed in the Requirements for IP Version 4 Routers RFC 570 [RFC1812], research seems to suggest that ICMP Source Quench is an 571 ineffective (and unfair) antidote for congestion. [RFC1812] further 572 states that routers SHOULD NOT send ICMP Source Quench messages in 573 response to congestion. On the other hand, TCP implements its own 574 congestion control mechanisms [RFC2581] [RFC3168], that do not depend 575 on ICMP Source Quench messages. 577 Based on this reasoning, a large number of implementations completely 578 ignore ICMP Source Quench messages meant for TCP connections. This 579 behavior has been implemented in, at least, Linux [Linux] since 2004, 580 and in FreeBSD [FreeBSD], NetBSD [NetBSD], and OpenBSD [OpenBSD] 581 since 2005. However, it must be noted that this behaviour violates 582 the requirement in [RFC1122] to react to ICMP Source Quench messages 583 by slowing transmission on the connection. 585 7. Blind performance-degrading attack 587 7.1. Description 589 When one IP system has a large amount of data to send to another 590 system, the data will be transmitted as a series of IP datagrams. It 591 is usually preferable that these datagrams be of the largest size 592 that does not require fragmentation anywhere along the path from the 593 source to the destination. This datagram size is referred to as the 594 Path MTU (PMTU), and is equal to the minimum of the MTUs of each hop 595 in the path. A technique called "Path MTU Discovery" (PMTUD) lets IP 596 systems determine the Path MTU of an arbitrary internet path. 597 [RFC1191] and [RFC1981] specify the PMTUD mechanism for IPv4 and 598 IPv6, respectively. 600 The PMTUD mechanism for IPv4 uses the Don't Fragment (DF) bit in the 601 IP header to dynamically discover the Path MTU. The basic idea 602 behind the PMTUD mechanism is that a source system assumes that the 603 MTU of the path is that of the first hop, and sends all its datagrams 604 with the DF bit set. If any of the datagrams is too large to be 605 forwarded without fragmentation by some intermediate router, the 606 router will discard the corresponding datagram, and will return an 607 ICMP "Destination Unreachable" (type 3) "fragmentation neeed and DF 608 set" (code 4) error message to the sending system. This message will 609 report the MTU of the constricting hop, so that the sending system 610 can reduce the assumed Path-MTU accordingly. 612 For IPv6, intermediate systems do not fragment packets. Thus, 613 there's an "implicit" DF bit set in every packet sent on a network. 614 If any of the datagrams is too large to be forwarded without 615 fragmentation by some intermediate router, the router will discard 616 the corresponding datagram, and will return an ICMPv6 "Packet Too 617 Big" (type 2, code 0) error message to sending system. This message 618 will report the MTU of the constricting hop, so that the sending 619 system can reduce the assumed Path-MTU accordingly. 621 As discussed in both [RFC1191] and [RFC1981], the Path-MTU Discovery 622 mechanism can be used to attack TCP. An attacker could send a forged 623 ICMP "Destination Unreachable, fragmentation needed and DF set" 624 packet (or their ICMPv6 counterpart) to the sending system, 625 advertising a small Next-Hop MTU. As a result, the attacked system 626 would reduce the size of the packets it sends for the corresponding 627 connection accordingly. 629 The effect of this attack is two-fold. On one hand, it will increase 630 the headers/data ratio, thus increasing the overhead needed to send 631 data to the remote TCP end-point. On the other hand, if the attacked 632 system wanted to keep the same throughput it was achieving before 633 being attacked, it would have to increase the packet rate. On 634 virtually all systems this will lead to an increase in the IRQ 635 (Interrrupt ReQuest) rate and protocol processing time, thus 636 increasing processor utilization, and degrading the overall system 637 performance. 639 A particular scenario that may take place is that in which an 640 attacker reports a Next-Hop MTU smaller than or equal to the amount 641 of bytes needed for headers (IP header, plus TCP header). For 642 example, if the attacker reports a Next-Hop MTU of 68 bytes, and the 643 amount of bytes used for headers (IP header, plus TCP header) is 644 larger than 68 bytes, the assumed Path-MTU will not even allow the 645 attacked system to send a single byte of application data without 646 fragmentation. This particular scenario might lead to unpredictable 647 results. Another posible scenario is that in which a TCP connection 648 is being secured by means of IPSec. If the Next-Hop MTU reported by 649 the attacker is smaller than the amount of bytes needed for headers 650 (IP and IPSec, in this case), the assumed Path-MTU will not even 651 allow the attacked system to send a single byte of the TCP header 652 without fragmentation. This is another scenario that may lead to 653 unpredictable results. 655 For IPv4, the reported Next-Hop MTU could be as low as 68 octets, as 656 [RFC0791] requires every internet module to be able to forward a 657 datagram of 68 octets without further fragmentation. For IPv6, the 658 reported Next-Hop MTU could be as low as 1280 octets (the minimum 659 IPv6 MTU) [RFC2460]. 661 7.2. Attack-specific counter-measures 663 This section describes a modification to the PMTUD mechanism 664 specified in [RFC1191] and [RFC1981] that has been implemented in a 665 variety of TCP implementations to improve TCP's resistance to the 666 blind performance-degrading attack described in Section 7.1. The 667 described mechanism basically disregards ICMP messages when a 668 connection makes progress. This modification does not violate any of 669 the requirements stated in [RFC1191] and [RFC1981]. 671 Henceforth, we will refer to both ICMP "fragmentation needed and DF 672 bit set" and ICMPv6 "Packet Too Big" messages as "ICMP Packet Too 673 Big" messages. 675 In addition to the general validation check described in Section 4.1, 676 these implementations include a modification to TCP's reaction to 677 ICMP "Packet Too Big" error messages that disregards them when a 678 connection makes progress, and honors them only after the 679 corresponding data have been retransmitted a specified number of 680 times. This means that upon receipt of an ICMP "Packet Too Big" 681 error message, TCP just records this information, and honors it only 682 when the corresponding data have already been retransmitted a 683 specified number of times. 685 While this basic policy would greatly mitigate the impact of the 686 attack against the PMTUD mechanism, it would also mean that it might 687 take TCP more time to discover the Path-MTU for a TCP connection. 688 This would be particularly annoying for connections that have just 689 been established, as it might take TCP several transmission attempts 690 (and the corresponding timeouts) before it discovers the PMTU for the 691 corresponding connection. Thus, this policy would increase the time 692 it takes for data to begin to be received at the destination host. 694 In order to protect TCP from the attack against the PMTUD mechanism, 695 while still allowing TCP to quickly determine the initial Path-MTU 696 for a connection, the aforementioned implementations have divided the 697 traditional PMTUD mechanism into two stages: Initial Path-MTU 698 Discovery, and Path-MTU Update. 700 The Initial Path-MTU Discovery stage is when TCP tries to send 701 segments that are larger than the ones that have so far been sent and 702 acknowledged for this connection. That is, in the Initial Path-MTU 703 Discovery stage TCP has no record of these large segments getting to 704 the destination host, and thus these implementations believe the 705 network when it reports that these packets are too large to reach the 706 destination host without being fragmented. 708 The Path-MTU Update stage is when TCP tries to send segments that are 709 equal to or smaller than the ones that have already been sent and 710 acknowledged for this connection. During the Path-MTU Update stage, 711 TCP already has knowledge of the estimated Path-MTU for the given 712 connection. Thus, in this case these implementations are more 713 cautious with the errors being reported by the network. 715 In order to allow TCP to distinguish segments between those 716 performing Initial Path-MTU Discovery and those performing Path-MTU 717 Update, two new variables are introduced to TCP: maxsizeacked and 718 maxsizesent. 720 maxsizesent holds the size (in octets) of the largest packet that has 721 so far been sent for this connection. It is initialized to 68 (the 722 minimum IPv4 MTU) when the underlying internet protocol is IPv4, and 723 is initialized to 1280 (the minimum IPv6 MTU) when the underlying 724 internet protocol is IPv6. Whenever a packet larger than maxsizesent 725 octets is sent, maxsizesent is set to that value. 727 On the other hand, maxsizeacked holds the size (in octets) of the 728 largest packet that has so far been acknowledged for this connection. 729 It is initialized to 68 (the minimum IPv4 MTU) when the underlying 730 internet protocol is IPv4, and is initialized to 1280 (the minimum 731 IPv6 MTU) when the underlying internet protocol is IPv6. Whenever an 732 acknowledgement for a packet larger than maxsizeacked octets is 733 received, maxsizeacked is set to the size of that acknowledged 734 packet. 736 Upon receipt of an ICMP "Packet Too Big" error message, the Next-Hop 737 MTU claimed by the ICMP message (henceforth "claimedmtu") is compared 738 with maxsizesent. If claimedmtu is equal to or larger than 739 maxsizesent, then the ICMP error message is silently discarded. The 740 rationale for this is that the ICMP error message cannot be 741 legitimate if it claims to have been elicited by a packet larger than 742 the largest packet we have so far sent for this connection. 744 If this check is passed, claimedmtu is compared with maxsizeacked. 745 If claimedmtu is equal to or larger than maxsizeacked, TCP is 746 supposed to be at the Initial Path-MTU Discovery stage, and thus the 747 ICMP "Packet Too Big" error message is honored immediately. That is, 748 the assumed Path-MTU is updated according to the Next-Hop MTU claimed 749 in the ICMP error message. Also, maxsizesent is reset to the minimum 750 MTU of the internet protocol in use (68 for IPv4, and 1280 for IPv6). 752 On the other hand, if claimedmtu is smaller than maxsizeacked, TCP is 753 supposed to be in the Path-MTU Update stage. At this stage, these 754 implementations are more cautious with the errors being reported by 755 the network, and therefore just record the received error message, 756 and delay the update of the assumed Path-MTU. 758 To perform this delay, one new variable and one new parameter is 759 introduced to TCP: nsegrto and MAXSEGRTO. nsegrto holds the number of 760 times a specified segment has timed out. It is initialized to zero, 761 and is incremented by one every time the corresponding segment times 762 out. MAXSEGRRTO specifies the number of times a given segment must 763 timeout before an ICMP "Packet Too Big" error message can be honored, 764 and can be set, in principle, to any value greater than or equal to 765 0. 767 Thus, if nsegrto is greater than or equal to MAXSEGRTO, and there's a 768 pending ICMP "Packet Too Big" error message, the corresponding error 769 message is processed. At that point, maxsizeacked is set to 770 claimedmtu, and maxsizesent is set to 68 (for IPv4) or 1280 (for 771 IPv6). 773 If while there is a pending ICMP "Packet Too Big" error message the 774 TCP SEQ claimed by the pending message is acknowledged (i.e., an ACK 775 that acknowledges that sequence number is received), then the 776 "pending error" condition is cleared. 778 The rationale behind performing this delayed processing of ICMP 779 "Packet Too Big" messages is that if there is progress on the 780 connection, the ICMP "Packet Too Big" errors must be a false claim. 781 By checking for progress on the connection, rather than just for 782 staleness of the received ICMP messages, TCP is protected from attack 783 even if the offending ICMP messages are "in window", and as a 784 corollary, is made more robust to spurious ICMP messages elicited by, 785 for example, corrupted TCP segments. 787 MAXSEGRTO can be set, in principle, to any value greater than or 788 equal to 0. Setting MAXSEGRTO to 0 would make TCP perform the 789 traditional PMTUD mechanism defined in [RFC1191] and [RFC1981]. A 790 MAXSEGRTO of 1 provides enough protection for most cases. In any 791 case, implementations are free to choose higher values for this 792 constant. MAXSEGRTO could be a function of the Next-Hop MTU claimed 793 in the received ICMP "Packet Too Big" message. That is, higher 794 values for MAXSEGRTO could be imposed when the received ICMP "Packet 795 Too Big" message claims a Next-Hop MTU that is smaller than some 796 specified value. 798 In the event a higher level of protection is desired at the expense 799 of a higher delay in the discovery of the Path-MTU, an implementation 800 could consider TCP to always be in the Path-MTU Update stage, thus 801 always delaying the update of the assumed Path-MTU. 803 Section 7.3 shows the proposed counter-measure in action. 804 Section 7.4 shows the proposed counter-measure in pseudo-code. 806 This behavior has been implemented in NetBSD [NetBSD] and OpenBSD 807 [OpenBSD] since 2005. 809 It is important to note that the mechanism proposed in this section 810 is an improvement to the current Path-MTU discovery mechanism, to 811 mitigate its security implications. The current PMTUD mechanism, as 812 specified by [RFC1191] and [RFC1981], still suffers from some 813 functionality problems [RFC2923] that this document does not aim to 814 address. A mechanism that addresses those issues is described in 815 [RFC4821]. 817 7.3. The counter-measure for the PMTUD attack in action 819 This SECTION shows the proposed counter-measure for the ICMP attack 820 against the PMTUD mechanism in action. It shows both how the fix 821 protects TCP from being attacked and how the counter-measure works in 822 normal scenarios. As discussed in Section 7.2, this section assumes 823 the PMTUD-specific counter-measure is implemented in addition to the 824 TCP sequence number checking described in Section 4.1. 826 Figure 1 illustrates an hypothetical scenario in which two hosts are 827 connected by means of three intermediate routers. It also shows the 828 MTU of each hypothetical hop. All the following subsections assume 829 the network setup of this figure. 831 Also, for simplicity sake, all subsections assume an IP header of 20 832 octets and a TCP header of 20 octets. Thus, for example, when the 833 PMTU is assumed to be 1500 octets, TCP will send segments that 834 contain, at most, 1460 octets of data. 836 For simplicity sake, all the following subsections assume the TCP 837 implementation at Host 1 has chosen a a MAXSEGRTO of 1. 839 +----+ +----+ +----+ +----+ +----+ 840 | H1 |--------| R1 |--------| R2 |--------| R3 |--------| H2 | 841 +----+ +----+ +----+ +----+ +----+ 842 MTU=4464 MTU=2048 MTU=1500 MTU=4464 844 Figure 1: Hypothetical scenario 846 7.3.1. Normal operation for bulk transfers 848 This subsection shows the proposed counter-measure in normal 849 operation, when a TCP connection is used for bulk transfers. That 850 is, it shows how the proposed counter-measure works when there is no 851 attack taking place, and a TCP connection is used for transferring 852 large amounts of data. This section assumes that just after the 853 connection is established, one of the TCP endpoints begins to 854 transfer data in packets that are as large as possible. 856 Host 1 Host 2 858 1. --> --> 859 2. <-- <-- 860 3. --> --> 861 4. --> --> 862 5. <--- ICMP "Packet Too Big" MTU=2048, TCPseq#=101 <--- R1 863 6. --> --> 864 7. <--- ICMP "Packet Too Big" MTU=1500, TCPseq#=101 <--- R2 865 8. --> --> 866 9. <-- <-- 868 Figure 2: Normal operation for bulk transfers 870 nsegrto is initialized to zero. Both maxsizeacked and maxsizesent 871 are initialized to the minimum MTU for the internet protocol being 872 used (68 for IPv4, and 1280 for IPv6). 874 In lines 1 to 3 the three-way handshake takes place, and the 875 connection is established. In line 4, H1 tries to send a full-sized 876 TCP segment. As described by [RFC1191] and [RFC1981], in this case 877 TCP will try to send a segment with 4424 bytes of data, which will 878 result in an IP packet of 4464 octets. Therefore, maxsizesent is set 879 to 4464. When the packet reaches R1, it elicits an ICMP "Packet Too 880 Big" error message. 882 In line 5, H1 receives the ICMP error message, which reports a Next- 883 Hop MTU of 2048 octets. After performing the TCP sequence number 884 check described in Section 4.1, the Next-Hop MTU reported by the ICMP 885 error message (claimedmtu) is compared with maxsizesent. As it is 886 smaller than maxsizesent, it passes the check, and thus is then 887 compared with maxsizeacked. As claimedmtu is larger than 888 maxsizeacked, TCP assumes that the corresponding TCP segment was 889 performing the Initial PMTU Discovery. Therefore, the TCP at H1 890 honors the ICMP message by updating the assumed Path-MTU. maxsizesent 891 is reset to the minimum MTU of the internet protocol in use (68 for 892 IPv4, and 1280 for IPv6). 894 In line 6, the TCP at H1 sends a segment with 2008 bytes of data, 895 which results in an IP packet of 2048 octets. maxsizesent is thus set 896 to 2008 bytes. When the packet reaches R2, it elicits an ICMP 897 "Packet Too Big" error message. 899 In line 7, H1 receives the ICMP error message, which reports a Next- 900 Hop MTU of 1500 octets. After performing the TCP sequence number 901 check, the Next-Hop MTU reported by the ICMP error message 902 (claimedmtu) is compared with maxsizesent. As it is smaller than 903 maxsizesent, it passes the check, and thus is then compared with 904 maxsizeacked. As claimedmtu is larger than maxsizeacked, TCP assumes 905 that the corresponding TCP segment was performing the Initial PMTU 906 Discovery. Therefore, the TCP at H1 honors the ICMP message by 907 updating the assumed Path-MTU. maxsizesent is reset to the minimum 908 MTU of the internet protocol in use. 910 In line 8, the TCP at H1 sends a segment with 1460 bytes of data, 911 which results in an IP packet of 1500 octets. maxsizesent is thus set 912 to 1500. This packet reaches H2, where it elicits an acknowledgement 913 (ACK) segment. 915 In line 9, H1 finally gets the acknowledgement for the data segment. 916 As the corresponding packet was larger than maxsizeacked, TCP updates 917 maxsizeacked, setting it to 1500. At this point TCP has discovered 918 the Path-MTU for this TCP connection. 920 7.3.2. Operation during Path-MTU changes 922 Let us suppose a TCP connection between H1 and H2 has already been 923 established, and that the PMTU for the connection has already been 924 discovered to be 1500. At this point, both maxsizesent and 925 maxsizeacked are equal to 1500, and nsegrto is equal to 0. Suppose 926 some time later the PMTU decreases to 1492. For simplicity, let us 927 suppose that the Path-MTU has decreased because the MTU of the link 928 between R2 and R3 has decreased from 1500 to 1492. Figure 3 929 illustrates how the proposed counter-measure would work in this 930 scenario. 932 Host 1 Host 2 934 1. (Path-MTU decreases) 935 2. --> --> 936 3. <--- ICMP "Packet Too Big" MTU=1492, TCPseq#=100 <--- R2 937 4. (Segment times out) 938 5. --> --> 939 6. <-- <-- 941 Figure 3: Operation during Path-MTU changes 943 In line 1, the Path-MTU for this connection decreases from 1500 to 944 1492. In line 2, the TCP at H1, without being aware of the Path-MTU 945 change, sends a 1500-byte packet to H2. When the packet reaches R2, 946 it elicits an ICMP "Packet Too Big" error message. 948 In line 3, H1 receives the ICMP error message, which reports a Next- 949 Hop MTU of 1492 octets. After performing the TCP sequence number 950 check, the Next-Hop MTU reported by the ICMP error message 951 (claimedmtu) is compared with maxsizesent. As claimedmtu is smaller 952 than maxsizesent, it is then compared with maxsizeacked. As 953 claimedmtu is smaller than maxsizeacked (full-sized packets were 954 getting to the remote end-point), this packet is assumed to be 955 performing Path-MTU Update. And a "pending error" condition is 956 recorded. 958 In line 4, the segment times out. Thus, nsegrto is incremented by 1. 959 As nsegrto is greater than or equal to MAXSEGRTO, the assumed Path- 960 MTU is updated. nsegrto is reset to 0, and maxsizeacked is set to 961 claimedmtu, and maxsizesent is set to the minimum MTU of the internet 962 protocol in use. 964 In line 5, H1 retransmits the data using the updated PMTU, and thus 965 maxsizesent is set to 1492. The resulting packet reaches H2, where 966 it elicits an acknowledgement (ACK) segment. 968 In line 6, H1 finally gets the acknowledgement for the data segment. 969 At this point TCP has discovered the new Path-MTU for this TCP 970 connection. 972 7.3.3. Idle connection being attacked 974 Let us suppose a TCP connection between H1 and H2 has already been 975 established, and the PMTU for the connection has already been 976 discovered to be 1500. Figure 4 shows a sample time-line diagram 977 that illustrates an idle connection being attacked. 979 Host 1 Host 2 981 1. --> --> 982 2. <-- <-- 983 3. <--- ICMP "Packet Too Big" MTU=68, TCPseq#=100 <--- 984 4. <--- ICMP "Packet Too Big" MTU=68, TCPseq#=100 <--- 985 5. <--- ICMP "Packet Too Big" MTU=68, TCPseq#=100 <--- 987 Figure 4: Idle connection being attacked 989 In line 1, H1 sends its last bunch of data. At line 2, H2 990 acknowledges the receipt of these data. Then the connection becomes 991 idle. In lines 3, 4, and 5, an attacker sends forged ICMP "Packet 992 Too Big" error messages to H1. Regardless of how many packets it 993 sends and the TCP sequence number each ICMP packet includes, none of 994 these ICMP error messages will pass the TCP sequence number check 995 described in Section 4.1, as H1 has no unacknowledged data in flight 996 to H2. Therefore, the attack does not succeed. 998 7.3.4. Active connection being attacked after discovery of the Path-MTU 1000 Let us suppose an attacker attacks a TCP connection for which the 1001 PMTU has already been discovered. In this case, as illustrated in 1002 Figure 1, the PMTU would be found to be 1500 bytes. Figure 5 shows a 1003 possible packet exchange. 1005 Host 1 Host 2 1007 1. --> --> 1008 2. --> --> 1009 3. --> --> 1010 4. --> --> 1011 5. <--- ICMP "Packet Too Big" MTU=68, TCPseq#=100 <--- 1012 6. <-- <-- 1014 Figure 5: Active connection being attacked after discovery of PMTU 1016 As we assume the PMTU has already been discovered, we also assume 1017 both maxsizesent and maxsizeacked are equal to 1500. We assume 1018 nsegrto is equal to zero, as there have been no segment timeouts. 1020 In lines 1, 2, 3, and 4, H1 sends four data segments to H2. In line 1021 5, an attacker sends a forged ICMP packet to H1. We assume the 1022 attacker is lucky enough to guess both the four-tuple that identifies 1023 the connection and a valid TCP sequence number. As the Next-Hop MTU 1024 claimed in the ICMP "Packet Too Big" message (claimedmtu) is smaller 1025 than maxsizeacked, this packet is assumed to be performing Path-MTU 1026 Update. Thus, the error message is recorded. 1028 In line 6, H1 receives an acknowledgement for the segment sent in 1029 line 1, before it times out. At this point, the "pending error" 1030 condition is cleared, and the recorded ICMP "Packet Too Big" error 1031 message is ignored. Therefore, the attack does not succeed. 1033 7.3.5. TCP peer attacked when sending small packets just after the 1034 three-way handshake 1036 This section analyzes an scenario in which a TCP peer that is sending 1037 small segments just after the connection has been established, is 1038 attacked. The connection could be being used by protocols such as 1039 SMTP [RFC2821] and HTTP [RFC2616], for example, which usually behave 1040 like this. 1042 Figure 6 shows a possible packet exchange for such scenario. 1044 Host 1 Host 2 1046 1. --> --> 1047 2. <-- <-- 1048 3. --> --> 1049 4. --> --> 1050 5. <-- <-- 1051 6. --> --> 1052 7. --> --> 1053 8. <--- ICMP "Packet Too Big" MTU=150, TCPseq#=101 <--- 1055 Figure 6: TCP peer attacked when sending small packets just after the 1056 three-way handshake 1058 nsegrto is initialized to zero. Both maxsizesent and maxsizeacked 1059 are initialized to the minimum MTU for the internet protocol being 1060 used (68 for IPv4, and 1280 for IPv6). 1062 In lines 1 to 3 the three-way handshake takes place, and the 1063 connection is established. At this point, the assumed Path-MTU for 1064 this connection is 4464. In line 4, H1 sends a small segment (which 1065 results in a 140-byte packet) to H2. maxsizesent is thus set to 140. 1066 In line 5 this segment is acknowledged, and thus maxsizeacked is set 1067 to 140. 1069 In lines 6 and 7, H1 sends two small segments to H2. In line 8, 1070 while the segments from lines 6 and 7 are still in flight to H2, an 1071 attacker sends a forged ICMP "Packet Too Big" error message to H1. 1072 Assuming the attacker is lucky enough to guess a valid TCP sequence 1073 number, this ICMP message will pass the TCP sequence number check. 1074 The Next-Hop MTU reported by the ICMP error message (claimedmtu) is 1075 then compared with maxsizesent. As claimedmtu is larger than 1076 maxsizesent, the ICMP error message is silently discarded. 1077 Therefore, the attack does not succeed. 1079 7.4. Pseudo-code for the counter-measure for the blind performance- 1080 degrading attack 1082 This section contains a pseudo-code version of the counter-measure 1083 described in Section 7.2 for the blind performance-degrading attack 1084 described in Section 7. It is meant as guidance for developers on 1085 how to implement this counter-measure. 1087 The pseudo-code makes use of the following variables, constants, and 1088 functions: 1090 ack 1091 Variable holding the acknowledgement number contained in the TCP 1092 segment that has just been received. 1094 acked_packet_size 1095 Variable holding the packet size (data, plus headers) the ACK that 1096 has just been received is acknowledging. 1098 adjust_mtu() 1099 Function that adjusts the MTU for this connection, according to 1100 the ICMP "Packet Too Big" that was last received. 1102 claimedmtu 1103 Variable holding the Next-Hop MTU advertised by the ICMP "Packet 1104 Too Big" error message. 1106 claimedtcpseq 1107 Variable holding the TCP sequence number contained in the payload 1108 of the ICMP "Packet Too Big" message that has just been received 1109 or was last recorded. 1111 current_mtu 1112 Variable holding the assumed Path-MTU for this connection. 1114 drop_message() 1115 Function that performs the necessary actions to drop the ICMP 1116 message being processed. 1118 initial_mtu 1119 Variable holding the MTU for new connections, as explained in 1120 [RFC1191] and [RFC1981]. 1122 maxsizeacked 1123 Variable holding the largest packet size (data, plus headers) that 1124 has so far been acked for this connection, as explained in 1125 Section 7.2. 1127 maxsizesent 1128 Variable holding the largest packet size (data, plus headers) that 1129 has so far been sent for this connection, as explained in 1130 Section 7.2. 1132 nsegrto 1133 Variable holding the number of times this segment has timed out, 1134 as explained in Section 7.2. 1136 packet_size 1137 Variable holding the size of the IP datagram being sent. 1139 pending_message 1140 Variable (flag) that indicates whether there is a pending ICMP 1141 "Packet Too Big" message to be processed. 1143 save_message() 1144 Function that records the ICMP "Packet Too Big" message that has 1145 just been received. 1147 MINIMUM_MTU 1148 Constant holding the minimum MTU for the internet protocol in use 1149 (68 for IPv4, and 1280 for IPv6). 1151 MAXSEGRTO 1152 Constant holding the number of times a given segment must timeout 1153 before an ICMP "Packet Too Big" error message can be honored. 1155 EVENT: New TCP connection 1157 current_mtu = initial_mtu; 1158 maxsizesent = MINIMUM_MTU; 1159 maxsizeacked = MINIMUM_MTU; 1160 nsegrto = 0; 1161 pending_message = 0; 1163 EVENT: Segment is sent 1164 if (packet_size > maxsizesent) 1165 maxsizesent = packet_size; 1167 EVENT: Segment is received 1169 if (acked_packet_size > maxsizeacked) 1170 maxsizeacked = acked_packet_size; 1172 if (pending_message) 1173 if (ack > claimedtcpseq){ 1174 pending_message = 0; 1175 nsegrto = 0; 1176 } 1178 EVENT: ICMP "Packet Too Big" message is received 1179 if (claimedtcpseq < SND.UNA || claimed_TCP_SEQ >= SND.NXT){ 1180 drop_message(); 1181 } 1183 else { 1184 if (claimedmtu >= maxsizesent || claimedmtu >= current_mtu) 1185 drop_message(); 1187 else { 1188 if (claimedmtu > maxsizeacked){ 1189 adjust_mtu(); 1190 current_mtu = claimedmtu; 1191 maxsizesent = MINIMUM_MTU; 1192 } 1194 else { 1195 pending_message = 1; 1196 save_message(); 1197 } 1198 } 1199 } 1201 EVENT: Segment times out 1203 nsegrto++; 1205 if (pending_message && nsegrto >= MAXSEGRTO){ 1206 adjust_mtu(); 1207 nsegrto = 0; 1208 pending_message = 0; 1209 maxsizeacked = claimedmtu; 1210 maxsizesent = MINIMUM_MTU; 1211 current_mtu = claimedmtu; 1212 } 1214 Notes: 1215 All comparisions between sequence numbers must be performed using 1216 sequence number arithmethic. 1217 The pseudo-code implements the mechanism described in Section 7.2, 1218 the TCP sequence number checking described in Section 4.1, and the 1219 validation check on the advertised Next-Hop MTU described in 1220 [RFC1191] and [RFC1981]. 1222 8. Security Considerations 1224 This document describes the use of ICMP error messages to perform a 1225 number of attacks against the TCP protocol, and describes a number of 1226 widely-implemented counter-measures that either eliminate or reduce 1227 the impact of these attacks when they are performed by off-path 1228 attackers. 1230 9. Acknowledgements 1232 This document was inspired by Mika Liljeberg, while discussing some 1233 issues related to [I-D.ietf-tcpm-tcp-soft-errors] by private e-mail. 1234 The author would like to thank (in alphabetical order): Bora Akyol, 1235 Mark Allman, Ran Atkinson, James Carlson, Alan Cox, Theo de Raadt, 1236 Ted Faber, Juan Fraschini, Markus Friedl, Guillermo Gont, John 1237 Heffner, Alfred Hoenes, Vivek Kakkar, Michael Kerrisk, Mika 1238 Liljeberg, Matt Mathis, David Miller, Miles Nordin, Eloy Paris, 1239 Kacheong Poon, Andrew Powell, Pekka Savola, Pyda Srisuresh, Fred 1240 Templin, and Joe Touch for contributing many valuable comments. 1242 Juan Fraschini and the author of this document implemented freely- 1243 available audit tools to help vendors audit their systems by 1244 reproducing the attacks discussed in this document. This tools are 1245 available at http://www.gont.com.ar/tools/index.html . 1247 Markus Friedl, Chad Loder, and the author of this document, produced 1248 and tested in OpenBSD [OpenBSD] the first implementation of the 1249 counter-measure described in Section 7.2. This first implementation 1250 helped to test the effectiveness of the ideas introduced in this 1251 document, and has served as a reference implementation for other 1252 operating systems. 1254 The author would like to thank the UK's National Infrastructure 1255 Security Co-ordination Centre (NISCC) for coordinating the disclosure 1256 of these issues with a large number of vendors and CSIRTs (Computer 1257 Security Incident Response Teams). 1259 The author wishes to express deep and heartfelt gratitude to Jorge 1260 Oscar Gont and Nelida Garcia, for their precious motivation and 1261 guidance. 1263 10. References 1264 10.1. Normative References 1266 [RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791, 1267 September 1981. 1269 [RFC0792] Postel, J., "Internet Control Message Protocol", STD 5, 1270 RFC 792, September 1981. 1272 [RFC0793] Postel, J., "Transmission Control Protocol", STD 7, 1273 RFC 793, September 1981. 1275 [RFC1122] Braden, R., "Requirements for Internet Hosts - 1276 Communication Layers", STD 3, RFC 1122, October 1989. 1278 [RFC1191] Mogul, J. and S. Deering, "Path MTU discovery", RFC 1191, 1279 November 1990. 1281 [RFC1812] Baker, F., "Requirements for IP Version 4 Routers", 1282 RFC 1812, June 1995. 1284 [RFC1981] McCann, J., Deering, S., and J. Mogul, "Path MTU Discovery 1285 for IP version 6", RFC 1981, August 1996. 1287 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1288 Requirement Levels", BCP 14, RFC 2119, March 1997. 1290 [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 1291 (IPv6) Specification", RFC 2460, December 1998. 1293 [RFC4301] Kent, S. and K. Seo, "Security Architecture for the 1294 Internet Protocol", RFC 4301, December 2005. 1296 [RFC4443] Conta, A., Deering, S., and M. Gupta, "Internet Control 1297 Message Protocol (ICMPv6) for the Internet Protocol 1298 Version 6 (IPv6) Specification", RFC 4443, March 2006. 1300 10.2. Informative References 1302 [DClark] Clark, D., "The Design Philosophy of the DARPA Internet 1303 Protocols", Computer Communication Review Vol. 18, No. 4, 1304 1988. 1306 [FreeBSD] The FreeBSD Project, "http://www.freebsd.org". 1308 [I-D.ietf-tcpm-tcp-soft-errors] 1309 Gont, F., "TCP's Reaction to Soft Errors", 1310 draft-ietf-tcpm-tcp-soft-errors-08 (work in progress), 1311 April 2008. 1313 [I-D.ietf-tcpm-tcpsecure] 1314 Ramaiah, A., Stewart, R., and M. Dalal, "Improving TCP's 1315 Robustness to Blind In-Window Attacks", 1316 draft-ietf-tcpm-tcpsecure-10 (work in progress), 1317 July 2008. 1319 [I-D.ietf-tsvwg-port-randomization] 1320 Larsen, M. and F. Gont, "Port Randomization", 1321 draft-ietf-tsvwg-port-randomization-02 (work in progress), 1322 August 2008. 1324 [ICMP-Filtering] 1325 Gont, F., "Filtering of ICMP error messages", http:// 1326 www.gont.com.ar/papers/ 1327 filtering-of-icmp-error-messages.pdf. 1329 [IP-filtering] 1330 NISCC, "NISCC Technical Note 01/2006: Egress and Ingress 1331 Filtering", http://www.niscc.gov.uk/niscc/docs/ 1332 re-20060420-00294.pdf?lang=en, 2006. 1334 [Linux] The Linux Project, "http://www.kernel.org". 1336 [McKusick] 1337 McKusick, M., Bostic, K., Karels, M., and J. Quarterman, 1338 "The Design and Implementation of the 4.4BSD Operating 1339 System", Addison-Wesley , 1996. 1341 [NISCC] NISCC, "NISCC Vulnerability Advisory 532967/NISCC/ICMP: 1342 Vulnerability Issues in ICMP packets with TCP payloads", 1343 http://www.niscc.gov.uk/niscc/docs/ 1344 al-20050412-00308.html?lang=en, 2005. 1346 [NetBSD] The NetBSD Project, "http://www.netbsd.org". 1348 [OpenBSD] The OpenBSD Project, "http://www.openbsd.org". 1350 [OpenBSD-PF] 1351 The OpenBSD Packet Filter, 1352 "http://www.openbsd.org/faq/pf/". 1354 [RFC0816] Clark, D., "Fault isolation and recovery", RFC 816, 1355 July 1982. 1357 [RFC1321] Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321, 1358 April 1992. 1360 [RFC1323] Jacobson, V., Braden, B., and D. Borman, "TCP Extensions 1361 for High Performance", RFC 1323, May 1992. 1363 [RFC2385] Heffernan, A., "Protection of BGP Sessions via the TCP MD5 1364 Signature Option", RFC 2385, August 1998. 1366 [RFC2581] Allman, M., Paxson, V., and W. Stevens, "TCP Congestion 1367 Control", RFC 2581, April 1999. 1369 [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., 1370 Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext 1371 Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999. 1373 [RFC2821] Klensin, J., "Simple Mail Transfer Protocol", RFC 2821, 1374 April 2001. 1376 [RFC2923] Lahey, K., "TCP Problems with Path MTU Discovery", 1377 RFC 2923, September 2000. 1379 [RFC3168] Ramakrishnan, K., Floyd, S., and D. Black, "The Addition 1380 of Explicit Congestion Notification (ECN) to IP", 1381 RFC 3168, September 2001. 1383 [RFC3390] Allman, M., Floyd, S., and C. Partridge, "Increasing TCP's 1384 Initial Window", RFC 3390, October 2002. 1386 [RFC4271] Rekhter, Y., Li, T., and S. Hares, "A Border Gateway 1387 Protocol 4 (BGP-4)", RFC 4271, January 2006. 1389 [RFC4821] Mathis, M. and J. Heffner, "Packetization Layer Path MTU 1390 Discovery", RFC 4821, March 2007. 1392 [RFC4907] Aboba, B., "Architectural Implications of Link 1393 Indications", RFC 4907, June 2007. 1395 [RFC4953] Touch, J., "Defending TCP Against Spoofing Attacks", 1396 RFC 4953, July 2007. 1398 [US-CERT] US-CERT, "US-CERT Vulnerability Note VU#222750: TCP/IP 1399 Implementations do not adequately validate ICMP error 1400 messages", http://www.kb.cert.org/vuls/id/222750, 2005. 1402 [Watson] Watson, P., "Slipping in the Window: TCP Reset Attacks", 1403 2004 CanSecWest Conference , 2004. 1405 [Wright] Wright, G. and W. Stevens, "TCP/IP Illustrated, Volume 2: 1406 The Implementation", Addison-Wesley , 1994. 1408 Appendix A. An analysis of ICMP hard errors 1410 This appendix contains an analysis of ICMP hard errors. 1412 ICMP type 3 (Destination Unreachable), code 2 (protocol unreachable) 1414 This ICMP error message indicates that the host sending the ICMP 1415 error message received a packet meant for a transport protocol it 1416 does not support. For connection-oriented protocols such as TCP, 1417 one could expect to receive such an error as the result of a 1418 connection-establishment attempt. However, it would be strange to 1419 get such an error during the life of a connection, as this would 1420 indicate that support for that transport protocol has been removed 1421 from the system sending the error message during the life of the 1422 corresponding connection. 1424 ICMP type 3 (Destination Unreachable), code 3 (port unreachable) 1426 This error message indicates that the system sending the ICMP 1427 error message received a packet meant for a socket (IP address, 1428 port number) on which there is no process listening. Those 1429 transport protocols which have their own mechanisms for notifying 1430 this condition should not be receiving these error messages, as 1431 the protocol would signal the port unreachable condition by means 1432 of its own messages. Assuming that once a connection is 1433 established it is not usual for the transport protocol to change 1434 (or be reloaded), it should be unusual to get these error 1435 messages. 1437 ICMP type 3 (Destination Unreachable), code 4 (fragmentation needed 1438 and DF bit set) 1440 This error message indicates that an intermediate node needed to 1441 fragment a datagram, but the DF (Don't Fragment) bit in the IP 1442 header was set. It is considered a soft error when TCP implements 1443 PMTUD, and a hard error if TCP does not implement PMTUD. Those 1444 TCPs that do not implement the PMTUD mechanism should not be 1445 sending their IP packets with the DF bit set, and thus should not 1446 be receiving these ICMP error messages. 1448 ICMPv6 type 1 (Destination Unreachable), code 1 (communication with 1449 destination administratively prohibited) 1451 This error message indicates that the destination is unreachable 1452 because of an administrative policy. For connection-oriented 1453 protocols such as TCP, one could expect to receive such an error 1454 as the result of a connection-establishment attempt. Receiving 1455 such an error for a connection in any of the synchronized states 1456 would mean that the administrative policy changed during the life 1457 of the connection. However, in the same way this error condition 1458 (which was not present when the conenction was established) 1459 appeared, it could get solved solved in the near term. 1461 ICMPv6 type 1 (Destination Unreachable), code 4 (port unreachable) 1463 This error message is analogous to the ICMP type 3 (Destination 1464 Unreachable), code 3 (Port unreachable) error message discussed 1465 above. Therefore, the same considerations apply. 1467 The Host Requirements RFC [RFC1122] states in Section 4.2.3.9 that 1468 TCP SHOULD abort the corresponding connection in response to ICMP 1469 messages of type 3, codes 2 (protocol unreachable), 3 (port 1470 unreachable), and 4 (fragmentation needed and DF bit set). However, 1471 Section 3.2.2.1 states that TCP MUST accept an ICMP port unreachable 1472 (type 3, code 3) for the same purpose as an RST. Therefore, for ICMP 1473 messages of type 3 codes 2 and 4 there is room to go against the 1474 advice provided in the existing specifications, while in the case of 1475 ICMP messages of type 3 code 3 there is ambiguity in the 1476 specifications that may or may not provide some room to go against 1477 that advice. 1479 Appendix B. Advice and guidance to vendors 1481 Vendors are urged to contact CPNI (vulteam@cpni.gsi.gov.uk) if they 1482 think they may be affected by the issues described in this document. 1483 As the lead coordination center for these issues, CPNI is well placed 1484 to give advice and guidance as required. 1486 CPNI works extensively with government departments and agencies, 1487 commercial organizations and the academic community to research 1488 vulnerabilities and potential threats to IT systems especially where 1489 they may have an impact on Critical National Infrastructure's (CNI). 1491 Other ways to contact CPNI, plus CPNI's PGP public key, are available 1492 at http://www.cpni.gov.uk . 1494 Appendix C. Changes from previous versions of the draft (to be removed 1495 by the RFC Editor before publishing this document as an 1496 RFC) 1498 C.1. Changes from draft-ietf-tcpm-icmp-attacks-03 1499 o The draft had expired and thus is resubmitted with no further 1500 changes. 1502 C.2. Changes from draft-ietf-tcpm-icmp-attacks-02 1504 o Added a disclaimer to indicate that this document does not update 1505 the current specifications. 1507 o Addresses feedback sent off-list by Alfred Hoenes. 1509 o The text (particulary that which describes the counter-measures) 1510 was reworded to document what current implementations are doing, 1511 rather than "proposing" the implementation of the counter- 1512 measures. 1514 o Some text has been removed: we're just documenting the problem, 1515 and what existing implementations have done. 1517 o Miscelaneous editorial changes. 1519 C.3. Changes from draft-ietf-tcpm-icmp-attacks-01 1521 o Fixed references to the antispoof documents (were hardcoded and 1522 missing in the References Section). 1524 o The draft had expired and thus is resubmitted with only a minor 1525 editorial change. 1527 C.4. Changes from draft-ietf-tcpm-icmp-attacks-00 1529 o Added references to the specific sections of each of the 1530 referenced specifications 1532 o Corrected the threat analysys 1534 o Added clarification about whether the counter-measures violate the 1535 current specifications or not. 1537 o Changed text so that the document fits better in the Informational 1538 path 1540 o Added a specific section on IPsec (Section 2.3) 1542 o Added clarification and references on the use of ICMP filtering 1543 based on the ICMP payload 1545 o Updated references to obsoleted RFCs 1546 o Added a discussion of multipath scenarios, and possible lose in 1547 responsiveness resulting from the reaction to hard errors as soft 1548 errors 1550 o Miscellaneous editorial changes 1552 C.5. Changes from draft-gont-tcpm-icmp-attacks-05 1554 o Removed RFC 2119 wording to make the draft suitable for 1555 publication as an Informational RFC. 1557 o Added additional checks that should be performed on ICMP error 1558 messages (checksum of the IP header in the ICMP payload, and 1559 others). 1561 o Added clarification of the rationale behind each the TCP SEQ check 1563 o Miscellaneous editorial changes 1565 C.6. Changes from draft-gont-tcpm-icmp-attacks-04 1567 o Added section on additional considerations for validating ICMP 1568 error messages 1570 o Added reference to (draft) [RFC4907] 1572 o Added stress on the fact that ICMP error messages are unreliable 1574 o Miscellaneous editorial changes 1576 C.7. Changes from draft-gont-tcpm-icmp-attacks-03 1578 o Added references to existing implementations of the proposed 1579 counter-measures 1581 o The discussion in Section 4 was improved 1583 o The discussion of the blind connection-reset vulnerability was 1584 expanded and improved 1586 o The proposed counter-measure for the attack against the PMTUD was 1587 improved and simplified 1589 o Section 7.4 was added 1591 o Miscellaneous editorial changes 1593 C.8. Changes from draft-gont-tcpm-icmp-attacks-02 1595 o Fixed errors in in the discussion of the blind connection-reset 1596 attack 1598 o The proposed counter-measure for the attack against the PMTUD 1599 mechanism was refined to allow quick discovery of the Path-MTU 1601 o Section 7.3 was added so as to clarify the operation of the 1602 counter-measure for the attack against the PMTUD mechanism 1604 o Added Appendix B 1606 o Miscellaneous editorial changes 1608 C.9. Changes from draft-gont-tcpm-icmp-attacks-01 1610 o The document was restructured for easier reading 1612 o A discussion of ICMPv6 was added in several sections of the 1613 document 1615 o Added Section on Acknowledgement number checking 1617 o Added Section 4.3 1619 o Added Section 7 1621 o Fixed typo in the ICMP types, in several places 1623 o Fixed typo in the TCP sequence number check formula 1625 o Miscellaneous editorial changes 1627 C.10. Changes from draft-gont-tcpm-icmp-attacks-00 1629 o Added a proposal to change the handling of the so-called ICMP hard 1630 errors during the synchronized states 1632 o Added a summary of the relevant RFCs in several sections 1634 o Miscellaneous editorial changes 1636 Author's Address 1638 Fernando Gont 1639 Universidad Tecnologica Nacional / Facultad Regional Haedo 1640 Evaristo Carriego 2644 1641 Haedo, Provincia de Buenos Aires 1706 1642 Argentina 1644 Phone: +54 11 4650 8472 1645 Email: fernando@gont.com.ar 1646 URI: http://www.gont.com.ar 1648 Full Copyright Statement 1650 Copyright (C) The IETF Trust (2008). 1652 This document is subject to the rights, licenses and restrictions 1653 contained in BCP 78, and except as set forth therein, the authors 1654 retain all their rights. 1656 This document and the information contained herein are provided on an 1657 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 1658 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 1659 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 1660 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 1661 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1662 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1664 Intellectual Property 1666 The IETF takes no position regarding the validity or scope of any 1667 Intellectual Property Rights or other rights that might be claimed to 1668 pertain to the implementation or use of the technology described in 1669 this document or the extent to which any license under such rights 1670 might or might not be available; nor does it represent that it has 1671 made any independent effort to identify any such rights. Information 1672 on the procedures with respect to rights in RFC documents can be 1673 found in BCP 78 and BCP 79. 1675 Copies of IPR disclosures made to the IETF Secretariat and any 1676 assurances of licenses to be made available, or the result of an 1677 attempt made to obtain a general license or permission for the use of 1678 such proprietary rights by implementers or users of this 1679 specification can be obtained from the IETF on-line IPR repository at 1680 http://www.ietf.org/ipr. 1682 The IETF invites any interested party to bring to its attention any 1683 copyrights, patents or patent applications, or other proprietary 1684 rights that may cover technology that may be required to implement 1685 this standard. Please address the information to the IETF at 1686 ietf-ipr@ietf.org.