Network Working Group M. Gupta Internet Draft
NokiaTropos Networks Document: draft-ietf-ospf-ospfv3-auth-07.txtdraft-ietf-ospf-ospfv3-auth-08.txt N. Melam Expires: August 2005 NokiaAug 2006 Juniper Networks February 20052006 Authentication/Confidentiality for OSPFv3 Status of this Memo By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of RFC 3668.BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. Abstract This document describes means/mechanisms to provide authentication/confidentiality to OSPFv3 using an IPv6 AH/ESP Extension Header. Copyright Notice Copyright (C) The Internet Society. (2004)Society (2006). Conventions used in this document The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC-2119 [N7]. Table of Contents 1. Introduction...................................................2 2. Transport Mode vs Tunnel Mode..................................2Mode..................................3 3. Authentication.................................................3 4. Confidentiality................................................3 5. Distinguishing OSPFv3 from OSPFv2..............................4 6. IPsec Requirements.............................................4 7. Key Management.................................................5 8. SA Granularity and Selectors...................................7 9. Virtual Links..................................................7 10. Rekeying......................................................8Rekeying......................................................9 10.1 Rekeying Procedure........................................8Procedure........................................9 10.2 KeyRolloverInterval.......................................9 10.3 Rekeying Interval.........................................9Interval........................................10 11. IPsec rules..................................................10Protection Barrier and SPD.............................10 12. Entropy of manual keys.......................................11 13. Replay Protection............................................11Protection............................................12 Security Considerations..........................................11Considerations..........................................12 IANA Considerations..............................................13 Normative References.............................................12References.............................................13 Informative References...........................................13 Acknowledgments..................................................13Acknowledgments..................................................14 Authors' Addresses...............................................14 1. Introduction OSPF (Open Shortest Path First) Version 2 [N1] defines the fields AuType and Authentication in its protocol header in orderto provide security. In OSPF for IPv6 (OSPFv3) [N2], both of the authentication fields were removed from OSPF headers. OSPFv3 relies on the IPv6 Authentication Header (AH) and IPv6 Encapsulating Security Payload (ESP) to provide integrity, authentication and/or confidentiality. This document describes how IPv6 AH/ESP extension headers can be used to provide authentication/confidentiality to OSPFv3. It is assumed that the reader is familiar with OSPFv3 [N2], AH [N5], ESP [N4], the concept of security associations, tunnel and transport mode of IPsec and the key management options available for AH and ESP (manual keying [N3] and Internet Key Exchange (IKE)[I1]). 2. Transport Mode vs Tunnel Mode TransportThe transport mode Security Association (SA) is generally used between two hosts or routers/gateways when they are acting as hosts. The SA must be a tunnel mode SA if either end of the security association is a router/gateway. Two hosts MAY establish a tunnel mode SA between themselves. OSPFv3 packets are exchanged between the routers but asrouters. However, since the packets are destined to the routers,locally delivered, the routers act likeassume the role of hosts in this case.the context of tunnel mode SA. All implementations confirming to this specification MUST support Transport mode SA to provide required IPsec security to OSPFv3 packets. They MAY also support Tunnel mode SA to provide required IPsec security to OSPFv3 packets. 3. Authentication Implementations conforming to this specification MUST support Authentication for OSPFv3. In order to provide authentication to OSPFv3, ESPimplementations MUST be supportedsupport ESP and AHMAY be supported by the implementation.support AH. If ESP in transport mode is used, it will only provide authentication to onlyOSPFv3 protocol headers but not topacket excluding the IPv6 header, extension headers and options. If AH in transport mode is used, it will provide authentication to OSPFv3 protocol headers,packet, selected portions of IPv6 header, selected portions of extension headers and selected options. When OSPFv3 authentication is enabled, O OSPFv3 packets that are not protected with AH or ESP MUST be silently discarded. O OSPFv3 packets that fail the authentication checks MUST be silently discarded. 4. Confidentiality Implementations conforming to this specification SHOULD support confidentiality for OSPFv3. If confidentiality is provided, ESP MUST be used. When OSPFv3 confidentiality is enabled, O OSPFv3 packets that are not protected with ESP MUST be silently discarded. O OSPFv3 packets that fail the confidentiality checks MUST be silently discarded. 5. Distinguishing OSPFv3 from OSPFv2 The IP/IPv6 Protocol Type for OSPFv2 and OSPFv3 is the same (89) and OSPF distinguishes them based on the OSPF header version number. HoweverHowever, current IPsec standards do not allow using arbitrary protocol specific header fields as the selectors. Therefore, in order to distinguish OSPFv3 packets fromthe OSPFv2 packets,OSPF version field in the OSPF header cannot be used.used in order to distinguish OSPFv3 packets from OSPFv2 packets. As OSPFv2 is only for IPv4 and OSPFv3 is only for IPv6, version field in IP header can be used to distinguish OSPFv3 packets from OSPFv2 packets. 6. IPsec Requirements In order to implement this specification, the following IPsec capabilities are required. Transport Mode IPsec in transport mode MUST be supported. [N3] TrafficMultiple SPDs The implementation MUST support multiple SPDs with a SPD selection function that provides an ability to choose a specific SPD based on interface. [N3] Selectors The implementation MUST be able to use interface index,source address, destination address, protocol and direction for choosingas selectors in the right security action.SPD. Interface ID tagging The implementation MUST be able to tag the inbound packets with the ID of the interface (physical or virtual) via which it arrived. [N3] Manual key support Manually configured keys MUST be able to secure the specified traffic. [N3] Encryption and Authentication Algorithms The implementation MUST NOT allow the user to choose stream ciphers as the encryption algorithm for securing OSPFv3 packets assince the stream ciphers are not suitable for manual keys. Except when in conflict with the above statement, the Keywords "MUST", "MUST NOT", "REQUIRED", "SHOULD" and "SHOULD NOT" that appear in the [N6] document for algorithms to be supported are to be interpreted as described in [N7] for OSPFv3 support too.as well. Dynamic IPsec rule configuration RoutingThe routing module SHOULD be able to configure, modify and delete IPsec rules on the fly. This is needed mainly for securing virtual links. Encapsulation of ESP packet IP encapsulation of ESP packets MUST be supported. For simplicity, UDP encapsulation of ESP packets SHOULD NOT be used. Different SAs for different DSCPs As per [N3], the IPsec implementation MUST support the establishment and maintenance of multiple SAs with the same selectors between a given sender and receiver, with the same selectors.receiver. This allows the implementation to put traffic ofassociate different classes, butclasses of traffic with same selector values, on different SAs tovalues in support QoS appropriately.of QoS. 7. Key Management OSPFv3 exchanges both multicast and unicast packets. While running OSPFv3 over a broadcast interface, the authentication/confidentiality required is "one to many". Since IKE is based on the Diffie-Hellman key agreement protocol and works only for two communicating parties, it is not possible to use IKE for providing the required "one to many" authentication/confidentiality. This specification mandates the usage of Manual Keying to work with the current IPsec implementations. Future specifications can explore the usage of protocols like KINK/GSAKMP as andwhen they are widely available. In manual keyingkeying, SAs are statically installed on the routers and these static SAs are used to authenticate/encrypt thepackets. The following discussion explains that it is not scalable and is practically infeasible to use different security associations for inbound and outbound traffic in orderto provide the required "one to many" security. Therefore, the implementations MUST use manually configured keys with the same SA parameters (SPI, keys etc.,) for both inbound and outbound trafficSA (as shown in Figure 3). A | SAa ------------>| SAb <------------| | B | SAb ------------>| SAa <------------| Figure: 1 | C | SAa/SAb ------------>| SAa/SAb <------------| | Broadcast Network If we consider communication between A and B in Figure 1, everything seems to be fine. A uses security association SAa for outbound packets and B uses the same for inbound packets and vice versa. Now if we include C in the group and C sends a packet outusing SAa then only A will be able to understand it orit. Similarly, if C sends the packets outa packet using SAb then only B will be able to understand it. Since the packets are multicast packetsand they are going to be processed by both A and B, there is no SA for C to use so that both A and B bothcan understand it.them. A | SAa ------------>| SAb <------------| SAc <------------| | B | SAb ------------>| SAa <------------| Figure: 2 SAc <------------| | C | SAc ------------>| SAa <------------| SAb <------------| | Broadcast Network The problem can be solved by configuring SAs for all the nodes on all the nodesevery other node as shown in Figure 2. So A, B and C will use SAa, SAb and SAc respectively for outbound traffic. Each node will lookup the SA to be used based on the source (A will use SAb and SAc for packets received from B and C respectively). This solution is not scalable and practically infeasible because every node will need to be configured witha large number of SAs andwill need to be configured on each node. Also, the addition of a node in the broadcast network will causerequire the addition of another SA on all the nodes.every other node. A | SAsSAo ------------>| SAsSAi <------------| | B | SAsSAo ------------>| SAsSAi <------------| Figure: 3 | C | SAsSAo ------------>| SAsSAi <------------| | Broadcast Network The problem can alsobe solved by using the same SA parameters (SPI, Keys etc.,) for both inbound (SAi) and outbound traffic(SAo) SAs as shown in Figure 3. 8. SA Granularity and Selectors The user SHOULD be given athe choice to shareof sharing the same SA among multiple interfaces or using a unique SA per interface. OSPFv3 supports running multiple instances over one interface using the "Instance Id" field contained in the OSPFv3 header. As IPsec does not support arbitrary fields in protocol header to be used as the selectors, it is not possible to use different SAs for different instances ofOSPFv3 instances running over the same interface. Therefore, all the instances ofOSPFv3 instances running over the same interface will have to use the same SA. In OSPFv3 RFC terminology, SAs are per-link and not per-interface.per- interface. 9. Virtual Links DifferentA different SA than the SA of the underlying interface MUST be provided for virtual links. Packets sent outon virtual links use unicast non- linknon-link local IPv6 addresses as the IPv6 source address and all the otherwhile packets sent on other interfaces use multicast and unicast link local addresses. This difference in the IPv6 source address is used in order to differentiatedifferentiates the packets sent on interfaces andvirtual links.links from other OSPFv3 interface types. As the virtual link end point IPIPv6 addresses of the virtual linksare not known at the time of configuration, the secure channel for these packets needsknown, it is not possible to be set up dynamically.install SPD/SAD entries at the time of configuration. The virtual link end point IPIPv6 addresses of virtual linksare learned during the routing table build upcomputation process. The packet exchange over the virtual links starts only after the discovery of the end point IPIPv6 addresses. In order to provide security toprotect these exchanges, the routing module should setup a secure IPsec channel dynamically once it acquiresmust install the required information.corresponding SPD/SAD entries before starting these exchanges. Note that manual SA parameters are preconfigured but not installed in the SAD until the end point addresses are learned. According to the OSPFv3 RFC [N2], the virtual neighbor's IP address is set to the first prefix with the "LA-bit" set from the list of prefixes in intra-area-prefix-LSAs originated by the virtual neighbor. But when it comes to choosing the source address for the packets that are sent over the virtual link, the RFC simply suggests using one of the router's own site-local orglobal IPv6 addresses. In order to install the required security rules for virtual links, the source address also needs to be predictable. So theHence, routers that implement this specification MUST change the way the source and destination addresses are chosen for thepackets exchanged over virtual links when the securityIPsec is enabled on that virtual link.enabled. The first IPv6 address with the "LA-bit" set in the list of prefixes advertised in intra-area-prefix-LSAs in the transit area MUST be used as the source address for packets exchanged over the virtual link. When multiple intra-area-prefix-LSAs are originated they are considered as being concatenated and are ordered by ascending Link State ID. The first IPv6 address with the "LA-bit" set in the list of prefixes received in intra-area-prefix-LSAs from the virtual neighbor in the transit area MUST be used as the destination address for packets exchanged over the virtual link. When multiple intra-area-prefix- LSAs are received they are considered as being concatenated and are ordered by ascending Link State ID. This makes both the source and destination addresses of thepackets exchanged over the virtual link,link predictable on both the routers for security purposes.when IPsec is enabled. 10. Rekeying To maintain the security of a link, the authentication and encryption key values SHOULD be changed from time to time.periodically. 10.1 Rekeying Procedure The following three-step procedure SHOULD be provided to rekey the routers on a link without dropping OSPFv3 protocol packets or disrupting the adjacency. (1) For every router on the link, create an additional inbound SA for the interface being rekeyed using a new SPI and the new key. (2) For every router on the link, replace the original outbound SA with one using the new SPI and key values. The SA replacement operation should be atomic with respect to sending OSPFv3 packets on the link so that no OSPFv3 packets are sent without authentication/encryption. (3) For every router on the link, remove the original inbound SA. Note that all therouters on the link must complete step 1 before any begin step 2. Likewise, all the routers on the link must complete step 2 before any begin step 3. One way to control the progression from one step to the next is for each router to have a configurable time constant KeyRolloverInterval. After the router begins step 1 on a given link, it waits for this interval and then moves to step 2. Likewise, after moving to step 2, it waits for this interval and then moves to step 3. In order to achieve smooth key transition, all therouters on a link should use the same value for KeyRolloverInterval,KeyRolloverInterval and should initiate the key rollover process within this time period. At the end of this procedure, all the routers on the link will have a single inbound and outbound SA for OSPFv3 on the linkwith the new SPI and key values. 10.2 KeyRolloverInterval The configured value of KeyRolloverInterval should be long enough to allow the administrator to change keys on all the involvedOSPFv3 routers. As this value can vary significantly depending upon the implementation and the deployment, it is left to the administrator to choose the appropriate value. 10.3 Rekeying Interval This section analyzes the security provided by themanual keying and recommends that the encryption and authentication keys SHOULD be changed at least every 90 days. The weakest security provided by the security mechanisms discussed in this specification is when NULL encryption (for ESP) or no encryption (for AH) is used with the HMAC-MD5 authentication. Any other algorithm combinations will at least be as hard to break as the oneones mentioned above asabove. This is shown by the following examples:reasonable assumptions: O NULL Encryption and HMAC-SHA-1 Authentication will be more secure as HMAC-SHA-1 is considered to be more secure than HMAC-MD5HMAC-MD5. O NON-NULL Encryption and NULL Authentication is not applicable as this specification mandates theauthentication when OSPFv3 security is enabledenabled. O DES Encryption and HMAC-MD5 Authentication will be more secure because of the additional security provided by DESDES. O Other encryption algorithms like 3DES,3DES and AES will be more secure than DESDES. RFC 3562 [I4] analyzes the rekeying requirements for the TCP MD5 signature option. The analysis provided in this RFC is also applicable to OSPFv3 securitythis specification as the analysis is independent of data patterns. 11. IPsec rulesProtection Barrier and SPD The following set of transport mode rules can be installed in a typicalIPsec implementation to provideprotection barrier MUST BE around the authentication/confidentiality to OSPFv3 packets. Outbound RulesOSPF protocol. Therefore, all the inbound and outbound OSPF traffic goes through IPsec processing. The SPD selection function MUST return a SPD with the following rule for interface runningall the interfaces that have OSPFv3 security:authentication/confidentiality disabled. No. source destination protocol action 1 fe80::/10any any OSPF apply Outbound Rulesbypass The SPD selection function MUST return a SPD with the following rules for virtual links runningall the interfaces that have OSPFv3 security:authentication/confidentiality enabled. No. source destination protocol action 2 src/128 dst/128fe80::/10 any OSPF apply Inbound Rules for interface running OSPFv3 security: No. source destination protocol actionprotect 3 fe80::/10 any ESP/OSPF or AH/OSPF applyprotect 4 fe80::/10 anysrc/128 dst/128 OSPF drop Inbound Rules for virtual links running OSPFv3 security: No. source destination protocol actionprotect 5 src/128 dst/128 ESP/OSPF or AH/OSPF apply 6 src/128 dst/128 OSPF dropprotect For outbound rules,rules 2 and 4, action "apply""protect" means encrypting/calculating ICV and adding an ESP or AH header. For inbound rules,rules 3 and 5, action "apply""protect" means decrypting/authenticating the packets and stripping the ESP or AH header. Rule 1 will bypass the OSPFv3 packets without any IPsec processing on the interfaces that have OSPFv3 authentication/confidentiality disabled. Rules 42 and 6 are to4 will drop the insecureinbound OSPFv3 packets withoutthat have not been secured with ESP/AH headers. ESP/OSPF or AH/OSPF in rules 3 and 5 mean that it is an OSPF packet secured with ESP or AH. Rules 1, 32 and 43 are meant to secure the unicast and multicast OSPF packets that are not being exchanged over the virtual links. These rules MUST be installed only in the security policy database (SPD) of the interface running OSPFv3 security.Rules 2, 54 and 65 are meant to secure the packets being exchanged over virtual links. These rules are dynamicallyinstalled after learning the virtual link end point IP addresses of a virtual link.IPv6 addresses. These rules MUST be installed on at leastin the SPD for the interfaces that are connected to the transit area for the virtual link. These rules MAY alternatively be installed on all the interfaces. If these rules are not installed on all the interfaces, clear text or malicious OSPFv3 packets with the same source and destination addresses as the virtual link end point IPv6 addresses will be delivered to OSPFv3. Though OSPFv3 drops these packets because they were not received on the right interface, OSPFv3 receives some clear text or malicious packets even when the security is on.enabled. Installing these rules on all the interfaces insures that OSPFv3 does not receive these clear text or malicious packets when security is turned on.enabled. On the other handhand, installing these rules on all the interfaces increases the processing overhead on the interfaces where there is no other IPsec processing otherwise.processing. The decision of installing these rules on all the interfaces or on just the interfaces that are connected to the transit area is a private decision and doesn't affect the interoperability in any way. So this decisionHence it is left to the implementers.an implementation choice. 12. Entropy of manual keys The implementations MUST allow the administrator to configure the cryptographic and authentication keys in hexadecimal format instead ofrather than restricting it to a subset of ASCII characters (letters, numbers etc). Otherwise theA restricted character set will reduce key entropy of the keys reducessignificantly as discussed in [I2]. 13. Replay Protection AsSince it is not possible as perusing the current standards to provide complete replay protection while using manual keying, the proposed solution will not provide protection against replay attacks. Detailed analysis of various vulnerabilities of the routing protocols and OSPF in particular is discussed in [I3] and [I2], but it can be summarized[I2]. The conclusion is that "Replay of OSPF packets can cause adjacencies to be disrupted, which can lead to a DoS attack on the network. It can also cause database exchange process to occur continuously thus causing CPU overload as well as micro loops in the network". Security Considerations This memo discusses the use of IPsec AH and ESP headers in order to provide security to OSPFv3 for IPv6. Hence security permeates throughout this document. OSPF Security Vulnerabilities Analysis [I2] identifies OSPF vulnerabilities in two scenarios - One with no authentication or simple password authentication and the other with cryptographic authentication. The solution described in this specification provides securityprotection against all the vulnerabilities identified for scenarioscenarios with cryptographic authentication with the following exceptions: Limitations of manual key: This specification mandates the usage of manual keys. The following are the known limitations of the usage of manual keys. O As the sequence numbers can not be negotiated, replay protection can not be provided. This leaves OSPF insecure against all the attacks that can be performed by replaying OSPF packets. O Manual keys are usually long lived (changing them veryoften is a tedious task). This gives an attacker enough time to discover the keys. O As the administrator is manually configuring the keys, there is a chance that the configured keys are weak (there are known weak keys for DES/3DES at least). Impersonating Attacks: The usage of the same key on all the OSPF routers on the sameconnected to a link for securing OSPFleaves itthem all insecure against impersonating attacks if any one of the OSPF routers is compromised, malfunctioning or misconfigured. Detailed analysis of various vulnerabilities of therouting protocols is discussed in [I3]. IANA Considerations This document has no IANA considerations. This section should be removed by the RFC Editor to final publication. Normative References N1. Moy, J., "OSPF version 2", RFC 2328, April 1998. N2. Coltun, R., Ferguson, D. and J. Moy, "OSPF for IPv6", RFC 2740, December 1999. N3. Kent, S. and K. Seo, "Security Architecture for the Internet Protocol", RFC XXXX, date [Note to RFC-Editor: Replace XXXX with the number of the RFC 2401 replacement].4301, December 2005. N4. Kent, S., "IP Encapsulating Security Payload (ESP)", RFC XXXY, date [Note to RFC-Editor: Replace XXXY with the number of the RFC 2406 replacement].4303, December 2005. N5. Kent, S., "IP Authentication Header (AH)", RFC XXXZ, date [Note to RFC-Editor: Replace XXXZ with the number of the RFC 2402 replacement].4302, December 2005. N6. Eastlake, D., "Cryptographic Algorithm Implementation Requirements For ESP And AH", RFC XXYY, date [Note to RFC-Editor: Replace XXYY with the number of the RFC that the draft draft-ietf-ipsec-esp-ah- algorithms-02.txt gets].4305, December 2005. N7. Bradner, S., "Key words for use in RFCs to Indicate Requirement Level", BCP 14, RFC 2119, March 1997. N8. Frankel, S., Glenn, R. and S. Kelly, "The AES-CBC Cipher Algorithm and Its Use with IPsec", RFC 3602, September 2003. N9. Madson, C. and R. Glenn, "The Use of HMAC-SHA-1-96 within ESP and AH", RFC 2404, November 1998. Informative References I1. Kaufman, C., "The Internet Key Exchange (IKEv2) Protocol", RFC XXZZ, date [Note to RFC-Editor: Replace XXZZ with the number of the RFC 2409 replacement].4306, December 2005. I2. Jones, E. and O. Moigne, "OSPF Security Vulnerabilities Analysis", draft-ietf-rpsec-ospf-vuln-01.txt, work in progress. I3. Barbir, A., Murphy, S. and Y. Yang, "Generic Threats to Routing Protocols", draft-ietf-rpsec-routing-threats-07.txt, work in progress. I4. Leech, M., "Key Management Considerations for the TCP MD5 Signature Option", RFC 3562, July 2003. Acknowledgments Authors would like to extend sincere thanks to Marc Solsona, Janne Peltonen, John Cruz, Dhaval Shah, Abhay Roy, Paul Wells andWells, Vishwas Manral and Sam Hartman for providing useful information and critiques in order to write this memo. Authors would like to extend special thanks to Acee Lindem for lots of editorial changes. We would also like to thank IPsec and OSPF WG people to provide valuable review comments. Authors' Addresses Mukesh Gupta Nokia 313 Fairchild Drive Mountain View,Tropos Networks 555 Del Rey Ave Sunnyvale, CA 9404394085 Phone: 650-625-2264408-331-6889 Email: Mukesh.Gupta@firstname.lastname@example.org Nagavenkata Suresh Melam Nokia 313 Fairchild Drive Mountain View,Juniper Networks 1194 N. Mathilda Ave Sunnyvale, CA 9404394089 Phone: 650-625-2949408-505-4392 Email: Nagavenkata.Melam@email@example.com Full copyright statement Copyright (C) The Internet Society (2004).This document is subject to the rights, licenses and restrictions contained in BCP 7878, and except as set forth therein, the authors retain all their rights. This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Intellectual Property The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at firstname.lastname@example.org.