idnits 2.17.1 draft-ietf-tcpm-icmp-attacks-00.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 15. -- Found old boilerplate from RFC 3978, Section 5.5 on line 1589. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1566. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1573. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1579. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard 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.) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (February 23, 2006) is 6636 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) ** Obsolete normative reference: RFC 793 (Obsoleted by RFC 9293) ** Obsolete normative reference: RFC 1981 (Obsoleted by RFC 8201) ** Obsolete normative reference: RFC 2401 (Obsoleted by RFC 4301) ** Obsolete normative reference: RFC 2460 (Obsoleted by RFC 8200) ** Obsolete normative reference: RFC 2463 (Obsoleted by RFC 4443) == Outdated reference: A later version (-10) exists of draft-iab-link-indications-04 == Outdated reference: A later version (-11) exists of draft-ietf-pmtud-method-05 == Outdated reference: A later version (-13) exists of draft-ietf-tcpm-tcpsecure-03 -- 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: 9 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 February 23, 2006 5 Expires: August 27, 2006 7 ICMP attacks against TCP 8 draft-ietf-tcpm-icmp-attacks-00.txt 10 Status of this Memo 12 By submitting this Internet-Draft, each author represents that any 13 applicable patent or other IPR claims of which he or she is aware 14 have been or will be disclosed, and any of which he or she becomes 15 aware will be disclosed, in accordance with Section 6 of BCP 79. 17 Internet-Drafts are working documents of the Internet Engineering 18 Task Force (IETF), its areas, and its working groups. Note that 19 other groups may also distribute working documents as Internet- 20 Drafts. 22 Internet-Drafts are draft documents valid for a maximum of six months 23 and may be updated, replaced, or obsoleted by other documents at any 24 time. It is inappropriate to use Internet-Drafts as reference 25 material or to cite them other than as "work in progress." 27 The list of current Internet-Drafts can be accessed at 28 http://www.ietf.org/ietf/1id-abstracts.txt. 30 The list of Internet-Draft Shadow Directories can be accessed at 31 http://www.ietf.org/shadow.html. 33 This Internet-Draft will expire on August 27, 2006. 35 Copyright Notice 37 Copyright (C) The Internet Society (2006). 39 Abstract 41 This document discusses the use of the Internet Control Message 42 Protocol (ICMP) to perform a variety of attacks against the 43 Transmission Control Protocol (TCP) and other similar protocols. It 44 proposes several counter-measures to eliminate or minimize the impact 45 of these attacks. 47 Table of Contents 49 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 50 2. Background . . . . . . . . . . . . . . . . . . . . . . . . . . 5 51 2.1. The Internet Control Message Protocol (ICMP) . . . . . . . 5 52 2.1.1. ICMP for IP version 4 (ICMP) . . . . . . . . . . . . . 5 53 2.1.2. ICMP for IP version 6 (ICMPv6) . . . . . . . . . . . . 6 54 2.2. Handling of ICMP error messages . . . . . . . . . . . . . 6 55 3. Constraints in the possible solutions . . . . . . . . . . . . 7 56 4. General counter-measures against ICMP attacks . . . . . . . . 8 57 4.1. TCP sequence number checking . . . . . . . . . . . . . . . 8 58 4.2. Port randomization . . . . . . . . . . . . . . . . . . . . 9 59 4.3. Filtering ICMP error messages based on the ICMP payload . 9 60 5. Blind connection-reset attack . . . . . . . . . . . . . . . . 10 61 5.1. Description . . . . . . . . . . . . . . . . . . . . . . . 10 62 5.2. Attack-specific counter-measures . . . . . . . . . . . . . 11 63 5.2.1. Changing the reaction to hard errors . . . . . . . . . 11 64 5.2.2. Delaying the connection-reset . . . . . . . . . . . . 13 65 6. Blind throughput-reduction attack . . . . . . . . . . . . . . 14 66 6.1. Description . . . . . . . . . . . . . . . . . . . . . . . 14 67 6.2. Attack-specific counter-measures . . . . . . . . . . . . . 14 68 7. Blind performance-degrading attack . . . . . . . . . . . . . . 14 69 7.1. Description . . . . . . . . . . . . . . . . . . . . . . . 14 70 7.2. Attack-specific counter-measures . . . . . . . . . . . . . 16 71 8. Security Considerations . . . . . . . . . . . . . . . . . . . 19 72 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 19 73 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 20 74 10.1. Normative References . . . . . . . . . . . . . . . . . . . 20 75 10.2. Informative References . . . . . . . . . . . . . . . . . . 21 76 Appendix A. The counter-measure for the PMTUD attack in action . 23 77 A.1. Normal operation for bulk transfers . . . . . . . . . . . 23 78 A.2. Operation during Path-MTU changes . . . . . . . . . . . . 25 79 A.3. Idle connection being attacked . . . . . . . . . . . . . . 26 80 A.4. Active connection being attacked after discovery of 81 the Path-MTU . . . . . . . . . . . . . . . . . . . . . . . 27 82 A.5. TCP peer attacked when sending small packets just 83 after the three-way handshake . . . . . . . . . . . . . . 27 84 Appendix B. Pseudo-code for the counter-measure for the blind 85 performance-degrading attack . . . . . . . . . . . . 28 86 Appendix C. Additional considerations for the validation of 87 ICMP error messages . . . . . . . . . . . . . . . . . 32 88 Appendix D. Advice and guidance to vendors . . . . . . . . . . . 32 89 Appendix E. Changes from previous versions of the draft . . . . . 33 90 E.1. Changes from draft-gont-tcpm-icmp-attacks-05 . . . . . . . 33 91 E.2. Changes from draft-gont-tcpm-icmp-attacks-04 . . . . . . . 33 92 E.3. Changes from draft-gont-tcpm-icmp-attacks-03 . . . . . . . 33 93 E.4. Changes from draft-gont-tcpm-icmp-attacks-02 . . . . . . . 33 94 E.5. Changes from draft-gont-tcpm-icmp-attacks-01 . . . . . . . 34 95 E.6. Changes from draft-gont-tcpm-icmp-attacks-00 . . . . . . . 34 96 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 35 97 Intellectual Property and Copyright Statements . . . . . . . . . . 36 99 1. Introduction 101 ICMP [RFC0792] is a fundamental part of the TCP/IP protocol suite, 102 and is used mainly for reporting network error conditions. However, 103 the current specifications do not recommend any kind of validation 104 checks on the received ICMP error messages, thus leaving the door 105 open to a variety of attacks that can be performed against TCP 106 [RFC0793] by means of ICMP, which include blind connection-reset, 107 blind throughput-reduction, and blind performance-degrading attacks. 108 All of these attacks can be performed even being off-path, without 109 the need to sniff the packets that correspond to the attacked TCP 110 connection. 112 While the security implications of ICMP have been known in the 113 research community for a long time, there has never been an official 114 proposal on how to deal with these vulnerabiliies. Thus, only a few 115 implementations have implemented validation checks on the received 116 ICMP error messages to minimize the impact of these attacks. 118 Recently, a disclosure process has been carried out by the UK's 119 National Infrastructure Security Co-ordination Centre (NISCC), with 120 the collaboration of other computer emergency response teams. A 121 large number of implementations were found vulnerable to either all 122 or a subset of the attacks discussed in this document [NISCC][US- 123 CERT]. The affected systems ranged from TCP/IP implementations meant 124 for desktop computers, to TCP/IP implementations meant for core 125 Internet routers. 127 It is clear that implementations should be more cautious when 128 processing ICMP error messages, to eliminate or mitigate the use of 129 ICMP to perform attacks against TCP [I-D.iab-link-indications]. 131 This document aims to raise awareness of the use of ICMP to perform a 132 variety of attacks against TCP, and proposes several counter-measures 133 that eliminate or minimize the impact of these attacks. 135 Section 2 provides background information on ICMP. Section 3 136 discusses the constraints in the general counter-measures that can be 137 implemented against the attacks described in this document. 138 Section 4 proposes several general validation checks and counter- 139 measures that can be implemented to mitigate any ICMP-based attack. 140 Finally, Section 5, Section 6, and Section 7, discuss a variety of 141 ICMP attacks that can be performed against TCP, and propose attack- 142 specific counter-measures that eliminate or greatly mitigate their 143 impact. 145 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 146 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 147 document are to be interpreted as described in RFC 2119 [RFC2119]. 149 2. Background 151 2.1. The Internet Control Message Protocol (ICMP) 153 The Internet Control Message Protocol (ICMP) is used in the Internet 154 Architecture mainly to perform the fault-isolation function, that is, 155 the group of actions that hosts and routers take to determine that 156 there is some network failure [RFC0816] 158 When an intermediate router detects a network problem while trying to 159 forward an IP packet, it will usually send an ICMP error message to 160 the source host, to raise awareness of the network problem taking 161 place. In the same way, there are a number of scenarios in which an 162 end-system may generate an ICMP error message if it finds a problem 163 while processing a datagram. The received ICMP errors are handled to 164 the corresponding transport-protocol instance, which will usually 165 perform a fault recovery function. 167 It is important to note that ICMP error messages are unreliable, and 168 may be discarded due to data corruption, network congestion and rate- 169 limiting. Thus, while they provide useful information, upper layer 170 protocols cannot depend on ICMP for correct operation. 172 2.1.1. ICMP for IP version 4 (ICMP) 174 [RFC0792] specifies the Internet Control Message Protocol (ICMP) to 175 be used with the Internet Protocol version 4 (IPv4). It defines, 176 among other things, a number of error messages that can be used by 177 end-systems and intermediate systems to report network errors to the 178 sending host. The Host Requirements RFC [RFC1122] classifies ICMP 179 error messages into those that indicate "soft errors", and those that 180 indicate "hard errors", thus roughly defining the semantics of them. 182 The ICMP specification [RFC0792] also defines the ICMP Source Quench 183 message (type 4, code 0), which is meant to provide a mechanism for 184 flow control and congestion control. 186 [RFC1191] defines a mechanism called "Path MTU Discovery" (PMTUD), 187 which makes use of ICMP error messages of type 3 (Destination 188 Unreachable), code 4 (fragmentation needed and DF bit set) to allow 189 hosts to determine the MTU of an arbitrary internet path. 191 Appendix D of [RFC2401] provides information about which ICMP error 192 messages are produced by hosts, intermediate routers, or both. 194 2.1.2. ICMP for IP version 6 (ICMPv6) 196 [RFC2463] specifies the Internet Control Message Protocol (ICMPv6) to 197 be used with the Internet Protocol version 6 (IPv6) [RFC2460]. 199 [RFC2463] defines the "Packet Too Big" (type 2, code 0) error 200 message, that is analogous to the ICMP "fragmentation needed and DF 201 bit set" (type 3, code 4) error message. [RFC1981] defines the Path 202 MTU Discovery mechanism for IP Version 6, that makes use of these 203 messages to determine the MTU of an arbitrary internet path. 205 Appendix D of [RFC2401] provides information about which ICMPv6 error 206 messages are produced by hosts, intermediate routers, or both. 208 2.2. Handling of ICMP error messages 210 The Host Requirements RFC [RFC1122] states that a TCP MUST act on an 211 ICMP error message passed up from the IP layer, directing it to the 212 connection that elicited the error. 214 In order to allow ICMP messages to be demultiplexed by the receiving 215 host, part of the original packet that elicited the message is 216 included in the payload of the ICMP error message. Thus, the 217 receiving host can use that information to match the ICMP error to 218 the transport protocol instance that elicited it. 220 Neither the Host Requirements RFC [RFC1122] nor the original TCP 221 specification [RFC0793] recommend any validation checks on the 222 received ICMP messages. Thus, as long as the ICMP payload contains 223 the information that identifies an existing communication instance, 224 it will be processed by the corresponding transport-protocol 225 instance, and the corresponding action will be performed. 227 Therefore, in the case of TCP, an attacker could send a forged ICMP 228 message to the attacked host, and, as long as he is able to guess the 229 four-tuple that identifies the communication instance to be attacked, 230 he will be able to use ICMP to perform a variety of attacks. 232 As discussed in [Watson], there are a number of scenarios in which an 233 attacker may be able to know or guess the four-tuple that identifies 234 a TCP connection. If we assume the attacker knows the two systems 235 involved in the TCP connection to be attacked, both the client-side 236 and the server-side IP addresses will be known. Furthermore, as most 237 Internet services use the so-called "well-known" ports, only the 238 client port number would need to be guessed. This means that an 239 attacker would need to send, in principle, at most 65536 packets to 240 perform any of the attacks described in this document. However, most 241 systems choose the port numbers they use for outgoing connections 242 from a subset of the whole port number space. Thus, in practice, 243 fewer packets are needed to perform any of the attacks discussed in 244 this document. 246 It is clear that TCP should be more cautious when processing received 247 ICMP error messages, in order to mitigate or eliminate the impact of 248 the attacks described in this document [I-D.iab-link-indications]. 250 3. Constraints in the possible solutions 252 For ICMPv4, [RFC0792] states that the internet header plus the first 253 64 bits of the packet that elicited the ICMP message are to be 254 included in the payload of the ICMP error message. Thus, it is 255 assumed that all data needed to identify a transport protocol 256 instance and process the ICMP error message is contained in the first 257 64 bits of the transport protocol header. [RFC1122] states that "the 258 Internet header and at least the first 8 data octets of the datagram 259 that triggered the error" are to be included in the payload of ICMP 260 error messages, and that "more than 8 octets MAY be sent", thus 261 allowing implementations to include more data from the original 262 packet than those required by the original ICMP specification. The 263 Requirements for IP Version 4 Routers RFC [RFC1812] states that ICMP 264 error messages "SHOULD contain as much of the original datagram as 265 possible without the length of the ICMP datagram exceeding 576 266 bytes". 268 Thus, for ICMP messages generated by hosts, we can only expect to get 269 the entire IP header of the original packet, plus the first 64 bits 270 of its payload. For TCP, this means that the only fields that will 271 be included in the ICMP payload are: the source port number, the 272 destination port number, and the 32-bit TCP sequence number. This 273 clearly imposes a constraint on the possible validation checks that 274 can be performed, as there is not much information avalable on which 275 to perform them. 277 This means, for example, that even if TCP were signing its segments 278 by means of the TCP MD5 signature option [RFC2385], this mechanism 279 could not be used as a counter-measure against ICMP-based attacks, 280 because, as ICMP messages include only a piece of the TCP segment 281 that elicited the error, the MD5 [RFC1321] signature could not be 282 recalculated. In the same way, even if the attacked peer were 283 authenticating its packets at the IP layer [RFC2401], because only a 284 part of the original IP packet would be available, the signature used 285 for authentication could not be recalculated, and thus this mechanism 286 could not be used as a counter-measure aganist ICMP-based attacks 287 against TCP. 289 For IPv6, the payload of ICMPv6 error messages includes as many 290 octets from the IPv6 packet that elicited the ICMPv6 error message as 291 will fit without making the resulting ICMPv6 packet exceed the 292 minimum IPv6 MTU (1280 octets) [RFC2463]. Thus, more information is 293 available than in the IPv4 case. 295 Hosts could require ICMP error messages to be authenticated 296 [RFC2401], in order to act upon them. However, while this 297 requirement could make sense for those ICMP error messages sent by 298 hosts, it would not be feasible for those ICMP error messages 299 generated by routers, as this would imply either that the attacked 300 host should have a security association [RFC2401] with every existing 301 intermediate system, or that it should be able to establish one 302 dynamically. Current levels of deployment of protocols for dynamic 303 establishment of security associations makes this unfeasible. Also, 304 there may be some cases, such as embedded devices, in which the 305 processing power requirements of authentication could not allow IPSec 306 authentication to be implemented effectively. 308 Additional considerations for the validation of ICMP error messages 309 can be found in Appendix C 311 4. General counter-measures against ICMP attacks 313 There are a number of counter-measures that can be implemented to 314 eliminate or mitigate the impact of the attacks discussed in this 315 document. Rather than being alternative counter-measures, they can 316 be implemented together to increase the protection against these 317 attacks. In particular, all TCP implementations should perform the 318 TCP sequence number checking described in Section 4.1. 320 4.1. TCP sequence number checking 322 The current specifications do not impose any validity checks on the 323 TCP segment that is contained in the ICMP payload. For instance, no 324 checks are performed to verify that a received ICMP error message has 325 been elicited by a segment that was "in flight" to destination. 326 Thus, even stale ICMP error messages will be acted upon. 328 TCP should check that the TCP sequence number contained in the 329 payload of the ICMP error message is within the range SND.UNA =< 330 SEG.SEQ < SND.NXT. This means that the sequence number should be 331 within the range of the data already sent but not yet acknowledged. 332 If an ICMP error message does not pass this check, it should be 333 discarded. 335 Even if an attacker were able to guess the four-tuple that identifies 336 the TCP connection, this additional check would reduce the 337 possibility of considering a spoofed ICMP packet as valid to 338 Flight_Size/2^^32 (where Flight_Size is the number of data bytes 339 already sent to the remote peer, but not yet acknowledged [RFC2581]). 340 For connections in the SYN-SENT or SYN-RECEIVED states, this would 341 reduce the possibility of considering a spoofed ICMP packet as valid 342 to 1/2^^32. For a TCP endpoint with no data "in flight", this would 343 completely eliminate the possibility of success of these attacks. 345 This validation check has been implemented in Linux [Linux] for many 346 years, in OpenBSD [OpenBSD] since 2004, and in FreeBSD [FreeBSD] and 347 NetBSD [NetBSD] since 2005. 349 It is important to note that while this check greatly increases the 350 number of packets required to perform any of the attacks discussed in 351 this document, this may not be enough in those scenarios in which 352 bandwidth is easily available, and/or large TCP windows [RFC1323] are 353 in use. Therefore, implementation of the attack-specific counter- 354 measures discussed in this document is strongly recommended. 356 4.2. Port randomization 358 As discussed in the previous sections, in order to perform any of the 359 attacks described in this document, an attacker would need to guess 360 (or know) the four-tuple that identifies the connection to be 361 attacked. Increasing the port number range used for outgoing TCP 362 connections, and randomizing the port number chosen for each outgoing 363 TCP conenctions would make it harder for an attacker to perform any 364 of the attacks discussed in this document. 366 [I-D.larsen-tsvwg-port-randomisation] discusses a number of 367 algorithms to randomize the ephemeral ports used by clients. 369 4.3. Filtering ICMP error messages based on the ICMP payload 371 The source address of ICMP error messages does not need to be spoofed 372 to perform the attacks described in this document. Therefore, simple 373 filtering based on the source address of ICMP error messages does not 374 serve as a counter-measure against these attacks. However, a more 375 advanced packet filtering could be implemented in firewalls as a 376 counter-measure. Firewalls implementing such advanced filtering 377 would look at the payload of the ICMP error messages, and would 378 perform ingress and egress packet filtering based on the source IP 379 address of the IP header contained in the payload of the ICMP error 380 message. As the source IP address contained in the payload of the 381 ICMP error message does need to be spoofed to perform the attacks 382 described in this document, this kind of advanced filtering would 383 serve as a counter-measure against these attacks. 385 5. Blind connection-reset attack 387 5.1. Description 389 When TCP is handled an ICMP error message, it will perform its fault 390 recovery function, as follows: 392 o If the network problem being reported is a hard error, TCP will 393 abort the corresponding connection. 395 o If the network problem being reported is a soft error, TCP will 396 just record this information, and repeatedly retransmit its data 397 until they either get acknowledged, or the connection times out. 399 The Host Requirements RFC [RFC1122] states that a host SHOULD abort 400 the corresponding connection when receiving an ICMP error message 401 that indicates a "hard error", and states that ICMP error messages of 402 type 3 (Destination Unreachable) codes 2 (protocol unreachable), 3 403 (port unreachable), and 4 (fragmentation needed and DF bit set) 404 should be considered to indicate hard errors. While [RFC2463] did 405 not exist when [RFC1122] was published, one could extrapolate the 406 concept of "hard errors" to ICMPv6 error messages of type 1 407 (Destination unreachable) codes 1 (communication with destination 408 administratively prohibited), and 4 (port unreachable). 410 Thus, an attacker could use ICMP to perform a blind connection-reset 411 attack. That is, even being off-path, an attacker could reset any 412 TCP connection taking place. In order to perform such an attack, an 413 attacker would send any ICMP error message that indicates a "hard 414 error", to either of the two TCP endpoints of the connection. 415 Because of TCP's fault recovery policy, the connection would be 416 immediately aborted. 418 As discussed in Section 2.2, all an attacker needs to know to perform 419 such an attack is the socket pair that identifies the TCP connection 420 to be attacked. In some scenarios, the IP addresses and port numbers 421 in use may be easily guessed or known to the attacker [Watson]. 423 Some stacks are known to extrapolate ICMP errors across TCP 424 connections, increasing the impact of this attack, as a single ICMP 425 packet could bring down all the TCP connections between the 426 corresponding peers. 428 It is important to note that even if TCP itself were protected 429 against the blind connection-reset attack described in [Watson] and 430 [I-D.ietf-tcpm-tcpsecure], by means authentication at the network 431 layer [RFC2401], by means of the TCP MD5 signature option [RFC2385], 432 or by means of the mechanism proposed in [I-D.ietf-tcpm-tcpsecure], 433 the blind connection-reset attack described in this document would 434 still succeed. 436 5.2. Attack-specific counter-measures 438 5.2.1. Changing the reaction to hard errors 440 An analysis of the circumstances in which ICMP messages that indicate 441 hard errors may be received can shed some light to eliminate the 442 impact of ICMP-based blind connection-reset attacks. 444 ICMP type 3 (Destination Unreachable), code 2 (protocol unreachable) 446 This ICMP error message indicates that the host sending the ICMP 447 error message received a packet meant for a transport protocol it 448 does not support. For connection-oriented protocols such as TCP, 449 one could expect to receive such an error as the result of a 450 connection-establishment attempt. However, it would be strange to 451 get such an error during the life of a connection, as this would 452 indicate that support for that transport protocol has been removed 453 from the host sending the error message during the life of the 454 corresponding connection. Thus, it would be fair to treat ICMP 455 protocol unreachable error messages as soft errors (or completely 456 ignore them) if they are meant for connections that are in 457 synchronized states. For TCP, this means TCP should treat ICMP 458 protocol unreachable error messages as soft errors (or completely 459 ignore them) if they are meant for connections that are in the 460 ESTABLISHED, FIN-WAIT-1, FIN-WAIT-2, CLOSE-WAIT, CLOSING, LAST-ACK 461 or TIME-WAIT states. 463 ICMP type 3 (Destination Unreachable), code 3 (port unreachable) 465 This error message indicates that the host sending the ICMP error 466 message received a packet meant for a socket (IP address, port 467 number) on which there is no process listening. Those transport 468 protocols which have their own mechanisms for notifying this 469 condition should not be receiving these error messages. However, 470 the Host Requirements RFC [RFC1122] states that even those 471 transport protocols that have their own mechanism for notifying 472 the sender that a port is unreachable MUST nevertheless accept an 473 ICMP Port Unreachable for the same purpose. For security reasons, 474 it would be fair to treat ICMP port unreachable messages as soft 475 errors (or completely ignore them) when they are meant for 476 protocols that have their own mechanism for reporting this error 477 condition. 479 ICMP type 3 (Destination Unreachable), code 4 (fragmentation needed 480 and DF bit set) 482 This error message indicates that an intermediate node needed to 483 fragment a datagram, but the DF (Don't Fragment) bit in the IP 484 header was set. Those systems that do not implement the PMTUD 485 mechanism should not be sending their IP packets with the DF bit 486 set, and thus should not be receiving these ICMP error messages. 487 Thus, it would be fair for them to treat this ICMP error message 488 as indicating a soft error, therefore not aborting the 489 corresponding connection when such an error message is received. 490 On the other hand, and for obvious reasons, those systems 491 implementing the Path-MTU Discovery (PMTUD) mechanism [RFC1191] 492 should not abort the corresponding connection when such an ICMP 493 error message is received. 495 ICMPv6 type 1 (Destination Unreachable), code 1 (communication with 496 destination administratively prohibited) 498 This error message indicates that the destination is unreachable 499 because of an administrative policy. For connection-oriented 500 protocols such as TCP, one could expect to receive such an error 501 as the result of a connection-establishment attempt. Receiving 502 such an error for a connection in any of the synchronized states 503 would mean that the administrative policy changed during the life 504 of the connection. Therefore, while it would be possible for a 505 firewall to be reconfigured during the life of a connection, it 506 would be fair, for security reasons, to ignore these messages for 507 connections that are in the ESTABLISHED, FIN-WAIT-1, FIN-WAIT-2, 508 CLOSE-WAIT, CLOSING, LAST-ACK or TIME-WAIT states. 510 ICMPv6 type 1 (Destination Unreachable), code 4 (port unreachable) 512 This error message is analogous to the ICMP type 3 (Destination 513 Unreachable), code 3 (Port unreachable) error message discussed 514 above. Therefore, the same considerations apply. 516 Therefore, TCP should treat all of the above messages as indicating 517 "soft errors", rather than "hard errors", and thus should not abort 518 the corresponding connection upon receipt of them. This is policy is 519 based on the premise that TCP should be as robust as possible. Also, 520 as discussed in Section 5.1, hosts should not extrapolate ICMP errors 521 across TCP connections. 523 In case the received message were legitimate, it would mean that the 524 "hard error" condition appeared during the life of the connection. 525 However, there is no reason to think that in the same way this error 526 condition appeared, it won't get solved in the near term. Therefore, 527 treating the received ICMP error messages as "soft errors" would make 528 TCP more robust, and could avoid TCP from aborting a TCP connection 529 unnecesarily. Aborting the connection would be to ignore the 530 valuable feature of the Internet that for many internal failures it 531 reconstructs its function without any disruption of the end points 532 [RFC0816]. 534 Also, it is important to note that the "Host Requirements RFC" 535 [RFC1122] allows this alternative processing of ICMP error messages. 537 One scenario in which a host would benefit from treating the so- 538 called ICMP "hard errors" as "soft errors" would be that in which the 539 packets that correspond to a given TCP connection are routed along 540 multiple different paths. Some (but not all) of these paths may be 541 experiencing an error condition, and therefore generating the so- 542 called ICMP hard errors. However, communication should survive if 543 there is still a working path to the destination host [DClark]. 544 Thus, treating the so-called "hard errors" as "soft errors" when a 545 connection is in any of the synchronized states would make TCP 546 achieve this goal. 548 It is interesting to note that, as ICMP error messages are 549 unreliable, transport protocols should not depend on them for correct 550 functioning. In the event one of these messages were legitimate, the 551 corresponding connection would eventually time out. Also, 552 applications may still be notified asynchronously about the received 553 error messages, and thus may still abort their connections on their 554 own if they consider it appropriate. 556 This counter-measure has been implemented in BSD-derived TCP/IP 557 implementations (e.g., [FreeBSD], [NetBSD], and [OpenBSD]) for more 558 than ten years [Wright][McKusick]. The Linux kernel has implemented 559 this policy for more than ten years, too [Linux]. 561 5.2.2. Delaying the connection-reset 563 An alternative counter-measure could be to delay the connection 564 reset. Rather than immediately aborting a connection, a TCP would 565 abort a connection only after an ICMP error message indicating a hard 566 error has been received, and the corresponding data have already been 567 retransmitted more than some specified number of times. 569 The rationale behind this proposed fix is that if a host can make 570 forward progress on a connection, it can completely disregard the 571 "hard errors" being indicated by the received ICMP error messages. 573 While this counter-measure could be useful, we think that the 574 counter-measure discussed in Section 5.2.1 is easier to implement, 575 and provides increased protection against this type of attack. 577 6. Blind throughput-reduction attack 579 6.1. Description 581 The Host requirements RFC [RFC1122] states that hosts MUST react to 582 ICMP Source Quench messages by slowing transmission on the 583 connection. Thus, an attacker could send ICMP Source Quench (type 4, 584 code 0) messages to a TCP endpoint to make it reduce the rate at 585 which it sends data to the other end-point of the connection. 586 [RFC1122] further adds that the RECOMMENDED procedure is to put the 587 corresponding connection in the slow-start phase of TCP's congestion 588 control algorithm [RFC2581]. In the case of those implementations 589 that use an initial congestion window of one segment, a sustained 590 attack would reduce the throughput of the attacked connection to 591 about SMSS (Sender Maximum Segment Size) [RFC2581] bytes per RTT 592 (round-trip time). The throughput achieved during attack might be a 593 little higher if a larger initial congestion window is in use 594 [RFC3390]. 596 6.2. Attack-specific counter-measures 598 The Host Requirements RFC [RFC1122] states that hosts MUST react to 599 ICMP Source Quench messages by slowing transmission on the 600 connection. However, as discussed in the Requirements for IP Version 601 4 Routers RFC [RFC1812], research seems to suggest ICMP Source Quench 602 is an ineffective (and unfair) antidote for congestion. [RFC1812] 603 further states that routers SHOULD NOT send ICMP Source Quench 604 messages in response to congestion. On the other hand, TCP 605 implements its own congestion control mechanisms [RFC2581] [RFC3168], 606 that do not depend on ICMP Source Quench messages. Thus, hosts 607 should completely ignore ICMP Source Quench messages meant for TCP 608 connections. 610 This behavior has been implemented in Linux [Linux] since 2004, and 611 in FreeBSD [FreeBSD], NetBSD [NetBSD], and OpenBSD [OpenBSD] since 612 2005. 614 7. Blind performance-degrading attack 616 7.1. Description 618 When one IP host has a large amount of data to send to another host, 619 the data will be transmitted as a series of IP datagrams. It is 620 usually preferable that these datagrams be of the largest size that 621 does not require fragmentation anywhere along the path from the 622 source to the destination. This datagram size is referred to as the 623 Path MTU (PMTU), and is equal to the minimum of the MTUs of each hop 624 in the path [RFC1191]. 626 A technique called "Path MTU Discovery" (PMTUD) mechanism lets IP 627 hosts determine the Path MTU of an arbitrary internet path. 628 [RFC1191] and [RFC1981] specify the PMTUD mechanism for IPv4 and 629 IPv6, respectively. 631 The PMTUD mechanism for IPv4 uses the Don't Fragment (DF) bit in the 632 IP header to dynamically discover the Path MTU. The basic idea 633 behind the PMTUD mechanism is that a source host assumes that the MTU 634 of the path is that of the first hop, and sends all its datagrams 635 with the DF bit set. If any of the datagrams is too large to be 636 forwarded without fragmentation by some intermediate router, the 637 router will discard the corresponding datagram, and will return an 638 ICMP "Destination Unreachable" (type 3) "fragmentation neeed and DF 639 set" (code 4) error message to sending host. This message will 640 report the MTU of the constricting hop, so that the sending host can 641 reduce the assumed Path-MTU accordingly. 643 For IPv6, intermediate systems do not fragment packets. Thus, 644 there's an "implicit" DF bit set in every packet sent on a network. 645 If any of the datagrams is too large to be forwarded without 646 fragmentation by some intermediate router, the router will discard 647 the corresponding datagram, and will return an ICMPv6 "Packet Too 648 Big" (type 2, code 0) error message to sending host. This message 649 will report the MTU of the constricting hop, so that the sending host 650 can reduce the assumed Path-MTU accordingly. 652 As discussed in both [RFC1191] and [RFC1981], the Path-MTU Discovery 653 mechanism can be used to attack TCP. An attacker could send a forged 654 ICMP "Destination Unreachable, fragmentation needed and DF set" 655 packet (or their ICMPv6 counterpart) to the sending host, advertising 656 a small Next-Hop MTU. As a result, the attacked system would reduce 657 the size of the packets it sends for the corresponding connection 658 accordingly. 660 The effect of this attack is two-fold. On one hand, it will increase 661 the headers/data ratio, thus increasing the overhead needed to send 662 data to the remote TCP end-point. On the other hand, if the attacked 663 system wanted to keep the same throughput it was achieving before 664 being attacked, it would have to increase the packet rate. On 665 virtually all systems this will lead to an increase in the IRQ 666 (Interrrupt ReQuest) rate, thus increasing processor utilization, and 667 degrading the overall system performance. 669 A particular scenario that may take place is that in which an 670 attacker reports a Next-Hop MTU smaller than or equal to the amount 671 of bytes needed for headers (IP header, plus TCP header). For 672 example, if the attacker reports a Next-Hop MTU of 68 bytes, and the 673 amount of bytes used for headers (IP header, plus TCP header) is 674 larger than 68 bytes, the assumed Path-MTU will not even allow the 675 attacked host to send a single byte of application data without 676 fragmentation. This particular scenario might lead to unpredictable 677 results. Another posible scenario is that in which a TCP connection 678 is being secured by means of IPSec. If the Next-Hop MTU reported by 679 the attacker is smaller than the amount of bytes needed for headers 680 (IP and IPSec, in this case), the assumed Path-MTU will not even 681 allow the attacked host to send a single byte of the TCP header 682 without fragmentation. This is another scenario that may lead to 683 unpredictable results. 685 For IPv4, the reported Next-Hop MTU could be as low as 68 octets, as 686 [RFC0791] requires every internet module to be able to forward a 687 datagram of 68 octets without further fragmentation. For IPv6, the 688 reported Next-Hop MTU could be as low as 1280 octets (the minimum 689 IPv6 MTU) [RFC2460]. 691 7.2. Attack-specific counter-measures 693 Henceforth, we will refer to both ICMP "fragmentation needed and DF 694 bit set" and ICMPv6 "Packet Too Big" messages as "ICMP Packet Too 695 Big" messages. 697 In addition to the general validation check described in Section 4.1, 698 a counter-measure similar to that described in Section 5.2.2 could be 699 implemented to greatly minimize the impact of this attack. 701 This would mean that upon receipt of an ICMP "Packet Too Big" error 702 message, TCP would just record this information, and would honor it 703 only when the corresponding data had already been retransmitted a 704 specified number of times. 706 While this policy would greatly mitigate the impact of the attack 707 against the PMTUD mechanism, it would also mean that it might take 708 TCP more time to discover the Path-MTU for a TCP connection. This 709 would be particularly annoying for connections that have just been 710 established, as it might take TCP several transmission attempts (and 711 the corresponding timeouts) before it discovers the PMTU for the 712 corresponding connection. Thus, this policy would increase the time 713 it takes for data to begin to be received at the destination host. 715 We would like to protect TCP from the attack against the PMTUD 716 mechanism, while still allowing TCP to quickly determine the initial 717 Path-MTU for a connection. 719 To achieve both goals, we can divide the traditional PMTUD mechanism 720 into two stages: Initial Path-MTU Discovery, and Path-MTU Update. 722 The Initial Path-MTU Discovery stage is when TCP tries to send 723 segments that are larger than the ones that have so far been sent and 724 acknowledged for this connection. That is, in the Initial Path-MTU 725 Discovery stage TCP has no record of these large segments getting to 726 the destination host, and thus it would be fair to believe the 727 network when it reports that these packets are too large to reach the 728 destination host without being fragmented. 730 The Path-MTU Update stage is when TCP tries to send segments that are 731 equal to or smaller than the ones that have already been sent and 732 acknowledged for this connection. During the Path-MTU Update stage, 733 TCP already has knowledge of the estimated Path-MTU for the given 734 connection. Thus, it would be fair to be more cautious with the 735 errors being reported by the network. 737 In order to allow TCP to distinguish segments between those 738 performing Initial Path-MTU Discovery and those performing Path-MTU 739 Update, two new variables should be introduced to TCP: maxsizeacked 740 and maxsizesent. 742 maxsizesent would hold the size (in octets) of the largest packet 743 that has so far been sent for this connection. It would be 744 initialized to 68 (the minimum IPv4 MTU) when the underlying internet 745 protocol is IPv4, and would be initialized to 1280 (the minimum IPv6 746 MTU) when the underlying internet protocol is IPv6. Whenever a 747 packet larger than maxsizesent octets is sent, maxsizesent should be 748 set to that value. 750 On the other hand, maxsizeacked would hold the size (in octets) of 751 the largest packet that has so far been acknowledged for this 752 connection. It would be initialized to 68 (the minimum IPv4 MTU) 753 when the underlying internet protocol is IPv4, and would be 754 initialized to 1280 (the minimum IPv6 MTU) when the underlying 755 internet protocol is IPv6. Whenever an acknowledgement for a packet 756 larger than maxsizeacked octets is received, maxsizeacked should be 757 set to the size of that acknowledged packet. 759 Upon receipt of an ICMP "Packet Too Big" error message, the Next-Hop 760 MTU claimed by the ICMP message (henceforth "claimedmtu") should be 761 compared with maxsizesent. If claimedmtu is equal to or larger than 762 maxsizesent, then the ICMP error message should be silently 763 discarded. The rationale for this is that the ICMP error message 764 cannot be legitimate if it claims to have been elicited by a packet 765 larger than the largest packet we have so far sent for this 766 connection. 768 If this check is passed, claimedmtu should be compared with 769 maxsizeacked. If claimedmtu is equal to or larger than maxsizeacked, 770 TCP is supposed to be at the Initial Path-MTU Discovery stage, and 771 thus the ICMP "Packet Too Big" error message should be honored 772 immediately. That is, the assumed Path-MTU should be updated 773 according to the Next-Hop MTU claimed in the ICMP error message. 774 Also, maxsizesent should be reset to the minimum MTU of the internet 775 protocol in use (68 for IPv4, and 1280 for IPv6). 777 On the other hand, if claimedmtu is smaller than maxsizeacked, TCP is 778 supposed to be in the Path-MTU Update stage. At this stage, we 779 should be more cautious with the errors being reported by the 780 network, and should therefore just record the received error message, 781 and delay the update of the assumed Path-MTU. 783 To perform this delay, one new variable and one new parameter should 784 be introduced to TCP: nsegrto and MAXSEGRTO. nsegrto will hold the 785 number of times a specified segment has timed out. It should be 786 initialized to zero, and should be incremented by one everytime the 787 corresponding segment times out. MAXSEGRRTO should specify the 788 number of times a given segment must timeout before an ICMP "Packet 789 Too Big" error message can be honored, and can be set, in principle, 790 to any value greater than or equal to 0. 792 Thus, if nsegrto is greater than or equal to MAXSEGRTO, and there's a 793 pending ICMP "Packet Too Big" error message, the correspoing error 794 message should be processed. At that point, maxsizeacked should be 795 set to claimedmtu, and maxsizesent should be set to 68 (for IPv4) or 796 1280 (for IPv6). 798 If while there is a pending ICMP "Packet Too Big" error message the 799 TCP SEQ claimed by the pending message is acknowledged (i.e., an ACK 800 that acknowledges that sequence number is received), then the 801 "pending error" condition should be cleared. 803 The rationale behind performing this delayed processing of ICMP 804 "Packet Too Big" messages is that if there is progress on the 805 connection, the ICMP "Packet Too Big" errors must be a false claim. 806 By checking for progress on the connection, rather than just for 807 staleness of the received ICMP messages, TCP is protected from attack 808 even if the offending ICMP messages are "in window", and as a 809 corollary, is made more robust to spurious ICMP messages elicited by, 810 for example, corrupted TCP segments. 812 MAXSEGRTO can be set, in principle, to any value greater than or 813 equal to 0. Setting MAXSEGRTO to 0 would make TCP perform the 814 traditional PMTUD mechanism defined in [RFC1191] and [RFC1981]. A 815 MAXSEGRTO of 1 should provide enough protection for most cases. In 816 any case, implementations are free to choose higher values for this 817 constant. MAXSEGRTO could be a function of the Next-Hop MTU claimed 818 in the received ICMP "Packet Too Big" message. That is, higher 819 values for MAXSEGRTO could be imposed when the received ICMP "Packet 820 Too Big" message claims a Next-Hop MTU that is smaller than some 821 specified value. 823 In the event a higher level of protection is desired at the expense 824 of a higher delay in the discovery of the Path-MTU, an implementation 825 could consider TCP to always be in the Path-MTU Update stage, thus 826 always delaying the update of the assumed Path-MTU. 828 Appendix A shows the proposed counter-measure in action. Appendix B 829 shows the proposed counter-measure in pseudo-code. 831 This behavior has been implemented in NetBSD [NetBSD] and OpenBSD 832 [OpenBSD] since 2005. 834 It is important to note that the mechanism proposed in this section 835 is an improvement to the current Path-MTU discovery mechanism, to 836 mitigate its security implications. The current PMTUD mechanism, as 837 specified by [RFC1191] and [RFC1981], still suffers from some 838 functionality problems [RFC2923] that this document does not aim to 839 address. A mechanism that addresses those issues is described in 840 [I-D.ietf-pmtud-method]. 842 8. Security Considerations 844 This document describes the use of ICMP error messages to perform a 845 number of attacks against the TCP protocol, and proposes a number of 846 counter-measures that either eliminate or reduce the impact of these 847 attacks. 849 9. Acknowledgements 851 This document was inspired by Mika Liljeberg, while discussing some 852 issues related to [I-D.gont-tcpm-tcp-soft-errors] by private e-mail. 853 The author would like to thank Ran Atkinson, James Carlson, Alan Cox, 854 Theo de Raadt, Ted Faber, Juan Fraschini, Markus Friedl, Guillermo 855 Gont, John Heffner, Vivek Kakkar, Michael Kerrisk, Mika Liljeberg, 856 Matt Mathis, David Miller, Miles Nordin, Eloy Paris, Kacheong Poon, 857 Andrew Powell, Pekka Savola, Joe Touch, and Andres Trapanotto, for 858 contributing many valuable comments. 860 Juan Fraschini and the author of this document implemented freely- 861 available audit tools to help vendors audit their systems by 862 reproducing the attacks discussed in this document. 864 Markus Friedl, Chad Loder, and the author of this document, produced 865 and tested in OpenBSD [OpenBSD] the first implementation of the 866 counter-measure described in Section 7.2. This first implementation 867 helped to test the effectiveness of the ideas introduced in this 868 document, and has served as a reference implementation for other 869 operating systems. 871 The author would like to thank the UK's National Infrastructure 872 Security Co-ordination Centre (NISCC) for coordinating the disclosure 873 of these issues with a large number of vendors and CSIRTs (Computer 874 Security Incident Response Teams). 876 The author wishes to express deep and heartfelt gratitude to Jorge 877 Oscar Gont and Nelida Garcia, for their precious motivation and 878 guidance. 880 10. References 882 10.1. Normative References 884 [RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791, 885 September 1981. 887 [RFC0792] Postel, J., "Internet Control Message Protocol", STD 5, 888 RFC 792, September 1981. 890 [RFC0793] Postel, J., "Transmission Control Protocol", STD 7, 891 RFC 793, September 1981. 893 [RFC1122] Braden, R., "Requirements for Internet Hosts - 894 Communication Layers", STD 3, RFC 1122, October 1989. 896 [RFC1191] Mogul, J. and S. Deering, "Path MTU discovery", RFC 1191, 897 November 1990. 899 [RFC1812] Baker, F., "Requirements for IP Version 4 Routers", 900 RFC 1812, June 1995. 902 [RFC1981] McCann, J., Deering, S., and J. Mogul, "Path MTU Discovery 903 for IP version 6", RFC 1981, August 1996. 905 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 906 Requirement Levels", BCP 14, RFC 2119, March 1997. 908 [RFC2401] Kent, S. and R. Atkinson, "Security Architecture for the 909 Internet Protocol", RFC 2401, November 1998. 911 [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 912 (IPv6) Specification", RFC 2460, December 1998. 914 [RFC2463] Conta, A. and S. Deering, "Internet Control Message 915 Protocol (ICMPv6) for the Internet Protocol Version 6 916 (IPv6) Specification", RFC 2463, December 1998. 918 10.2. Informative References 920 [DClark] Clark, D., "The Design Philosophy of the DARPA Internet 921 Protocols", Computer Communication Review Vol. 18, No. 4, 922 1988. 924 [FreeBSD] The FreeBSD Project, "http://www.freebsd.org". 926 [I-D.gont-tcpm-tcp-soft-errors] 927 Gont, F., "TCP's Reaction to Soft Errors", 928 draft-gont-tcpm-tcp-soft-errors-02 (work in progress), 929 September 2005. 931 [I-D.iab-link-indications] 932 Aboba, B., "Architectural Implications of Link 933 Indications", draft-iab-link-indications-04 (work in 934 progress), December 2005. 936 [I-D.ietf-pmtud-method] 937 Mathis, M. and J. Heffner, "Path MTU Discovery", 938 draft-ietf-pmtud-method-05 (work in progress), 939 October 2005. 941 [I-D.ietf-tcpm-tcpsecure] 942 Dalal, M., "Improving TCP's Robustness to Blind In-Window 943 Attacks", draft-ietf-tcpm-tcpsecure-03 (work in progress), 944 May 2005. 946 [I-D.larsen-tsvwg-port-randomisation] 947 Larsen, M., "Port Randomisation", 948 draft-larsen-tsvwg-port-randomisation-00 (work in 949 progress), October 2004. 951 [Linux] The Linux Project, "http://www.kernel.org". 953 [McKusick] 954 McKusick, M., Bostic, K., Karels, M., and J. Quarterman, 955 "The Design and Implementation of the 4.4BSD Operating 956 System", Addison-Wesley , 1996. 958 [NISCC] NISCC, "NISCC Vulnerability Advisory 532967/NISCC/ICMP: 959 Vulnerability Issues in ICMP packets with TCP payloads", 960 http://www.niscc.gov.uk/niscc/docs/ 961 al-20050412-00308.html?lang=en, 2005. 963 [NetBSD] The NetBSD Project, "http://www.netbsd.org". 965 [OpenBSD] The OpenBSD Project, "http://www.openbsd.org". 967 [RFC0816] Clark, D., "Fault isolation and recovery", RFC 816, 968 July 1982. 970 [RFC1321] Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321, 971 April 1992. 973 [RFC1323] Jacobson, V., Braden, B., and D. Borman, "TCP Extensions 974 for High Performance", RFC 1323, May 1992. 976 [RFC2385] Heffernan, A., "Protection of BGP Sessions via the TCP MD5 977 Signature Option", RFC 2385, August 1998. 979 [RFC2581] Allman, M., Paxson, V., and W. Stevens, "TCP Congestion 980 Control", RFC 2581, April 1999. 982 [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., 983 Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext 984 Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999. 986 [RFC2821] Klensin, J., "Simple Mail Transfer Protocol", RFC 2821, 987 April 2001. 989 [RFC2923] Lahey, K., "TCP Problems with Path MTU Discovery", 990 RFC 2923, September 2000. 992 [RFC3168] Ramakrishnan, K., Floyd, S., and D. Black, "The Addition 993 of Explicit Congestion Notification (ECN) to IP", 994 RFC 3168, September 2001. 996 [RFC3390] Allman, M., Floyd, S., and C. Partridge, "Increasing TCP's 997 Initial Window", RFC 3390, October 2002. 999 [US-CERT] US-CERT, "US-CERT Vulnerability Note VU#222750: TCP/IP 1000 Implementations do not adequately validate ICMP error 1001 messages", http://www.kb.cert.org/vuls/id/222750, 2005. 1003 [Watson] Watson, P., "Slipping in the Window: TCP Reset Attacks", 1004 2004 CanSecWest Conference , 2004. 1006 [Wright] Wright, G. and W. Stevens, "TCP/IP Illustrated, Volume 2: 1007 The Implementation", Addison-Wesley , 1994. 1009 Appendix A. The counter-measure for the PMTUD attack in action 1011 This appendix shows the proposed counter-measure for the ICMP attack 1012 against the PMTUD mechanism in action. It shows both how the fix 1013 protects TCP from being attacked and how the counter-measure works in 1014 normal scenarios. As discussed in Section 7.2, this Appendix assumes 1015 the PMTUD-specific counter-measure is implemented in addition to the 1016 TCP sequence number checking described in Section 4.1. 1018 Figure 1 illustrates an hypothetical scenario in which two hosts are 1019 connected by means of three intermediate routers. It also shows the 1020 MTU of each hypothetical hop. All the following subsections assume 1021 the network setup of this figure. 1023 Also, for simplicity sake, all subsections assume an IP header of 20 1024 octets and a TCP header of 20 octets. Thus, for example, when the 1025 PMTU is assumed to be 1500 octets, TCP will send segments that 1026 contain, at most, 1460 octets of data. 1028 For simplicity sake, all the following subsections assume the TCP 1029 implementation at Host 1 has chosen a a MAXSEGRTO of 1. 1031 +----+ +----+ +----+ +----+ +----+ 1032 | H1 |--------| R1 |--------| R2 |--------| R3 |--------| H2 | 1033 +----+ +----+ +----+ +----+ +----+ 1034 MTU=4464 MTU=2048 MTU=1500 MTU=4464 1036 Figure 1: Hypothetical scenario 1038 A.1. Normal operation for bulk transfers 1040 This subsection shows the proposed counter-measure in normal 1041 operation, when a TCP connection is used for bulk transfers. That 1042 is, it shows how the proposed counter-measure works when there is no 1043 attack taking place, and a TCP connection is used for transferring 1044 large amounts of data. This section assumes that just after the 1045 connection is established, one of the TCP endpoints begins to 1046 transfer data in packets that are as large as possible. 1048 Host 1 Host 2 1050 1. --> --> 1051 2. <-- <-- 1052 3. --> --> 1053 4. --> --> 1054 5. <--- ICMP "Packet Too Big" MTU=2048, TCPseq#=101 <--- R1 1055 6. --> --> 1056 7. <--- ICMP "Packet Too Big" MTU=1500, TCPseq#=101 <--- R2 1057 8. --> --> 1058 9. <-- <-- 1060 Figure 2: Normal operation for bulk transfers 1062 nsegrto is initialized to zero. Both maxsizeacked and maxsizesent 1063 are initialized to the minimum MTU for the internet protocol being 1064 used (68 for IPv4, and 1280 for IPv6). 1066 In lines 1 to 3 the three-way handshake takes place, and the 1067 connection is established. In line 4, H1 tries to send a full-sized 1068 TCP segment. As described by [RFC1191] and [RFC1981], in this case 1069 TCP will try to send a segment with 4424 bytes of data, which will 1070 result in an IP packet of 4464 octets. Therefore, maxsizesent is set 1071 to 4464. When the packet reaches R1, it elicits an ICMP "Packet Too 1072 Big" error message. 1074 In line 5, H1 receives the ICMP error message, which reports a Next- 1075 Hop MTU of 2048 octets. After performing the TCP sequence number 1076 check described in Section 4.1, the Next-Hop MTU reported by the ICMP 1077 error message (claimedmtu) is compared with maxsizesent. As it is 1078 smaller than maxsizesent, it passes the check, and thus is then 1079 compared with maxsizeacked. As claimedmtu is larger than 1080 maxsizeacked, TCP assumes that the corresponding TCP segment was 1081 performing the Initial PMTU Discovery. Therefore, the TCP at H1 1082 honors the ICMP message by updating the assumed Path-MTU. maxsizesent 1083 is reset to the minimum MTU of the internet protocol in use (68 for 1084 IPv4, and 1280 for IPv6). 1086 In line 6, the TCP at H1 sends a segment with 2008 bytes of data, 1087 which results in an IP packet of 2048 octets. maxsizesent is thus set 1088 to 2008 bytes. When the packet reaches R2, it elicits an ICMP 1089 "Packet Too Big" error message. 1091 In line 7, H1 receives the ICMP error message, which reports a Next- 1092 Hop MTU of 1500 octets. After performing the TCP sequence number 1093 check, the Next-Hop MTU reported by the ICMP error message 1094 (claimedmtu) is compared with maxsizesent. As it is smaller than 1095 maxsizesent, it passes the check, and thus is then compared with 1096 maxsizeacked. As claimedmtu is larger than maxsizeacked, TCP assumes 1097 that the corresponding TCP segment was performing the Initial PMTU 1098 Discovery. Therefore, the TCP at H1 honors the ICMP message by 1099 updating the assumed Path-MTU. maxsizesent is reset to the minimum 1100 MTU of the internet protocol in use. 1102 In line 8, the TCP at H1 sends a segment with 1460 bytes of data, 1103 which results in an IP packet of 1500 octets. maxsizesent is thus set 1104 to 1500. This packet reaches H2, where it elicits an acknowledgement 1105 (ACK) segment. 1107 In line 9, H1 finally gets the acknowledgement for the data segment. 1108 As the corresponding packet was larger than maxsizeacked, TCP updates 1109 maxsizeacked, setting it to 1500. At this point TCP has discovered 1110 the Path-MTU for this TCP connection. 1112 A.2. Operation during Path-MTU changes 1114 Let us suppose a TCP connection between H1 and H2 has already been 1115 established, and that the PMTU for the connection has already been 1116 discovered to be 1500. At this point, both maxsizesent and 1117 maxsizeacked are equal to 1500, and nsegrto is equal to 0. Suppose 1118 some time later the PMTU decreases to 1492. For simplicity, let us 1119 suppose that the Path-MTU has decreased because the MTU of the link 1120 between R2 and R3 has decreased from 1500 to 1492. Figure 3 1121 illustrates how the proposed counter-measure would work in this 1122 scenario. 1124 Host 1 Host 2 1126 1. (Path-MTU decreases) 1127 2. --> --> 1128 3. <--- ICMP "Packet Too Big" MTU=1492, TCPseq#=100 <--- R2 1129 4. (Segment times out) 1130 5. --> --> 1131 6. <-- <-- 1133 Figure 3: Operation during Path-MTU changes 1135 In line 1, the Path-MTU for this connection decreases from 1500 to 1136 1492. In line 2, the TCP at H1, without being aware of the Path-MTU 1137 change, sends a 1500-byte packet to H2. When the packet reaches R2, 1138 it elicits an ICMP "Packet Too Big" error message. 1140 In line 3, H1 receives the ICMP error message, which reports a Next- 1141 Hop MTU of 1492 octets. After performing the TCP sequence number 1142 check, the Next-Hop MTU reported by the ICMP error message 1143 (claimedmtu) is compared with maxsizesent. As claimedmtu is smaller 1144 than maxsizesent, it is then compared with maxsizeacked. As 1145 claimedmtu is smaller than maxsizeacked (full-sized packets were 1146 getting to the remote end-point), this packet is assumed to be 1147 performing Path-MTU Update. And a "pending error" condition is 1148 recorded. 1150 In line 4, the segment times out. Thus, nsegrto is incremented by 1. 1151 As nsegrto is greater than or equal to MAXSEGRTO, the assumed Path- 1152 MTU is updated. nsegrto is reset to 0, and maxsizeacked is set to 1153 claimedmtu, and maxsizesent is set to the minimum MTU of the internet 1154 protocol in use. 1156 In line 5, H1 retransmits the data using the updated PMTU, and thus 1157 maxsizesent is set to 1492. The resulting packet reaches H2, where 1158 it elicits an acknowledgement (ACK) segment. 1160 In line 6, H1 finally gets the acknowledgement for the data segment. 1161 At this point TCP has discovered the new Path-MTU for this TCP 1162 connection. 1164 A.3. Idle connection being attacked 1166 Let us suppose a TCP connection between H1 and H2 has already been 1167 established, and the PMTU for the connection has already been 1168 discovered to be 1500. Figure 4 shows a sample time-line diagram 1169 that illustrates an idle connection being attacked. 1171 Host 1 Host 2 1173 1. --> --> 1174 2. <-- <-- 1175 3. <--- ICMP "Packet Too Big" MTU=68, TCPseq#=100 <--- 1176 4. <--- ICMP "Packet Too Big" MTU=68, TCPseq#=100 <--- 1177 5. <--- ICMP "Packet Too Big" MTU=68, TCPseq#=100 <--- 1179 Figure 4: Idle connection being attacked 1181 In line 1, H1 sends its last bunch of data. At line 2, H2 1182 acknowledges the receipt of these data. Then the connection becomes 1183 idle. In lines 3, 4, and 5, an attacker sends forged ICMP "Packet 1184 Too Big" error messages to H1. Regardless of how many packets it 1185 sends and the TCP sequence number each ICMP packet includes, none of 1186 these ICMP error messages will pass the TCP sequence number check 1187 described in Section 4.1, as H1 has no unacknowledged data in flight 1188 to H2. Therefore, the attack does not succeed. 1190 A.4. Active connection being attacked after discovery of the Path-MTU 1192 Let us suppose an attacker attacks a TCP connection for which the 1193 PMTU has already been discovered. In this case, as illustrated in 1194 Figure 1, the PMTU would be found to be 1500 bytes. Figure 5 shows a 1195 possible packet exchange. 1197 Host 1 Host 2 1199 1. --> --> 1200 2. --> --> 1201 3. --> --> 1202 4. --> --> 1203 5. <--- ICMP "Packet Too Big" MTU=68, TCPseq#=100 <--- 1204 6. <-- <-- 1206 Figure 5: Active connection being attacked after discovery of PMTU 1208 As we assume the PMTU has already been discovered, we also assume 1209 both maxsizesent and maxsizeacked are equal to 1500. We assume 1210 nsegrto is equal to zero, as there have been no segment timeouts. 1212 In lines 1, 2, 3, and 4, H1 sends four data segments to H2. In line 1213 5, an attacker sends a forged ICMP packet to H1. We assume the 1214 attacker is lucky enough to guess both the four-tuple that identifies 1215 the connection and a valid TCP sequence number. As the Next-Hop MTU 1216 claimed in the ICMP "Packet Too Big" message (claimedmtu) is smaller 1217 than maxsizeacked, this packet is assumed to be performing Path-MTU 1218 Update. Thus, the error message is recorded. 1220 In line 6, H1 receives an acknowledgement for the segment sent in 1221 line 1, before it times out. At this point, the "pending error" 1222 condition is cleared, and the recorded ICMP "Packet Too Big" error 1223 message is ignored. Therefore, the attack does not succeed. 1225 A.5. TCP peer attacked when sending small packets just after the three- 1226 way handshake 1228 This section analyzes an scenario in which a TCP peer that is sending 1229 small segments just after the connection has been established, is 1230 attacked. The connection could be being used by protocols such as 1231 SMTP [RFC2821] and HTTP [RFC2616], for example, which usually behave 1232 like this. 1234 Figure 6 shows a possible packet exchange for such scenario. 1236 Host 1 Host 2 1238 1. --> --> 1239 2. <-- <-- 1240 3. --> --> 1241 4. --> --> 1242 5. <-- <-- 1243 6. --> --> 1244 7. --> --> 1245 8. <--- ICMP "Packet Too Big" MTU=150, TCPseq#=101 <--- 1247 Figure 6: TCP peer attacked when sending small packets just after the 1248 three-way handshake 1250 nsegrto is initialized to zero. Both maxsizesent and maxsizeacked 1251 are initialized to the minimum MTU for the internet protocol being 1252 used (68 for IPv4, and 1280 for IPv6). 1254 In lines 1 to 3 the three-way handshake takes place, and the 1255 connection is established. At this point, the assumed Path-MTU for 1256 this connection is 4464. In line 4, H1 sends a small segment (which 1257 results in a 140-byte packet) to H2. maxsizesent is thus set to 140. 1258 In line 5 this segment is acknowledged, and thus maxsizeacked is set 1259 to 140. 1261 In lines 6 and 7, H1 sends two small segments to H2. In line 8, 1262 while the segments from lines 6 and 7 are still in flight to H2, an 1263 attacker sends a forged ICMP "Packet Too Big" error message to H1. 1264 Assuming the attacker is lucky enough to guess a valid TCP sequence 1265 number, this ICMP message will pass the TCP sequence number check. 1266 The Next-Hop MTU reported by the ICMP error message (claimedmtu) is 1267 then compared with maxsizesent. As claimedmtu is larger than 1268 maxsizesent, the ICMP error message is silently discarded. 1269 Therefore, the attack does not succeed. 1271 Appendix B. Pseudo-code for the counter-measure for the blind 1272 performance-degrading attack 1274 This section contains a pseudo-code version of the counter-measure 1275 described in Section 7.2 for the blind performance-degrading attack 1276 described in Section 7. It is meant as guidance for developers on 1277 how to implement this counter-measure. 1279 The pseudo-code makes use of the following variables, constants, and 1280 functions: 1282 ack 1283 Variable holding the acknowledgement number contained in the TCP 1284 segment that has just been received. 1286 acked_packet_size 1287 Variable holding the packet size (data, plus headers) the ACK that 1288 has just been received is acknowledging. 1290 adjust_mtu() 1291 Function that adjusts the MTU for this connection, according to 1292 the ICMP "Packet Too Big" that was last received. 1294 claimedmtu 1295 Variable holding the Next-Hop MTU advertised by the ICMP "Packet 1296 Too Big" error message. 1298 claimedtcpseq 1299 Variable holding the TCP sequence number contained in the payload 1300 of the ICMP "Packet Too Big" message that has just been received 1301 or was last recorded. 1303 current_mtu 1304 Variable holding the assumed Path-MTU for this connection. 1306 drop_message() 1307 Function that performs the necessary actions to drop the ICMP 1308 message being processed. 1310 initial_mtu 1311 Variable holding the MTU for new connections, as explained in 1312 [RFC1191] and [RFC1981]. 1314 maxsizeacked 1315 Variable holding the largest packet size (data, plus headers) that 1316 has so for been acked for this connection, as explained in 1317 Section 7.2 1319 maxsizesent 1320 Variable holding the largest packet size (data, plus headers) that 1321 has so for been sent for this connection, as explained in 1322 Section 7.2 1324 nsegrto 1325 Variable holding the number of times this segment has timed out, 1326 as explained in Section 7.2 1328 packet_size 1329 Variable holding the size of the IP datagram being sent 1331 pending_message 1332 Variable (flag) that indicates whether there is a pending ICMP 1333 "Packet Too Big" message to be processed. 1335 save_message() 1336 Function that records the ICMP "Packet Too Big" message that has 1337 just been received. 1339 MINIMUM_MTU 1340 Constant holding the minimum MTU for the internet protocol in use 1341 (68 for IPv4, and 1280 for IPv6. 1343 MAXSEGRTO 1344 Constant holding the number of times a given segment must timeout 1345 before an ICMP "Packet Too Big" error message can be honored. 1347 EVENT: New TCP connection 1349 current_mtu = initial_mtu; 1350 maxsizesent = MINIMUM_MTU; 1351 maxsizeacked = MINIMUM_MTU; 1352 nsegrto = 0; 1353 pending_message = 0; 1355 EVENT: Segment is sent 1356 if (packet_size > maxsizesent) 1357 maxsizesent = packet_size; 1359 EVENT: Segment is received 1361 if (acked_packet_size > maxsizeacked) 1362 maxsizeacked = acked_packet_size; 1364 if (pending_mesage) 1365 if (ack > claimedtcpseq){ 1366 pending_message = 0; 1367 nsegrto = 0; 1368 } 1370 EVENT: ICMP "Packet Too Big" message is received 1372 if (claimedtcpseq < SND.UNA || claimed_TCP_SEQ >= SND.NXT){ 1373 drop_message(); 1374 } 1376 else { 1377 if (claimedmtu >= maxsizesent || claimedmtu >= current_mtu) 1378 drop_message(); 1380 else { 1381 if (claimedmtu > maxsizeacked){ 1382 adjust_mtu(); 1383 current_mtu = claimedmtu; 1384 maxsizesent = MINIMUM_MTU; 1385 } 1387 else { 1388 pending_message = 1; 1389 save_message(); 1390 } 1391 } 1392 } 1394 EVENT: Segment times out 1396 nsegrto++; 1398 if (pending_message && nsegrto >= MAXSEGRTO){ 1399 adjust_mtu(); 1400 nsegrto = 0; 1401 pending_message = 0; 1402 maxsizeacked = claimedmtu; 1403 maxsizesent = MINIMUM_MTU; 1404 current_mtu = claimedmtu; 1405 } 1407 Notes: 1408 All comparisions between sequence numbers must be performed using 1409 sequence number arithmethic. 1410 The pseudo-code implements the mechanism described in Section 7.2, 1411 the TCP sequence number checking described in Section 4.1, and the 1412 validation check on the advertised Next-Hop MTU described in 1413 [RFC1191] and [RFC1981]. 1415 Appendix C. Additional considerations for the validation of ICMP error 1416 messages 1418 The checksum of the IP datagram contained in the ICMP payload should 1419 be checked to be valid. In case it is invalid, the ICMP error 1420 message should be silently dropped. 1422 If a full IP datagram is contained in the ICMP payload, and the IP 1423 datagram is authenticated [RFC2401], the signature should be 1424 recalculated for that packet. If it doesn't match the one already 1425 included in the ICMP payload, the ICMP error message should be 1426 silently dropped. 1428 If a full TCP segment is contained in the payload of the ICMP error 1429 message, then the first check that should be performed is that the 1430 TCP checksum is valid. Then, if a TCP MD5 option is present, the MD5 1431 signature should be recalculated for the encapsulated packet, and if 1432 it doesn't match the one contained in the TCP MD5 option, the ICMP 1433 error message should be silently dropped. 1435 Regardless of whether the received ICMP error message contains a full 1436 packet or not, if a TCP timestamp option is present, it should be 1437 used to validate the error message according to the rules specified 1438 in [RFC1323]. 1440 It must be noted that most of the checks discussed in this appendix 1441 imply that the ICMP error message contains more data than just the 1442 full IP header and the first 64 bits of the payload of the original 1443 datagram that elicited the error message. As discussed in Section 3, 1444 for obvious reasons one should not expect an attacker to include in 1445 the packets it sends more information than that required to by the 1446 current specifications. 1448 Appendix D. Advice and guidance to vendors 1450 Vendors are urged to contact NISCC (vulteam@niscc.gov.uk) if they 1451 think they may be affected by the issues described in this document. 1452 As the lead coordination center for these issues, NISCC is well 1453 placed to give advice and guidance as required. 1455 NISCC works extensively with government departments and agencies, 1456 commercial organizations and the academic community to research 1457 vulnerabilities and potential threats to IT systems especially where 1458 they may have an impact on Critical National Infrastructure's (CNI). 1460 Other ways to contact NISCC, plus NISCC's PGP public key, are 1461 available at http://www.uniras.gov.uk/vuls/ . 1463 Appendix E. Changes from previous versions of the draft 1465 E.1. Changes from draft-gont-tcpm-icmp-attacks-05 1467 o Removed RFC 2119 wording to make the draft suitable for 1468 publication as an Informational RFC. 1470 o Added additional checks that should be performed on ICMP error 1471 messages (checksum of the IP header in the ICMP payload, and 1472 others). 1474 o Added clarification of the rationale behind each the TCP SEQ check 1476 o Miscellaneous editorial changes 1478 E.2. Changes from draft-gont-tcpm-icmp-attacks-04 1480 o Added Appendix C 1482 o Added reference to [I-D.iab-link-indications] 1484 o Added stress on the fact that ICMP error messages are unreliable 1486 o Miscellaneous editorial changes 1488 E.3. Changes from draft-gont-tcpm-icmp-attacks-03 1490 o Added references to existing implementations of the proposed 1491 counter-measures 1493 o The discussion in Section 4 was improved 1495 o The discussion in Section 5.2.1 was expanded and improved 1497 o The proposed counter-measure for the attack against the PMTUD was 1498 improved and simplified 1500 o Appendix B was added 1502 o Miscellaneous editorial changes 1504 E.4. Changes from draft-gont-tcpm-icmp-attacks-02 1506 o Fixed errors in Section 5.2.1 1508 o The proposed counter-measure for the attack against the PMTUD 1509 mechanism was refined to allow quick discovery of the Path-MTU 1511 o Appendix A was added so as to clarify the operation of the 1512 counter-measure for the attack against the PMTUD mechanism 1514 o Added Appendix D 1516 o Miscellaneous editorial changes 1518 E.5. Changes from draft-gont-tcpm-icmp-attacks-01 1520 o The document was restructured for easier reading 1522 o A discussion of ICMPv6 was added in several sections of the 1523 document 1525 o Added Section on Acknowledgement number checking"/> 1527 o Added Section 4.3 1529 o Added Section 7 1531 o Fixed typo in the ICMP types, in several places 1533 o Fixed typo in the TCP sequence number check formula 1535 o Miscellaneous editorial changes 1537 E.6. Changes from draft-gont-tcpm-icmp-attacks-00 1539 o Added a proposal to change the handling of the so-called ICMP hard 1540 errors during the synchronized states 1542 o Added a summary of the relevant RFCs in several sections 1544 o Miscellaneous editorial changes 1546 Author's Address 1548 Fernando Gont 1549 Universidad Tecnologica Nacional 1550 Evaristo Carriego 2644 1551 Haedo, Provincia de Buenos Aires 1706 1552 Argentina 1554 Phone: +54 11 4650 8472 1555 Email: fernando@gont.com.ar 1557 Intellectual Property Statement 1559 The IETF takes no position regarding the validity or scope of any 1560 Intellectual Property Rights or other rights that might be claimed to 1561 pertain to the implementation or use of the technology described in 1562 this document or the extent to which any license under such rights 1563 might or might not be available; nor does it represent that it has 1564 made any independent effort to identify any such rights. Information 1565 on the procedures with respect to rights in RFC documents can be 1566 found in BCP 78 and BCP 79. 1568 Copies of IPR disclosures made to the IETF Secretariat and any 1569 assurances of licenses to be made available, or the result of an 1570 attempt made to obtain a general license or permission for the use of 1571 such proprietary rights by implementers or users of this 1572 specification can be obtained from the IETF on-line IPR repository at 1573 http://www.ietf.org/ipr. 1575 The IETF invites any interested party to bring to its attention any 1576 copyrights, patents or patent applications, or other proprietary 1577 rights that may cover technology that may be required to implement 1578 this standard. Please address the information to the IETF at 1579 ietf-ipr@ietf.org. 1581 Disclaimer of Validity 1583 This document and the information contained herein are provided on an 1584 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 1585 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 1586 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 1587 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 1588 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1589 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1591 Copyright Statement 1593 Copyright (C) The Internet Society (2006). This document is subject 1594 to the rights, licenses and restrictions contained in BCP 78, and 1595 except as set forth therein, the authors retain all their rights. 1597 Acknowledgment 1599 Funding for the RFC Editor function is currently provided by the 1600 Internet Society.