idnits 2.17.1 draft-ietf-dnsext-signed-nonexistence-requirements-03.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 576. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 553. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 560. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 566. ** 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.) == There are 2 instances of lines with non-RFC2606-compliant FQDNs in the document. 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 (June 16, 2006) is 6517 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) == Unused Reference: 'RFC2026' is defined on line 516, but no explicit reference was found in the text == Unused Reference: 'RFC2418' is defined on line 522, but no explicit reference was found in the text Summary: 4 errors (**), 0 flaws (~~), 5 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group B. Laurie 3 Internet-Draft Nominet 4 Expires: December 18, 2006 R. Loomis 5 SAIC 6 June 16, 2006 8 Requirements related to DNSSEC Signed Proof of Non-Existence 9 draft-ietf-dnsext-signed-nonexistence-requirements-03 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 December 18, 2006. 36 Copyright Notice 38 Copyright (C) The Internet Society (2006). 40 Abstract 42 DNSSEC-bis uses the NSEC record to provide authenticated denial of 43 existence of RRsets. NSEC also has the side-effect of permitting 44 zone enumeration, even if zone transfers have been forbidden. 45 Because some see this as a problem, this document has been assembled 46 to detail the possible requirements for denial of existence A/K/A 47 signed proof of non-existence. 49 Table of Contents 51 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 52 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 53 3. Non-purposes . . . . . . . . . . . . . . . . . . . . . . . . . 3 54 4. Group 1 - Zone Enumeration and exposure . . . . . . . . . . . 4 55 5. Group 2 - Zone Size . . . . . . . . . . . . . . . . . . . . . 4 56 6. Group 3 - Compatibility and Transition . . . . . . . . . . . . 5 57 7. Group 4 - Empty Non-terminals . . . . . . . . . . . . . . . . 5 58 8. Group 5 - DNSSEC-Adoption and Zone-Growth Relationship . . . . 6 59 9. Group 6 - Non-overlap of denial records with possible zone 60 records . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 61 10. Group 7 - Exposure of Private Keys . . . . . . . . . . . . . . 7 62 11. Group 8 - Minimisation of Zone Signing Cost . . . . . . . . . 8 63 12. Group 9 - DoS prevention/symmetric cost . . . . . . . . . . . 8 64 13. Group 10 - Acceptable Complexity . . . . . . . . . . . . . . . 8 65 14. Group 11 - Completeness . . . . . . . . . . . . . . . . . . . 8 66 15. Group 12 - Purity of Namespace . . . . . . . . . . . . . . . . 9 67 16. Group 13 - Replay Attacks . . . . . . . . . . . . . . . . . . 9 68 17. Group 14 - Security during Zone Transition . . . . . . . . . . 9 69 18. Group 15a - Universal Signing . . . . . . . . . . . . . . . . 10 70 19. Group 15b - Universal Signing . . . . . . . . . . . . . . . . 10 71 20. Group 15c - Universal Signing . . . . . . . . . . . . . . . . 10 72 21. Group 16 - NSEC++ as seen by NSEC-only resolver . . . . . . . 10 73 22. Prioritization . . . . . . . . . . . . . . . . . . . . . . . . 11 74 23. Non-requirements . . . . . . . . . . . . . . . . . . . . . . . 11 75 24. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 11 76 25. Requirements notation . . . . . . . . . . . . . . . . . . . . 11 77 26. Security Considerations . . . . . . . . . . . . . . . . . . . 12 78 27. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12 79 27.1. Normative References . . . . . . . . . . . . . . . . . . 12 80 27.2. Informative References . . . . . . . . . . . . . . . . . 12 81 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 13 82 Intellectual Property and Copyright Statements . . . . . . . . . . 14 84 1. Introduction 86 NSEC records allow trivial enumeration of zones - a situation that 87 has existed for several years but which has recently been raised as a 88 significant concern for DNSSECbis deployment in several zones. 89 Alternate proposals have been made that make zone enumeration more 90 difficult, and some previous proposals to modify DNSSEC had related 91 requirements/desirements that are relevant to the discussion. In 92 addition the original designs for NSEC/NXT records were based on 93 working group discussions and the choices made were not always 94 documented with context and requirements-- so some of those choices 95 may need to be restated as requirements. Overall, the working group 96 needs to better understand the requirements for denial of existence 97 (and certain other requirements related to DNSSECbis deployment) in 98 order to evaluate the proposals that may replace NSEC. The -01 99 version of this document was presented at IETF61 on 10 November 2004 100 along with a re-categorization of the then-current list of potential 101 requirements. This version of the document formalizes that re- 102 categorization of the requirements, and is intended to serve as the 103 basis for further discussions and evaluation of potential solutions. 105 2. Terminology 107 In the remainder of this document, "NSEC++" is used as shorthand for 108 "a denial of existence proof that will replace NSEC". "NSECbis" has 109 also been used as shorthand for this, but we avoid that usage since 110 NSECbis will not be part of DNSSECbis and therefore there might be 111 some confusion. We also use the term "DNSSEC-TNG" A/K/A "DNSSECter". 112 This is meant to indicate the current DNSSECbis plus whatever changes 113 are required as part of NSEC++. We expect that DNSSECter will likely 114 still include the current NSEC record as well. 116 3. Non-purposes 118 This document does not currently document the reasons why zone 119 enumeration might be "bad" from a privacy, security, business, or 120 other perspective--except insofar as those reasons result in 121 requirements. Once the list of requirements is complete and vaguely 122 coherent, the trade-offs (reducing zone enumeration will have X cost, 123 while providing Y benefit) may be revisited. The editors of this 124 compendium received inputs on the potential reasons why zone 125 enumeration is bad (and there was significant discussion on the 126 DNSEXT WG mailing list) but that information fell outside the scope 127 of this document. 129 Note also that this document does not assume that NSEC *must* be 130 replaced with NSEC++, if the requirements can be met through other 131 methods (e.g., "white lies" with the current NSEC). As is stated 132 above, this document is focused on requirements collection and 133 (ideally) prioritization rather than on the actual implementation. 135 4. Group 1 - Zone Enumeration and exposure 137 Comprised of previous requirements numbered as 3, 4, 5, 6, 10, and 26 139 The editors suggest that these boil down to: "DNSSECter should not 140 make it easier to enumerate zones than it is with plain DNS." 142 We believe that this is a high-priority requirement. 144 Threshold requirement: Enumeration is at least non-trivial (where 145 current NSEC provides a linked list that is considered trivial to 146 walk). 148 A concrete test might be that a random zone is infeasible to fully 149 enumerate--this also reflects the "goal requirement" 151 Contributor: various 153 5. Group 2 - Zone Size 155 Requirement: NSEC++ should make it possible to take precautions 156 against trivial zone size estimates. Since not all zone owners care 157 about others estimation of the size of a zone, it is not always 158 necessary to prohibit trivial estimation of the size of the zone but 159 NSEC++ should allow such measures. 161 We believe that this is a "nice to have" item and not a true 162 requirement, and recommend weighting it appropriately when 163 considering solutions. 165 Additional Discussion: Even with proposals based on obfuscating names 166 with hashes it is trivial to give very good estimates of the number 167 of domains in a certain zone. Just send 10 random queries and look 168 at the range between the two hash values returned in each NSEC++. As 169 hash output can be assumed to follow a rectangular random 170 distribution, using the mean difference between the two values, you 171 can estimate the total number of records. It is probably sufficient 172 to look at even one NSEC++, since the two hash values should follow a 173 (I believe) Poisson distribution. 175 The concern is motivated by some wording remembered from NSEC, which 176 stated that NSEC MUST only be present for existing owner names in the 177 zone, and MUST NOT be present for non-existing owner names. If 178 similar wording were carried over to NSEC++, introducing bogus owner 179 names in the hash chain (an otherwise simple solution to guard 180 against trivial estimates of zone size) wouldn't be allowed. 182 One simple attempt at solving this is to describe in the 183 specifications how zone signer tools can add a number of random 184 "junk" records. 186 Editor's comment: it is interesting that obfuscating names might 187 actually make it easier to estimate zone size. 189 Contributor: Simon Josefsson. 191 6. Group 3 - Compatibility and Transition 193 Comprised of requirements previously numbered as 8, 20, 21, 22, 23, 194 24 196 Editor comments: The editors suggest that these boil down to, 197 "Current deployment of DNSSECbis with NSEC, by those who care not 198 about zone enumeration, should not be affected by future NSEC++ 199 deployment." 201 We believe that this is a high priority requirement. 203 NOTE: Requirement 8 is no longer truly applicable, because it would 204 have mandated a change to the draft DNSSECbis documents that was not 205 made before they were submitted for IESG review. 207 Contributor: Various 209 7. Group 4 - Empty Non-terminals 211 Goal: Empty-non-terminals (ENT) should remain empty. In other words, 212 adding NSEC++ records to an existing DNS structure should not cause 213 the creation of NSEC++ records (or related records) at points that 214 are otherwise ENT. 216 Editor comments: We believe that this is a low-priority desire and 217 not a strict requirement, and we recommend that it be weighted 218 appropriately when comparing possible solutions. 220 Additional discussion: Currently NSEC complies with ENT requirement: 221 b.example.com NSEC a.c.example.com implies the existence of an ENT 222 with ownername c.example.com. NSEC2 breaks that requirement, since 223 the ownername is entirely hashed causing the structure to disappear. 224 This is why EXIST was introduced. But EXIST causes ENT to be non- 225 empty-terminals. Next to the dissappearance of ENT, it causes (some) 226 overhead since an EXIST record needs a SIG, NSEC2 and SIG(NSEC2). 227 DNSNR honours this requirement by hashing individual labels instead 228 of ownernames. However this causes very long labels. Truncation is 229 a measure against very long ownernames, but that is controversial. 230 There is a fair discussion of the validity of truncation in the DNSNR 231 draft, but that hasn't got proper review yet. 233 Contributor: Roy Arends. 235 (Editor comment: it is not clear to us that an EXIST record needs an 236 NSEC2 record, since it is a special purpose record only used for 237 denial of existence) 239 8. Group 5 - DNSSEC-Adoption and Zone-Growth Relationship 241 Background: Currently with NSEC, when a delegation centric zone 242 deploys DNSSEC, the zone-size multiplies by a non-trivial factor even 243 when the DNSSEC-adoption rate of the subzones remains low--because 244 each delegation point creates at least one NSEC record and 245 corresponding signature in the parent even if the child is not 246 signed. 248 Goal/Requirements: A delegation-only (or delegation-mostly) zone that 249 is signed but which has no signed child zones should initially need 250 only to add SIG(SOA), DNSKEY, and SIG(DNSKEY) at the apex, along with 251 some minimal set of NSEC++ records to cover zone contents. Further, 252 during the transition of a delegation-only zone from 0% signed 253 children to 100% signed children, the growth in the delegation-only 254 zone should be roughly proportional to the percentage of signed child 255 zones. 257 Editor comments: We believe that this is a medium-priority goal or 258 desire and should be considered. Because of the similarity of this 259 item to the older "opt-in signed zones" proposal, we recognize that 260 consideration of this item may bog down the DNSEXT WG and that a 261 decision must be made by the WG chairs. 263 Additional Discussion: This is why DNSNR has the Authoritative Only 264 bit. This is similar to opt-in for delegations only. This (bit) is 265 currently the only method to help delegation-centric zone cope with 266 zone-growth due to DNSSEC adoption. As an example, A delegation only 267 zone which deploys DNSSEC with the help of this bit, needs to add 268 SIG(SOA), DNSKEY, SIG(DNSKEY), DNSNR, SIG(DNSNR) at the apex. No 269 more than that. 271 Contributor: Roy Arends. 273 9. Group 6 - Non-overlap of denial records with possible zone records 275 Goal: NSEC++ records should in some way be differentiated from 276 regular zone records, so that there is no possibility that a record 277 in the zone could be duplicated by a non-existence proof (NSEC++) 278 record. 280 Editor comment: We are not sure that this is a valid concern much 281 less a requirement. Even if there is an apparent conflict or 282 overlap, the "conflicting" NSEC2 name _only_ appears in NSEC2 283 records, and the other name _never_ appears in NSEC2 records. 284 Protocols cannot protect against all possible silly or foolish 285 actions, and should a randomly chosen salt produce an NSEC2 record 286 that matches a zone entry (either current or future) then the 287 solution will be to pick a new salt and re-sign the zone. 289 Additional discussion: This requirement is derived from a discussion 290 on the DNSEXT mailing list related to copyrights and domain names. 291 As was outlined there, one solution would be to put NSEC++ records in 292 a separate namespace, e.g.: $ORIGIN co.uk. 293 873bcdba87401b485022b8dcd4190e3e IN NS jim.rfc1035.com ; your 294 delegation 873bcdba87401b485022b8dcd4190e3e._no IN NSEC++ 881345... ; 295 for amazon.co.uk. However, it is not obvious that this separate 296 namespace is useful. 298 Contributor: various 300 10. Group 7 - Exposure of Private Keys 302 Private keys associated with the public keys in the DNS should be 303 exposed as little as possible. It is highly undesirable for private 304 keys to be distributed to nameservers, or to otherwise be available 305 in the run-time environment of nameservers. 307 We believe that this is a medium priority desire. For some 308 organizations the use of online keys may be an acceptable trade-off 309 if it allows the prevention of zone enumeration. On the other hand, 310 there are some organizations which may be concerned about zone 311 enumeration and for whom online storage/availability of keys on the 312 authoritative servers may be unacceptable. 314 Contributors: Nominet, Olaf Kolkman, Ed Lewis 316 11. Group 8 - Minimisation of Zone Signing Cost 318 The additional cost of creating an NSEC++ signed zone should not 319 significantly exceed the cost of creating an ordinary signed zone. 320 Furthermore, DNSSEC++ should not make incremental signing of existing 321 zones any "harder" (in terms of computational or administrative 322 resources) than it currently is with DNSSECbis/NSEC. 324 We believe that this is a medium-priority desire. 326 Contributor: Nominet 328 12. Group 9 - DoS prevention/symmetric cost 330 NSEC++ should not make Denial of Service (DoS) attacks significantly 331 more effective than plain DNSSECbis. Any increase in real-time cost 332 at the name server (to respond) should correspond to a proportional 333 increase in real-time cost to generate the original query. 335 Editor comment: We believe that this is a low-priority desire. In 336 general DNSSEC makes DoS attacks against both authoritative and 337 recursive DNS servers so much easier that the answer will be to 338 increase available server CPU resources. Further, we are not sure 339 that this a realistic requirement given the other requirements for 340 NSEC++. In the end, we recommend that this be considered along with 341 other factors when reviewing potential solutions. 343 Contributor: Nominet 345 13. Group 10 - Acceptable Complexity 347 Caching, wildcards, CNAMEs, and DNAMEs should continue to work 348 without significant increases in complexity at the client side--where 349 complexity specifically includes complexity of operational usage and 350 complexity of validator implementation. 352 We believe that this is a medium priority desire. 354 Contributor: Olaf Kolkman 356 14. Group 11 - Completeness 358 There should not be a proof of nonexistence possible for any valid 359 data in the zone. NOTE: This has a much different meaning than the 360 way in which this requirement was stated in the -01 version of this 361 document, based on further discussions with the original contributor. 363 This requirement now appears to conflict with Group 5 above and has 364 been given the same priority as Group 5 (previously requirement 11). 365 The WG will need to resolve the conflict and remove one of the two 366 goals/requirements from consideration. 368 Contributor: Olaf Kolkman 370 15. Group 12 - Purity of Namespace 372 The name space should not be muddied with fake names or data sets. 374 Editor comment: After further discussion with the contributor, this 375 appears to be more of an awareness issue than a true requirement, and 376 one that may be possible to address on the implementation side. See 377 also Group 6, which appears to be based on similar concerns (although 378 the similarity was not identified during discussions at IETF 61). 380 Contributor: Ed Lewis 382 16. Group 13 - Replay Attacks 384 Requirement: NSEC++ should not allow replay attacks that are any more 385 effective than those which currently exist in DNSSECbis. 387 Editor comment: This is a high-priority requirement. The requirement 388 was reworded based on further discussion with the original 389 contributor and other WG members. The basis for the rewording is 390 that DNSSECbis by design does not allow replay attacks that deny a 391 record which already exists. However, attacks against a record which 392 has been added will succeed (until the signature expires on the 393 relevant NSEC) 395 Contributor: Ed Lewis 397 17. Group 14 - Security during Zone Transition 399 Requirement: It should be possible to switch between NSEC and NSEC++ 400 without any zone data appearing to be unsigned, insecure, or "partly 401 secure" during the transition, taking into account externally cached 402 data. 404 Additional discussion: We never want an end-user to see 405 "inconsistently signed" data. Both positive and negative answers 406 should still be able to be validated. 408 Editor comment: This is a newly identified requirement. This is at 409 least highly desirable and perhaps a hard-and-fast requirement. 411 18. Group 15a - Universal Signing 413 Editor comment: The 15 a/b/c nomenclature is used in this version for 414 consistency with the presentation made to DNSEXT by the editors 415 during IETF 61 in DC. This should probably be fixed in some way for 416 the next version of this document...hopefully in a way that minimizes 417 confusion. 419 Requirement: "Every zone that can be signed with DNSSECbis can also 420 be signed with DNSSECter." (We believe that this is all zones, but 421 do not want to prove it nor raise the bar for DNSSECter.) 423 Additional discussion: This is a newly-identified, hard-and-fast 424 requirement. 426 19. Group 15b - Universal Signing 428 Requirement: It should be possible to sign all zones with DNSSECter. 430 Additional discussion: Newly identified requirement. We rate this as 431 highly desirable. 433 20. Group 15c - Universal Signing 435 Requirement: If it is not possible to sign all zones with NSEC++, 436 then it should be clearly defined which zones cannot be signed. 438 This is a newly identified, hard-and-fast requirement. 440 21. Group 16 - NSEC++ as seen by NSEC-only resolver 442 Requirement: An NSEC++ (only) zone, regardless of whether parent uses 443 NSEC or NSEC++, should appear as consistently unsigned when seen by 444 an NSEC-only resolver. 446 Basis: We never want an end-user to see "inconsistently signed" data. 448 This is a newly-identified requirement. This is at least highly 449 desirable and perhaps a hard-and-fast requirement. 451 22. Prioritization 453 Clearly not all of these requirements can be met. Therefore the 454 editors have attempted to prioritize the requirements as they 455 understand the relevant impacts and needs. The following lists give 456 details as to the prioritization. The order of listing within each 457 priority level is also intended to show which requirements should be 458 given higher priority if a "tie-breaker" is needed. Further, there 459 are likely some potential DNSSEC users who would assign different 460 priorities to specific requirement sets--these are meant to be an 461 overall list that best serves the wider community. 463 High priority: Group 1 (Zone enumeration and exposure), group 3 464 (compatibility and transition), group 13 (replay), group 15a 465 (universal signing), and group 15c (universal signing). 467 Medium priority: Group 14 (security during transition), group 15b 468 (universal signing), Group 16 (NSEC-only resolver results), group 5 469 (adoption and zone growth), group 11 (completeness), group 7 470 (exposure of signing keys), group 10 (complexity), group 12 (DNS 471 "purity"), group 8 (zone signing cost) 473 Low priority: Group 9 (DoS prevention), group 2 (zone size), group 4 474 (Empty non-terminals), group 6 (non-overlap in namespace) 476 23. Non-requirements 478 Explicit non-requirement: Prevent enumeration of RR types for a given 479 name. 481 Even if it is notionally possible to provide this capability, we 482 expect a steep cost and little benefit. 484 Future provision of this capability is not prevented, if warranted. 486 24. Acknowledgements 488 25. Requirements notation 490 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 491 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 492 document are to be interpreted as described in [RFC2119]. 494 26. Security Considerations 496 There are only very limited security considerations called out in 497 this draft, primarily related to questions of whether some of the 498 methods for avoiding zone enumeration might require a message to be 499 cryptographically signed "on the fly", which would imply that private 500 keys must in some way be accessible on authoritative nameservers. 502 There will be security considerations in the choice of which 503 requirements will be implemented, but there are no specific security 504 requirements during the requirements collection process. 506 27. References 508 27.1. Normative References 510 [dnssecbis-protocol] 511 "DNSSECbis Protocol Definitions", BCP XX, RFC XXXX, Some 512 Month 2004. 514 27.2. Informative References 516 [RFC2026] Bradner, S., "The Internet Standards Process -- Revision 517 3", BCP 9, RFC 2026, October 1996. 519 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 520 Requirement Levels", BCP 14, RFC 2119, March 1997. 522 [RFC2418] Bradner, S., "IETF Working Group Guidelines and 523 Procedures", BCP 25, RFC 2418, September 1998. 525 Authors' Addresses 527 Ben Laurie 528 Nominet 529 17 Perryn Road 530 London W3 7LR 531 England 533 Phone: +44 (20) 8735 0686 534 Email: ben@algroup.co.uk 536 Rip Loomis 537 Science Applications International Corporation 538 7125 Columbia Gateway Drive, Suite 300 539 Columbia, MD 21046 540 US 542 Email: gilbert.r.loomis@saic.com 544 Intellectual Property Statement 546 The IETF takes no position regarding the validity or scope of any 547 Intellectual Property Rights or other rights that might be claimed to 548 pertain to the implementation or use of the technology described in 549 this document or the extent to which any license under such rights 550 might or might not be available; nor does it represent that it has 551 made any independent effort to identify any such rights. Information 552 on the procedures with respect to rights in RFC documents can be 553 found in BCP 78 and BCP 79. 555 Copies of IPR disclosures made to the IETF Secretariat and any 556 assurances of licenses to be made available, or the result of an 557 attempt made to obtain a general license or permission for the use of 558 such proprietary rights by implementers or users of this 559 specification can be obtained from the IETF on-line IPR repository at 560 http://www.ietf.org/ipr. 562 The IETF invites any interested party to bring to its attention any 563 copyrights, patents or patent applications, or other proprietary 564 rights that may cover technology that may be required to implement 565 this standard. Please address the information to the IETF at 566 ietf-ipr@ietf.org. 568 Disclaimer of Validity 570 This document and the information contained herein are provided on an 571 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 572 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 573 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 574 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 575 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 576 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 578 Copyright Statement 580 Copyright (C) The Internet Society (2006). This document is subject 581 to the rights, licenses and restrictions contained in BCP 78, and 582 except as set forth therein, the authors retain all their rights. 584 Acknowledgment 586 Funding for the RFC Editor function is currently provided by the 587 Internet Society.