idnits 2.17.1 draft-ietf-ospf-ospfv3-auth-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.a on line 14. -- Found old boilerplate from RFC 3978, Section 5.5 on line 540. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 551. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 562. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 562. ** The document seems to lack an RFC 3978 Section 5.1 IPR Disclosure Acknowledgement -- however, there's a paragraph with a matching beginning. Boilerplate error? ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** The document seems to lack an RFC 3978 Section 5.4 Reference to BCP 78 -- however, there's a paragraph with a matching beginning. Boilerplate error? ** 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. ** The document uses RFC 3667 boilerplate or RFC 3978-like boilerplate instead of verbatim RFC 3978 boilerplate. After 6 May 2005, submission of drafts without verbatim RFC 3978 boilerplate is not accepted. The following non-3978 patterns matched text found in the document. That text should be removed or replaced: 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 BCP 79. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 12 longer pages, the longest (page 3) being 71 lines == It seems as if not all pages are separated by form feeds - found 0 form feeds but 13 pages 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 (October 2004) is 7132 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Missing reference section? 'N7' on line 46 looks like a reference -- Missing reference section? 'N1' on line 70 looks like a reference -- Missing reference section? 'N2' on line 296 looks like a reference -- Missing reference section? 'N5' on line 81 looks like a reference -- Missing reference section? 'N4' on line 82 looks like a reference -- Missing reference section? 'N3' on line 163 looks like a reference -- Missing reference section? 'I1' on line 84 looks like a reference -- Missing reference section? 'N6' on line 167 looks like a reference Summary: 7 errors (**), 0 flaws (~~), 4 warnings (==), 15 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Network Working Group M. Gupta 2 Internet Draft Nokia 3 Document: draft-ietf-ospf-ospfv3-auth-05.txt N. Melam 4 Expires: April 2005 Nokia 5 October 2004 7 Authentication/Confidentiality for OSPFv3 9 Status of this Memo 11 By submitting this Internet-Draft, each author represents that any 12 applicable patent or other IPR claims of which he or she is aware 13 have been or will be disclosed, and any of which he or she becomes 14 aware will be disclosed, in accordance with Section 6 of RFC 3668. 16 Internet-Drafts are working documents of the Internet Engineering 17 Task Force (IETF), its areas, and its working groups. Note that 18 other groups may also distribute working documents as Internet- 19 Drafts. 21 Internet-Drafts are draft documents valid for a maximum of six months 22 and may be updated, replaced, or obsoleted by other documents at any 23 time. It is inappropriate to use Internet-Drafts as reference 24 material or to cite them other than as "work in progress." 26 The list of current Internet-Drafts can be accessed at 27 http://www.ietf.org/ietf/1id-abstracts.txt 29 The list of Internet-Draft Shadow Directories can be accessed at 30 http://www.ietf.org/shadow.html. 32 Abstract 34 This document describes means/mechanisms to provide 35 authentication/confidentiality to OSPFv3 using an IPv6 AH/ESP 36 Extension Header. 38 Copyright Notice 39 Copyright (C) The Internet Society. (2004) 41 Conventions used in this document 43 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 44 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 45 document are to be interpreted as described in RFC-2119 [N7]. 47 Table of Contents 49 1. Introduction...................................................2 50 2. Transport Mode vs Tunnel Mode..................................2 51 3. Authentication.................................................3 52 4. Confidentiality................................................3 53 5. Distinguishing OSPFv3 from OSPFv2..............................4 54 6. IPsec Requirements.............................................4 55 7. Key Management.................................................4 56 8. SA Granularity and Selectors...................................6 57 9. Virtual Links..................................................7 58 10. Changing Keys.................................................8 59 11. IPsec rules...................................................8 60 12. Mandatory Encryption and Authentication Algorithms...........10 61 13. Replay Protection............................................10 62 Security Considerations..........................................10 63 Normative References.............................................11 64 Informative References...........................................11 65 Acknowledgments..................................................11 66 Authors' Addresses...............................................12 68 1. Introduction 70 OSPF (Open Shortest Path First) Version 2 [N1] defines fields AuType 71 and Authentication in its protocol header in order to provide 72 security. In OSPF for IPv6 (OSPFv3) [N2], both of the authentication 73 fields were removed from OSPF headers. OSPFv3 relies on the 74 IPv6 Authentication Header (AH) and IPv6 Encapsulating Security 75 Payload (ESP) to provide integrity, authentication and/or 76 confidentiality. 78 This document describes how IPv6 AH/ESP extension headers can be used 79 to provide authentication/confidentiality to OSPFv3. 81 It is assumed that the reader is familiar with OSPFv3 [N2], AH [N5], 82 ESP [N4], the concept of security associations, tunnel and transport 83 mode of IPsec and the key management options available for AH and ESP 84 (manual keying [N3] and Internet Key Exchange (IKE)[I1]). 86 2. Transport Mode vs Tunnel Mode 88 Transport mode Security Association (SA) is the security association 89 between two hosts or routers/gateways when they are acting as hosts. 90 SA must be tunnel mode if either end of the security association is a 91 router/gateway. OSPFv3 packets are exchanged between the routers but 92 as the packets are destined to the routers, the routers act like 93 hosts in this case. So transport mode SA MUST be used in order to 94 provide required security to OSPFv3. 96 3. Authentication 98 Implementations conforming to this specification MUST support 99 Authentication for OSPFv3. 101 In order to provide authentication to OSPFv3, "ESP with NULL 102 encryption" MUST be supported and AH SHOULD be supported by the 103 implementation. 105 If "ESP with NULL encryption" in transport mode is used, it will 106 provide authentication to only OSPFv3 protocol headers but not to the 107 IPv6 header, extension headers and options. 109 If AH in transport mode is used, it will provide authentication to 110 OSPFv3 protocol headers, selected portions of IPv6 header, selected 111 portions of extension headers and selected options. 113 When OSPFv3 authentication is enabled, 115 O OSPFv3 packets that are not protected with AH or ESP MUST be 116 silently discarded. 118 O OSPFv3 packets that fail the authentication checks MUST be 119 silently discarded. 121 4. Confidentiality 123 Implementations conforming to this specification SHOULD support 124 confidentiality for OSPFv3. 126 If confidentiality is provided, "ESP with non-null encryption" MUST 127 be used. 129 When OSPFv3 confidentiality is enabled, 131 O OSPFv3 packets that are not protected with ESP MUST be silently 132 discarded. 134 O OSPFv3 packets that fail the confidentiality checks MUST be 135 silently discarded. 137 5. Distinguishing OSPFv3 from OSPFv2 139 The IP/IPv6 Protocol Type for OSPFv2 and OSPFv3 is same (89) and 140 OSPF distinguishes them based on the OSPF header version number. 141 However current IPsec standards do not allow using arbitrary protocol 142 specific header fields as the selectors. Therefore, in order to 143 distinguish OSPFv3 packets from the OSPFv2 packets, OSPF version 144 field in the OSPF header cannot be used. As OSPFv2 is only for IPv4 145 and OSPFv3 is only for IPv6, version field in IP header can be used 146 to distinguish OSPFv3 packets from OSPFv2 packets. 148 6. IPsec Requirements 150 In order to implement this specification, the following IPsec 151 capabilities are required. 153 Transport Mode 154 IPsec in transport mode MUST be supported. [N3] 156 Traffic Selectors 157 The implementation MUST be able to use interface index, source 158 address, destination address, protocol and direction for choosing 159 the right security action. 161 Manual key support 162 Manually configured keys MUST be able to secure the specified 163 traffic. [N3] 165 Encryption and Authentication Algorithms 166 AES-CBC and HMAC-SHA1 MUST be supported as the encryption and the 167 authentication algorithms respectively. [N6] 169 Dynamic IPsec rule configuration 170 Routing module SHOULD be able to configure, modify and delete 171 IPsec rules on the fly. This is needed mainly for securing 172 virtual links. 174 7. Key Management 176 OSPFv3 exchanges both multicast and unicast packets. While running 177 OSPFv3 over a broadcast interface, the authentication/confidentiality 178 required is "one to many". Since IKE is based on the Diffie-Hellman 179 key agreement protocol and works only for two communicating parties, 180 it is not possible to use IKE for providing the required "one to 181 many" authentication/confidentiality. Manual keying MUST be used for 182 this purpose. In manual keying SAs are statically installed on the 183 routers and these static SAs are used to authenticate/encrypt the 184 packets. 186 The following discussion explains that it is not scalable and 187 practically infeasible to use different security associations for 188 inbound and outbound traffic in order to provide the required "one to 189 many" security. Therefore, the implementations MUST use manually 190 configured keys with same SA for inbound and outbound traffic (as 191 shown in Figure 3). 193 A | 194 SAa ------------>| 195 SAb <------------| 196 | 197 B | 198 SAb ------------>| 199 SAa <------------| Figure: 1 200 | 201 C | 202 SAa/SAb ------------>| 203 SAa/SAb <------------| 204 | 205 Broadcast 206 Network 208 If we consider communication between A and B in Figure 1, everything 209 seems to be fine. A uses security association SAa for outbound 210 packets and B uses the same for inbound packets and vice versa. Now 211 if we include C in the group and C sends a packet out using SAa then 212 only A will be able to understand it or if C sends the packets out 213 using SAb then only B will be able to understand it. Since the 214 packets are multicast packets and they are going to be processed by 215 both A and B, there is no SA for C to use so that A and B both can 216 understand it. 218 A | 219 SAa ------------>| 220 SAb <------------| 221 SAc <------------| 222 | 223 B | 224 SAb ------------>| 225 SAa <------------| Figure: 2 226 SAc <------------| 227 | 229 C | 230 SAc ------------>| 231 SAa <------------| 232 SAb <------------| 233 | 234 Broadcast 235 Network 237 The problem can be solved by configuring SAs for all the nodes on all 238 the nodes as shown in Figure 2. So A, B and C will use SAa, SAb and 239 SAc respectively for outbound traffic. Each node will lookup the SA 240 to be used based on the source (A will use SAb and SAc for packets 241 received from B and C respectively). This solution is not scalable 242 and practically infeasible because every node will need to be 243 configured with a large number of SAs and addition of a node in the 244 network will cause addition of another SA on all the nodes. 246 A | 247 SAs ------------>| 248 SAs <------------| 249 | 250 B | 251 SAs ------------>| 252 SAs <------------| Figure: 3 253 | 254 C | 255 SAs ------------>| 256 SAs <------------| 257 | 258 Broadcast 259 Network 261 The problem can also be solved by using the same SA for inbound and 262 outbound traffic as shown in Figure 3. 264 8. SA Granularity and Selectors 266 The user SHOULD be given a choice to share the same SA among multiple 267 interfaces or using unique SA per interface. 269 OSPFv3 supports running multiple instances over one interface using 270 the "Instance Id" field contained in the OSPFv3 header. As IPsec 271 does not support arbitrary fields in protocol header to be used as 272 the selectors, it is not possible to use different SAs for different 273 instances of OSPFv3 running over the same interface. Therefore, all 274 the instances of OSPFv3 running over the same interface will have to 275 use the same SA. In OSPFv3 RFC terminology, SAs are per-link and not 276 per-interface. 278 9. Virtual Links 280 Different SA than the SA of underlying interface MUST be provided for 281 virtual links. Packets sent out on virtual links use unicast non- 282 link local IPv6 addresses as the IPv6 source address and all the 283 other packets use multicast and unicast link local addresses. This 284 difference in the IPv6 source address is used in order to 285 differentiate the packets sent on interfaces and virtual links. 287 As the end point IP addresses of the virtual links are not known at 288 the time of configuration, the secure channel for these packets needs 289 to be set up dynamically. The end point IP addresses of virtual 290 links are learned during the routing table build up process. The 291 packet exchange over the virtual links starts only after the 292 discovery of end point IP addresses. In order to provide security to 293 these exchanges, the routing module should setup a secure IPsec 294 channel dynamically once it acquires the required information. 296 According to the OSPFv3 RFC [N2], the virtual neighbor's IP address 297 is set to the first prefix with the "LA-bit" set from the list of 298 prefixes in intra-area-prefix-LSAs originated by the virtual 299 neighbor. But when it comes to choosing the source address for the 300 packets that are sent over the virtual link, the RFC simply suggests 301 using one of the router's own site-local or global IPv6 addresses. 302 In order to install the required security rules for virtual links, 303 the source address also needs to be predictable. So the routers that 304 implement this specification MUST change the way the source and 305 destination addresses are chosen for the packets exchanged over 306 virtual links when the security is enabled on that virtual link. 308 The first IPv6 address with the "LA-bit" set in the list of prefixes 309 advertised in intra-area-prefix-LSAs in the transit area MUST be used 310 as the source address for packets exchanged over the virtual link. 311 When multiple intra-area-prefix-LSAs are originated they are 312 considered as being concatenated and are ordered by ascending Link 313 State ID. 315 The first IPv6 address with the "LA-bit" set in the list of prefixes 316 received in intra-area-prefix-LSAs from the virtual neighbor in the 317 transit area MUST be used as the destination address for packets 318 exchanged over the virtual link. When multiple intra-area-prefix- 319 LSAs are received they are considered as being concatenated and are 320 ordered by ascending Link State ID. 322 This makes both the source and destination addresses of the packets 323 exchanged over the virtual link, predictable on both the routers for 324 security purposes. 326 10. Changing Keys 328 To maintain the security of a link, the key values SHOULD be changed 329 from time to time. The following three-step procedure SHOULD be 330 provided to rekey the routers on a link without dropping OSPFv3 331 protocol packets or disrupting the adjacency. 333 (1) For every router on the link, create an additional inbound SA for 334 the interface being rekeyed using a new SPI and the new key. 336 (2) For every router on the link, replace the original outbound SA 337 with one using the new SPI and key values. The SA replacement 338 operation should be atomic with respect to sending OSPFv3 packets 339 on the link so that no OSPFv3 packets are sent without 340 authentication/encryption. 342 (3) For every router on the link, remove the original inbound SA. 344 Note that all the routers on the link must complete step 1 before any 345 begin step 2. Likewise, all the routers on the link must complete 346 step 2 before any begin step 3. 348 One way to control the progression from one step to the next is for 349 each router to have a configurable time constant KeyRolloverInterval. 350 After the router begins step 1 on a given link, it waits for this 351 interval and then moves to step 2. Likewise, after moving to step 2, 352 it waits for this interval and then moves to step 3. 354 In order to achieve smooth key transition, all the routers on a link 355 should use the same value for KeyRolloverInterval, and should 356 initiate the key rollover process within this time period. 358 At the end of this procedure, all the routers will have a single 359 inbound and outbound SA for OSPFv3 on the link with the new SPI and 360 key values. 362 11. IPsec rules 364 The following set of transport mode rules can be installed in a 365 typical IPsec implementation to provide the 366 authentication/confidentiality to OSPFv3 packets. 368 Outbound Rules for interface running OSPFv3 security: 370 No. source destination protocol action 371 1 fe80::/10 any OSPF apply 373 Outbound Rules for virtual links running OSPFv3 security: 375 No. source destination protocol action 376 2 src/128 dst/128 OSPF apply 378 Inbound Rules for interface running OSPFv3 security: 380 No. source destination protocol action 381 3 fe80::/10 any ESP/OSPF or AH/OSPF apply 382 4 fe80::/10 any OSPF drop 384 Inbound Rules for virtual links running OSPFv3 security: 386 No. source destination protocol action 387 5 src/128 dst/128 ESP/OSPF or AH/OSPF apply 388 6 src/128 dst/128 OSPF drop 390 For outbound rules, action "apply" means encrypting/calculating ICV 391 and adding ESP or AH header. For inbound rules, action "apply" means 392 decrypting/authenticating the packets and stripping ESP or AH header. 394 Rules 4 and 6 are to drop the insecure OSPFv3 packets without ESP/AH 395 headers. 397 ESP/OSPF or AH/OSPF in rules 3 and 5 mean that it is an OSPF packet 398 secured with ESP or AH. 400 Rules 1, 3 and 4 are meant to secure the unicast and multicast OSPF 401 packets that are not being exchanged over the virtual links. These 402 rules MUST be installed only in the security policy database (SPD) of 403 the interface running OSPFv3 security. 405 Rules 2, 5 and 6 are meant to secure the packets being exchanged over 406 virtual links. These rules are dynamically installed after learning 407 the end point IP addresses of a virtual link. These rules MUST be 408 installed on at least the interfaces that are connected to the 409 transit area for the virtual link. These rules MAY alternatively be 410 installed on all the interfaces. If these rules are not installed on 411 all the interfaces, clear text or malicious OSPFv3 packets with same 412 source and destination addresses as virtual link end point addresses 413 will be delivered to OSPFv3. Though OSPFv3 drops these packets 414 because they were not received on the right interface, OSPFv3 415 receives some clear text or malicious packets even when the security 416 is on. Installing these rules on all the interfaces insures that 417 OSPFv3 does not receive these clear text or malicious packets when 418 security is turned on. On the other hand installing these rules on 419 all the interfaces increases the processing overhead on the 420 interfaces where there is no IPsec processing otherwise. The 421 decision of installing these rules on all the interfaces or on just 422 the interfaces that are connected to the transit area is a private 423 decision and doesn't affect the interoperability in any way. So this 424 decision is left to the implementers. 426 12. Mandatory Encryption and Authentication Algorithms 428 The implementation MUST allow the user to choose AES-CBC as the 429 encryption algorithm and HMAC-SHA1 as the authentication algorithm 430 for securing OSPFv3 packets. 432 The implementation MUST NOT allow the user to choose stream ciphers 433 as the encryption algorithm for securing OSPFv3 packets as the stream 434 ciphers are not suitable for manual keys. 436 13. Replay Protection 438 As it is not possible as per the current standards to provide 439 complete replay protection while using manual keying, the proposed 440 solution will not provide protection against replay attacks. 442 Fields LS age, LS Sequence Number and LS checksum in LSA header are 443 kept intact in OSPFv3. Though these fields do not provide the 444 complete protection, they certainly help against replay attacks. 446 Security Considerations 448 This memo discusses the use of IPsec AH and ESP headers in order to 449 provide security to OSPFv3 for IPv6. Hence security permeates 450 throughout this document. 452 This specification mandates the usage of manual keys. The following 453 are the known limitations of the usage of manual keys. 455 O Manual keys are usually long lived (changing them very often is 456 a tedious task). This gives an attacker enough time to discover 457 the keys. 459 O As the administrator is manually configuring the keys, there is 460 a chance that the configured keys are weak (there are known weak 461 keys for DES/3DES at least). 463 O As the sequence numbers can not be negotiated, replay protection 464 can not be provided. 466 Inspite of the above known limitations, the security provided by the 467 usage of the manual keys should be adequate for a routing protocol. 469 Normative References 471 N1. Moy, J., "OSPF version 2", RFC 2328, April 1998 473 N2. Coltun, R., Ferguson, D. and J. Moy, "OSPF for IPv6", RFC 2740, 474 December 1999 476 N3. Kent, S. and K. Seo, "Security Architecture for the Internet 477 Protocol", RFC XXXX, date [Note to RFC-Editor: Replace XXXX with 478 the number of the RFC 2401 replacement]. 480 N4. Kent, S., "IP Encapsulating Security Payload (ESP)", RFC XXXY, 481 date [Note to RFC-Editor: Replace XXXY with the number of the RFC 482 2406 replacement]. 484 N5. Kent, S., "IP Authentication Header (AH)", RFC XXXZ, date [Note to 485 RFC-Editor: Replace XXXZ with the number of the RFC 2402 486 replacement]. 488 N6. Eastlake, D., "Cryptographic Algorithm Implementation Requirements 489 For ESP And AH", RFC XXYY, date [Note to RFC-Editor: Replace XXYY 490 with the number of the RFC that the draft draft-ietf-ipsec-esp-ah- 491 algorithms-02.txt gets]. 493 N7. Bradner, S., "Key words for use in RFCs to Indicate Requirement 494 Level", BCP 14, RFC 2119, March 1997. 496 Informative References 498 I1. Kaufman, C., "The Internet Key Exchange (IKEv2) Protocol", RFC 499 XXZZ, date [Note to RFC-Editor: Replace XXZZ with the number of the 500 RFC 2409 replacement]. 502 Acknowledgments 504 Authors would like to extend sincere thanks to Marc Solsona, Janne 505 Peltonen, John Cruz, Dhaval Shah, Abhay Roy and Paul Wells for 506 providing useful information and critiques in order to write this 507 memo. 509 We would also like to thank IPsec and OSPF WG people to provide 510 valuable review comments. 512 Authors' Addresses 514 Mukesh Gupta 515 Nokia 516 313 Fairchild Drive 517 Mountain View, CA 94043 518 Phone: 650-625-2264 519 Email: Mukesh.Gupta@nokia.com 521 Nagavenkata Suresh Melam 522 Nokia 523 313 Fairchild Drive 524 Mountain View, CA 94043 525 Phone: 650-625-2949 526 Email: Nagavenkata.Melam@nokia.com 528 Full copyright statement 530 Copyright (C) The Internet Society (2004). This document is subject 531 to the rights, licenses and restrictions contained in BCP 78 and 532 except as set forth therein, the authors retain all their rights. 534 This document and the information contained herein are provided on an 535 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 536 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 537 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 538 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 539 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 540 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 542 Intellectual Property 544 The IETF takes no position regarding the validity or scope of any 545 Intellectual Property Rights or other rights that might be claimed to 546 pertain to the implementation or use of the technology described in 547 this document or the extent to which any license under such rights 548 might or might not be available; nor does it represent that it has 549 made any independent effort to identify any such rights. Information 550 on the procedures with respect to rights in RFC documents can be 551 found in BCP 78 and BCP 79. 553 Copies of IPR disclosures made to the IETF Secretariat and any 554 assurances of licenses to be made available, or the result of an 555 attempt made to obtain a general license or permission for the use of 556 such proprietary rights by implementers or users of this 557 specification can be obtained from the IETF on-line IPR repository at 558 http://www.ietf.org/ipr. The IETF invites any interested party to 559 bring to its attention any copyrights, patents or patent 560 applications, or other proprietary rights that may cover technology 561 that may be required to implement this standard. Please address the 562 information to the IETF at ietf-ipr@ietf.org.