idnits 2.17.1 draft-ietf-rpsec-bgp-session-sec-req-01.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 15. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 492. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 503. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 510. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 516. 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 IETF Trust Copyright Line does not match the current year == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- 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 (July 10, 2008) is 5766 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Outdated reference: A later version (-14) exists of draft-ietf-idr-bgp-identifier-09 == Outdated reference: A later version (-10) exists of draft-ietf-rpsec-bgpsecrec-09 == Outdated reference: A later version (-11) exists of draft-ietf-tcpm-tcp-auth-opt-00 -- Obsolete informational reference (is this intentional?): RFC 2385 (Obsoleted by RFC 5925) -- Obsolete informational reference (is this intentional?): RFC 4346 (Obsoleted by RFC 5246) -- Obsolete informational reference (is this intentional?): RFC 4423 (Obsoleted by RFC 9063) Summary: 2 errors (**), 0 flaws (~~), 5 warnings (==), 10 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group M. Behringer 3 Internet-Draft Cisco Systems Inc 4 Intended status: Informational July 10, 2008 5 Expires: January 11, 2009 7 BGP Session Security Requirements 8 draft-ietf-rpsec-bgp-session-sec-req-01.txt 10 Status of this Memo 12 By submitting this Internet-Draft, each author represents that any 13 applicable patent or other IPR claims of which he or she is aware 14 have been or will be disclosed, and any of which he or she becomes 15 aware will be disclosed, in accordance with Section 6 of BCP 79. 17 Internet-Drafts are working documents of the Internet Engineering 18 Task Force (IETF), its areas, and its working groups. Note that 19 other groups may also distribute working documents as Internet- 20 Drafts. 22 Internet-Drafts are draft documents valid for a maximum of six months 23 and may be updated, replaced, or obsoleted by other documents at any 24 time. It is inappropriate to use Internet-Drafts as reference 25 material or to cite them other than as "work in progress." 27 The list of current Internet-Drafts can be accessed at 28 http://www.ietf.org/ietf/1id-abstracts.txt. 30 The list of Internet-Draft Shadow Directories can be accessed at 31 http://www.ietf.org/shadow.html. 33 This Internet-Draft will expire on January 11, 2009. 35 Abstract 37 The document "BGP security requirements" (draft-ietf-rpsec-bgpsecrec) 38 specifies general security requirements for BGP. However, specific 39 security requirements for single BGP sessions, i.e., the connection 40 between two BGP peers, are only touched on briefly in the section 41 "transport layer protection". This document expands on this 42 particular aspect of BGP security, defining the security requirements 43 between two BGP peers. 45 Table of Contents 47 1. Introduction and Problem Statement . . . . . . . . . . . . . . 3 48 2. The Threat Model . . . . . . . . . . . . . . . . . . . . . . . 4 49 3. BGP Session Security Requirements . . . . . . . . . . . . . . 5 50 3.1. BGP Speaker Identity . . . . . . . . . . . . . . . . . . . 5 51 3.2. Peer Authentication . . . . . . . . . . . . . . . . . . . 6 52 3.3. Integrity . . . . . . . . . . . . . . . . . . . . . . . . 6 53 3.4. Confidentiality . . . . . . . . . . . . . . . . . . . . . 6 54 3.5. Anti-Replay . . . . . . . . . . . . . . . . . . . . . . . 7 55 3.6. Availability and Restricting IP Reachability . . . . . . . 7 56 3.7. Key Management and Operational Considerations . . . . . . 7 57 3.8. Logging and Alerting . . . . . . . . . . . . . . . . . . . 8 58 3.9. General Considerations . . . . . . . . . . . . . . . . . . 8 59 4. Security Considerations . . . . . . . . . . . . . . . . . . . 9 60 5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 9 61 6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 9 62 6.1. Normative References . . . . . . . . . . . . . . . . . . . 9 63 6.2. Informative References . . . . . . . . . . . . . . . . . . 9 64 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 11 65 Intellectual Property and Copyright Statements . . . . . . . . . . 12 67 1. Introduction and Problem Statement 69 The document "BGP security requirements" [I-D.ietf-rpsec-bgpsecrec] 70 specifies general security requirements for BGP. However, specific 71 security requirements for single BGP sessions, i.e., the connection 72 between two BGP peers, are only touched on briefly in the section 73 "transport layer protection". This document expands on this 74 particular aspect of BGP security, defining the security requirements 75 between two BGP peers. 77 It is important to note that security requirements between BGP peers 78 are not limited to the BGP protocol itself or a particular layer of 79 the OSI stack. Crafted ICMP messages for example may have an impact 80 on an established BGP session: An ICMP port unreachable, referring to 81 the BGP port on the peer router, would tear down the BGP session, if 82 no additional security measures are taken to prevent this. A similar 83 effect can be achieved with ICMP source quench messages. Some of the 84 mechanims currently employed to secure a BGP session are on the TCP 85 layer (e.g., MD5), some on the IP layer (e.g., GTSM). This document 86 provides an overall, practical view on the security requirements for 87 BGP sessions, not limited to the BGP protocol. 89 Previous work in this area includes most notably the following 90 documents: 91 o "Protection of BGP Sessions via the TCP MD5 Signature Option" 92 [RFC2385] 93 o "Key Management Considerations for the TCP MD5 Signature Option" 94 [RFC3562] 95 o "Key Change Strategies for TCP-MD5" [RFC4808] 96 o "The Generalized TTL Security Mechanism (GTSM)" [RFC5082] 97 o "Problem Statement and Requirements for a TCP Authentication 98 Option" [I-D.bellovin-tcpsec] 99 o "The TCP Authentication Option" [I-D.ietf-tcpm-tcp-auth-opt]. 100 o "BGP Security Requirements" [I-D.ietf-rpsec-bgpsecrec] 101 o "Generic Security Requirements for Routing Protocols" 102 [I-D.ietf-rpsec-generic-requirements] 103 o "An Attack Tree for the Border Gateway Protocol" 104 [I-D.ietf-rpsec-bgpattack] 105 o "Automated key selection extension for the TCP Enhanced 106 Authentication Option" [I-D.weis-tcp-auth-auto-ks] 107 o "Backbone Infrastructure Attacks and Protections" 108 [I-D.savola-rtgwg-backbone-attacks] 110 Current implementations of BGP include a combination of some of these 111 mechanisms. However, while the security level achieved with these is 112 probably currently acceptable for most providers, they pose some 113 operational challenges which limit the effectiveness of BGP point to 114 point security. Current problems with BGP session security (between 115 BGP peers) include: 116 o The use of static keys, which tend to be changed infrequently, and 117 often not at all. [RFC3562] states that keys SHOULD be changed at 118 least every 90 days. However, the relative complexity of changing 119 MD5 keys on all BGP peering sessions, specifically when securing 120 sessions to routers maintained by two different organisations, 121 means that keys are often not changed at all. This makes long 122 term brute force attacks feasible. 123 o The key change process needs to be coordinated between both sides 124 of the BGP session, making this an operationally expensive 125 exercise. 126 o The keys are typically chosen by humans, and expressed in ASCII; 127 therefore, the entropy is typically small, making the keys easier 128 to guess. [RFC3562] outlines this problem. 129 o Dependence on the MD5 algorithm, which brings two problems: MD5 is 130 not considered strong enough for the future. ([RFC4278] states 131 that "the IESG believes that [RFC2385], though adequate for BGP 132 deployments at this moment, is not strong enough for general 133 use".) And, security architectures should also allow a choice of 134 algorithms, to have an alternative in case serious vulnerabilities 135 are discobered in an algorithm. 136 o Where confidentiality of BGP routing information is required, this 137 can only be achieved today by securing the BGP session with IPsec. 138 Other ways to provide confidentiality may be required in the 139 future. 141 This document lists the requirements for BGP session security, with 142 the goal to provide a guideline for flexible, operationally 143 manageable, and secure algorithms for BGP session protection. 145 The keywords MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD, 146 SHOULD NOT, RECOMMENDED, MAY, and OPTIONAL, when they appear in this 147 document, are to be interpreted as described in [RFC2119]. 149 2. The Threat Model 151 The threat model presented here is based on the document "Generic 152 Threats to Routing Protocols" [RFC4593], which explains generic 153 threats to routing protocols. That document provides a 154 categorization and classification of threat sources, threat actions, 155 threat consequences, threat consequence zones, and threat consequence 156 periods. 158 Security threats to point to point BGP sessions can be classified 159 with the following parameters: 161 o Threat source: Any host in the Internet that can reach one of the 162 BGP peers. (By using The Generalized TTL Security Mechanism 163 (GTSM) [RFC5082] the threat source must be within the configured 164 IP hop count, in the ideal case directly connected.) A threat 165 source can also be a wire tap agent, either passively listening to 166 the BGP session, or actively modifying BGP data in transit. 167 o Threat action: Sending of forged BGP packets, or sniffing BGP 168 traffic. 169 o Threat consequence: Break of confidentiality by wire tapping, 170 break of integrity by faking BGP messages or hijacking a session, 171 or denial of service, for example by sending fake RST packets, 172 terminating a BGP session abnormally. 173 o Threat consequence zones: The BGP peering session itself, the BGP 174 tables on the affected peers, or potentially larger areas of the 175 BGP routing system. 176 o Threat consequence period: Depending on the attack and the 177 implemented counter measures, a threat might be preliminarily 178 mitigated by changing the MD5 key, unless it is a threat against 179 MD5 itself, in which case the threat period is indefinite. 181 Threats not considered in this document include: 182 o Attacks from legitimate BGP speakers, in other words, attacks from 183 other BGP speakers, which are trusted (implicitly or explicitly). 184 The source of the attack in this case could be either a 185 misconfiguration, or an attacker gaining illegitimate access to a 186 router, for example through SSH brute force attacks. 188 The document "Backbone Infrastructure Attacks and Protections" 189 [I-D.savola-rtgwg-backbone-attacks] describes general attack forms 190 against backbones, not limited to the BGP protocol. It provides 191 useful background information to this threat model. 193 3. BGP Session Security Requirements 195 3.1. BGP Speaker Identity 197 A BGP speaker MUST have a unique identity to present to its peer. 198 This serves as a base for subsequent security mechanisms, such as 199 peer authentication. At this moment this identity is tied to the IP 200 address used for the BGP peering session. This address can be either 201 the IP address of a loopback interface, or a physical interface. 203 Any point to point security mechanism for BGP MUST refer to and use a 204 specific BGP ID. This ID MUST be unique for the BGP peers, it SHOULD 205 be unique within an autonomous system, and it MAY be globally unique. 207 A BGP speaker SHOULD be capable of using different IDs to different 208 peers, because a single router identity (the same ID for all peers) 209 may not be sufficient from an operational point of view. For example 210 internally a provider may want to use address space which should not 211 be seen from or accessible to the outside of his network. 212 Alternatively, a provider who uses private address space [RFC1918] 213 inside his network for iBGP sessions, may want to use public address 214 space for eBGP sessions on the same router. 216 Although currently the IP address used for the BGP peering is used as 217 an identifier, it is entirely possible to use an alternative BGP ID, 218 for example based on public/private key pairs, or the HIP 219 architecture [RFC4423]. The document "AS-wide Unique BGP Identifier 220 for BGP-4" [I-D.ietf-idr-bgp-identifier] for example proposes a 221 4-byte unsigned, non-zero integer as an identity, which should be 222 unique in the autonomous system. 224 Note that this document does not mandate or recommend the use of a 225 particular type of BGP ID, nor does it discuss the differences 226 between the various approaches. It only specifies the generic 227 requirements for BGP IDs. 229 3.2. Peer Authentication 231 A BGP speaker MUST have a way to authenticate messages from its peer. 232 Currently this is achieved by [RFC2385] derived mechanisms, however, 233 several alternatives are conceivable and partly under discussion, for 234 example [I-D.ietf-tcpm-tcp-auth-opt]. Also IPsec [RFC4301] provides 235 peer authentication, as does TLS [RFC4346] or SSH [RFC4251]. (Note: 236 Key management is discussed below.) 238 3.3. Integrity 240 A BGP speaker MUST have methods to ensure integrity of messages in 241 transit, to avoid insertion of fake messages in the transport layer. 242 This requirement is currently addressed by RFC 2385-derived 243 mechanisms. However, new methods should avoid the operational issues 244 mentioned in the introduction of that RFC. It MUST be possible to 245 use various algorithms, either statically by specifying the 246 algorithms used for integrity services, or by dynamic negotiation. 247 (Note: Key management is discussed below.) 249 3.4. Confidentiality 251 A BGP speaker MAY have mechanisms to encrypt BGP messages in transit, 252 thus providing confidentiality. This service is rarely used today, 253 but since BGP is used increasingly for more applications, amongst 254 which for example signaling security measures, it is conceivable that 255 the need for confidentiality for BGP sessions will increase. If 256 confidentiality services are provided, they MUST allow for different 257 crypto algorithms, and negotiation of which algorithm to use. (Note: 258 Key management is discussed below.) 260 3.5. Anti-Replay 262 A BGP speaker MUST have methods to detect and prevent replay of 263 messages, to avoid for example an attacker saving a session reset 264 message, and replaying it later, to produce a denial of service 265 attack. 267 3.6. Availability and Restricting IP Reachability 269 A BGP speaker SHOULD have mechanisms to protect the BGP session 270 against denial of service attacks, targeting the availability of the 271 BGP session. More specifically, a BGP speaker SHOULD have mechanisms 272 to drop non-session packets efficiently (with minimum CPU impact, 273 specifically before any crypto operations). This includes access 274 control lists (ACL) on layer 3/4 and possibly layer 2, providing easy 275 protection against some forms of attack. It also includes TTL based 276 mechanisms such as proposed in [RFC5082]. Any reachability 277 restriction of these types MUST be carried out before more CPU 278 intensive tasks such as crypto operations, to be effective against 279 denial of service attacks. 281 Fragmentation attacks can bypass layer 4 ACLs, by fragmenting packets 282 in a way that no fragment is recognized by the ACL. (Note that layer 283 4 ACLs still provide operationally useful filtering, and should 284 therefore be supported.) Fragmentation cannot occur on a single-hop 285 BGP session, therefore a BGP speaker MUST have the capability to drop 286 fragments on a single-hop BGP session. On multi-hop BGP sessions 287 fragmentation should not occur, if the network has been correctly 288 designed, therefore a BGP speaker SHOULD also be capable of dropping 289 fragements on a multi-hop BGP session. Also on other, related, 290 protocols fragmentation needs to be specially considered, since it 291 can bypass some forms of ACLs. 293 The document "Service Provider Infrastructure Security" 294 [I-D.ietf-opsec-infrastructure-security] provides an overview of best 295 practices regarding infrastructure protection, and is useful 296 background material. 298 3.7. Key Management and Operational Considerations 300 Some of the requirements above may, in turn, require mechanisms that 301 employ shared keys between the BGP peers. Currently, statically- 302 defined and manually configured keys are used for this purpose. 303 [RFC3562] explains possible shortcomings of such keys, and gives 304 recommendations to improve security. Key selection is also discussed 305 in [I-D.weis-tcp-auth-auto-ks], as an extension to 306 [I-D.ietf-tcpm-tcp-auth-opt]. 308 For any new mechanism aimed at securing BGP sessions it is highly 309 desirable to use automated key generation and negotiation mechanisms, 310 based on the BGP speaker identity. 312 Mechanisms based on key lists with defined life times for keys, for 313 example as defined by the document "Authentication-Key Rollover 314 mechanism for Routing and Management Protocols" 315 [I-D.viswanathan-keyrollover] may be acceptable if there are good 316 reasons to avoid automated key negotiation. 318 3.8. Logging and Alerting 320 To be able to detect attempts of security breaks, BGP speakers MUST 321 have be able to produce related alerts or logging messages. General 322 considerations to logging apply here: There should be summarization 323 of events, to avoid for example a message to be sent for each packet 324 that is not authenticated. When available, secure syslog should be 325 used to guarantee delivery of those messages to the management 326 center. 328 3.9. General Considerations 330 For many of the above mentioned security requirements there are a 331 vast range of protocol and implementation options, with varying 332 degrees of effective security. While strong security is desirable, 333 there are several considerations to be taken into account for a BGP 334 implementation: 335 o Efficient use of system resources: Stronger security mechanisms 336 may require more system resources (CPU, memory, bandwidth) than 337 more light-weight versions, or the unprotected BGP protocol. A 338 security mechanism may lead to an excessively higher exposure to 339 denial of service attacks than the unprotected protocol, or 340 another security mechanims.When considering security mechanisms, 341 the "cost" in terms of system resources should be taken into 342 account. 343 o Ease of configuration: Complicated configurations increase the 344 likelihood for misconfigurations, with potential security 345 vulnerabilities. BGP security mechanisms should therefore be easy 346 to configure, where "easy" referes to both the length of the 347 configuration, as well as the complexity of it. 349 Both efficient use of system resources and ease of configuration 350 cannot be judged on their own, but rather represent additional 351 variables to judge an overall BGP security implementation. In other 352 words, a highly secure, but also highly complex and resource- 353 consuming solution may be less preferrable over a somewhat less 354 secure but simple and light-weight solution. This has to be decided 355 case-by-case. 357 4. Security Considerations 359 This document is entirely about security requirements for BGP point- 360 to-point connections. No new security exposures are created by this 361 document. 363 5. Acknowledgements 365 The author would like to thank Russ White, Alvaro Retana, Brian Weis, 366 Carlos Pignataro, Stephen Kent, and Joe Touch for their feedback and 367 support. 369 6. References 371 6.1. Normative References 373 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 374 Requirement Levels", BCP 14, RFC 2119, March 1997. 376 6.2. Informative References 378 [I-D.bellovin-tcpsec] 379 Bellovin, S., "Problem Statement and Requirements for a 380 TCP Authentication Option", draft-bellovin-tcpsec-01 (work 381 in progress), July 2007. 383 [I-D.ietf-idr-bgp-identifier] 384 Chen, E. and J. Yuan, "AS-wide Unique BGP Identifier for 385 BGP-4", draft-ietf-idr-bgp-identifier-09 (work in 386 progress), May 2008. 388 [I-D.ietf-opsec-infrastructure-security] 389 Lewis, D., "Service Provider Infrastructure Security", 390 draft-ietf-opsec-infrastructure-security-01 (work in 391 progress), April 2007. 393 [I-D.ietf-rpsec-bgpattack] 394 Convery, S., "An Attack Tree for the Border Gateway 395 Protocol", draft-ietf-rpsec-bgpattack-00 (work in 396 progress), April 2004. 398 [I-D.ietf-rpsec-bgpsecrec] 399 Christian, B. and T. Tauber, "BGP Security Requirements", 400 draft-ietf-rpsec-bgpsecrec-09 (work in progress), 401 November 2007. 403 [I-D.ietf-rpsec-generic-requirements] 404 McPherson, D., "Generic Security Requirements for Routing 405 Protocols", draft-ietf-rpsec-generic-requirements-01 (work 406 in progress), January 2005. 408 [I-D.ietf-tcpm-tcp-auth-opt] 409 Touch, J., Mankin, A., and R. Bonica, "The TCP 410 Authentication Option", draft-ietf-tcpm-tcp-auth-opt-00 411 (work in progress), November 2007. 413 [I-D.savola-rtgwg-backbone-attacks] 414 Savola, P., "Backbone Infrastructure Attacks and 415 Protections", draft-savola-rtgwg-backbone-attacks-03 (work 416 in progress), January 2007. 418 [I-D.viswanathan-keyrollover] 419 Viswanathan, S., "Authentication-Key Rollover mechanism 420 for Routing and Management Protocols", 421 draft-viswanathan-keyrollover-00 (work in progress), 422 October 2006. 424 [I-D.weis-tcp-auth-auto-ks] 425 Weis, B., Appanna, C., McGrew, D., and A. Ramaiah, 426 "Automated key selection extension for the TCP Enhanced 427 Authentication Option", draft-weis-tcp-auth-auto-ks-03 428 (work in progress), October 2007. 430 [RFC1918] Rekhter, Y., Moskowitz, R., Karrenberg, D., Groot, G., and 431 E. Lear, "Address Allocation for Private Internets", 432 BCP 5, RFC 1918, February 1996. 434 [RFC2385] Heffernan, A., "Protection of BGP Sessions via the TCP MD5 435 Signature Option", RFC 2385, August 1998. 437 [RFC3562] Leech, M., "Key Management Considerations for the TCP MD5 438 Signature Option", RFC 3562, July 2003. 440 [RFC4251] Ylonen, T. and C. Lonvick, "The Secure Shell (SSH) 441 Protocol Architecture", RFC 4251, January 2006. 443 [RFC4278] Bellovin, S. and A. Zinin, "Standards Maturity Variance 444 Regarding the TCP MD5 Signature Option (RFC 2385) and the 445 BGP-4 Specification", RFC 4278, January 2006. 447 [RFC4301] Kent, S. and K. Seo, "Security Architecture for the 448 Internet Protocol", RFC 4301, December 2005. 450 [RFC4346] Dierks, T. and E. Rescorla, "The Transport Layer Security 451 (TLS) Protocol Version 1.1", RFC 4346, April 2006. 453 [RFC4423] Moskowitz, R. and P. Nikander, "Host Identity Protocol 454 (HIP) Architecture", RFC 4423, May 2006. 456 [RFC4593] Barbir, A., Murphy, S., and Y. Yang, "Generic Threats to 457 Routing Protocols", RFC 4593, October 2006. 459 [RFC4808] Bellovin, S., "Key Change Strategies for TCP-MD5", 460 RFC 4808, March 2007. 462 [RFC5082] Gill, V., Heasley, J., Meyer, D., Savola, P., and C. 463 Pignataro, "The Generalized TTL Security Mechanism 464 (GTSM)", RFC 5082, October 2007. 466 Author's Address 468 Michael H. Behringer 469 Cisco Systems Inc 470 Village d'Entreprises Green Side 471 400, Avenue Roumanille, Batiment T 3 472 Biot - Sophia Antipolis 06410 473 France 475 Email: mbehring@cisco.com 476 URI: http://www.cisco.com 478 Full Copyright Statement 480 Copyright (C) The IETF Trust (2008). 482 This document is subject to the rights, licenses and restrictions 483 contained in BCP 78, and except as set forth therein, the authors 484 retain all their rights. 486 This document and the information contained herein are provided on an 487 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 488 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 489 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 490 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 491 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 492 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 494 Intellectual Property 496 The IETF takes no position regarding the validity or scope of any 497 Intellectual Property Rights or other rights that might be claimed to 498 pertain to the implementation or use of the technology described in 499 this document or the extent to which any license under such rights 500 might or might not be available; nor does it represent that it has 501 made any independent effort to identify any such rights. Information 502 on the procedures with respect to rights in RFC documents can be 503 found in BCP 78 and BCP 79. 505 Copies of IPR disclosures made to the IETF Secretariat and any 506 assurances of licenses to be made available, or the result of an 507 attempt made to obtain a general license or permission for the use of 508 such proprietary rights by implementers or users of this 509 specification can be obtained from the IETF on-line IPR repository at 510 http://www.ietf.org/ipr. 512 The IETF invites any interested party to bring to its attention any 513 copyrights, patents or patent applications, or other proprietary 514 rights that may cover technology that may be required to implement 515 this standard. Please address the information to the IETF at 516 ietf-ipr@ietf.org.