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