idnits 2.17.1 draft-liu-ospfv3-automated-keying-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 18. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 593. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 564. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 571. ** The document seems to lack an RFC 3979 Section 5, para. 3 IPR Disclosure Invitation -- however, there's a paragraph with a matching beginning. Boilerplate error? Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents -- however, there's a paragraph with a matching beginning. Boilerplate error? ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** There are 4 instances of too long lines in the document, the longest one being 1 character in excess of 72. ** The abstract seems to contain references ([RFC4046]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. 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 (July 7, 2007) is 6138 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) == Unused Reference: 'RFC2119' is defined on line 468, but no explicit reference was found in the text == Unused Reference: 'RFC2234' is defined on line 471, but no explicit reference was found in the text == Unused Reference: 'RFC4552' is defined on line 499, but no explicit reference was found in the text == Unused Reference: 'RFC4593' is defined on line 502, but no explicit reference was found in the text ** Obsolete normative reference: RFC 2234 (Obsoleted by RFC 4234) ** Obsolete normative reference: RFC 2740 (Obsoleted by RFC 5340) ** Obsolete normative reference: RFC 3547 (Obsoleted by RFC 6407) ** Downref: Normative reference to an Informational RFC: RFC 3740 ** Downref: Normative reference to an Informational RFC: RFC 4046 ** Downref: Normative reference to an Informational RFC: RFC 4593 Summary: 12 errors (**), 0 flaws (~~), 6 warnings (==), 6 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Internet Engineering Task Force Y. Liu 2 Internet Draft Huawei 3 Expires: January 2008 R. White 4 B. Weis 5 M. Barnes 6 Cisco 7 July 7, 2007 9 OSPFv3 Automated Group Keying Requirements 10 draft-liu-ospfv3-automated-keying-req-01.txt 12 Status of this Memo 14 By submitting this Internet-Draft, each author represents that 15 any applicable patent or other IPR claims of which he or she is 16 aware have been or will be disclosed, and any of which he or she 17 becomes aware will be disclosed, in accordance with Section 6 of 18 BCP 79. 20 This document MAY only be posted in an Internet-Draft. 22 Internet-Drafts are working documents of the Internet Engineering 23 Task Force (IETF), its areas, and its working groups. Note that 24 other groups MAY also distribute working documents as Internet-Drafts. 26 Internet-Drafts are draft documents valid for a maximum of six months 27 and MAY be updated, replaced, or obsoleted by other documents at any 28 time. It is inappropriate to use Internet-Drafts as reference 29 material or to cite them other than as "work in progress." 31 The list of current Internet-Drafts can be accessed at 32 http://www.ietf.org/ietf/1id-abstracts.txt 34 The list of Internet-Draft Shadow Directories can be accessed at 35 http://www.ietf.org/shadow.html 37 This Internet-Draft will expire on January 26, 2008. 39 Copyright Notice 41 Copyright (C) The IETF Trust (2007). 43 Abstract 45 RFC4552 describes how to provide authentication/confidentiality to 46 OSPFv3 using IPsec. It specifies that same IPsec SA parameters be 47 configured for both inbound and outbound SAs to provide the "one to 48 many" security for multicast OSPFv3 communications over broadcast 49 links (e.g., Ethernet). Manual keying is specified as the mandatory 50 and default group key management solution. However, issues of 51 scalability and security exist with manual keying. It is better to 52 replace manual keying with automated group key management. This 53 document discusses the requirements on OSPFv3 automated group key 54 management, assuming that the centralized group key management 55 architecture introduced in [RFC4046] is used. 57 Table of Contents 59 1. Introduction..................................................4 60 2. Terminology...................................................4 61 3. General Requirements..........................................5 62 3.1. Authentication and Authorization of Routers..............5 63 3.2. Secure Distribution of Group SA..........................6 64 3.3. Storing Capability of Keys, Authorizations, and Policies.6 65 4. GCKS Deployment Example and its Specific Requirements.........6 66 4.1. Decentralized GCKSs......................................7 67 4.1.1. Single Point of GCKS Failure........................8 68 4.1.2. GCKS Selecting/Switchover Issue.....................8 69 4.1.3. Authorization and Authentication of GCKS............8 70 4.1.4. New Joiner Issue....................................8 71 4.2. Decentralized KSs, Centralized GC........................9 72 4.2.1. Bootstrapping Issue.................................9 73 4.2.2. New Joiner Issue....................................9 74 4.2.3. Authorization and Authentication of KS..............9 75 4.3. Decentralized Delegates, Centralized GCKS...............10 76 4.3.1. Bootstrapping Issue................................10 77 4.3.2. New Joiner Issue...................................10 78 4.3.3. Single Point of Delegate Failure...................10 79 4.3.4. Delegate Selecting/Switchover Issue................11 80 4.3.5. Authorization and Authentication of Delegate.......11 81 5. Security Considerations......................................11 82 5.1. Decentralized GCKS......................................11 83 5.2. Decentralized KS, Centralized GC........................11 84 5.3. Decentralized Delegate, Centralized GCKS................11 85 6. IANA Considerations..........................................11 86 7. Acknowledgments..............................................12 87 8.1. Normative References....................................12 88 8.2. Informative References..................................13 89 Author's Addresses..............................................14 90 Intellectual Property Statement.................................15 91 Full Copyright Statement........................................15 92 Acknowledgment..................................................15 94 1. Introduction 96 OSPFv3 [RFC2740] relies on IPSec to provide integrity, authentication, 97 and/or confidentiality. RFC4552 describes how to provide 98 authentication/confidentiality to OSPFv3 using AH/ESP. In Section 7 99 of RFC4552, it is proved that best scalability and feasibility can be 100 achieved if the same parameters are used for both inbound and 101 outbound AH/ESP SAs to provide the "one to many" communication 102 security while running OSPFv3 over broadcast interfaces. It means 103 that group security model be used to protect OSPFv3 multicast 104 communications over broadcast network. 106 However, RFC4552 specifies Manual Keying [RFC4301] as the default 107 group key management method, which is neither scalable nor secure. 108 This document discusses replacing manual keying with automated keying 109 using either a "one to many" or "many to many" communication model. 110 It is based on the fact that several GKM protocols have been, or 111 being, standardized by MSEC working group [RFC3547] [RFC3830] 112 [RFC4535] [GKDP], which makes it feasible to provide automated group 113 key management for OSPFv3 using GKM protocols. 115 Meanwhile, [I-D: draft-ietf-msec-ipsec-extensions] describes 116 multicast extensions to IPsec, which makes it feasible to provide 117 group security to OSPFv3 using standard multicast IPsec. 119 This document describes the requirements on OSPFv3 automated group 120 key management. It is assumed that the centralized group security 121 architecture [RFC3740] and group key management architecture [RFC4046] 122 would be used, where group SAs are centrally managed on separate key 123 server(s). And one of MSEC GKM protocols will be chosen as the group 124 keying protocols. Use of group key agreement techniques, for example, 125 Cliques [CLIQUES], is out of consideration. 127 2. Terminology 129 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 130 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 131 document are to be interpreted as described in RFC-2119. 133 Group Key Management (GKM) Protocol 135 A group key management protocol used by a GCKS to distribute 136 IPsec Security Association policy and keying material. A GKM 137 protocol is used when a group of IPsec devices require the same 138 SAs. For example, when an IPsec SA describes an IP multicast 139 destination, the sender and all receivers MUST have the group SA. 141 Group Controller Key Server (GCKS) 143 A Group Key Management (GKM) protocol server that manages IPsec 144 state for a group. A GCKS authenticates and provides the IPsec SA 145 policy and keying material to GKM group members. 147 GC and KS may also be acted by different entities. GC is 148 responsible defining and distributing group policy and 149 authorization, while KS providing group keying service to a 150 specific group. 152 Group Member 154 An IPsec device that belongs to a group. A Group Member is 155 authorized to be a Group Speaker and/or a Group Receiver. 157 Group Security Association (Group SA/GSA) 159 A collection of IPsec Security Associations (SAs) and GKM SAs 160 necessary for a Group Member to receive key updates. A GSA 161 describes the working policy for a group. Refer to RFC 4046 162 [RFC4046] for additional information. 164 State Synchronization (SS) 166 A generalization of OSPFv3 communications that occur after two 167 routers discover each other. It includes neighbor discovering, 168 exchanging DDs and LSAs, etc. 170 3. General Requirements 172 Requirements discussed in this section are considered general to all 173 keying solutions. 175 3.1. Authentication and Authorization of Routers 177 When a router uses a GKM protocol to contact a GCKS, the GCKS 178 authenticates the router and verifies that the router is authorized 179 to participate in the group. Both steps are necessary in order for 180 the Group SA to ensure that the Group SA is kept private to OSPF 181 routers that are allowed to participate in OSPF. Both authentication 182 and authorization MUST be enforced before a Group SA is distributed 183 to a router. 185 3.2. Secure Distribution of Group SA 187 Eavesdroppers are not able to access the group keys by intercepting 188 the group SA distribution packets. All existing GKM protocols can 189 meet this requirement. 191 3.3. Storing Capability of Keys, Authorizations, and Policies 193 It is expected that a network start up autonomously without a 194 provisioning step after rebooting. To actualize that target, routers 195 SHOULD to be able to store group security context information, such 196 as group policy, authorization, neighbor list, and GSA, etc., in 197 their storages (i.e., flash, hard disk). After rebooting, if this 198 policy is stored a router quickly resumes its group security context 199 to the same state as that of before rebooting and keeps in 200 synchronization with its neighbors. After every router has done that, 201 the OSPF SS process can be securely re-done in the network. Fast 202 routes convergence is assured during this process. 204 Group security context may change during rebooting. In such cases, 205 synchronization of group security context among routers can not be 206 achieved just by caching and resuming mechanisms. Other measures are 207 needed. Specific requirements on this topic will be discussed case by 208 case in the following sections. 210 4. GCKS Deployment Example and its Specific Requirements 212 MSEC GKM protocols, such as GSAKMP and GDOI, are based on a 213 client/server model. This means these protocols rely on reachability 214 between clients and servers for the clients to obtain the group SA 215 from the server. In this case, the GKM is providing protection for 216 OSPF, which is an essential component in providing reachability 217 between the clients and servers. Hence, the client/server model 218 breaks down in this situation. 220 To overcome this problem, the group SA must be locally available to 221 each group member (each OSPFv3 router). Possible solutions to this 222 circular dependency and their specific requirements are presented in 223 this section. 225 The expected network where OSPFv3 multicast communications occur and 226 group SA is assumed to be deployed is like the network N1 shown in 227 Fig.1. This network is used in this memo to derive the specific 228 requirements. 230 N2 N3 231 +-----+ +-----+ 232 | | 233 |2 | 234 +---+ +---+ 235 |RT1| |RT2| 236 +---+ +---+ 237 |1 |1 238 N1 | | 239 +------------------------------------+ 240 | | | 241 |1 |1 |1 242 +---+ +---+ +---+ 243 |RT3| |RT4| |RT5| 244 +---+ +---+ +---+ 245 | | | 246 | | | 247 +-----+ +-----+ +-----+ 248 N4 N5 N6 250 Figure 1 : The scenario used to derive the requirements 252 N1 is a broadcast network, where GSA is used to protect the OSPFv3 253 multicast communications among RT1~RT5. Group members attached to N1, 254 including RT1~RT5, get the group SA from GCKS. For convenience of 255 this example, broadcast interfaces attached to N1 are numbered as #1, 256 which each router recognizes is part of a single group. 258 Types of networks N2~N6 are not fixed. They MAY be either broadcast, 259 P2MP, or NBMA. It is assumed that a GSA plays locally on a multicast 260 network. Whether N2~N6 will share the same GSA with N1 is out the 261 scope of this memo even if they are broadcast type either. 263 4.1. Decentralized GCKSs 265 In this deployment example, there will be a GCKS for each multicast 266 network. The GCKS may be either a physical server or a logical one 267 that is acted by an OSPFv3 router, e.g., one router from RT1~RT5 is 268 selected as N1's GCKS. The GCKS and group members are located in the 269 same network, and share a GSA that is used only on that network. (If 270 a group member is attached to multiple networks, then it will install 271 a unique GSA for each network.) The GCKS may deliver either a single 272 SA used by each group member (a "many to many" SA) or deliver an 273 individual SA used by a unique sender (several "one to many" SAs). 274 GSA messages can be distributed from GCKS to group members within one 275 hop. Group members can download the GSA from their GCKS before they 276 establish their routes. It means no routes need to be pre-available 277 before the OSPFv3 router members run the GKM protocol to download GSA 278 from their GCKS. This solution can solve the contradiction mentioned 279 above. It applies to both small and large ASs. 281 Requirements introduced by this solution are illustrated as follows. 283 4.1.1. Single Point of GCKS Failure 285 This is a requirement common to all client/server 286 protocols/applications. The GCKS MAY be out of service because of 287 attacks, accidents, reboots, etc. Measures MUST be prepared to 288 provide continuous keying service in case of single point of GCKS 289 failure. 291 4.1.2. GCKS Selecting/Switchover Issue 293 To deal with the problem of single point of GCKS failure, at least 2 294 GCKSs need to be deployed in each multicast network. If GCKSs are 295 acted by the routers, switchover mechanisms are necessary to the GKM 296 protocol to provide continuous keying service when the running GCKS 297 becomes out of service and its service needs to be transferred to the 298 backup GCKS. 300 Another requirement is GCKS selecting mechanism, which is very like 301 OSPF DR/BDR selecting mechanism. It is necessary in the case of a 302 logical GCKS. Routers MUST be able to select their master/backup GCKS 303 when they start up. 305 4.1.3. Authorization and Authentication of GCKS 307 When routers begin to select their GCKS and backup GCKS, they need to 308 authenticate the candidates and verify that the selected GCKSs are 309 authorized to act as the GCKSs in the group. Both steps are necessary 310 in order to ensure that attackers can not become the GCKS by cheating 311 others. Both authentication and authorization MUST be enforced during 312 a GCKS selecting process. 314 4.1.4. New Joiner Issue 316 New router may join an existing network. It should be able to 317 automatically discover the local GCKS and contact it to get current 318 GSA so it can securely perform OSPF SS process with its neighbors. 320 However, dynamic changes of group membership may not be pre-known. 321 Thus, the list of authorized routers may not be pre-installed on each 322 GCKS. GCKS must be able to deal with such dynamic changes of 323 authorizations. If a new router registers with it, GCKS MUST be able 324 to authenticate the new one and verify whether it is authorized to 325 access the GSA even if the new router is not in the GCKS's authorized 326 routers list. 328 4.2. Decentralized KSs, Centralized GC 330 In this solution, KS and GC are separate roles. KS is logical and is 331 deployed per network; while GC is centrally deployed. This solution 332 allows for a centralized group management, but allows the KSs to act 333 autonomously. The GC is responsible for defining the group policy and 334 authorization, and pushing them to each KS. Each key server then 335 distributes a GSA conforming to the group policy. As in the 336 Decentralized GCKS case, each key server distributes a GSA that is 337 used only on a single network and SAs may be either have a scope of 338 "many to many" or "one to many". 340 Requirements in section 4.1.1 and 4.1.2 apply. New requirements 341 introduced by this solution are illustrated as follows. 343 4.2.1. Bootstrapping Issue 345 When the network originally starts up, there are no routes, and 346 candidate KS/backup KS routers do not have the authorization 347 information of group membership. After the KS/backup KS are selected, 348 they will not be able to provide the keying service because they 349 don't know the information of authorization and authentication of 350 routers. Measure MUST be provided to handle such issue. 352 4.2.2. New Joiner Issue 354 GC is responsible for determining list of authorized routers. 355 Measures must be provided to keep authorization information in 356 synchronization between GC and KS. For example, if a new router is 357 authorized by GC to join the network, KS must be able to authenticate 358 it and verify it is an authorized one even if it does not know the 359 new router and cannot contact with the GC. 361 4.2.3. Authorization and Authentication of KS 363 When routers begin to select their master/backup KSs, they must be 364 able to authenticate the candidates and verify that the selected KSs 365 are authorized to play such roles. Both steps of authentication and 366 authorization check are necessary in order to ensure that attackers 367 can not become the KS by cheating others. Both authentication and 368 authorization MUST be enforced during a KS selecting process. 370 4.3. Decentralized Delegates, Centralized GCKS 372 In this solution, there is a delegate in each OSPFv3 multicast 373 network. GSA messages are created by the centralized GCKS which may 374 serve multiple OSPFv3 networks at the same time. A delegate is 375 responsible for receiving GSA messages from the GCKS and re- 376 distributing them to its local group members. A delegate can be 377 either physical or logical. 379 Requirements introduced by this solution are as follows. 381 4.3.1. Bootstrapping Issue 383 When neighboring routers initially start, e.g., routers attached to 384 N1, they have no routes to the key server and so, can not download 385 the GSA from the centralized GCKS. Security measures MUST be provided 386 to protect the initial communications among OSPFv3 routers before 387 their adjacencies are established and routes are calculated out. 389 4.3.2. New Joiner Issue 391 When a new router joins, it will perform OSPF SS process with its 392 neighbors, and then calculate its routes. Before routes are 393 calculated out, the new coming router cannot contact the remote GCKS 394 to get current GSA. Measures MUST be provided to let the new joining 395 router get current GSA from GCKS so that it can securely communicate 396 with its neighboring routers. 398 Another problem is that routers may reboot singly. A rebooting router 399 needs to re-join the network after it restarts. However, during the 400 rebooting process, GSA may be updated by the GCKS and distributed to 401 other running routers. Therefore, after a router restarts and resumes 402 the GSA from its storage (e.g., flash), it may find its local GSA is 403 out of synchronization with its neighbors and thus, cannot establish 404 relationship with neighboring routers before it gets the latest GSA. 405 Measures must be provided to let rebooting routers make sure whether 406 its local GSA is out of synchronization with its neighbors and, if 407 yes, be able to get the updated GSA to keep its GSA in 408 synchronization with its neighbors. 410 4.3.3. Single Point of Delegate Failure 412 The delegate may crash or reboot. In such cases, the GSA 413 redistribution service will be not available. Measures MUST be 414 prepared to assure continuous GSA relaying service. 416 4.3.4. Delegate Selecting/Switchover Issue 418 To deal with the single point of delegate failure, at least 2 419 delegates must be deployed on every network. In the case of logical 420 delegates, delegate selecting mechanism is required for the GKM 421 protocols so routers can autonomously elect their local master/backup 422 delegates of their local network. 424 Switchover mechanism is needed to ensure that the backup delegate can 425 immediately supersede the master delegate in case that the later one 426 is out of service. 428 4.3.5. Authorization and Authentication of Delegate 430 In the delegates selecting process, routers need to authenticate the 431 candidates and verify that the selected delegates are authorized to 432 play such roles. Both steps of authenticating and authorization 433 checking are necessary in order to ensure that an attacker can not 434 become the delegate by cheating others. 436 5. Security Considerations 438 This document lists requirements for automated group keying of OSPFv3. 439 Several possible solutions and their specific requirements are 440 discussed. This section will discuss the security risk of the 441 mentioned solutions. 443 5.1. Decentralized GCKS 445 TBD 447 5.2. Decentralized KS, Centralized GC 449 TBD 451 5.3. Decentralized Delegate, Centralized GCKS 453 TBD 455 6. IANA Considerations 457 This document has no IANA considerations. 459 7. Acknowledgments 461 Thank Zengjie Kou, Jinliang Feng and Zhenhai Li for technical 462 discussions. 464 8. References 466 8.1. Normative References 468 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 469 Requirement Levels", BCP 14, RFC 2119, March 1997. 471 [RFC2234] Crocker, D. and Overell, P. (Editors), "Augmented BNF for 472 Syntax Specifications: ABNF", RFC 2234, Internet Mail 473 Consortium and Demon Internet Ltd., November 1997. 475 [RFC2740] Coltun, R., Ferguson, D. and J. Moy, "OSPF for IPv6", RFC 476 2740, December 1999. 478 [RFC3547] Baugher, M., Weis, B., Hardjono, T. and H. Harney, "The 479 Group Domain of Interpretation", RFC3547, July 2003. 481 [RFC3740] Hardjono, T. and B. Weis, "The Multicast Group Security 482 Architecture", RFC3740, March 2004. 484 [RFC3830] Arkko, J., Carrara, E., Lindholm, F., Naslund, M. and K. 485 Norrman, "MIKEY: Multimedia Internet KEYing", RFC3830, 486 August 2004. 488 [RFC4046] Baugher, M., Canetti, R., Dondeti, L. and F. Lindholm, 489 "Multicast Security (MSEC) Group Key Management 490 Architecture", RFC4046, April 2005. 492 [RFC4301] Kent, S. and K. Seo, "Security Architecture for the 493 Internet Protocol", RFC4301, December 2005. 495 [RFC4535] Harney, H., Meth, U., Colegrove, A. and G. Gross, "GSAKMP: 496 Group Secure Association Key Management Protocol", RFC4535, 497 June 2006. 499 [RFC4552] Gupta, M. and N. Melam, "Authentication/Confidentiality for 500 OSPFv3", RFC4552, June 2006. 502 [RFC4593] Barbir, A. and Murphy, S. and Y. Yang, "Generic Threats to 503 Routing Protocols", RFC4593, October 2006. 505 8.2. Informative References 507 [GKDP] Dondeti, L., Xiang, J. and S. Rowles, "GKDP: Group Key 508 Distribution Protocol", work in progress, October 2006. 510 [I-D: draft-ietf-msec-ipsec-extensions] Weis, B., Gross, G. and D. 511 Ignjatic, "Multicast Extensions to the Security 512 Architecture for the Internet Protocol", work in progress, 513 October 2006. 515 [CLIQUES] Steiner, M., Tsudik, G. and M. Waidner, "CLIQUES: A New 516 Approach to Group key Agreement", IEEE ICDCS'98 , MAY 1998. 518 Author's Addresses 520 Ya Liu 521 Huawei Technologies 522 Kuike Bld., No.9 Xinxi Rd., Shang-Di Information Industry Base 523 Hai-Dian District, Beijing 100086 524 P.R. China 526 Phone: 8610-82836072 527 Email: liuya@huawei.com 529 Russ White 530 Cisco Systems 531 7025 Kit Creek Road 532 RTP, NC 27709 533 USA 535 Email: riw@cisco.com 537 Brian Weis 538 Cisco Systems 539 170 W. Tasman Drive 540 San Jose, CA 95134-1706 541 USA 543 Phone: +1-408-526-4796 544 Email: bew@cisco.com 546 Michael Barnes 547 Cisco, Inc. 548 170 W. Tasman Drive 549 San Jose, CA 95134 550 USA 552 Phone: +1-408-525-2785 553 Email: mjbarnes@cisco.com 555 Intellectual Property Statement 557 The IETF takes no position regarding the validity or scope of any 558 Intellectual Property Rights or other rights that might be claimed to 559 pertain to the implementation or use of the technology described in 560 this document or the extent to which any license under such rights 561 might or might not be available; nor does it represent that it has 562 made any independent effort to identify any such rights. Information 563 on the procedures with respect to rights in RFC documents can be 564 found in BCP 78 and BCP 79. 566 Copies of IPR disclosures made to the IETF Secretariat and any 567 assurances of licenses to be made available, or the result of an 568 attempt made to obtain a general license or permission for the use of 569 such proprietary rights by implementers or users of this 570 specification can be obtained from the IETF on-line IPR repository at 571 http://www.ietf.org/ipr. 573 The IETF invites any interested party to bring to its attention any 574 copyrights, patents or patent applications, or other proprietary 575 rights that MAY cover technology that MAY be required to implement 576 this standard. Please address the information to the IETF at 577 ietf-ipr@ietf.org. 579 Full Copyright Statement 581 Copyright (C) The IETF Trust (2007). 583 This document is subject to the rights, licenses and restrictions 584 contained in BCP 78, and except as set forth therein, the authors 585 retain all their rights. 587 This document and the information contained herein are provided on an 588 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 589 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 590 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 591 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 592 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 593 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 595 Acknowledgment 597 Funding for the RFC Editor function is currently provided by the 598 Internet Society.