idnits 2.17.00 (12 Aug 2021) /tmp/idnits10821/draft-hubert-dns-anti-spoofing-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 16. -- Found old boilerplate from RFC 3978, Section 5.5 on line 625. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 602. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 609. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 615. ** 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.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. 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 (August 14, 2006) is 5758 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 2821 (Obsoleted by RFC 5321) ** Downref: Normative reference to an Informational RFC: RFC 3833 Summary: 7 errors (**), 0 flaws (~~), 2 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group A. Hubert 3 Internet-Draft Netherlabs Computer Consulting BV. 4 Expires: February 15, 2007 R. van Mook 5 Virtu 6 August 14, 2006 8 Measures to prevent DNS spoofing 9 draft-hubert-dns-anti-spoofing-00.txt 11 Status of this Memo 13 By submitting this Internet-Draft, each author represents that any 14 applicable patent or other IPR claims of which he or she is aware 15 have been or will be disclosed, and any of which he or she becomes 16 aware will be disclosed, in accordance with Section 6 of BCP 79. 18 Internet-Drafts are working documents of the Internet Engineering 19 Task Force (IETF), its areas, and its working groups. Note that 20 other groups may also distribute working documents as Internet- 21 Drafts. 23 Internet-Drafts are draft documents valid for a maximum of six months 24 and may be updated, replaced, or obsoleted by other documents at any 25 time. It is inappropriate to use Internet-Drafts as reference 26 material or to cite them other than as "work in progress." 28 The list of current Internet-Drafts can be accessed at 29 http://www.ietf.org/ietf/1id-abstracts.txt. 31 The list of Internet-Draft Shadow Directories can be accessed at 32 http://www.ietf.org/shadow.html. 34 This Internet-Draft will expire on February 15, 2007. 36 Copyright Notice 38 Copyright (C) The Internet Society (2006). 40 Abstract 42 The current internet climate poses serious threats to the Domain Name 43 System. In the interim period before the DNS protocol can be secured 44 more fully, measures can be taken to make 'spoofing' a recursing 45 nameserver can be made many orders of magnitude harder. This 46 document sets out how to achieve this improved security. 48 Table of Contents 50 1. Requirements and definitions . . . . . . . . . . . . . . . . . 3 51 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 52 3. Description of DNS spoofing . . . . . . . . . . . . . . . . . 6 53 4. Details . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 54 4.1. Matching the question . . . . . . . . . . . . . . . . . . 7 55 4.2. Matching the ID field . . . . . . . . . . . . . . . . . . 8 56 4.3. Matching the source address of the authentic answer . . . 8 57 4.4. Matching the destination address of the authentic 58 answer . . . . . . . . . . . . . . . . . . . . . . . . . . 8 59 4.5. Have the answer arrive before the authentic answer . . . . 9 60 5. Birthday attacks . . . . . . . . . . . . . . . . . . . . . . . 10 61 6. Combined difficulty . . . . . . . . . . . . . . . . . . . . . 11 62 7. Discussion . . . . . . . . . . . . . . . . . . . . . . . . . . 14 63 8. Countermeasures . . . . . . . . . . . . . . . . . . . . . . . 15 64 9. Security Considerations . . . . . . . . . . . . . . . . . . . 16 65 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 17 66 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 17 67 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 18 68 Intellectual Property and Copyright Statements . . . . . . . . . . 19 70 1. Requirements and definitions 72 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 73 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 74 document are to be interpreted as described in [RFC2119]. 76 This document uses the following definitions: 78 Client: typically a 'stub-resolver' on an end-user's computer 80 Resolver: a nameserver performing recursive service for clients, 81 also known as a caching server 83 Question: a question sent out by a resolver, typically in a UDP 84 packet 86 Answer: the answer sent back by an authoritative nameserver, 87 typically in a UDP packet 89 Third party: any host other than the resolver or the intended 90 recipient of a question. The third party may have access to a 91 random authoritative nameserver, but has no access to packets 92 transmitted by the Resolver. 94 Attacker: malicious third party. 96 Spoof: the activity of subverting the DNS process by getting a 97 chosen answer accepted 99 Authentic answer: the answer that would be accepted if no third 100 party interferes 102 Target domain: domain for which the attacker wishes to spoof in an 103 answer 105 Fake data: answer chosen by the attacker 107 2. Introduction 109 This document describes several common problems in DNS 110 implementations which, although previously recognized, remain largely 111 unsolved. Besides briefly recapping these problems, this RFC 112 contains rules that, if implemented, make complying nameservers 113 vastly more resistant to the attacks described. 115 Almost every transaction on the internet involves the Domain Name 116 System, which is described in [RFC1034], [RFC1035] and beyond. 118 Additionally, it has recently become possible to acquire SSL 119 certificates with no other confirmation of identity than the ability 120 to respond to a verification email sent via SMTP ([RFC2821]) - which 121 generally uses DNS for its routing. 123 In other words, any party that (temporarily) controls the Domain Name 124 System is in a position to reroute most kinds of Internet 125 transactions, including the verification steps in acquiring an SSL 126 certificate for a domain. This in turn means that even transactions 127 protected by SSL could be diverted. 129 It is entirely conceivable that such rerouted traffic could be used 130 to the disadvantage of internet users. 132 These and other developments have made the security and 133 trustworthiness of DNS of renewed importance. Although the DNS 134 community is working hard on finalising and implementing a 135 cryptographically enhanced DNS protocol, steps should be taken to 136 make sure that the existing use of DNS is as secure as possible 137 within the bounds of the relevant standards. 139 It should be noted that the most commonly used resolver currently 140 does not perform as well as possible in this respect, making this 141 document of urgent importance. 143 A thorough analysis of risks facing DNS can be found in [RFC3833]. 145 This document expands on some of the risks mentioned in RFC 3833. 146 Furthermore, it emphasises a number of existing rules and guidelines 147 embodied in the relevant STDs and RFCs. The following also specifies 148 new requirements to make sure the Domain Name System can be relied 149 upon until a more secure protocol has been standardised and deployed. 151 It should be noted that even when all measures suggested below are 152 implemented, protocol users are not protected against third parties 153 with the ability to intercept, change or inject packets sent to the 154 resolver. 156 There are protocol extensions under development that offer protection 157 against these scenarios, see [RFC4033] and beyond. 159 This memo is strictly aimed at improving the DNS during the interim 160 period before more structural protocol enhancements can be put in 161 place. 163 3. Description of DNS spoofing 165 When proper steps are taken it is feasible to 'spoof' the current 166 deployed majority of caching servers with carefully crafted and timed 167 DNS packets. Once spoofed, a caching server will repeat the data it 168 wrongfully accepted, and make its clients contact the wrong, and 169 possibly malicious, servers. 171 To understand how this process works it is important to know what 172 makes a name server (and more specifically a caching server) accept 173 an answer. 175 Paragraph 5.3.3 of [RFC1034] presaged the present problem: 177 The resolver should be highly paranoid in its parsing of responses. 178 It should also check that the response matches the query it sent 179 using the ID field in the response. 181 DNS data is accepted by a resolver if and only if: 183 1. The question section of the reply packet is identical to that of 184 a question packet currently waiting for an answer 186 2. The ID field of the reply packet matches that of the question 187 packet 189 3. The answer comes from the same network address the question was 190 sent to 192 4. The answer comes in on the same network address, including port 193 number, as the question was sent from 195 5. It is the first answer to match the previous four conditions. 197 Note that the fifth condition can strictly speaking be derived from 198 the first. It is included for clarity reasons only. 200 If a third party succeeds in meeting the first four conditions before 201 the answer from the authentic answer does so, it is in a position to 202 feed a resolver fabricated data. When it does so, we dub it an 203 attacker, attempting to spoof in fake data. 205 All conditions mentioned above can theoretically be met, with the 206 difficulty being a function of the resolver implementation and zone 207 configuration. 209 4. Details 211 The previous paragraph discussed a number of requirements an attacker 212 must match in order to spoof in manipulated (or fake) data. This 213 section discusses the relative difficulties and how implementation 214 defined choices impact the amount of work an attacker has to perform 215 to meet said difficulties. 217 Some more details can be found in paragraph 2.2 of [RFC3833]. 219 4.1. Matching the question 221 Formally, there is no need for a nameserver to perform service except 222 for its operator, its customers or more generally its users. 223 Recently, open recursing nameservers have been used to amplify denial 224 of service attacks. 226 In spite of this, many resolvers perform at least partial service for 227 the whole world. This is partially out of lack of concern, and is 228 reminiscent of the open relay SMTP service the net enjoyed up to the 229 early 1990s. Some access providers may serve so many subnets that it 230 is hard to enumerate these all in the DNS configuration. 232 Providing full service enables the third party to send the target 233 resolver a question for the domain name it intends to spoof. On 234 receiving this question, and not finding the answer in its cache, the 235 resolver will transmit questions to relevant authoritative 236 nameservers. This opens up a window of opportunity for getting fake 237 answer data accepted. 239 Some operators restrict access by not recursing for unauthorised IP 240 addresses, but only respond with data from the cache. This makes 241 spoofing harder for a third party as it cannot then force the exact 242 moment a question will be asked. It is still possible however to 243 determine a time range when this will happen, because nameservers 244 helpfully publish the decreasing TTL of entries in the cache, which 245 indicate from which absolute time onwards a new query could be sent 246 to refresh the expired entry. 248 The time to live of the 'target domain' determines how often a window 249 of opportunity is available, which implies that a short TTL makes 250 spoofing far more viable. 252 Note that the attacker might very well have authorised access to the 253 target resolver by virtue of being a customer or employee of its 254 operator. 256 4.2. Matching the ID field 258 The DNS ID field is 16 bits wide, meaning that if full use is made of 259 all these bits, and if their contents are truly random, it will 260 require on average 32768 attempts to guess. Anecdotal evidence 261 suggests there are implementations utilising only 14 bits, meaning on 262 average 8192 attempts will suffice. 264 Additionally, if the target nameserver can be forced into having 265 multiple identical questions outstanding, the 'Birthday Attack' 266 phenomenon means that any fake data sent by the attacker is matched 267 against multiple outstanding questions, significantly raising the 268 chance of success. Further details in Section 5. 270 4.3. Matching the source address of the authentic answer 272 Most domains have two or three authoritative nameservers, which make 273 matching the source address of the authentic answer very likely with 274 even a naive choice having a double digit success rate. 276 Most recursing nameservers store relative performance indications of 277 authoritative nameservers, which may make it easier to predict which 278 nameserver would originally be queried - the that is likely to 279 respond the quickest. 281 Generally, this condition requires at most two or three attempts 282 before it is matched. 284 It should be noted that meeting this condition entails being able to 285 transmit packets on behalf of the address of the authoritative 286 nameserver. While several important documents ([RFC2827] and 287 [RFC3013] specifically) direct internet access providers to prevent 288 their customers from assuming IP addresses that are not assigned to 289 them, these recommendations are not universally (nor even widely) 290 implemented. 292 4.4. Matching the destination address of the authentic answer 294 Note that the destination address of the authentic answer is the 295 source address of the original question. 297 The actual address of a recursing nameserver is generally known; the 298 port used for asking questions is harder to determine. Most current 299 resolvers pick a random port at startup and use this for all outgoing 300 questions. In quite a number of cases the source port of outgoing 301 questions is fixed at the traditional DNS assigned port of 53. 303 If the source port of the original question is random, but static, 304 any authoritative nameserver under control of the attacker can be 305 used to determine this port. This means that matching this 306 conditions often requires no guess work. 308 Less common nameservers choose a random port per outgoing question. 309 If this strategy is followed, this port number can be regarded as an 310 additional ID field, again containing around 16 bits. 312 On average, around 32128 source ports would have to be tried before 313 matching that of the original question, as ports below 1024 may be 314 unavailable for use, leaving 64512 options. 316 It should be noted that a firewall will not prevent the matching of 317 this address, as it will accept answers that (appear) to come from 318 the correct address, offering no additional security. 320 4.5. Have the answer arrive before the authentic answer 322 Once any packet has matched the previous four conditions, no further 323 answers should be accepted. 325 This means that the third party has a limited time in which to inject 326 its spoofed answer, typically in the order of at most 100ms. 328 This time period can be far longer if the authentic authoritative 329 nameservers are (briefly) overloaded by queries, perhaps by the 330 attacker. 332 5. Birthday attacks 334 A curious mathematical phenomenon means that a group of 22 people 335 suffices to have a more than even chance at having two or more 336 members of the group share a birthday. 338 An attacker can benefit from this phenomenon if it can force the 339 target resolver to have multiple outstanding questions at any one 340 time for the same domain to the same authoritative server. 342 Any packet the attacker sends then has a much higher chance of being 343 accepted because it only has to match any of the outstanding queries 344 for that single domain. Compared to the birthday analogy above, of 345 the group composed of questions and answers, the chance of having any 346 of these share an ID rises quickly. 348 As long as small numbers of questions are sent out, the chance of 349 successfully spoofing an anwers rises linearly with the number of 350 outstanding questions for the exact domain and nameserver. 352 For larger numbers this effect is less pronounced. 354 More details are available in US-CERT [vu-457875]. 356 6. Combined difficulty 358 Given a known or static destination port, matching ID field, source 359 and destination address requires on average in the order of 2 * 2^15 360 = 65000 packets, assuming a domain has 2 authoritative nameservers. 362 If the window of opportunity available is around 100ms, as assumed 363 above, an attacker would need to be able to briefly transmit 650000 364 packets/s to have a 50% chance to get spoofed data accepted on the 365 first attempt. 367 A realistic minimal DNS answer consists of around 80 bytes, including 368 IP headers, making the packet rate above correspond to a respectable 369 burst of 416Mb/s. 371 As of mid-2006, this kind of bandwidth was not common but not scarce 372 either, especially among those in a position to control many servers. 374 These numbers change when a window of a full second is assumed, 375 possibly because the arrival of the authentic answer can be prevented 376 by overloading the bonafide authoritative servers with decoy 377 questions. This reduces the needed bandwith to 42 Mb/s. 379 If in addition the attacker is granted more than a single chance and 380 allowed up to 60 minutes of work on a domain with a time to live of 381 300 seconds, a meagre 4Mb/s suffices for a 50% chance at getting fake 382 data accepted. Once equipped with a longer time, matching condition 383 1 mentioned above is straightforward - any popular domain will have 384 been queried a number of times within this hour, and given the short 385 TTL, this would lead to questions to authoritative nameservers, 386 opening windows of opportunity. 388 Assume the following symbols are used: 390 I: Number distinct IDs available (maximum 65536) 392 P: Number of ports used (maximum around 64000, but often 1) 394 N: Number of authoritative nameservers for a domain (averages 395 around 2.5) 397 F: Number of 'fake' packets sent by the attacker 399 R: Number of packets sent per second by the attacker 400 W: Window of opportunity, in seconds. Bounded by the response 401 time of the authoritative servers (often 0.1s) 403 D: Average number of identical outstanding questions of a resolver 404 (typically 1, see Section 5) 406 A: Number of attempts, one for each window of opportunity 408 The probability of spoofing a resolver is equal to amount of fake 409 packets that arrive within the window of opportunity, divided by the 410 size of the problem space. 412 When the resolver has 'D' multiple identical outstanding questions, 413 each fake packet has a proportionally higher chance of matching any 414 of these questions. This assumption only holds for small values of 415 'D'. 417 In symbols, if the probability of being spoofed is denoted as P_s: 419 D * F 420 P_s = --------- 421 N * P * I 423 It is more useful to reason not in terms of aggregate packets but to 424 convert to packet rate, which can easily be converted to bandwidth if 425 needed. 427 If the Window of opportunity length is 'W' and the attacker can send 428 'R' packets per second, the number of fake packets 'F' that are 429 candidates to be accepted is: 431 D * R * W 432 F = R * W -> P_s = ---------- 433 N * P * I 435 Finally, to calculate the combined chance 'P_cs' of spoofing over a 436 chosen time period 'T', it should be realised that the attacker has a 437 new window of opportunity each time the TTL 'TTL' of the target 438 domain expires. This means that the number of attempts 'A' is equal 439 to 'T / TTL'. 441 To calculate the combined chance of at least one success, the 442 following formula holds: 444 (T / TTL) 445 A ( D * R * W ) 446 P_cs = 1 - ( 1 - P_s ) = 1 - ( 1 - --------- ) 447 ( N * P * I ) 449 When common numbers (as listed above) for D, W, N, P and I are 450 inserted, this formula reduces to: 452 (T / TTL) 453 ( R ) 454 P_cs = 1 - ( 1 - ------- ) 455 ( 1638400 ) 457 From this formula it can be seen that, if the nameserver 458 implementation is unchanged, only raising the TTL offers protection. 459 Raising N, the number of authoritative nameservers, is not feasible 460 beyond a small number. 462 For the degenerate case of a zero-second TTL, a window of opportunity 463 opens for each question asked, making the effective TTL equal to 'W' 464 above, the response time of the authoritative server. 466 7. Discussion 468 The calculations above indicate the relative ease with which DNS data 469 can be spoofed. For example, using the formula derived earlier on a 470 domain with a 3600 second TTL, an attacker sending 7000 fake answer 471 packets/s (a rate of 4.5Mb/s), stands a 10% chance of spoofing a 472 record in the first 24 hours, which rises to 50% after a week. 474 For a domain with a TTL of 60 seconds, the 10% level is hit after 24 475 minutes, 50% after less than 3 hours, 90% after around 9 hours. 477 Note that the attacks mentioned above can be detected by watchful 478 server operators - an unexpected incoming stream of 4.5mbit/s of 479 packets might be noticed. 481 An important assumption however in these calculations is a known or 482 static destination port of the authentic answer. 484 If that port number is unknown and needs to be guessed as well, the 485 problem space expands by a factor of 64000, leading the attacker to 486 need in excess of 285Gb/s to achieve similar success rates. 488 Such bandwidth is not generally available, nor expected to be so in 489 the foreseeable future. 491 Note that some firewalls may need reconfiguring if they are currently 492 setup to only allow outgoing queries from a single DNS source port. 494 8. Countermeasures 496 Given the above, a resolver MUST: 498 o Use a new random source port from its available range for each 499 outgoing query 501 o Make full use of all 16 bits of the ID field 503 o Assure that its choices of port and ID cannot be predicted by an 504 attacker having knowledge of its (pseudo-)random generator 506 o Take measures to prevent having multiple equivalent questions 507 outstanding to any authoritative server 509 A resolver SHOULD offer diagnostics that enable the operator to 510 determine a spoofing attempt is under way. 512 Operators SHOULD attempt to restrict recursing service, either full 513 or partial, to authorised users. 515 A resolver MAY use heuristics to detect an excess of unacceptable 516 answers and take measures if it believes an attempt is made to spoof 517 it. 519 Futhermore, zone operators SHOULD NOT configure the Time To Live of 520 domains to be lower than realistically needed for proper operations. 522 9. Security Considerations 524 This document directly impacts the operational security of the Domain 525 Name System, readers are urged to implement its recommendations. 527 10. Acknowledgements 529 Although any mistakes remain our own, the authors gratefully 530 acknowledge the help and contributions of: 532 Stephane Bortzmeyer, 534 Sean Leach, 536 Norbert Sendetzky 538 Furthermore, it should be noted that source port randomisation was 539 first implemented by Dan J. Bernstein. 541 11. References 543 [RFC1034] Mockapetris, P., "Domain names - concepts and facilities", 544 STD 13, RFC 1034, November 1987. 546 [RFC1035] Mockapetris, P., "Domain names - implementation and 547 specification", STD 13, RFC 1035, November 1987. 549 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 550 Requirement Levels", BCP 14, RFC 2119, March 1997. 552 [RFC2821] Klensin, J., "Simple Mail Transfer Protocol", RFC 2821, 553 April 2001. 555 [RFC2827] Ferguson, P. and D. Senie, "Network Ingress Filtering: 556 Defeating Denial of Service Attacks which employ IP Source 557 Address Spoofing", BCP 38, RFC 2827, May 2000. 559 [RFC3013] Killalea, T., "Recommended Internet Service Provider 560 Security Services and Procedures", BCP 46, RFC 3013, 561 November 2000. 563 [RFC3833] Atkins, D. and R. Austein, "Threat Analysis of the Domain 564 Name System (DNS)", RFC 3833, August 2004. 566 [RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S. 567 Rose, "DNS Security Introduction and Requirements", 568 RFC 4033, March 2005. 570 [vu-457875] 571 United States CERT, "Various DNS service implementations 572 generate multiple simultaneous queries for the same 573 resource record", VU 457875, November 2002. 575 Authors' Addresses 577 bert hubert 578 Netherlabs Computer Consulting BV. 579 Donkerstraat 9a 580 Delft 2611 TE 581 The Netherlands 583 Email: bert.hubert@netherlabs.nl 585 Remco van Mook 586 Virtu 587 Auke Vleerstraat 1 588 Enschede 7521 PE 589 The Netherlands 591 Email: remco@virtu.nl 593 Intellectual Property Statement 595 The IETF takes no position regarding the validity or scope of any 596 Intellectual Property Rights or other rights that might be claimed to 597 pertain to the implementation or use of the technology described in 598 this document or the extent to which any license under such rights 599 might or might not be available; nor does it represent that it has 600 made any independent effort to identify any such rights. Information 601 on the procedures with respect to rights in RFC documents can be 602 found in BCP 78 and BCP 79. 604 Copies of IPR disclosures made to the IETF Secretariat and any 605 assurances of licenses to be made available, or the result of an 606 attempt made to obtain a general license or permission for the use of 607 such proprietary rights by implementers or users of this 608 specification can be obtained from the IETF on-line IPR repository at 609 http://www.ietf.org/ipr. 611 The IETF invites any interested party to bring to its attention any 612 copyrights, patents or patent applications, or other proprietary 613 rights that may cover technology that may be required to implement 614 this standard. Please address the information to the IETF at 615 ietf-ipr@ietf.org. 617 Disclaimer of Validity 619 This document and the information contained herein are provided on an 620 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 621 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 622 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 623 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 624 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 625 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 627 Copyright Statement 629 Copyright (C) The Internet Society (2006). This document is subject 630 to the rights, licenses and restrictions contained in BCP 78, and 631 except as set forth therein, the authors retain all their rights. 633 Acknowledgment 635 Funding for the RFC Editor function is currently provided by the 636 Internet Society.