idnits 2.17.1 draft-bellovin-useipsec-04.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 524. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 501. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 508. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 514. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (September 2005) is 6796 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: 'RFC2041' is mentioned on line 225, but not defined -- Looks like a reference, but probably isn't: '2385' on line 331 == Unused Reference: 'RFC2385' is defined on line 448, but no explicit reference was found in the text ** Obsolete normative reference: RFC 2401 (Obsoleted by RFC 4301) ** Obsolete normative reference: RFC 2402 (Obsoleted by RFC 4302, RFC 4305) ** Obsolete normative reference: RFC 2406 (Obsoleted by RFC 4303, RFC 4305) ** Obsolete normative reference: RFC 2409 (Obsoleted by RFC 4306) ** Obsolete normative reference: RFC 3280 (Obsoleted by RFC 5280) -- Obsolete informational reference (is this intentional?): RFC 1771 (Obsoleted by RFC 4271) -- Obsolete informational reference (is this intentional?): RFC 2284 (Obsoleted by RFC 3748) -- Obsolete informational reference (is this intentional?): RFC 2385 (Obsoleted by RFC 5925) -- Obsolete informational reference (is this intentional?): RFC 2960 (Obsoleted by RFC 4960) Summary: 9 errors (**), 0 flaws (~~), 4 warnings (==), 12 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group Steven M. Bellovin 3 Internet Draft Columbia University 5 Expiration Date: March 2006 September 2005 7 Guidelines for Mandating the Use of IPsec 9 draft-bellovin-useipsec-04.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 Copyright Notice 36 Copyright (C) The Internet Society (2005). 38 Abstract 40 The Security Considerations sections of many Internet Drafts say, in 41 effect, "just use IPsec". While this is sometimes correct, more 42 often it will leave users without real, interoperable security 43 mechanisms. This memo offers some guidance on when IPsec should and 44 should not be specified. 46 1. Introduction 48 The Security Considerations sections of many Internet Drafts say, in 49 effect, "just use IPsec". While this is sometimes correct, more 50 often it will leave users without real, interoperable security 51 mechanisms. IPsec is often unavailable in the likely endpoints. 52 Even if it is available, it may not provide the proper granularity of 53 protection. Finally, if it is available and appropriate, the 54 document mandating it needs to specify just how it is to be used. 56 Recall that the goal is realistic, interoperable security. 57 Specifying, as the only security mechanism, a configuration which is 58 unavailable to -- and hence unusable by -- a majority of the user 59 community is tantamount to saying "turn off security". 61 For further guidance on security considerations (including discussion 62 of IPsec), see [RFC3552]. 64 NOTE: Many of the arguments below relate to the capabilities of 65 current implementations of IPsec. These may change over time; this 66 advice based on the knowledge available to the IETF at publication 67 time. 69 2. WARNING 71 The design of security protocols is a subtle and difficult art. The 72 cautions here about specifying use of IPsec should NOT be taken to 73 mean that that you should invent your own new security protocol for 74 each new application. If IPsec is a bad choice, use another 75 standardized, well-understood security protocol. Don't roll your 76 own. 78 3. The Pieces of IPsec 80 IPsec is composed of a number of different pieces. These can be used 81 to provide confidentiality, integrity, and replay protection; though 82 some these can be configured manually, in general a key management 83 component is used. Additionally, the decision about whether and how 84 to use IPsec is controlled by a policy database of some sort. 86 3.1. AH and ESP 88 The Authentication Header (AH) [RFC2402] and the Encapsulating 89 Security Protocol (ESP) [RFC2406] are the over-the-wire security 90 protocols. Both provide (optional) replay protection. ESP typically 91 is used to provide confidentiality (encryption), integrity and 92 authentication for traffic. ESP also can provide integrity and 93 authentication without confidentiality, which makes it a good 94 alternative to AH in most cases where confidentiality is not a 95 required or desired service. Finally, ESP can be used to provide 96 confidentiality alone, although this is not recommended [Bell96]. 98 The difference in integrity protection offered by AH is that AH 99 protects portions of the preceding IP header, including the source 100 and destination address. However, when ESP is used in tunnel mode 101 (see section 4.2), and if integrity/authentication is enabled, the IP 102 header seen by the source and destination hosts is completely 103 protected anyway. 105 AH can also protect those IP options that need to be seen by 106 intermediate routers, but must be intact and authentic when delivered 107 to the receiving system. At this time, use (and existence) of such 108 IP options is extremely rare. 110 If an application requires such protection, and if the information to 111 be protected cannot be inferred from the key management process, AH 112 must be used. (ESP is generally regarded as easier to implement; 113 however, virtually all IPsec packages support both.) If 114 confidentiality is required, ESP must be used. It is possible to use 115 AH in conjunction with ESP, but this combination is rarely required. 117 All variants of IPsec have problems with NAT boxes -- see [RFC3715] 118 for details -- but AH is considerably more troublesome. In 119 environments where there is substantial likelihood that the two end- 120 points will be separated by a NAT box, AH should be avoided. Note 121 that [RFC3948] is for ESP only, and cannot be used for AH. 123 3.2. Transport and Tunnel Mode 125 AH and ESP can both be used in either transport mode or tunnel mode. 126 In tunnel mode, the IPsec header is followed by an inner IP header; 127 this is the normal usage for Virtual Private Networks (VPN), and it 128 is generally required whenever either end of the IPsec-protected path 129 is not the ultimate IP destination, e.g., when IPsec is implemented 130 in a firewall, router, etc. Transport mode is preferred for point- 131 to-point communication, though tunnel mode can be used for this 132 purpose. 134 3.3. Key Management 136 Any cryptographic system requires key management. IPsec provides for 137 both manual and automatic key management schemes. Manual key 138 management is easy; however, it doesn't scale very well. Also, 139 IPsec's replay protection mechanisms are not available if manual key 140 management is used. The need for automatic key exchange is discussed 141 in more detail in [RFC4107]. 143 One automated key exchange mechanism is available, Internet Key 144 Exchange (IKE) [RFC2409]. A new, simpler version of IKE has been 145 approved, but there are few if any deployments [IKEv2]. A second 146 mechanism, Kerberized Internet Negotiation of Keys (KINK) [KINK], is 147 being defined. It, of course, uses Kerberos, and is suitable if and 148 only if a Kerberos infrastructure is available. 150 If a decision to use IKE is made, the precise mode of operation must 151 be specified as well. IKE can be used in main mode or aggressive 152 mode; both support digital signatures, two different ways of using 153 public key encryption, and shared secrets for authentication. 155 Shared secret authentication is simpler; however, it doesn't scale as 156 well in many-to-many communication scenarios, since each endpoint 157 must share a unique secret with every peer with which it can 158 communicate. Note, though, that using shared secrets in IKE is far 159 preferable to manual keying. 161 In most real-world situations where public key modes of IKE are used, 162 locally-issued certificates are employed. That is, the administrator 163 of the system or network concerned will issue certificates to all 164 authorized users. These certificates are useful only for IPsec. 166 It is sometimes possible to use certificates [RFC3280] from an 167 existing public key infrastructure (PKI) with IKE. In practice, this 168 is rare. Furthermore, there not only is no global PKI for the 169 Internet, there probably never will be one. Designing a structure 170 which assumes such a PKI is a mistake. In particular, assuming that 171 an arbitrary node will have an "authentic" certificate, issued by a 172 mutually trusted third party and vouching for that node's identity, 173 is wrong. Again, such a PKI does not and probably will not exist. 174 Public key IKE is generally a good idea, but almost always with 175 locally-issued certificates. 177 Note that public key schemes require a substantial amount of 178 computation. Protocol designers should consider whether or not such 179 computations are feasible on devices of interest to their clientele. 180 Using certificates roughly doubles the number of large 181 exponentiations that must be performed, compared with shared secret 182 versions of IKE. 184 Today, even low-powered devices can generally perform enough 185 computation to set up a limited number of security associations; 186 concentration points, such as firewalls or VoIP servers, may require 187 hardware assists, especially if many peers are expected to create 188 security associations at about the same time. 190 3.4. Applications Program Interface (API) 192 It is, in some sense, a misnomer to speak of the API as a part of 193 IPsec, since that piece is missing on many systems. To the extent 194 that it does exist, it isn't standardized. The problem is simple: 195 it is difficult or impossible to request IPsec protection, or to tell 196 if was used for given inbound packets or connections. 198 There is an additional problem: applications generally are not built 199 directly on IP or IPsec. Rather, they are layered on top of some 200 transport protocol, which in turn is layered on IP or IPsec. 202 Router- or firewall-based IPsec implementations pose even greater 203 problems, since there is no standardized over-the-wire protocol for 204 communicating this information from outboard encryptors to hosts. 206 4. Availability of IPsec in Target Devices 208 Although IPsec is now widely implemented, and is available for 209 current releases of most host operating systems, it is less available 210 for embedded systems. Few hubs, network address translators, etc., 211 implement it, especially at the low end. It is generally 212 inappropriate to rely on IPsec when many of the endpoints are in this 213 category. 215 Even for host-to-host use, IPsec availability (and experience, and 216 ease of use) has generally been for VPNs. Hosts that support IPsec 217 for VPN use do not always support it on a point-to-point basis, 218 especially via a stable, well-defined API or user interface. 220 Finally, few implementations support multiple layers of IPsec. If a 221 telecommuter is using IPsec in VPN mode to access an organizational 222 network, he or she may not be able to employ a second level of IPsec 223 to protect an application connection to a host within the 224 organization. (We note that such support is, in fact, mandated by 225 Case 4 of Section 4.5 of [RFC2041]. Nevertheless, it is not widely 226 available.) The likelihood of such deployment scenarios should be 227 taken into account when deciding whether or not to mandate IPsec. 229 5. Endpoints 231 [RFC2401] describes many different forms of endpoint identifier. 232 These include source addresses (both IPv4 and IPv6), host names 233 (possibly as embedded in X.500 certificates), and user IDs (again, 234 possibly as embedded in a certificate). Not all forms of identifier 235 are available on all implementations; in particular, user-granularity 236 identification is not common. This is especially a concern for 237 multi-users systems, where it may not be possible to use different 238 certificates to distinguish between traffic from two different users. 240 Again, we note that the ability to provide fine-grained protection, 241 such as keying each connection separately, and with per-user 242 credentials, was one of the original design goals of IPsec. 243 Nevertheless, only a few platforms support it. Indeed, some 244 implementations do not even support using port numbers when deciding 245 whether or not to apply IPsec protection. 247 6. Selectors and the SPD 249 Section 4.4 of [RFC2401] describes the Security Policy Database (SPD) 250 and "selectors" used to decide what traffic should be protected by 251 IPsec. Choices include source and destination addresses (or address 252 ranges), protocol numbers (i.e., 6 for TCP and 17 for UDP), and port 253 numbers for TCP and UDP. Protocols whose protection requirements 254 cannot be described in such terms are poorer candidates for IPsec in 255 particular, it becomes impossible to apply protection at any finer 256 grain than "destination host". Thus, traffic embedded in an L2TP 257 [RFC2661] session cannot be protected selectively by IPsec above the 258 L2TP layer, because IPsec has no selectors defined that let it peer 259 into the L2TP packet to find the TCP port numbers. Similarly, SCTP 260 [RFC2960] did not exist when [RFC2401] was written; thus, protecting 261 individual SCTP applications on the basis of port number could not be 262 done until a new document was written [RFC3554] that defined new 263 selectors for IPsec, and implementations appeared. 265 The granularity of protection available may have side-effects. If 266 certain traffic between a pair of machines is protected by IPsec, 267 does the implementation permit other traffic to be unprotected, or 268 protected by different policies? Alternatively, if the 269 implementation is such that it is only capable of protecting all 270 traffic or none, does the device have sufficient CPU capacity to 271 encrypt everything? Note that some low-end devices may have limited 272 secure storage capacity for keys, etc. 274 Implementation issues are also a concern here. As before, too many 275 vendors have not implemented the full specifications; too many IPsec 276 implementations are not capable of using port numbers in their 277 selectors. Protection of traffic between two hosts is thus on an all 278 or nothing basis when these non-compliant implementations are 279 employed. 281 7. Broadcast and Multicast 283 Although the designers of IPsec tried to leave room for protection of 284 multicast traffic, a complete design wasn't finished until much 285 later. There is, as yet, no key management for the general case, 286 though MIKEY [RFC3830] will work for peer-to-peer, simple one-to- 287 many, and small group multicast. Worse yet, an important component 288 of over-the-wire IPsec -- replay protection -- was designed even 289 later [2401bis,2402bis,ESPv3], and is thus unavailable in deployed 290 multicast implementations. IPsec is thus inappropriate for such 291 protocols unless and until suitable key management and replay 292 protection mechanisms are available in the target domain. 294 8. Mandating IPsec 296 Despite all of the caveats given above, it may still be appropriate 297 to use IPsec in particular situations. The range of choices make it 298 mandatory to define precisely how IPsec is to be used. Authors of 299 RFCs that rely on IPsec must specify the following: 301 (a) What selectors the initiator of the conversation (the client, 302 in client-server architectures) should use? What addresses, 303 port numbers, etc., are to be used? 305 (b) What IPsec protocol is to be used: AH or ESP? What mode is 306 to be employed: transport mode or tunnel mode? 308 (c) What form of key management is appropriate? 310 (d) What security policy database entry types should be used by 311 the responder (i.e., the server) when deciding whether or not 312 to accept the IPsec connection request? 314 (e) What form of identification should be used? Choices include 315 IP address, DNS name, and X.500 distinguished name. 317 (f) What form of authentication should be used? Choices include 318 pre-shared secrets, certificates, and (for IKEv2) an EAP 319 exchange [RFC2284]. 321 (g) Which of the many variants of IKE must be supported? Main 322 mode? Aggressive mode? 324 (h) Is suitable IPsec support available in likely configurations 325 of the products that would have to employ IPsec? 327 9. Example 329 Suppose that the designers of the Border Gateway Protocl (BGP) 330 [RFC1771] wished to use IPsec for security, rather than the mechanism 331 described in [2385]. Does it meet these criteria? (Note that the 332 deeper security issues raised by BGP are not addressed by IPsec or 333 any other transmission security mechanism. See [Kent00a] and 334 [Kent00b] for more details.) 336 Selectors 337 The issue of selectors is easy. BGP already runs between 338 manually-configured pairs of hosts on TCP port 179. The 339 appropriate selector would be the pair of BGP speakers, for 340 that port only. Note that the router's "loopback address" is 341 almost certainly the address to use. 343 Mode 344 Clearly, transport mode is the proper choice. The information 345 being communicated is generally not confidential, so 346 encryption need not be used. Either AH or ESP can be used; if 347 ESP is used, the sender's IP address would need to be checked 348 against the IP address asserted in the key management 349 exchange. (This check is mandated by [RFC2401].) For the 350 sake of interoperability, the RFC author should pick one. 352 Key Management 353 To permit replay detection, an automated key management system 354 should be used, most likely IKE. Again, the RFC author should 355 pick one. 357 Security Policy 358 Connections should be accepted only from the designated peer. 360 Authentication 361 Given the number of BGP-speaking routers used internally by 362 large ISPs, it is likely that shared key mechanisms are 363 inadequate. Consequently, certificate-based IKE must be 364 supported. However, shared secret mode is reasonable on 365 peering links, or (perhaps) on links between ISPs and 366 customers. Whatever scheme is used, it must tie back to a 367 source IP address or AS number in some fashion, since other 368 BGP policies are expressed in these terms. If certficates are 369 used, would they use IP addresses or AS numbers? Which? 371 Availability 372 For this scenario, availability is the crucial question. Do 373 likely BGP speakers -- both backbone routers and access 374 routers -- support the profile of IPsec described above? Will 375 use of IPsec, with its attendant expensive cryptographic 376 operations, raise the issue of new denial of service attacks? 377 The working group and the IESG must make these determinations 378 before deciding to use IPsec to protect BGP. 380 10. Security Considerations 382 IPsec provides transmission security and simple access control only. 383 There are many other dimensions to protocol security that are beyond 384 the scope of this memo. Within its scope, the security of any 385 resulting protocol depends heavily on the accuracy of the analysis 386 that resulted in a decision to use IPsec. 388 11. Acknowledgments 390 Ran Atkinson, Barbara Fraser, Paul Hoffman, Russ Housley, Stephen 391 Kent, Eric Fleischman, and others have made many useful suggestions. 393 12. Normative References 395 [2401bis] "Security Architecture for the Internet Protocol". S. Kent 396 and K. Seo. draft-ietf-ipsec-rfc2401bis, work in progress, 397 2005. 399 [2402bis] "IP Authentication Header", S. Kent, draft-ietf-ipsec- 400 rfc2402bis, work in proress, 2005. 402 [ESPv3] "IP Encapsulating Security Payload (ESP)". S. Kent. 403 draft-ietf-ipsec-esp-v3, work in progress, 2005. 405 [IKEv2] "Internet Key Exchange (IKEv2) Protocol", C. Kaufman, ed. 406 draft-ietf-ipsec-ikev2, work in progress, 2005. 408 [RFC2401] "Security Architecture for the Internet Protocol", S. Kent 409 and R. Atkinson, RFC 2401, November 1998. 411 [RFC2402] "IP Authentication Header", S. Kent and R. Atkinson, RFC 412 2402, November 1998. 414 [RFC2406] "IP Encapsulating Security Payload (ESP)", S. Kent and R. 415 Atkinson, RFC 2406, November 1998. 417 [RFC2409] "The Internet Key Exchange (IKE)", D. Harkins and D. 418 Carrel. RFC 2409, November 1998. 420 [RFC3280] "Internet X.509 Public Key Infrastructure Certificate and 421 Certificate Revocation List (CRL) Profile." R. Housley, W. Polk, 422 W. Ford, D. Solo. RFC 3280. April 2002. 424 13. Informative References 426 [Bell96] "Problem Areas for the IP Security Protocols", S.M. 427 Bellovin, Proc. Sixth Usenix Security Symposium, 1996, pp. 428 205-214. 430 [Kent00a] "Secure Border Gateway Protocol (Secure-BGP)", S. Kent, C. 431 Lynn, and K. Seo, IEEE Journal on Selected Areas in 432 Communications 18:4, April 2000, pp. 582-592. 434 [Kent00b] "Secure Border Gateway Protocol (S-BGP) -- Real World 435 Performance and Deployment Issues", S. Kent, C. Lynn, J. 436 Mikkelson, and K. Seo, Proc. Network and Distributed System 437 Security Symposium, February 2000. 439 [KINK] "Kerberized Internet Negotiation of Keys (KINK)", M. Thomas 440 and J. Vilhuber, draft-ietf-kink-kink, work in progress, 2005. 442 [RFC1771] "A Border Gateway Protocol 4 (BGP-4)", Y. Rekhter and T. 443 Li. RFC 1771, March 1995. 445 [RFC2284] "PPP Extensible Authentication Protocol (EAP)." L. Blunk, 446 J. Vollbrecht. RFC 2284. March 1998. 448 [RFC2385] "Protection of BGP Sessions via the TCP MD5 Signature 449 Option." A. 450 Heffernan. RFC 2385. August 1998. 452 [RFC2661] "Layer Two Tunneling Protocol L2TP", W. Townsley, A. 453 Valencia, A. Rubens, G. Pall, G. Zorn, B. Palter. RFC 2661, 454 August 1999. 456 [RFC2960] "Stream Control Transmission Protocol", R. Stewart, Q. Xie, 457 K. Morneault, C. Sharp, H. Schwarzbauer, T. Taylor, I. Rytina, 458 M. Kalla, L. Zhang, and V. Paxson. RFC 2960, October 2000. 460 [RFC3552] "Guidelines for Writing RFC Text on Security 461 Considerations", E. Rescorla and B. Korver. RFC 3552. 2003. 463 [RFC3554] "On the Use of Stream Control Transmission Protocol (SCTP) 464 with IPsec. S. Bellovin, J. Ioannidis, A. Keromytis, R. Stewart. 465 RFC 3554. July 2003. 467 [RFC3715] "IPsec-Network Address Translation (NAT) Compatibility 468 Requirements." B. Aboba, W. Dixon. RFC 3715. March 2004. 470 [RFC3830] "MIKEY: Multimedia Internet KEYing." J. Arkko, E. Carrara, 471 F. Lindholm, M. Naslund, K. Norrman. RFC 3830. August 2004. 473 [RFC3948] "UDP Encapsulation of IPsec ESP Packets", A. Huttunen, B. 474 Swander, V. Volpe, L. DiBurro, M. Stenberg. RFC 3948. January 475 2005. 477 [RFC4107] "Guidelines for Cryptographic Key Management," S. Bellovin, 478 R. Housley. RFC 4107. June 2005. 480 14. Author Information 482 Steven M. Bellovin 483 Department of Computer Science 484 Columbia University 485 Mailcode 0401 486 1214 Amsterdam Avenue 487 New York, NY 10027-7003 488 USA 489 Phone: +1 212 939 7149 490 email: bellovin@acm.org 492 Intellectual Property Statement 494 The IETF takes no position regarding the validity or scope of any 495 Intellectual Property Rights or other rights that might be claimed to 496 pertain to the implementation or use of the technology described in 497 this document or the extent to which any license under such rights 498 might or might not be available; nor does it represent that it has 499 made any independent effort to identify any such rights. Information 500 on the procedures with respect to rights in RFC documents can be 501 found in BCP 78 and BCP 79. 503 Copies of IPR disclosures made to the IETF Secretariat and any 504 assurances of licenses to be made available, or the result of an 505 attempt made to obtain a general license or permission for the use of 506 such proprietary rights by implementers or users of this 507 specification can be obtained from the IETF on-line IPR repository at 508 http://www.ietf.org/ipr. 510 The IETF invites any interested party to bring to its attention any 511 copyrights, patents or patent applications, or other proprietary 512 rights that may cover technology that may be required to implement 513 this standard. Please address the information to the IETF at ietf- 514 ipr@ietf.org. 516 Disclaimer of Validity 518 This document and the information contained herein are provided on an 519 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 520 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 521 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 522 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 523 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 524 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 526 Copyright Statement 528 Copyright (C) The Internet Society (2005). This document is subject 529 to the rights, licenses and restrictions contained in BCP 78, and 530 except as set forth therein, the authors retain all their rights.