idnits 2.17.1 draft-ietf-dnsext-delegation-signer-04.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? == 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 Introduction section. ** The document seems to lack a Security Considerations section. ** 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 a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 157: '...in a secure zone MUST contain a DS RR ...' RFC 2119 keyword, line 160: '...ld zone is unsecure. DS sets MUST NOT...' RFC 2119 keyword, line 163: '... In a zone that uses DS, insecure delegations MUST have the NODS[TBD]...' RFC 2119 keyword, line 169: '...Delegating zones MUST NOT store KEY re...' RFC 2119 keyword, line 173: '... Zone MUST self sign its apex KEY set...' (14 more instances...) -- The abstract seems to indicate that this document updates RFC1035, but the header doesn't have an 'Updates:' line to match this. -- The abstract seems to indicate that this document updates RFC2535, but the header doesn't have an 'Updates:' line to match this. -- The abstract seems to indicate that this document updates RFC3008, but the header doesn't have an 'Updates:' line to match this. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == The "Author's Address" (or "Authors' Addresses") section title is misspelled. == The expression 'MAY NOT', while looking like RFC 2119 requirements text, is not defined in RFC 2119, and should not be used. Consider using 'MUST NOT' instead (if that is what you mean). Found 'MAY NOT' in this paragraph: The key words "MAY","MAY NOT", "MUST", "MUST NOT", "REQUIRED", "RECOMMENDED", "SHOULD", and "SHOULD NOT" in this document are to be interpreted as described in RFC2119. -- 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 (November 2001) is 8198 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) -- Missing reference section? 'RFC1035' on line 426 looks like a reference -- Missing reference section? 'RFC2535' on line 429 looks like a reference -- Missing reference section? 'RFC3090' on line 435 looks like a reference -- Missing reference section? 'RFC3008' on line 432 looks like a reference -- Missing reference section? 'Parent' on line 441 looks like a reference -- Missing reference section? 'TBD' on line 163 looks like a reference -- Missing reference section? 'OKbit' on line 438 looks like a reference Summary: 6 errors (**), 0 flaws (~~), 4 warnings (==), 12 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 DNSEXT Working Group Olafur Gudmundsson 3 INTERNET-DRAFT November 2001 4 6 Updates: RFC 1035, RFC 2535, RFC 3008. 8 Delegation Signer record in parent. 10 Status of this Memo 12 This document is an Internet-Draft and is in full conformance with all 13 provisions of Section 10 of RFC2026. 15 Internet-Drafts are working documents of the Internet Engineering Task 16 Force (IETF), its areas, and its working groups. Note that other 17 groups may also distribute working documents as Internet-Drafts. 19 Internet-Drafts are draft documents valid for a maximum of six months 20 and may be updated, replaced, or obsoleted by other documents at any 21 time. It is inappropriate to use Internet-Drafts as reference 22 material or to cite them other than as ``work in progress.'' 24 The list of current Internet-Drafts can be accessed at 25 http://www.ietf.org/ietf/1id-abstracts.txt 27 The list of Internet-Draft Shadow Directories can be accessed at 28 http://www.ietf.org/shadow.html 30 Comments should be sent to the authors or the DNSEXT WG mailing list 31 namedroppers@ops.ietf.org 33 This draft expires on May 20, 2002. 35 Copyright Notice 37 Copyright (C) The Internet Society (2001). All rights reserved. 39 Abstract 41 The Delegation Signer (DS) RR set is stored in a delegating (parent) 42 zone at each delegation point, and indicates the keys used in the 43 delegated (child) zone. The main design goal of the DS RR simplify the 44 operation of secure delegations by eliminating the need to store the 45 same RR in parent and child, as is done with the NS RR set and the KEY 46 set in RFC2535. 47 Secure resolvers need to take an additional step with DS to verify a 48 child's KEY RR set. Operationally this schema is much simpler as 49 operation of the two zones at delegation is now decoupled to great 50 extent. 51 This document updates RFC1035, RFC2535 and RFC3008. 53 1 - Introduction 55 Familiarity with the DNS system [RFC1035], DNS security extensions 56 [RFC2535] and DNSSEC terminology [RFC3090] is important. 58 When the same data can reside in two administratively different DNS 59 zones, the data frequently gets out of sync. NS record in a zone 60 indicates that this name is a delegation and the NS record lists the 61 authorative servers for the real zone. Based on actual measurements 62 10-30% of all delegations in the Internet have differing NS sets at 63 parent and child. There are number of reasons for this, including lack 64 of communication between parent and child and bogus name-servers being 65 listed to meet registrar requirements. 67 DNSSEC [RFC2535,RFC3008,RFC3090] specifies that child must have its 68 KEY set signed by the parent to create a verifiable chain of KEYs. 69 There is some debate, where the signed KEY set should reside, 70 parent[Parent] or child[RFC2535]. If the KEY set resides at the child, 71 frequent two way communication is needed between the two parties. 72 First the child needs to transmit the key set to parent and then the 73 parent sends the signed set or signatures to child. If the KEY set 74 resides at the parent the communication is reduced as the child only 75 sends changed key sets to parent. 77 DNSSEC[RFC2535] requires that the parent store NULL key set for 78 unsecure children, this complicates resolution process in many cases 79 as servers for both parent and child need to be queried for KEY set if 80 the child server does not return a KEY set. Storing the KEY record 81 only in the parent zone simplifies this and allows the elimination of 82 the NULL key set. 84 Another complication of the DNSSEC KEY model is that KEY record is 85 used to store DNS zone keys and public keys for other protocols. 86 There are number of potential problems with this including: 87 1. KEY set can become quite large if many applications/protocols 88 store their keys at the zone apex. Possible protocols are IPSEC, 89 HTTP, SMTP, SSH and others that use public key cryptography. 90 2. Key set may require frequent updates. 91 3. Probability of compromised/lost keys increases and triggers 92 emergency key rollover procedures. 94 4. Parent may refuse sign key sets with NON DNS zone keys. 95 5. Parent may not meet the child's expectations in turnaround time 96 in resigning the key set. 98 Given these and other reasons there is good reason to explore 99 alternatives to using only KEY records to create chain of trust. 101 Some of these problems can be reduced or eliminated by operational 102 rules or protocol changes. To reduce the number of keys at apex, a 103 rule to require applications to store their KEY records at the SRV 104 name for that application is one possibility. Another is to restrict 105 KEY record to DNS keys only and create a new type for all non DNS 106 keys. Third possible solution is to ban the storage of non DNS related 107 keys at zone apex. There are other possible solutions but they are 108 outside the scope of this document. 110 1.2 - Reserved words 112 The key words "MAY","MAY NOT", "MUST", "MUST NOT", "REQUIRED", 113 "RECOMMENDED", "SHOULD", and "SHOULD NOT" in this document are to be 114 interpreted as described in RFC2119. 116 2 - DS (Delegation KEY Signer) 118 2.1 - Delegation Signer Record model 120 This document proposes an alternative to the KEY record chain of 121 trust, that uses a special record that can only reside at the parent. 122 This record will identify the key(s) that child are allowed to self 123 sign its own KEY set. 125 The chain of trust is now established by verifying the parent KEY set, 126 the DS set from the parent and the KEY set at the child. This is 127 cryptographically equivalent to just using KEY records. 129 Communication between the parent and child is greatly reduced, since 130 the child only needs to notify parent about changes in keys that sign 131 its apex KEY RRset. Parent is ignorant of all other keys in the 132 child's apex KEY RRset, and the child maintains full control over the 133 apex KEY set and its content. Child can maintain any policies over 134 its DNS and other KEY usage with minimal impact on parent. Thus if 135 child wants to have frequent key rollover for its DNS keys parent does 136 not need to be aware of it as the child can use one key to only sign 137 its apex KEY set and other keys to sign the other record sets in the 138 zone. 140 This model fits well with slow roll out of DNSSEC and islands of 141 security model. In the islands of security model someone that trusts 142 "good.example." can preconfigure a key from "good.example." as a 143 trusted keys and from then on trusts any data that is signed by that 144 key or has a chain of trust to that key. If "example." starts 145 advertising DS records, "good.example." does not have to change 146 operations, by suspending self-signing. DS records can also be used to 147 identify trusted keys instead of KEY records. One further advantage 148 is the information stored in the parent is minimized, as only records 149 for secure delegations are needed. 151 The main disadvantage of this approach that verifying delegations KEY 152 set requires twice as many signature verification operations. There 153 is no impact on the number of signatures verified for other RR sets. 155 2.2 Protocol change 157 Each secure delegation in a secure zone MUST contain a DS RR set. If 158 a DS RR set accompanies the NS RR set, the intent is to state that the 159 child zone is secured. If an NS RR set exists without a DS RR set the 160 intent is to state that the child zone is unsecure. DS sets MUST NOT 161 appear at non delegations or at zone APEX. 163 In a zone that uses DS, insecure delegations MUST have the NODS[TBD] 164 bit set in the NXT record. This is required to differenciate this 165 delegation from Secure RFC2535 delegation. 167 Updates RFC2535 sections 2.3.4 and 3.4, as well as RFC3008 section 168 2.7: 169 Delegating zones MUST NOT store KEY records for delegations. The only 170 records that can appear at delegation in parent are NS, SIG, NXT and 171 DS. 173 Zone MUST self sign its apex KEY set, it SHOULD sign it with a key 174 that corresponds to a DS record in the parent. The KEY used to sign 175 the apex KEY RRset MAY sign other RRsets in the zone. 177 If child apex KEY RRset is not signed with one of the keys specified 178 in the DS record the child is locally secure[RFC3090] and SHOULD only 179 be considered secure if the resolver has been configured to trust the 180 key used. 182 Authorative server answering a query with the OK bit[OKbit] set, MUST 183 include the DS records and NXT record along with signatures in answers 184 for a delegation and space is available. DS and NXT records SHOULD 185 have lower priority than address records but higher priority than KEY. 186 Caching servers SHOULD return the DS and parent NXT record(s) in the 187 additional section under the same condition. 189 2.2.1 - Comments on protocol change 191 Over the years there has been various discussions on that the 192 delegation model in DNS is broken as there is no real good way to 193 assert if delegation exists. In RFC2535 version of DNSSEC the 194 authentication of a delegation is the NS bit in the NXT bitmap at the 195 delegation point. Something more explicit is needed and the DS record 196 addresses this for secure delegations. 198 DS record is the first DNS record that can only appear on the upper 199 side of a delegation. NS records appear at both sides as do SIG and 200 NXT. All other records can only appear at the lower side. This will 201 cause some problems as servers authorative for parent, reject DS 202 record even if the server understands unknown types, or will not hand 203 them out unless explicitly asked. Similarly a nameserver acting as a 204 authorative for child and as a caching recursive server may never 205 return the DS record. 207 A caching server that supports unkown types, does not care from which 208 side DS record comes from and thus does not have to be changed. 209 Different TTL values on the child's NS set and parents DS set can 210 cause the DS set to expire before the NS set. 212 Secure resolvers need to know about the DS record and how to interpret 213 it. In the worst case, introducing the DS record, doubles the 214 signatures that need to be checked to validate a KEY set. 216 2.3 Wire format of DS record 218 The DS (type=TDB) record consists of algorithm, key tag and SHA-1 219 digest of the public key KEY record allowed to sign the child's 220 delegation. 222 1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3 223 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 224 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 225 | key tag | algorithm | | 226 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 227 | SHA-1 digest | 228 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 229 | (20 bytes) | 230 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 231 | | 232 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-| 233 | | 234 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-| 235 | | 236 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 238 The key tag is calculated as specified in RFC2535, Algorithm MUST be 239 an algorithm number assigned in the range 1..251 and the algorithm 240 MUST be allowed to sign DNS data. The SHA-1 digest is calculated over 241 the canonical name of the delegation followed by the RDATA of the KEY 242 record. 243 DS records MUST NOT point to a null KEY record, and the KEY records 244 pointed to by DS records MUST have protocol value 3 (DNSSEC). 245 DS records MUST NOT point to KEY records where flag field has folowing 246 bit settings, bit 0 (no authentication) is set, bit 6 MUST be set to 0 247 and bit 7 MUST be set to 1 (zone key). Settings of other bits are not 248 important. 249 The size of the DS RDATA is 23 bytes, regardless of key size. 251 2.3.1 Justifications for fields 253 The algorithm and key tag fields are here to allow resolvers to 254 quickly identify the candidate KEY records to examine. The key tag 255 adds some greater assurance than SHA-1 digest on its own. SHA-1 is a 256 strong cryptographic checksum, it is real hard for attacker to 257 generate a KEY record that has the same SHA-1 digest. Combining the 258 name of the key and the key data as input to the digest provides 259 stronger assurance of the binding. 261 This format allows concise representation of the keys that child will 262 use, thus keeping down the size of the answer for the delegation, 263 reducing the probability of packet overflow. The SHA-1 hash is strong 264 enough to uniquely identify the key. This is similar to the PGP 265 footprint. 267 DS record is also well suited to lists trusted keys for islands of 268 security in configuration files. 270 2.4 Presentation format of DS record 272 The presentation format of DS record consists of 2 numbers followed by 273 digest presented in hex. 274 foo.example DS 12345 3 123456789abcdef67890 276 2.5 Transition issues for installed base 278 RFC2535 compliant resolver will assume that all DS secured delegations 279 are locally secure. This is a bad thing, thus it might be necessary 280 for a transition period to support both DS and SIG@Child. The cost is 281 one or more signatures in the answer for KEY records and that early 282 adopters have to use cumbersome communications that DS solves. #.bp 284 2.6 Backwards compatibilty with RFC2535 SIG@child and RFC1035 286 This section documents how a resolver determines the type of 287 delegation. 288 RFC1035 delegation has: 290 RFC1035 NS 292 RFC2535 adds the following two cases: 294 Secure RFC2535: NS + NXT + SIG(NXT) 295 NXT bit map contains: NS SIG NXT 296 Insecure RFC2535: NS + KEY + SIG(KEY) + NXT + SIG(NXT) 297 NXT bit map contains: NS SIG KEY NXT 298 KEY must be null-key. 300 DS adds the following two states: 302 Secure DS: NS + DS + SIG(DS) + NXT + SIG(NXT) 303 NXT bit map contains: NS SIG NXT DS 304 Insecure DS: NS + NXT + SIG(NXT) 305 NXT bit map contains: NS SIG KEY NXT NODS 307 If the NODS bit is not used, a resover can not determine if this is a 308 DS delegation zone. Thus is not able to determine if this delegtion is 309 a secure RFC2535 or a insecure DS. 311 2.6.1 NODS support in servers 313 NODS is a virtual type, servers MUST refuse to store any record of 314 this type. No special processing is required on answers. 316 3 Resolver Example 318 To create a chain of trust resolver goes from trusted KEY to DS to 319 KEY. 321 Assume the key for domain "example." is trusted. In zone "example." 322 we have 323 example. KEY 324 secure.example. DS tag=10243 alg=3 325 secure.example. NS ns1.secure.example. 326 NS ns2.secure.example. 327 secure.example. NXT NS SIG NXT DS unsecure.example. 328 secure.example. SIG(NXT) 329 secure.example. SIG(DS) 330 unsecure.example NS ns1.unsecure.example. 331 unsecure.example NS ns2.unsecure.example. 332 unsecure.example. NXT NS SIG NXT NODS .example. 333 unsecure.example. SIG(NXT) 335 In zone "secure.example." we have 336 secure.example. SOA 337 secure.example. NS ns1.secure.example. 338 NS ns1.secure.example. 339 secure.example. KEY 340 KEY 341 KEY 342 secure.example. SIG(KEY) 343 secure.example. SIG(SOA) 344 secure.example. SIG(NS) 346 In this example the trusted key for "example." signs the DS record for 347 "secure.example.", making that a trusted record. The DS record states 348 what key is expected to sign the KEY RRset at "secure.example". Here 349 "secure.example." has three different KEY records and the KEY 350 identified in the DS record signs the KEY set, thus the KEY set is 351 validated and trusted. Note that one of the other keys in the keyset 352 actually signs the zone data, and resolvers will trust the signatures 353 as the key appears in the KEY set. 355 This example has only one DS record for the child but there no reason 356 to outlaw multiple DS records. More than one DS record is needed 357 during signing key rollover. It is strongly recommended that the DS 358 set be kept small. 360 Resolver determines the security status of "unsecure.example." by 361 examining the parent size NXT for this name. 363 3.1 Resolver cost estimates for DS records 365 From a RFC2535 resolver point of view for each delegation followed to 366 chase down an answer one KEY record has to be verified and possibly 367 some other records based on policy, for example the contents of the NS 368 set. Once the resolver gets to the appropriate delegation validating 369 the answer may require verifying one or more signatures. A simple A 370 record lookup requires at least N delegations to be verified and 1 371 RRset. For a DS enabled resolver the cost is 2N+1. For MX record the 372 cost where the target of the MX record is in the same zone as the MX 373 record the costs are N+2 and 2N+2. In the case of negative answer the 374 same ratios hold true. 376 Resolver may require an extra query to get the DS record and this may 377 add to the overall cost of the query, but this is never worse than 378 chasing down NULL KEY records from the parent in RFC2535 DNSSEC. 380 DS adds processing overhead on resolvers, increases the size of 381 delegation answers but much less than SIG@Parent. 383 4 Acknowledgments 385 Number of people have over the last few years contributed number of 386 ideas that are captured in this document. The core idea of using one 387 key to only sign key set, comes from discussions with Bill Manning and 388 Perry Metzger on how to put in a single root key in all resolvers. 389 Alexis Yushin, Brian Wellington, Jakob Schlyter, Scott Rosen, Edward 390 Lewis, Dan Massey, Lars-Johan Liman, Mark Kosters, Olaf Kolman, Miek 391 Gieben, Havard Eidnes, Donald Eastlake 3rd., Randy Bush, David Blacka, 392 Rob Austein, Derek Atkins, Roy Arends, and others have provided useful 393 comments. 395 4 - Security Considerations: 397 This document proposes a change to the validation chain of KEY records 398 in DNS. The change in is not believed to reduce security in the 399 overall system, in RFC2535 DNSSEC child must communicate keys to 400 parent and prudent parents will require some authentication on that 401 handshake. The modified protocol will require same authentication but 402 allows the child to exert more local control over its own KEY set. 404 There is a possibility that an attacker can generate an valid KEY that 405 matches all the DS fields thus starting to forge data from the child. 406 This is considered impractical as on average more than 2^80 keys must 407 be generated before one is found that will match. 409 DS record is a change to DNSSEC protocol and there is some installed 410 base of implementations, as well as text books on how to set up 411 secured delegations. Implementations that do not understand DS record 412 will not be able to follow the KEY to DS to KEY chain and consider all 413 zone secured that way insecure. 415 5 - IANA Considerations: 417 IANA needs to allocate RR type code for DS from the standard RR type 418 space. 420 IANA needs to allocate RR type code for the virtual NODS record from 421 the standard RR type space. Note: SINK (40) was never implemented and 422 that type code can be reused for NODS. 424 References: 426 [RFC1035] P. Mockapetris, ``Domain Names - Implementation and 427 Specification'', STD 13, RFC 1035, November 1987. 429 [RFC2535] D. Eastlake, ``Domain Name System Security Extensions'', RFC 430 2535, March 1999. 432 [RFC3008] B. Wellington, ``Domain Name System Security (DNSSEC) Signing 433 Authority'', RFC 3008, November 2000. 435 [RFC3090] E. Lewis `` DNS Security Extension Clarification on Zone 436 Status'', RFC 3090, March 2001. 438 [OKbit] D. Conrad, ``Indicating Resolver Support of DNSSEC'', work in 439 progress , April 2001. 441 [Parent] R. Gieben, T. Lindgreen, ``Parent stores the child's zone 442 KEYs'', work in progress , May 2001. 445 Author Address 447 Olafur Gudmundsson 448 3826 Legation Street, NW 449 Washington, DC, 20015 450 USA 451 453 Appendix A: Changes from Prior versions 455 Changes from version 03 456 Added strict rules on what KEY records can be pointed to by DS. 458 Changes from version 02 459 Added text outlawing DS at non delegations. 460 Added table showing the contents of DS, SIG@child, and RFC1034 461 delegations. 462 Added the NODS type/bit definition to distiguish insecure DS 463 delegation from secure SIG@child one. 464 Added the requirement that NXT be returned with referal answers. 465 Minor text edits. 467 Changes from version 01 468 Deleted KEY size field as it did not contribute anything but 469 complexity. 470 Number of wordsmith changes to make document more readable. 471 The word CAN was used when SHOULD was intended. 472 Deleted section 2.4 "Justifications for compact format" moved relevant 473 text to section 2.2. 474 Reverse alphabetized the acknowledgments section. 475 Reorganized sections 1 and 2 for readability. 477 Changes from version 00 478 Changed name from DK to DS based on working group comments. 479 Dropped verbose format based on WG comments. 480 Added text about TTL issue/problem in caching servers. 481 Added text about islands of security and clarified the cost impact. 482 Major editing of arguments and some reordering of text for clarity. 483 Added section on transition issues. 485 Full Copyright Statement 487 Copyright (C) The Internet Society (2001). All Rights Reserved. 489 This document and translations of it may be copied and furnished to 490 others, and derivative works that comment on or otherwise explain it 491 or assist in its implementation may be prepared, copied, published and 492 distributed, in whole or in part, without restriction of any kind, 493 provided that the above copyright notice and this paragraph are 494 included on all such copies and derivative works. However, this 495 document itself may not be modified in any way, such as by removing 496 the copyright notice or references to the Internet Society or other 497 Internet organizations, except as needed for the purpose of developing 498 Internet standards in which case the procedures for copyrights defined 499 in the Internet Standards process must be followed, or as required to 500 translate it into languages other than English. 502 The limited permissions granted above are perpetual and will not be 503 revoked by the Internet Society or its successors or assigns. 505 This document and the information contained herein is provided on an 506 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 507 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT 508 NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN 509 WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 510 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE."