idnits 2.17.1 draft-ietf-rserpool-threats-09.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 23. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 658. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 669. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 676. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 682. 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 : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust 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 (October 24, 2007) is 6029 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: '1' is defined on line 589, but no explicit reference was found in the text == Unused Reference: '2' is defined on line 594, but no explicit reference was found in the text == Unused Reference: '3' is defined on line 597, but no explicit reference was found in the text == Outdated reference: A later version (-06) exists of draft-ietf-rserpool-overview-02 Summary: 1 error (**), 0 flaws (~~), 5 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group M. Stillman, Ed. 3 Internet-Draft Nokia 4 Intended status: Informational R. Gopal 5 Expires: April 26, 2008 Nokia Research Center 6 E. Guttman 7 Sun Microsystems 8 M. Holdrege 9 Strix Systems 10 S. Sengodan 11 Nokia Research Center 12 October 24, 2007 14 Threats Introduced by RSerPool and Requirements for Security in Response 15 to Threats 16 draft-ietf-rserpool-threats-09.txt 18 Status of this Memo 20 By submitting this Internet-Draft, each author represents that any 21 applicable patent or other IPR claims of which he or she is aware 22 have been or will be disclosed, and any of which he or she becomes 23 aware will be disclosed, in accordance with Section 6 of BCP 79. 25 Internet-Drafts are working documents of the Internet Engineering 26 Task Force (IETF), its areas, and its working groups. Note that 27 other groups may also distribute working documents as Internet- 28 Drafts. 30 Internet-Drafts are draft documents valid for a maximum of six months 31 and may be updated, replaced, or obsoleted by other documents at any 32 time. It is inappropriate to use Internet-Drafts as reference 33 material or to cite them other than as "work in progress." 35 The list of current Internet-Drafts can be accessed at 36 http://www.ietf.org/ietf/1id-abstracts.txt. 38 The list of Internet-Draft Shadow Directories can be accessed at 39 http://www.ietf.org/shadow.html. 41 This Internet-Draft will expire on April 26, 2008. 43 Copyright Notice 45 Copyright (C) The IETF Trust (2007). 47 Abstract 49 Rserpool is an architecture and set of protocols for the management 50 and access to server pools supporting highly reliable applications 51 and for client access mechanisms to a server pool. This Internet 52 draft describes security threats to the Rserpool architecture and 53 presents requirements for security to thwart these threats. 55 Table of Contents 57 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 58 1.1. Definitions . . . . . . . . . . . . . . . . . . . . . . . 3 59 2. Threats . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 60 2.1. PE Registration/Deregistration flooding -- 61 non-existent PE . . . . . . . . . . . . . . . . . . . . . 4 62 2.2. PE Registration/Deregistration flooding -- 63 unauthorized PE . . . . . . . . . . . . . . . . . . . . . 4 64 2.3. PE Registration/Deregistration spoofing . . . . . . . . . 5 65 2.4. PE Registration/Deregistration unauthorized . . . . . . . 5 66 2.5. Malicious ENRP server joins the group of legitimate 67 ENRP servers . . . . . . . . . . . . . . . . . . . . . . . 6 68 2.6. Registration/deregistration with malicious ENRP server . . 6 69 2.7. Malicious ENRP Handlespace Resolution . . . . . . . . . . 6 70 2.8. Malicious node performs a replay attack . . . . . . . . . 7 71 2.9. Re-establishing PU-PE security during failover . . . . . . 7 72 2.10. Integrity . . . . . . . . . . . . . . . . . . . . . . . . 8 73 2.11. Data Confidentiality . . . . . . . . . . . . . . . . . . . 8 74 2.12. ENRP Server Discovery . . . . . . . . . . . . . . . . . . 9 75 2.13. Flood of endpoint unreachable messages from the PU to 76 the ENRP server . . . . . . . . . . . . . . . . . . . . . 9 77 2.14. Flood of endpoint keep alive messages from the ENRP 78 server to a PE . . . . . . . . . . . . . . . . . . . . . . 10 79 3. Security Considerations . . . . . . . . . . . . . . . . . . . 10 80 3.1. Security of the ENRP Database . . . . . . . . . . . . . . 12 81 3.2. Cookie mechanism security . . . . . . . . . . . . . . . . 12 82 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 83 5. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13 84 5.1. Normative References . . . . . . . . . . . . . . . . . . . 13 85 5.2. Informative References . . . . . . . . . . . . . . . . . . 13 86 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 13 87 Intellectual Property and Copyright Statements . . . . . . . . . . 15 89 1. Introduction 91 RSerPool provides a session layer for robustness. The session layer 92 function may redirect communication transparently to upper layers. 93 This alters the direct one-to-one association between communicating 94 endpoints which typically exists between clients and servers. In 95 particular, secure operation of protocols often relies on assumptions 96 at different layers regarding the identity of the communicating party 97 and the continuity of the communication between endpoints. Further, 98 the operation of RSerPool itself has security implications and risks. 99 The session layer operates dynamically which imposes additional 100 concerns for the overall security of the end-to-end application. 101 This document explores the security implications of RSerPool, both 102 due to its own functions and due to its being interposed between 103 applications and transport interfaces. 105 1.1. Definitions 107 This document uses the following terms: 109 Endpoint Name Resolution Protocol (ENRP): 110 Within the operational scope of Rserpool, ENRP defines the 111 procedures and message formats of a distributed fault-tolerant 112 registry service for storing, bookkeeping, retrieving, and 113 distributing pool operation and membership information. 115 Aggregate Server Access Protocol (ASAP): 116 A session layer protocol which uses ENRP to provide a high 117 availability handlespace. ASAP is responsible for the abstraction 118 of the underlying transport technologies, load distribution 119 management,fault management, as well as the presentation to the 120 upper layer (i.e., the ASAP user) a unified primitive interface. 122 Operational scope: 123 The part of the network visible to pool users by a specific 124 instance of the reliable server pooling protocols. 126 Pool (or server pool): 127 A collection of servers providing the same application 128 functionality. 130 Pool handle: 131 A logical pointer to a pool. Each server pool will be 132 identifiable in the operational scope of the system by a unique 133 pool handle. 135 ENRP handlespace (or handlespace): 136 A cohesive structure of pool names and relations that may be 137 queried by an internal or external agent. 139 Pool element (PE): A server entity having registered to a pool. 141 Pool user (PU): A server pool user. 143 2. Threats 145 2.1. PE Registration/Deregistration flooding -- non-existent PE 147 2.1.1. Threat 149 A malicious node could send a stream of false registrations/ 150 deregistrations on behalf of non-existent PEs to ENRP servers at a 151 very rapid rate and thereby create unnecessary state in an ENRP 152 server. 154 2.1.2. Effect 156 Corrupting the pool registrar database and/or disabling the Rserpool 157 discovery and database function. This represents a denial of service 158 attack as the PU would potentially get an IP address of a non- 159 existent PE in response to an ENRP query. 161 2.1.3. Requirement 163 An ENRP server that receives a registration/deregistration should not 164 create or update state information until it has authenticated the PE. 166 2.2. PE Registration/Deregistration flooding -- unauthorized PE 168 2.2.1. Threat 170 A malicious node or PE could send a stream of registrations/ 171 deregistrations that are unauthorized to register/deregister - to 172 ENRP servers at a very rapid rate and thereby create unnecessary 173 state in an ENRP server. 175 2.2.2. Effect 177 Corrupting the pool registrar database and/or disabling the Rserpool 178 discovery and database function. This represents a denial of service 179 attack as the PU would potentially get an IP address of a rogue PE in 180 response to an ENRP query which might not provide the actual service. 181 If it does provide the service, this would be a man in the middle 182 attack to allow them to collect data. This could also prevent 183 legitimate PEs from registering. 185 2.2.3. Requirement 187 An ENRP server that receives a registration/deregistration should not 188 create or update state information until the authorization of the 189 registering/de-registering entity is verified. 191 2.3. PE Registration/Deregistration spoofing 193 2.3.1. Threat 195 A malicious node could send false registrations/deregistrations to 196 ENRP servers concerning a legitimate PE thereby creating false state 197 information in the ENRP servers. 199 2.3.2. Effect 201 Misinformation in the ENRP server concerning a PE would get 202 propagated to other ENRP servers thereby corrupting the ENRP 203 database. DDoS, by adding a PE that is a target for DDoS attack for 204 some popular high volume service the attacker can register a PE that 205 a lot of PUs will try to connect to. This allows man in the middle 206 or masquerade attacks on the service provided by the legitimate PEs. 207 If a hacker registers its server address as a PE and handles the 208 requests he can eavesdrop on service data. 210 2.3.3. Requirement 212 An ENRP server that receives a registration/deregistration should not 213 create or update state information until it has authenticated the PE. 215 2.4. PE Registration/Deregistration unauthorized 217 2.4.1. Threat 219 A PE who is not authorized to join a pool could send registrations/ 220 deregistrations to ENRP servers thereby creating false state 221 information in the ENRP servers. 223 2.4.2. Effect 225 Misinformation in the ENRP server concerning a PE would get 226 propagated to other ENRP servers thereby corrupting the ENRP 227 database. This allows man in the middle or masquerade attacks on the 228 service provided by the legitimate PEs. If a hacker registers its 229 server address as a PE and handles the requests he can eavesdrop on 230 service data. 232 2.4.3. Requirement 234 An ENRP server that receives a registration/deregistration should not 235 create or update state information until it has authorized the 236 requesting entity. 238 2.5. Malicious ENRP server joins the group of legitimate ENRP servers 240 2.5.1. Threat 242 Malicious ENRP server joins the group of legitimate ENRP servers with 243 the intent of propagating inaccurate updates to corrupt the ENRP 244 database. 246 2.5.2. Effect 248 Inconsistent ENRP database state. 250 2.5.3. Requirement 252 Mutual authentication of ENRP servers. 254 2.6. Registration/deregistration with malicious ENRP server 256 2.6.1. Threat 258 A PE unknowingly registers/deregisters with malicious ENRP server. 260 2.6.2. Effect 262 Registration might not be properly processed or ignored. A rogue 263 ENRP server has the ability to return any address to a user 264 requesting service which could result in denial of service or 265 connection to a rouge PE of the hackers choice for service. 267 2.6.3. Requirement 269 PE needs to authenticate the ENRP server. 271 2.7. Malicious ENRP Handlespace Resolution 273 2.7.1. Threat 275 The ASAP protocol receives a handlespace resolution response from an 276 ENRP server, but the ENRP server is malicious and returns random IP 277 addresses or an inaccurate list in response to the pool handle. 279 2.7.2. Effect 281 PU application communicates with the wrong PE or is unable to locate 282 the PE since the response is incorrect in saying that a PE with that 283 handle did not exist. A rouge ENRP server has the ability to return 284 any address to ASAP requesting an address list which could result in 285 denial of service or connection to a rouge PE of the hackers choice 286 for service. From the PE, the hacker could eavesdrop or tamper with 287 the application. 289 2.7.3. Requirement 291 ASAP needs to authenticate the ENRP server. 293 2.8. Malicious node performs a replay attack 295 2.8.1. Threat 297 A malicious node could replay the entire message previously sent by a 298 legitimate entity. This could create false/unnecessary state in the 299 ENRP servers when the replay is for registration/de-registration or 300 update. 302 2.8.2. Effect 304 False/extra state is maintained by ENRP servers. This would most 305 likely be used as a denial of service attack if the replay is used to 306 deregister all PEs. 308 2.8.3. Requirement 310 Care should be taken to prevent replay attacks. 312 2.9. Re-establishing PU-PE security during failover 314 2.9.1. Threat 316 PU fails over from PE A to PE B. In the case that the PU had a 317 trusted relationship with PE A, then the PU will likely not have the 318 same relationship established with PE B. 320 2.9.2. Effect 322 If there was a trust relationship involving security context between 323 PU and PE A, the equivalent trust relationship will not exist between 324 PU and PE B. This will violate security policy. 326 2.9.3. Requirement 328 Either notify the application when fail over occurs so the 329 application can take appropriate action to establish a trusted 330 relationship with PE B OR reestablish the security context 331 transparently. 333 2.10. Integrity 335 2.10.1. Threat 337 a. ENRP response to pool handle resolution is corrupted during 338 transmission 340 b. ENRP peer messages are corrupted during transmission 342 c. PE sends update for values and that information is corrupted 343 during transmission 345 2.10.2. Effect 347 ASAP receives corrupt information for pool handle resolution which 348 the PU believes to be accurate. 350 2.10.3. Requirement 352 Integrity mechanism needed. 354 2.11. Data Confidentiality 356 2.11.1. Threat 358 An eavesdropper capable of snooping on fields within messages in 359 transit, may be able to garner information such as 360 topology/location/IP addresses etc. that may not be desirable to 361 divulge. 363 2.11.2. Effect 365 Information that an administrator does not wish to divulge are 366 divulged. The hacker gains valuable information that can be used for 367 financial gain or attacks on hosts. 369 2.11.3. Requirement 371 Provision for data confidentiality service. 373 2.12. ENRP Server Discovery 375 2.12.1. Threats 377 a. Thwarting successful discovery: When a PE wishes to register with 378 an ENRP server, it needs to discover an ENRP server. An attacker 379 could thwart the successful discovery of ENRP server(s) thereby 380 inducing the PE to believe that no ENRP server is available. For 381 instance, the attacker could reduce the returned set of ENRP 382 servers to null or a small set of inactive ENRP servers. 384 b. A similar thwarting scenario also applies when an ENRP server or 385 ASAP on behalf of a PU needs to discover ENRP servers. 387 c. Spoofing successful discovery: An attacker could spoof the 388 discovery by claiming to be a legitimate ENRP server. When a PE 389 wishes to register, it finds the spoofed ENRP server. 391 d. A similar spoofing scenario also applies when an ENRP server or 392 ASAP on behalf of a PU needs to discover ENRP servers. 394 2.12.2. Effects 396 a. A PE that could have been in an application server pool does not 397 become part of a pool. The PE does not complete discovery 398 operation. This is a DOS attack. 400 b. An ENRP server that could have been in an ENRP server pool does 401 not become part of a pool. A PU is unable to utilize services of 402 ENRP servers. 404 c. This malicious ENRP would either misrepresent, ignore or 405 otherwise hide or distort information about the PE to subvert 406 RSerPool operation. 408 d. Same as last. 410 2.12.3. Requirement 412 Provision for data confidentiality service. 414 2.13. Flood of endpoint unreachable messages from the PU to the ENRP 415 server 417 2.13.1. Threat 419 These messages are sent by ASAP to the ENRP server when it is unable 420 to contact a PE. There is the potential that a PU could flood the 421 ENRP server intentionally or unintentionally with these messages. 423 2.13.2. Effect 425 DOS attack on the ENRP server. 427 2.13.3. Requirement 429 Need to limit the number of endpoint unreachable messages sent to the 430 ENRP server from the PU. 432 2.14. Flood of endpoint keep alive messages from the ENRP server to a 433 PE 435 2.14.1. Threat 437 These messages would be sent in response to a flood of endpoint 438 unreachable messages from the PUs to the ENRP server. 440 2.14.2. Effect 442 Unintentional DOS attack on the PE. 444 2.14.3. Requirement 446 ENRP must limit the frequency of keep alive messages to a given PE to 447 prevent overwhelming the PE. 449 3. Security Considerations 451 This informational document characterizes potential security threats 452 targeting the Rserpool architecture. The security mechanisms 453 required to mitigate these threats are summarized for each 454 architectural component. It will be noted which mechanisms are 455 required and which are optional. 457 From the threats described in this document, the security services 458 required for the RSerPool protocol suite are given in the following 459 table. 461 +--------------+----------------------------------------------------+ 462 | Threat | Security mechanism in response | 463 +--------------+----------------------------------------------------+ 464 | Section 2.1 | ENRP server authenticates the PE. | 465 | Section 2.2 | ENRP server authenticates the PE. | 466 | Section 2.3 | ENRP server authenticates the PE. | 467 | Section 2.4 | ENRP server authenticates the PE. | 468 | Section 2.5 | ENRP servers mutually authenticate. | 469 | Section 2.6 | PE authenticates the ENRP server. | 470 | Section 2.7 | The PU authenticates the ENRP server. If the | 471 | | authentication fails, it looks for another ENRP | 472 | | server. | 473 | Section 2.8 | Security protocol which has protection from replay | 474 | | attacks. | 475 | Section 2.9 | Either notify the application when fail over | 476 | | occurs so the application can take appropriate | 477 | | action to establish a trusted relationship with PE | 478 | | B OR reestablish the security context | 479 | | transparently. | 480 | Section 2.10 | Security protocol which supports integrity | 481 | | protection. | 482 | Section 2.12 | Security protocol which supports data | 483 | | confidentiality. | 484 | Section 2.11 | The PU authenticates the ENRP server. If the | 485 | | authentication fails, it looks for another ENRP | 486 | | server. | 487 | Section 2.13 | ASAP must control the number of endpoint | 488 | | unreachable messages transmitted from the PU to | 489 | | the ENRP server. | 490 | Section 2.14 | ENRP server must control the number of | 491 | | Endpoint_KeepAlive messages to the PE. | 492 +--------------+----------------------------------------------------+ 494 The first four threats combined with the sixth threat result in a 495 requirement for mutual authentication of the ENRP server and the PE. 497 To summarize the first twelve threats require security mechanisms 498 which support authentication, integrity, data confidentiality and 499 protection from replay attacks. For RSerPool we need to authenticate 500 the following: 502 o PU -----> ENRP Server (PU authenticates the ENRP server) 504 o PE <----> ENRP Server (mutual authentication) 506 o ENRP server <-----> ENRP Server (mutual authentication) 508 Summary by component: 510 RSerPool client -- mandatory to implement authentication of the ENRP 511 server is required for accurate pool handle resolution. This is 512 to protect against threats from rogue ENRP servers. In addition, 513 confidentiality, integrity and preventing replay attack are also 514 mandatory to implement to protect from eavesdropping and data 515 corruption or false data transmission. Confidentiality is 516 mandatory to implement and is used when privacy is required. 518 PE to ENRP communications -- mandatory to implement mutual 519 authentication, integrity and protection from replay attack is 520 required for PE to ENRP communications. This is to protect the 521 integrity of the ENRP handle space database. Confidentiality is 522 mandatory to implement and is used when privacy is required. 524 ENRP to ENRP communications -- mandatory to implement mutual 525 authentication, integrity and protection from replay attack is 526 required for ENRP to ENRP communications. This is to protect the 527 integrity of the ENRP handle space database. Confidentiality is 528 mandatory to implement and is used when privacy is required. 530 3.1. Security of the ENRP Database 532 Another consideration involves the security characteristics of the 533 ENRP database. Suppose that some of the PEs register with an ENRP 534 server using security and some do not. In this case, when a client 535 requests handle space resolution information from ENRP, it would have 536 to be informed which entries are "secure" and which are not. This 537 would not only complicate the protocol, but actually bring into 538 question the security and integrity of such a database. What can be 539 asserted about the security of such a database is a very thorny 540 question. Due to these two facts it was decided that either the 541 entire ENRP server database is secure, that is, it has registrations 542 exclusively from PEs that have used security mechanisms or the entire 543 database is insecure, that is, registrations are from PEs that have 544 used no security mechanisms. ENRP servers that support security are 545 required to reject any PE server registration that does not use the 546 security mechanisms. Likewise, ENRP servers that support security 547 should not accept updates from other ENRP servers that do not use 548 security mechanisms. 550 3.2. Cookie mechanism security 552 The application layer is out of scope for RSerPool. However, some 553 questions have been raised about the security of the cookie mechanism 554 which will be addressed. 556 Cookies are passed via the ASAP control channel. If TCP is selected 557 as the transport, the data and control channel must always be 558 multiplexed. Therefore, the cases: 560 a. control channel is secured; data channel is not 562 b. data channel is secured; control channel is not 564 are not allowed. It is even hard to understand what this really 565 means from a security point of view. 567 The multiplexing requirement results in the following cases: 569 1. the multiplexed control channel-data channel is secure OR 571 2. the multiplexed control channel-data channel is not secured 573 This applies to cookies in the sense that if you choose to secure 574 your control-data channel, then the cookies are secured. 576 A second issue is that the PE could choose to sign and/or encrypt the 577 cookie. In this case, it must share keys and other information with 578 other PEs. This application level state sharing is out of scope of 579 Rserpool. 581 4. IANA Considerations 583 This document introduces no additional considerations for IANA. 585 5. References 587 5.1. Normative References 589 [1] Lei, P., "An Overview of Reliable Server Pooling Protocols", 590 draft-ietf-rserpool-overview-02 (work in progress), July 2007. 592 5.2. Informative References 594 [2] Bradner, S., "The Internet Standards Process -- Revision 3", 595 BCP 9, RFC 2026, October 1996. 597 [3] Schiller, J., "Strong Security Requirements for Internet 598 Engineering Task Force Standard Protocols", BCP 61, RFC 3365, 599 August 2002. 601 Authors' Addresses 603 Maureen Stillman (editor) 604 Nokia 605 35 Woodcrest Avenue 606 Ithaca, NY 14850 607 US 609 Email: maureen.stillman@nokia.com 611 Ram Gopal 612 Nokia Research Center 613 5 Wayside Road 614 Burlington, MA 01803 615 US 617 Email: ram.gopal@nokia.com 619 Erik Guttman 620 Sun Microsystems 621 Eichhoelzelstrasse 7 622 74915 Waibstadt 623 DE 625 Email: Erik.Guttman@sun.com 627 Matt Holdrege 628 Strix Systems 629 26610 Agoura Road 630 Suite 110 631 Calabasas, CA 91302 632 US 634 Email: matt@strixsystems.com 636 Senthil Sengodan 637 Nokia Research Center 638 5 Wayside Road 639 Burlington, MA 01803 640 US 642 Email: Senthil.sengodan@nokia.com 644 Full Copyright Statement 646 Copyright (C) The IETF Trust (2007). 648 This document is subject to the rights, licenses and restrictions 649 contained in BCP 78, and except as set forth therein, the authors 650 retain all their rights. 652 This document and the information contained herein are provided on an 653 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 654 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 655 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 656 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 657 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 658 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 660 Intellectual Property 662 The IETF takes no position regarding the validity or scope of any 663 Intellectual Property Rights or other rights that might be claimed to 664 pertain to the implementation or use of the technology described in 665 this document or the extent to which any license under such rights 666 might or might not be available; nor does it represent that it has 667 made any independent effort to identify any such rights. Information 668 on the procedures with respect to rights in RFC documents can be 669 found in BCP 78 and BCP 79. 671 Copies of IPR disclosures made to the IETF Secretariat and any 672 assurances of licenses to be made available, or the result of an 673 attempt made to obtain a general license or permission for the use of 674 such proprietary rights by implementers or users of this 675 specification can be obtained from the IETF on-line IPR repository at 676 http://www.ietf.org/ipr. 678 The IETF invites any interested party to bring to its attention any 679 copyrights, patents or patent applications, or other proprietary 680 rights that may cover technology that may be required to implement 681 this standard. Please address the information to the IETF at 682 ietf-ipr@ietf.org. 684 Acknowledgment 686 Funding for the RFC Editor function is provided by the IETF 687 Administrative Support Activity (IASA).