idnits 2.17.1 draft-gont-tcpm-icmp-attacks-01.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.a on line 19. -- Found old boilerplate from RFC 3978, Section 5.5 on line 518. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 495. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 502. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 508. ** The document seems to lack an RFC 3978 Section 5.1 IPR Disclosure Acknowledgement. ** 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. ** The document uses RFC 3667 boilerplate or RFC 3978-like boilerplate instead of verbatim RFC 3978 boilerplate. After 6 May 2005, submission of drafts without verbatim RFC 3978 boilerplate is not accepted. The following non-3978 patterns matched text found in the document. That text should be removed or replaced: This document is an Internet-Draft and is subject to all provisions of Section 3 of RFC 3667. By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. 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 (September 9, 2004) is 7169 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 (ref. '1') (Obsoleted by RFC 9293) -- Obsolete informational reference (is this intentional?): RFC 1323 (ref. '7') (Obsoleted by RFC 7323) == Outdated reference: A later version (-13) exists of draft-ietf-tcpm-tcpsecure-01 == Outdated reference: A later version (-01) exists of draft-poon-tcp-tstamp-mod-00 -- Obsolete informational reference (is this intentional?): RFC 816 (ref. '11') (Obsoleted by RFC 7805) -- Obsolete informational reference (is this intentional?): RFC 2401 (ref. '12') (Obsoleted by RFC 4301) -- Obsolete informational reference (is this intentional?): RFC 2581 (ref. '14') (Obsoleted by RFC 5681) == Outdated reference: A later version (-02) exists of draft-gont-tcpm-tcp-soft-errors-00 Summary: 7 errors (**), 0 flaws (~~), 5 warnings (==), 11 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 September 9, 2004 5 Expires: March 10, 2005 7 ICMP attacks against TCP 8 draft-gont-tcpm-icmp-attacks-01.txt 10 Status of this Memo 12 This document is an Internet-Draft and is subject to all provisions 13 of section 3 of RFC 3667. By submitting this Internet-Draft, each 14 author represents that any applicable patent or other IPR claims of 15 which he or she is aware have been or will be disclosed, and any of 16 which he or she become aware will be disclosed, in accordance with 17 RFC 3668. This document may not be modified, and derivative works of 18 it may not be created, except to publish it as an RFC and to 19 translate it into languages other than English. 21 Internet-Drafts are working documents of the Internet Engineering 22 Task Force (IETF), its areas, and its working groups. Note that 23 other groups may also distribute working documents as 24 Internet-Drafts. 26 Internet-Drafts are draft documents valid for a maximum of six months 27 and may be updated, replaced, or obsoleted by other documents at any 28 time. It is inappropriate to use Internet-Drafts as reference 29 material or to cite them other than as "work in progress." 31 The list of current Internet-Drafts can be accessed at 32 http://www.ietf.org/ietf/1id-abstracts.txt. 34 The list of Internet-Draft Shadow Directories can be accessed at 35 http://www.ietf.org/shadow.html. 37 This Internet-Draft will expire on March 10, 2005. 39 Copyright Notice 41 Copyright (C) The Internet Society (2004). 43 Abstract 45 This document discusses the use of the Internet Control Message 46 Protocol (ICMP) to perform a variety of attacks against the 47 Transmission Control Protocol (TCP) and other similar protocols. It 48 proposes a work-around to eliminate or minimize the impact of this 49 type of attack. 51 Table of Contents 53 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 54 2. Background . . . . . . . . . . . . . . . . . . . . . . . . . . 3 55 2.1 Internet Control Message Protocol (ICMP) . . . . . . . . . 3 56 2.2 Handling of ICMP errors . . . . . . . . . . . . . . . . . 4 57 3. ICMP attacks against TCP . . . . . . . . . . . . . . . . . . . 5 58 3.1 Blind connection-reset attacks . . . . . . . . . . . . . . 5 59 3.2 Degrading the performance of a connection . . . . . . . . 6 60 4. Constraints in the possible solutions . . . . . . . . . . . . 6 61 5. Solutions to the problem . . . . . . . . . . . . . . . . . . . 6 62 5.1 TCP sequence number checking . . . . . . . . . . . . . . . 6 63 5.2 Delaying the connection-reset . . . . . . . . . . . . . . 7 64 5.3 Changing the handling of ICMP error messages for 65 connections in the synchronized states . . . . . . . . . . 7 66 5.3.1 ICMP type 2 (Destination Unreachable), code 2 67 (protocol unreachable) . . . . . . . . . . . . . . . . 7 68 5.3.2 ICMP type 2 (Destination Unreachable), code 3 69 (port unreachable) . . . . . . . . . . . . . . . . . . 8 70 5.3.3 ICMP type 2 (Destination Unreachable), code 4 71 (fragmentation needed and DF bit set) . . . . . . . . 8 72 5.4 Ignoring ICMP Source Quench messages . . . . . . . . . . . 8 73 5.5 Port randomization . . . . . . . . . . . . . . . . . . . . 8 74 5.6 Authentication . . . . . . . . . . . . . . . . . . . . . . 9 75 6. Future work . . . . . . . . . . . . . . . . . . . . . . . . . 9 76 7. Security Considerations . . . . . . . . . . . . . . . . . . . 9 77 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 9 78 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 9 79 9.1 Normative References . . . . . . . . . . . . . . . . . . . . 9 80 9.2 Informative References . . . . . . . . . . . . . . . . . . . 10 81 Author's Address . . . . . . . . . . . . . . . . . . . . . . . 11 82 A. Changes from draft-gont-tcpm-icmp-attacks-00 . . . . . . . . . 11 83 Intellectual Property and Copyright Statements . . . . . . . . 12 85 1. Introduction 87 Recently, awareness has been raised about several threats against the 88 TCP [1] protocol, which include blind connection-reset attacks [6]. 89 These attacks are based on sending forged TCP segments to any of the 90 TCP endpoints, requiring the attacker to be able to guess the 91 four-tuple that identifies the connection to be attacked. 93 While these attacks were known by the research community, they were 94 considered to be unfeasible. However, increases in bandwidth 95 availability, and the use of larger TCP windows [7] have made these 96 attacks feasible. Several solutions have been proposed to either 97 eliminate or minimize the impact of these attacks [8][9][10]. 99 However, there is still a possibility for performing a number of 100 attacks against the TCP protocol, by means of ICMP [2]. These 101 attacks include, among others, blind connection-reset attacks. 103 This document aims to raise awareness of the use of ICMP to perform a 104 number of attacks against TCP, and proposes several counter-measures 105 that can eliminate or minimize the impact of these attacks. 107 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 108 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 109 document are to be interpreted as described in RFC 2119 [3]. 111 2. Background 113 2.1 Internet Control Message Protocol (ICMP) 115 The Internet Control Message Protocol (ICMP) is used by the Internet 116 Architecture to perform the fault-isolation function, that is, the 117 group of actions that hosts and routers take to determine that there 118 is some network failure [11]. 120 When an intermediate router detects a network problem while trying to 121 forward an IP packet, it will send an ICMP error message to the 122 source host, to raise awareness of the network problem. In the same 123 way, there are a number of cases in which an end-system may generate 124 an ICMP error message when it finds a problem while processing a 125 datagram. 127 The internet header plus the first 64 bits of the packet that 128 elicited the ICMP message are included in the payload of the ICMP 129 error message, so that the receiving host can match the error to the 130 instance of the transport protocol that elicited the error message. 131 Thus, it is assumed that all data needed to identify a transport 132 protocol instance is contained in the first 64 bits of the transport 133 protocol header. 135 When the transport protocol is notified of the error condition, it 136 will perform a fault recovery function. That is, it will try to 137 survive the network failure. 139 In the case of TCP, the fault recovery policy is as follows: 141 o If the network problem being reported is a hard error, abort the 142 corresponding connection. 144 o If the network problem being reported is a soft error, just record 145 this information, and repeatedly retransmit the segment until 146 either it gets acknowledged, or the connection times out. 148 The Host Requirements RFC [4] defines "hard errors" as ICMP error 149 messages of type 3 (Destination Unreachable) codes 2 (protocol 150 unreachable), 3 (port unreachable), and 4 (fragmentation needed and 151 DF bit set). Thus, any of these ICMP messages could elicit a 152 connection abort. 154 [12] provides information about which ICMP error messages are 155 produced by hosts, intermediate routers, or both. 157 2.2 Handling of ICMP errors 159 The Host Requirements RFC [4] states that a TCP instance should be 160 notified of ICMP error messages received for its corresponding 161 connection. However, neither the Host Requirements RFC nor the 162 original TCP specification [1] recommend any additional security 163 checks on the received ICMP messages. 165 Therefore, as long as the ICMP payload contains the correct 166 four-tuple that identifies the communication instance, it will be 167 processed by the corresponding transport-protocol instance, and the 168 corresponding action will be performed. 170 Thus, in order to perform any of the attacks discussed in this 171 document, an attacker only needs to guess the four-tuple that 172 identifies the communication instance to be attacked. As discussed 173 in [6], there are a number of scenarios in which an attacker may be 174 able to know or guess this four-tuple. 176 Furthermore, it must be noted that most services use the so-called 177 "well-known" ports, so that only the client port would need to be 178 guessed. In the event that an attacker had no knowledge about the 179 range of port numbers used by clients, this would mean that an 180 attacker would need to send, at most, 65535 packets to perform any of 181 the attacks described in this document. 183 It is clear that additional security checks should be performed on 184 the received ICMP error messages. 186 3. ICMP attacks against TCP 188 ICMP messages can be used to perform a variety of attacks. These 189 attacks have been discussed by the research community to a large 190 extent. 192 Some TCP/IP implementations have added extra security checks on the 193 received ICMP error messages to minimize the impact of these attacks. 194 However, as there has not been any official proposal about what would 195 be the best way to deal with these attacks, these additional security 196 checks have not been widely implemented. 198 The following subsections discuss some of the possible attacks, and 199 propose work-arounds to eliminate or minimize the impact of these 200 attacks. 202 3.1 Blind connection-reset attacks 204 The Host Requirements RFC [4] states that a host SHOULD abort the 205 corresponding connection when receiving an ICMP error message that 206 indicates a hard error. 208 For ICMP messages of type 2 (Destination Unreachable) code 2 209 (protocol unreachable), specifically, the Host Requirements RFC 210 states that even those transport protocols that have their own 211 mechanisms to indicate that a port is unreachable MUST accept these 212 ICMP error messages for the same purpose. That is, they MUST abort 213 the corresponding connection when an ICMP port unreachable message is 214 received. 216 Thus, an attacker could use ICMP to perform a blind connection-reset 217 attack. That is, even being off-path, an attacker could reset any 218 TCP connection taking place. In order to perform such an attack, an 219 attacker would send any ICMP error message that indicates a "hard 220 error", to either of the two TCP endpoints of the connection. 221 Because of TCP's fault recovery policy, the connection would be 222 immediately aborted. 224 All an attacker needs to know to perform such an attack is the socket 225 pair that identifies the TCP connection to be attacked. In some 226 scenarios, the IP addresses and port numbers in use may be easily 227 guessed or known to the attacker [6]. 229 There are some points to be considered about this type of attack: 231 o The source address of the ICMP error message need not be forged. 232 Thus, simple egress-filtering based on the source address of IP 233 packets would not serve as a counter-measure against this type of 234 attack. 236 o Even if TCP itself were protected against the blind 237 connection-reset attack described in [6] and [8], the type of 238 attack described in this document could still succeed. 240 3.2 Degrading the performance of a connection 242 The Host requirements RFC states hosts MUST react to ICMP Source 243 Quench messages by slowing transmission on the connection. Thus, an 244 attacker could send ICMP Source Quench [2] messages to a TCP endpoint 245 to make it reduce the rate at which it sends data to the other party. 246 While this would not reset the connection, it would certainly degrade 247 the performance of the data transfer taking place over it. 249 4. Constraints in the possible solutions 251 The original ICMP specification [2] requires nodes generating ICMP 252 errors to include the IP header of the packet that elicited the ICMP 253 error message, plus the first 64 bits of its payload, in the payload 254 of the ICMP error message. For TCP, that means that the only fields 255 that will be included are: the source port number, the destination 256 port number, and the 32-bit sequence number. This imposes a 257 constraint on the possible solutions, as there is not much 258 information avalable on which to perform additional security checks. 259 While there exists a proposal to recommend hosts to include more data 260 from the original datagram in the payload of ICMP error messages 261 [13], we cannot yet propose any work-around based on any data past 262 the first 64 bits of the payload of the original IP datagram that 263 elicited the ICMP error message. 265 5. Solutions to the problem 267 There are a number of counter-measures against this type of attack. 268 Rather than being alternative measures, they could be implemented 269 together to increase the protection against this type of attack. 271 5.1 TCP sequence number checking 273 TCP SHOULD check that the sequence number in the TCP header contained 274 in the payload of the ICMP error message is within the range SND.UNA 275 < SEG.SEQ < SND.NXT. This means that the sequence number should be 276 within the range of the data already sent but not yet acknowledged. 277 If an ICMP error message doesn't pass this check, it SHOULD be 278 discarded. 280 Even if an attacker were able to guess the four-tuple that identifies 281 the TCP connection, this additional check would reduce the 282 possibility of success of the attacker to Flight_Size/2^^32 (where 283 Flight_Size is the number of data bytes already sent to the remote 284 peer, but not yet acknowledged [14]). For connections in the 285 SYN-SENT or SYN-RECEIVED states, this would reduce the probability of 286 success of a blind-connection reset attack during the 287 connection-establishment phase to 1/2^^32. For a TCP endpoint with 288 no data "in flight", this would completely eliminate the possibility 289 of success of this attack. 291 5.2 Delaying the connection-reset 293 For connections in any of the synchronized states, an additional 294 counter-measure against the blind connection-reset attack could be 295 taken. Rather than immediately aborting a connection, a TCP could 296 abort a connection only after an ICMP error message indicating a hard 297 error has been received a specified number of times, and the 298 corresponding data have already been retransmitted more than some 299 specified number of times. 301 For example, hosts could abort connections only after a fourth ICMP 302 error message indicating a hard error is received, and the 303 corresponding data have already been retransmitted more than six 304 times. 306 The rationale behind this proposed fix is that if a host can make 307 forward progress on a connection, it can completely disregard the 308 "hard errors" being indicated by the received ICMP error messages. 310 5.3 Changing the handling of ICMP error messages for connections in the 311 synchronized states 313 An analysis of the circumstances in which ICMP messages that indicate 314 hard errors may be received can shed some light to minimize (or even 315 eliminate) the impact of blind connection-reset attacks. 317 5.3.1 ICMP type 2 (Destination Unreachable), code 2 (protocol 318 unreachable) 320 This ICMP error message indicates that the host sending the ICMP 321 error message received a packet meant for a transport protocol it 322 does not support. For connection-oriented protocols such as TCP, one 323 could expect to receive such an error as the result of a connection 324 request. However, it would be strange to get such an error during 325 the life of a connection, as this would indicate that support for 326 that transport protocol has been removed from the host sending the 327 error message during the life of the corresponding connection. Thus, 328 it would be fair to ignore ICMP protocol unreachable error messages 329 meant for connections that are in synchronized states. For TCP, this 330 would mean one would ignore ICMP port unreachable error messages 331 meant for connections that are in the ESTABLISHED, FIN-WAIT-1, 332 FIN-WAIT-2, CLOSE-WAIT, CLOSING, LAST-ACK or TIME-WAIT states. 334 5.3.2 ICMP type 2 (Destination Unreachable), code 3 (port unreachable) 336 This error message indicates that the host sending the ICMP error 337 message received a packet meant for a socket (IP address, port 338 number) on which there is no process listening. Those transport 339 protocols which have their own mechanisms for notifying this 340 condition should not be receiving these error messages. However, the 341 Host Requirements RFC [4] states that even those transport protocols 342 that have their own mechanism for notifying the sender that a port is 343 unreachable MUST nevertheless accept an ICMP Port Unreachable for the 344 same purpose. For security reasons, it would be fair to ignore ICMP 345 port unreachable messages that are meant for protocols that have 346 their own mechanisms for reporting this condition. 348 5.3.3 ICMP type 2 (Destination Unreachable), code 4 (fragmentation 349 needed and DF bit set) 351 This error message indicates that an intermediate node needed to 352 fragment a datagram, but the DF (Don't Fragment) bit in the IP header 353 was set. Those TCP/IP stacks implementing the Path-MTU Discovery 354 (PMTUD) mechanism [5] should not abort the corresponding connection 355 when such an error message is received. 357 5.4 Ignoring ICMP Source Quench messages 359 The Host Requirements RFC [4] states that hosts MUST react to ICMP 360 Source Quench messages by slowing transmission on the connection. 361 However, as discussed in the Requirements for IP Version 4 Routers 362 RFC [15], research seems to suggest ICMP Source Quench is an 363 ineffective (and unfair) antidote for congestion. Thus, we recommend 364 hosts to completely ignore ICMP Source Quench messages. 366 5.5 Port randomization 368 As discussed in the previous sections, in order to perform any of the 369 attacks described in this document, an attacker needs to guess (or 370 know) the four-tuple that identifies the connection to be attacked. 371 Randomizing the ephemeral ports used by the clients would reduce the 372 chances of success by an attacker. 374 A proposal exists to enable TCP to reassign a well-known port number 375 to a random value [16]. 377 5.6 Authentication 379 Hosts could require ICMP error messages to be authenticated [12], in 380 order to act upon them. However, while this requirement could make 381 sense for those ICMP error messages sent by hosts, it would not be 382 feasible for those ICMP error messages generated by intermediate 383 routers. 385 [12] contains a discussion on the authentication of ICMP messages. 387 6. Future work 389 The same considerations discussed in this document should be applied 390 to other similar protocols. 392 7. Security Considerations 394 This document describes the use of ICMP error messages to perform a 395 number of attacks against the TCP protocol, and proposes a number of 396 counter-measures that either eliminate or reduce the impact of these 397 attacks. 399 8. Acknowledgements 401 This document was inspired by Mikka Liljeberg, while discussing some 402 issues related to [17] by private e-mail. The author would like to 403 thank James Carlson, Juan Fraschini, Markus Friedl, Guillermo Gont, 404 Michael Kerrisk, Kacheong Poon, and Andrew Powell, for contributing 405 many valuable comments. 407 9. References 409 9.1 Normative References 411 [1] Postel, J., "Transmission Control Protocol", STD 7, RFC 793, 412 September 1981. 414 [2] Postel, J., "Internet Control Message Protocol", STD 5, RFC 792, 415 September 1981. 417 [3] Bradner, S., "Key words for use in RFCs to Indicate Requirement 418 Levels", BCP 14, RFC 2119, March 1997. 420 [4] Braden, R., "Requirements for Internet Hosts - Communication 421 Layers", STD 3, RFC 1122, October 1989. 423 [5] Mogul, J. and S. Deering, "Path MTU discovery", RFC 1191, 424 November 1990. 426 9.2 Informative References 428 [6] Watson, P., "Slipping in the Window: TCP Reset Attacks", 2004 429 CanSecWest Conference , 2004. 431 [7] Jacobson, V., Braden, B. and D. Borman, "TCP Extensions for 432 High Performance", RFC 1323, May 1992. 434 [8] Stewart, R., "Transmission Control Protocol security 435 considerations", draft-ietf-tcpm-tcpsecure-01 (work in 436 progress), June 2004. 438 [9] Touch, J., "ANONsec: Anonymous IPsec to Defend Against Spoofing 439 Attacks", draft-touch-anonsec-00 (work in progress), May 2004. 441 [10] Poon, K., "Use of TCP timestamp option to defend against blind 442 spoofing attack", draft-poon-tcp-tstamp-mod-00 (work in 443 progress), June 2004. 445 [11] Clark, D., "Fault isolation and recovery", RFC 816, July 1982. 447 [12] Kent, S. and R. Atkinson, "Security Architecture for the 448 Internet Protocol", RFC 2401, November 1998. 450 [13] Gont, F., "Increasing the payload of ICMP error messages", 451 (work in progress) draft-gont-icmp-payload-00.txt, 2004. 453 [14] Allman, M., Paxson, V. and W. Stevens, "TCP Congestion 454 Control", RFC 2581, April 1999. 456 [15] Baker, F., "Requirements for IP Version 4 Routers", RFC 1812, 457 June 1995. 459 [16] Shepard, T., "Reassign Port Number option for TCP", 460 draft-shepard-tcp-reassign-port-number-00 (work in progress), 461 July 2004. 463 [17] Gont, F., "TCP's Reaction to Soft Errors", 464 draft-gont-tcpm-tcp-soft-errors-00 (work in progress), June 465 2004. 467 Author's Address 469 Fernando Gont 470 Universidad Tecnologica Nacional 471 Evaristo Carriego 2644 472 Haedo, Provincia de Buenos Aires 1706 473 Argentina 475 Phone: +54 11 4650 8472 476 EMail: fernando@gont.com.ar 478 Appendix A. Changes from draft-gont-tcpm-icmp-attacks-00 480 o Added Section 5.3 482 o Added a summary of the relevant RFCs in several sections 484 o Miscellaneous editorial changes 486 Intellectual Property Statement 488 The IETF takes no position regarding the validity or scope of any 489 Intellectual Property Rights or other rights that might be claimed to 490 pertain to the implementation or use of the technology described in 491 this document or the extent to which any license under such rights 492 might or might not be available; nor does it represent that it has 493 made any independent effort to identify any such rights. Information 494 on the procedures with respect to rights in RFC documents can be 495 found in BCP 78 and BCP 79. 497 Copies of IPR disclosures made to the IETF Secretariat and any 498 assurances of licenses to be made available, or the result of an 499 attempt made to obtain a general license or permission for the use of 500 such proprietary rights by implementers or users of this 501 specification can be obtained from the IETF on-line IPR repository at 502 http://www.ietf.org/ipr. 504 The IETF invites any interested party to bring to its attention any 505 copyrights, patents or patent applications, or other proprietary 506 rights that may cover technology that may be required to implement 507 this standard. Please address the information to the IETF at 508 ietf-ipr@ietf.org. 510 Disclaimer of Validity 512 This document and the information contained herein are provided on an 513 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 514 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 515 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 516 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 517 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 518 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 520 Copyright Statement 522 Copyright (C) The Internet Society (2004). This document is subject 523 to the rights, licenses and restrictions contained in BCP 78, and 524 except as set forth therein, the authors retain all their rights. 526 Acknowledgment 528 Funding for the RFC Editor function is currently provided by the 529 Internet Society.