idnits 2.17.1 draft-manral-rpsec-existing-crypto-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 on line 561. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 538. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 545. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 551. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** 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. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an Introduction section. ** There are 18 instances of too long lines in the document, the longest one being 6 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == The document doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- 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 (January 16, 2006) is 6674 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: 'RFC1995' is mentioned on line 99, but not defined == Missing Reference: 'MD5' is mentioned on line 102, but not defined == Missing Reference: 'OSPF' is mentioned on line 202, but not defined == Missing Reference: 'ESH' is mentioned on line 224, but not defined == Missing Reference: 'IKE' is mentioned on line 230, but not defined == Missing Reference: 'RFC793' is mentioned on line 395, but not defined ** Obsolete undefined reference: RFC 793 (Obsoleted by RFC 9293) == Unused Reference: 'RFC0793' is defined on line 456, but no explicit reference was found in the text == Outdated reference: A later version (-08) exists of draft-ietf-ospf-ospfv3-auth-07 ** Obsolete normative reference: RFC 793 (Obsoleted by RFC 9293) ** Downref: Normative reference to an Historic RFC: RFC 1058 ** Obsolete normative reference: RFC 1388 (Obsoleted by RFC 1723) ** Obsolete normative reference: RFC 1723 (Obsoleted by RFC 2453) ** Obsolete normative reference: RFC 2385 (Obsoleted by RFC 5925) ** Obsolete normative reference: RFC 2740 (Obsoleted by RFC 5340) ** Downref: Normative reference to an Informational RFC: RFC 3562 ** Obsolete normative reference: RFC 3567 (Obsoleted by RFC 5304) Summary: 14 errors (**), 0 flaws (~~), 11 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Network Working Group V. Manral 2 Internet-Draft SiNett Corp 3 Expires: July 16, 2006 S. Hares 4 NextHop 5 R. White 6 Cisco Systems 7 January 16, 2006 9 Issues with existing Cryptographic Protection Methods for Routing 10 Protocols 11 draft-manral-rpsec-existing-crypto-01 13 Status of this Memo 15 By submitting this Internet-Draft, each author represents that any 16 applicable patent or other IPR claims of which he or she is aware 17 have been or will be disclosed, and any of which he or she becomes 18 aware will be disclosed, in accordance with Section 6 of BCP 79. 20 Internet-Drafts are working documents of the Internet Engineering 21 Task Force (IETF), its areas, and its working groups. Note that 22 other groups may also distribute working documents as Internet- 23 Drafts. 25 Internet-Drafts are draft documents valid for a maximum of six months 26 and may be updated, replaced, or obsoleted by other documents at any 27 time. It is inappropriate to use Internet-Drafts as reference 28 material or to cite them other than as "work in progress." 30 The list of current Internet-Drafts can be accessed at 31 http://www.ietf.org/ietf/1id-abstracts.txt. 33 The list of Internet-Draft Shadow Directories can be accessed at 34 http://www.ietf.org/shadow.html. 36 This Internet-Draft will expire on July 16, 2006. 38 Copyright Notice 40 Copyright (C) The Internet Society (2006). 42 Abstract 44 Routing protocols often use cryptographic mechanisms to authenticate 45 data being received from a neighboring router has not been modified 46 in transit, and actually originated from the nrighboring router 47 purporting to have originating the data. Most of the cryptographic 48 mechanisms rely on hash algorithms applied to the data in the routing 49 protocol packet, which means the data is transported, in the clear, 50 along with the has signature based on the data itself. These 51 mechanisms rely on the manual configuration of the keys used to seed, 52 or build, these hash based sigantures. This document outlines some 53 of the problems with manual keying of these cryptographic algorithms. 55 Requirements Language 57 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 58 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 59 document are to be interpreted as described in RFC 2119 [RFC2119]. 61 Table of Contents 63 1. Problem Statement . . . . . . . . . . . . . . . . . . . . . 3 65 2. OSPF (OSPFv2) . . . . . . . . . . . . . . . . . . . . . . . 4 66 2.1 Management Issues with OSPF . . . . . . . . . . . . . . . 4 67 2.2 Technical Issues with OSPF . . . . . . . . . . . . . . . . 4 69 3. OSPFv3 . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 70 3.1 Management Issues with OSPFv3 . . . . . . . . . . . . . . 6 71 3.2 Technical Issues with OSPFv3 . . . . . . . . . . . . . . . 6 73 4. IS-IS . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 74 4.1 Management Issues with IS-IS . . . . . . . . . . . . . . . 8 75 4.2 Technical Issues with IS-IS . . . . . . . . . . . . . . . 8 77 5. BGP . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10 78 5.1 Management Issues with BGP . . . . . . . . . . . . . . . . 10 79 5.2 Technical Issues with BGP . . . . . . . . . . . . . . . . 10 81 6. The Routing Information Protocol (RIP) . . . . . . . . . . . 11 83 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . 12 85 8. Security Considerations . . . . . . . . . . . . . . . . . . 13 87 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 14 89 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 15 90 10.1 Normative References . . . . . . . . . . . . . . . . . . 15 91 10.2 Informative References . . . . . . . . . . . . . . . . . 16 93 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 16 95 Intellectual Property and Copyright Statements . . . . . . . 17 97 1. Problem Statement 99 Routing protocols, such as OSPF [RFC2740] [RFC2328], IS-IS [RFC1995], 100 and [BGP], rely on various mechanisms to create a cryptographic 101 digest of each transmitted routing protocol. Generally, these 102 digests are the results of a hash algorithm, such as [MD5], across 103 the contents of the packet being transmitted, using a private key as 104 the hash base (or seed). These digests are recomputed by the 105 receiving router, using the same key as the originating router used 106 to create the hash, and compared with the transmited digest to 107 verify: 109 o That the router originating this piece of data is authorized to 110 peer with the local router, and to transmit routing data. This 111 generally protects against falsely generated routing data being 112 injected into a routing system by rogue systems. 114 o That the data has not been changed while transiting between the 115 two neighboring routers. 117 These sorts of authentication methods are not generally used to 118 protect the confidentiality of information being exchanged between 119 routers, since this information (entries in the routing table) is 120 generally freely available in many other context; if anyone has 121 access to the physical media between two routers exchanging routing 122 data, they will also probably have other ways to capture or otherwise 123 discover the contents of the routing tables in those routers. 125 The main problems with the authentication mechanisms in use today 126 revolve around: 128 o Manual configuration of shared secret keys, especially in large 129 scale networks, poses a major management problem, especially as 130 there is generally no way to gracefully move from one secret key 131 to another. 133 o In some cases, when manual keys are configured, some forms of 134 replay protection are disabled, allowing the routing protocol to 135 be attacked. 137 In fact, the MD5 digest algorithm was not designed to be used in the 138 way most routing protocols are using it, which leads to serious 139 security implications. 141 2. OSPF (OSPFv2) 143 OSPF [RFC2328] describes the use of an MD5 digest with OSPF packets. 144 MD5 keys are manually configured. The OSPF packet Header includes an 145 authentication type field as well as 64-bits of data for use by the 146 appropriate authentication scheme. [OSPF] also provides for a non- 147 decreasing sequence number to be included in each OSPF protocol 148 packet to protect against replay attacks. 150 2.1 Management Issues with OSPF 152 According to the OSPF specification, [RFC2328], digests are applied 153 to packets transmitted between adjacent neighbors, rather than being 154 applied to the routing information originated by a router (digests 155 are not applied at the LSA level, but rather at the packet level). 156 [RFC2328] states that any set of OSPF routers adjacent across a 157 single link may use a different key to build MD5 digests than the key 158 used to build MD5 digests on any other link. Thus, MD5 keys may be 159 configured, and changed, on a per-link basis in an OSPF network. 161 [OSPF] does not specify a mechanims to negotiate keys, nor does it 162 specify any mechanism to negotiate the hash algorithms to be used. 164 With the proliferation of the number of hash algorithms, as well as 165 the need to continuously upgrade the algorithms, manually configuring 166 the information becomes very tedious. 168 2.2 Technical Issues with OSPF 170 While [OSPF] provides relatively strong protection through the 171 inclusion of MD5 sigantures, with additional data and sequence 172 numbers, in transmitted packets, there are still two possible attacks 173 against OSPF: 175 o The sequence number is initialized to zero when forming an 176 adjacency with a newly discovered neighbor, and is also set to 177 zero whenever the neighbor is brought down. If the 178 cryptographically protected packets of a router that is brought 179 down(for administrative or other reasons) are stored by a 180 malicious router. The new router could replay the packets from 181 the previous session thus forcing traffic through the malicious 182 router. Dropping of such packets by the router could result in 183 blackholes. Also wrongly forwarding packets could result in 184 routing loops. 186 o [OSPF] allows multiple packets with the same sequence number. 187 This could mean the same packet can be replayed many times before 188 the next legitimate packet is sent. An attacker may resend the 189 same packet repeatedly until the next hello packet is transmitted 190 and received, which means the hello interval determines the attack 191 window. 193 o [OSPF] does not specify the use of any particular hash algorithm, 194 however the use of only MD5 is specified in the document. Most OSPF 195 implementations only support MD5. 197 Recently, attacks on collision-resistance properties of MD5 and SHA-1 198 hash functions have been discovered; [HASH-ATTACK] summarizes the 199 discoveries. The attacks on MD5 are practical on any mordern computer. 200 For this reason the use of algorithms needs to be discouraged. 202 o [OSPF] on a broadcast network shares the same key between all neighbors 203 on a broadcast network. Some OSPF packets are sent on multicast address. 205 This allows spoofing by any malicious neighbor very easy. Possesion of 206 the key itself is used as an identity check. There is no other identity 207 check used. A neighbor could send a packet specifying the packet came 208 from some other neighbor and there would be no way in which the attacked 209 router could figure out the identity of the packet sender. 211 3. OSPFv3 213 OSPFv3 [RFC2740] relies on the IP Authentication Header described in 214 [AH] and the IP Encapsulating Payload described in [ESP] to 215 cryptographically sign routing information passed between routers. 216 Generally, a null encryption algorithm is used, so the data carried 217 in the OSPFv3 packets is signed, but not encrypted. This provides 218 authentication or adjacent routers, and assurance data transmitted by 219 a router has not changed, but does not provide confidentiality of the 220 information transmitted. [OSPF-AUTH] does provide for protecting the 221 confidentiality of routing information transmitted, using [ESP] 222 encryption. 224 [OSPF-AUTH] describes OSPFv3's use of [AH] and [ESH], and specifies 225 that only manual keying of routing information may be used. 227 3.1 Management Issues with OSPFv3 229 [OSPF-AUTH] discusses, at length, the reasoning behind using manual 230 keys, rather than keys distributed through [IKE] or some other key 231 distribution mechanism. The primary problem is that all current key 232 distribution mechanisms are deisgned for one-to-one correlation of 233 keys, while OSPF adjacencies are formed on a one-to-many basis. This 234 forces the system administrator to use manual keys to provide 235 authentication and, if desired, confidentiality. 237 OSPFv3 security document [OSPF-AUTH] states that 239 As it is not possible as per the current standards to provide 240 complete replay protection while using manual keying, the proposed 241 solution will not provide protection against replay attacks. 243 The primary administrative issue with manual keys in the OSPFv3 case 244 is the simple management issue of mantaining matching sets of keys on 245 all routers within a network. [OSPF-AUTH] does not require that all 246 OSPFv3 routers have the same key configured for every neighbor, so 247 each set of neighbors connected to a single link could have a 248 different key configured. While this makes it easier to change the 249 keys, by forcing the system administrator to only change the keys on 250 the routers a single link, the process of manual configuration for 251 all the routers in a network to change the keys used for OSPFv3 252 digests and confidentiality on a periodic basis can be difficult. 254 3.2 Technical Issues with OSPFv3 256 The primary technical concern with the current specifications for 257 OSPFv3 is that when manual keys are used, [AH] specifies, in section 258 3.3.2, Sequence Number Generation: "The sender assumes anti-replay is 259 enabled as a default, unless otherwise notified by the receiver (see 260 3.4.3) or if the SA was configured using manual key management." 261 Replayed OSPFv3 packets can cause several failures in a network, 262 including: 264 o Replaying hello packets with an empty neighbor list can cause all 265 the neighbor adajcencies with the sending router to be reset, 266 disrupting network communications. 268 o Replaying hello packets from early in the designated router 269 election process on broadcast links can cause all the neighbor 270 adjacencies with the sending router to be reset, disrupting 271 network communications. 273 o Replaying database description (DB-Description) packets can cause 274 all FULL neighbor adjacencies with the sending router to be reset, 275 disrupting network communications. 277 o Replaying link state request (LS-Request) packets can cause all 278 FULL neighbor adjacencies with the sending router to be reset, 279 disrupting network communications. 281 o Capturing a full adjacency process (from two-way all the way to 282 FULL state), and then replaying this process when the router is no 283 longer attached can cause a false adjacency to be formed, allowing 284 an attacker to attract and black hole traffic. 286 4. IS-IS 288 IS-IS [RFC1195] uses HMAC-MD5 authentication with manual keying, as 289 described in [RFC3567]. There is no provision within IS-IS to 290 encrypt the body of a routing protocol message. 292 4.1 Management Issues with IS-IS 294 [RFC3567] states that each LSP generated by an intermediate system is 295 signed with the HMAC-MD5 algorithm using a key manually defined by 296 the network administrator. Since authentication is performed on the 297 LSPs transmitted by an intermediate system, rather than on the 298 packets transmitted to a specific neighbor, it is implied that all 299 the intermediate systems within a single flooding domain must be 300 configured with the same key for authentication to work correctly. 301 The initial configuration of manual keys for authentication within an 302 IS-IS network is simplified by a state where LSPs containing HMAC-MD5 303 authentication TLVs are accepted, but the digest is not validated. 304 Once an initial set of keys are configured on all routers, however, 305 changing those keys becomes much more difficult. 307 IS-IS [RFC1195] does not specify a mechanims to negotiate keys, nor does 308 it specify any mechanism to negotiate the hash algorithms to be used. 310 With the proliferation of the number of hash algorithms, as well as 311 the need to continuously upgrade the algorithms, manually configuring 312 the information becomes very tedious. 314 4.2 Technical Issues with IS-IS 316 [RFC3567] states: "This mechanism does not prevent replay attacks, 317 however, in most cases, such attacks would trigger existing 318 mechanisms in the IS-IS protocol that would effectively reject old 319 information." The few case where existing mechanisms in the IS-IS 320 protocol would not effectively reject old information is the case of 321 the hello packets (IIHs) used to discover neighborsand SNP packets. 323 As described in IS-IS [RFC1195], a list of known neighbors is 324 included in each hello transmitted by an intermediate system, to 325 ensure two-way communications with any specific neighbor before 326 exchanging link state databases. 328 IS-IS does not provide a sequence number. Hence IS-IS packets are 329 liable to replay attacks. As any packet can be replayed at any point 330 of time, as long as the keys used are the same. 332 A hello packet containing a digest within a TLV, and an emtpy 334 Internet-Draft Routing Protocol Protection Issues July 16, 06 336 neighbor list, could be replayed, causing all adjacencies with the 337 original transmitting intermediate system to be restarted. 339 A replay of an old CSNP packets could cause LSP's to be flooded, thus 340 causing an LSP storm. 342 IS-IS specifies the use of the hash algorithm HMAC-MD5 to protect 343 IS-IS PDU's. 345 IS-IS does not have a notion of Key ID. During Key rollover, each 346 message received has to be checked for integrity against all keys that 347 are valid. A DoS attack may be caused by sending IS-IS packets with 348 random hashes. This will cause the IS-IS packet to be checked for 349 authentication, with all possible keys. Thus increasing the amount of 350 processing required. 352 Recently, attacks on collision-resistance properties of MD5 and SHA-1 353 hash functions have been discovered; [HASH-ATTACK] summarizes the 354 discoveries. The attacks on MD5 are practical on any mordern computer. 355 For this reason the use of algorithms needs to be discouraged. 357 HMAC's are not susceptible to any known collision-reduction attack. 358 However IS-IS should provide a way to upgrade to other stronger 359 algorithms. 361 IS-IS on a broadcast network shares the same key between all neighbors 362 on a broadcast network. Some IS-IS PDU's are sent on link-layer multicast 363 address. 365 This makes spoofing by any malicious neighbor very easy. Possession of 366 the key itself is used as an identity check. There is no other identity 367 check used. A neighbor could send a packet specifying the packet came 368 from some other neighbor and there would be no way in which the attacked 369 router could figure out the identity of the packet sender. 371 5. BGP 373 [BGP] uses TCP [RFC793] for transporting routing information between 374 BGP speakers which have formed an adjacency, as described in 375 [RFC2385], with suggestions for choosing MD5 keys described in 376 [RFC3562]. 378 5.1 Management Issues with BGP 380 Each pair of BGP speakers forming an adjacency may have a different 381 MD5 shared key, facilitating the configuration and changing of keys 382 across a large scale network. Manual configuration and maintenance 383 of manual keys on all routers is a challenge in any large scale 384 environment, however. Most BGP implementations will accept BGP 385 packets with a bad digest for the hold interval negotiated between 386 BGP peers at peering startup, allowing MD5 keys to be changed without 387 impacting the operation of the network. This technique does, 388 however, allow some short period of time during which an attacker may 389 inject BGP packets with false MD5 digests into the network, and can 390 expect those packets to be accepted, even though their MD5 digests 391 are not valid. 393 5.2 Technical Issues with BGP 395 Since BGP relies on TCP [RFC793] for transporting data between BGP 396 speakers, BGP can rely on TCP's protections against data corruption 397 and replay to prevent replay attacks against BGP sessions. A great 398 deal of research has gone into the difficulty or ease with which an 399 attacker can overcome these protections, including [TCP-WINDOW] and 400 [BGP-ATTACK]. Most implementations of BGP have modified their TCP 401 implementations to resolve the security vulnerabilities described in 402 these references, where possible. 404 6. The Routing Information Protocol (RIP) 406 RIP [RFC1058] does not provide for any authentication or 407 authorization of routing data, and thus is vulnerable to any of the 408 various attacks against routing protocols. 410 RIPv2 [RFC1388, RFC1723] provides for authenticating packets by 411 carrying a digest, but has no counter for replay protection. Packets 412 can be replayed at will, allowing the injection of false routing 413 information and various denial of service attacks, such as 414 continuously requesting a routing table download, causing devices 415 running RIP to become overloaded. 417 7. IANA Considerations 419 This document makes no request of IANA. 421 Note to RFC Editor: this section may be removed on publication as an 422 RFC. 424 8. Security Considerations 426 This draft outlines security issues arising from the manual keying of 427 cryptographic keys for various routing protocols. No changes to any 428 protocols are proposed in this draft, and no new security 429 requirements result. 431 9. Acknowledgements 433 We would like to acknowledge Sam Hartman, Ran Atkinson, Steve Kent 434 and Brian Wies for their comments on this draft. Thanks to Manav 435 Bhatia for comments on IS-IS section of the draft. 437 10. References 439 10.1 Normative References 441 [AH] Kent, S., "IP Authentication Header", 442 RFC draft-ietf-ipsec-rfc2402bis-11.txt, March 2005. 444 [BGP] Rekhter , Y., Li, T., and S. Hares, "A Border Gateway 445 Protocol 4 (BGP-4)", RFC draft-ietf-idr-bgp4-26.txt, 446 October 2004. 448 [ESP] Kent, S., "IP Encapsulating Security Payload (ESP)", 449 RFC draft-ietf-ipsec-esp-v3-10.txt, March 2005. 451 [OSPF-AUTH] 452 Gupta, M. and N. Melam, "Authentication/Confidentiality 453 for OSPFv3", RFC draft-ietf-ospf-ospfv3-auth-07.txt, 454 February 2005. 456 [RFC0793] Postel, J., "Transmission Control Protocol", STD 7, 457 RFC 793, September 1981. 459 [RFC1058] Hedrick, C., "Routing Information Protocol", RFC 1058, 460 June 1988. 462 [RFC1195] Callon, R., "Use of OSI IS-IS for routing in TCP/IP and 463 dual environments", RFC 1195, December 1990. 465 [RFC1388] Malkin, G., "RIP Version 2 Carrying Additional 466 Information", RFC 1388, January 1993. 468 [RFC1723] Malkin, G., "RIP Version 2 - Carrying Additional 469 Information", STD 56, RFC 1723, November 1994. 471 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 472 Requirement Levels", BCP 14, RFC 2119, March 1997. 474 [RFC2328] Moy, J., "OSPF Version 2", STD 54, RFC 2328, April 1998. 476 [RFC2385] Heffernan, A., "Protection of BGP Sessions via the TCP MD5 477 Signature Option", RFC 2385, August 1998. 479 [RFC2740] Coltun, R., Ferguson, D., and J. Moy, "OSPF for IPv6", 480 RFC 2740, December 1999. 482 [RFC3562] Leech, M., "Key Management Considerations for the TCP MD5 483 Signature Option", RFC 3562, July 2003. 485 [RFC3567] Li, T. and R. Atkinson, "Intermediate System to 486 Intermediate System (IS-IS) Cryptographic Authentication", 487 RFC 3567, July 2003. 489 10.2 Informative References 491 [BGP-ATTACK] Convery, S. and M. Franz, "BGP Vulnerability Testing: 492 Separating Fact from FUD v1.00", June 2003. 494 [TCP-WINDOW] Watson, T., "TCP Reset Spoofing", October 2003. 496 [HASH-ATTACK] Hoffman, P. and B. Schneier, "Attacks on Cryptographic 497 Hashes in Internet Protocols", RFC4270, November 2005. 499 Authors' Addresses 501 Vishwas Manral 502 SiNett Corp 503 Bangalore 504 India 506 Phone: 507 Fax: 508 Email: vishwas@sinett.com 510 Sure Hares 511 NextHop 512 USA 514 Phone: 515 Fax: 516 Email: shares@nexthop.com 517 URI: 519 Russ White 520 Cisco Systems 521 RTP, NC 522 USA 524 Phone: 525 Fax: 526 Email: riw@cisco.com 527 URI: 529 Intellectual Property Statement 531 The IETF takes no position regarding the validity or scope of any 532 Intellectual Property Rights or other rights that might be claimed to 533 pertain to the implementation or use of the technology described in 534 this document or the extent to which any license under such rights 535 might or might not be available; nor does it represent that it has 536 made any independent effort to identify any such rights. Information 537 on the procedures with respect to rights in RFC documents can be 538 found in BCP 78 and BCP 79. 540 Copies of IPR disclosures made to the IETF Secretariat and any 541 assurances of licenses to be made available, or the result of an 542 attempt made to obtain a general license or permission for the use of 543 such proprietary rights by implementers or users of this 544 specification can be obtained from the IETF on-line IPR repository at 545 http://www.ietf.org/ipr. 547 The IETF invites any interested party to bring to its attention any 548 copyrights, patents or patent applications, or other proprietary 549 rights that may cover technology that may be required to implement 550 this standard. Please address the information to the IETF at 551 ietf-ipr@ietf.org. 553 Disclaimer of Validity 555 This document and the information contained herein are provided on an 556 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 557 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 558 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 559 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 560 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 561 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 563 Copyright Statement 565 Copyright (C) The Internet Society (2005). This document is subject 566 to the rights, licenses and restrictions contained in BCP 78, and 567 except as set forth therein, the authors retain all their rights. 569 Acknowledgment 571 Funding for the RFC Editor function is currently provided by the 572 Internet Society.