idnits 2.17.00 (12 Aug 2021) /tmp/idnits15010/draft-gupta-ospf-ospfv2-sec-00.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 15. -- Found old boilerplate from RFC 3978, Section 5.5 on line 616. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 627. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 638. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 638. ** 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 : ---------------------------------------------------------------------------- == There are 1 instance of lines with private range IPv4 addresses in the document. If these are generic example addresses, they should be changed to use any of the ranges defined in RFC 6890 (or successor): 192.0.2.x, 198.51.100.x or 203.0.113.x. 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 2006) is 5696 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) ** Obsolete normative reference: RFC 2740 (ref. 'N2') (Obsoleted by RFC 5340) ** Obsolete normative reference: RFC 4305 (ref. 'N6') (Obsoleted by RFC 4835) -- Obsolete informational reference (is this intentional?): RFC 4306 (ref. 'I1') (Obsoleted by RFC 5996) Summary: 5 errors (**), 0 flaws (~~), 3 warnings (==), 8 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group M. Gupta 3 Internet Draft Tropos Networks 4 Document: draft-gupta-ospf-ospfv2-sec-00.txt N. Melam 5 Expires: April 2007 Juniper Networks 6 October 2006 8 Authentication/Confidentiality for OSPFv2 10 Status of this Memo 12 By submitting this Internet-Draft, each author represents that any 13 applicable patent or other IPR claims of which he or she is aware 14 have been or will be disclosed, and any of which he or she becomes 15 aware will be disclosed, in accordance with Section 6 of BCP 79. 17 Internet-Drafts are working documents of the Internet Engineering 18 Task Force (IETF), its areas, and its working groups. Note that 19 other groups may also distribute working documents as Internet- 20 Drafts. 22 Internet-Drafts are draft documents valid for a maximum of six months 23 and may be updated, replaced, or obsoleted by other documents at any 24 time. It is inappropriate to use Internet-Drafts as reference 25 material or to cite them other than as "work in progress." 27 The list of current Internet-Drafts can be accessed at 28 http://www.ietf.org/ietf/1id-abstracts.txt 30 The list of Internet-Draft Shadow Directories can be accessed at 31 http://www.ietf.org/shadow.html. 33 Abstract 35 This document describes means and mechanisms to provide 36 authentication/confidentiality to OSPFv2 using IPsec (IP Security). 38 Copyright Notice 39 Copyright (C) The Internet Society (2006). 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..................................3 51 3. Authentication.................................................3 52 4. Confidentiality................................................3 53 5. Distinguishing OSPFv2 from OSPFv3 [N2].........................4 54 6. IPsec Requirements.............................................4 55 7. Key Management.................................................5 56 8. SA Granularity and Selectors...................................7 57 9. Virtual Links..................................................7 58 10. Rekeying......................................................8 59 10.1 . Rekeying Procedure......................................8 60 10.2 . KeyRolloverInterval.....................................8 61 10.3 . Rekeying Interval.......................................9 62 11. IPsec rules...................................................9 63 12. Entropy of Manual Keys.......................................11 64 13. Replay Protection............................................11 65 Security Considerations..........................................11 66 IANA Considerations..............................................12 67 Normative References.............................................12 68 Informative References...........................................13 69 Acknowledgments..................................................13 70 Authors' Addresses...............................................13 72 1. Introduction 74 OSPF (Open Shortest Path First) Version 2 [N1] defines the fields 75 AuType and Authentication in its protocol header to provide security. 76 These fields do not provide any confidentiality and also the 77 authentication provided by these fields is weak [specific problems 78 here]. 80 The demands for securing the routing protocols have increased since 81 the OSPFv2 protocol was designed. This document describes how IP 82 Security (Encapsulating Security Payload and Authentication Header 83 protocols) can be used to provide integrity, authentication, and/or 84 confidentiality to OSPFv2. 86 It is assumed that the reader is familiar with OSPFv2 [N1], 87 Authentication Header (AH) [N5], Encapsulating Security Payload (ESP) 88 [N4], the concept of security associations, tunnel and transport mode 89 of IPsec, and the key management options available for AH and ESP 90 (manual keying [N3] and Internet Key Exchange (IKE)[I1]). 92 2. Transport Mode vs Tunnel Mode 94 The transport mode Security Association (SA) is generally used 95 between two hosts or routers/gateways when they are acting as hosts. 96 The SA must be a tunnel mode SA if either end of the security 97 association is a router/gateway. Two hosts MAY establish a tunnel 98 mode SA between themselves. OSPFv2 packets are exchanged between 99 routers. However, since the packets are locally delivered, the 100 routers assume the role of hosts in the context of tunnel mode SA. 101 All implementations confirming to this specification MUST support 102 transport mode SA to provide required IPsec security to OSPFv2 103 packets. They MAY also support tunnel mode SA to provide required 104 IPsec security to OSPFv2 packets. 106 3. Authentication 108 Implementations conforming to this specification MUST support 109 authentication for OSPFv2. 111 In order to provide authentication to OSPFv2, implementations MUST 112 support ESP and MAY support AH. 114 If ESP in transport mode is used, it will only provide authentication 115 to OSPFv2 protocol packets excluding the IP header and IP options. 117 If AH in transport mode is used, it will provide authentication to 118 OSPFv2 protocol packet, selected portions of IP header and selected 119 IP options. 121 When OSPFv2 authentication is enabled, 123 o OSPFv2 packets that are not protected with AH or ESP MUST be 124 silently discarded. 126 o OSPFv2 packets that fail the authentication checks MUST be 127 silently discarded. 129 4. Confidentiality 131 Implementations conforming to this specification SHOULD support 132 confidentiality for OSPFv2. 134 If confidentiality is provided, ESP MUST be used. 136 When OSPFv2 confidentiality is enabled, 138 o OSPFv2 packets that are not protected with ESP MUST be silently 139 discarded. 141 o OSPFv2 packets that fail the confidentiality checks MUST be 142 silently discarded. 144 5. Distinguishing OSPFv2 from OSPFv3 [N2] 146 The IP/IPv6 Protocol Type for OSPFv2 and OSPFv3 is the same (89) and 147 OSPF distinguishes them based on the OSPF header version number. 148 However, current IPsec standards do not allow using arbitrary 149 protocol-specific header fields as the selectors. Therefore, the 150 OSPF version field in the OSPF header cannot be used in order to 151 distinguish OSPFv2 packets from OSPFv3 packets. As OSPFv2 is only 152 for IPv4 and OSPFv3 is only for IPv6, the version field in the IP 153 header can be used to distinguish OSPFv2 packets from OSPFv3 packets. 155 6. IPsec Requirements 157 In order to implement this specification, the following IPsec 158 capabilities are required. 160 Transport mode 161 IPsec in transport mode MUST be supported. [N3] 163 Multiple Security Policy Databases (SPDs) 164 The implementation MUST support multiple SPDs with a specific SPD 165 selection function. [N3] 167 Selectors 168 The implementation MUST be able to use source address, destination 169 address, protocol, and direction as selectors in the SPD. 171 Interface ID tagging 172 The implementation MUST be able to tag the inbound packets with 173 the ID of the interface (physical or virtual) via which it 174 arrived. [N3] 176 Manual key support 177 Manually configured keys MUST be able to secure the specified 178 traffic. [N3] 180 Encryption and authentication algorithms 182 The implementation MUST NOT allow the user to choose stream 183 ciphers as the encryption algorithm for securing OSPFv2 packets 184 since the stream ciphers are not suitable for manual keys. 186 Except when in conflict with the above statement, the key words 187 "MUST", "MUST NOT", "REQUIRED", "SHOULD", and "SHOULD NOT" that 188 appear in the [N6] document for algorithms to be supported are to 189 be interpreted as described in [N7] for OSPFv2 support as well. 191 Dynamic IPsec rule configuration 192 The routing module SHOULD be able to configure, modify and delete 193 IPsec rules on the fly. This is needed mainly for securing 194 virtual links. 196 Encapsulation of ESP packet 197 IP encapsulation of ESP packets MUST be supported. For 198 simplicity, UDP encapsulation of ESP packets SHOULD NOT be used. 200 Different SAs for different Differentiated Services Code Points 201 (DSCPs) 202 As per [N3], the IPsec implementation MUST support the 203 establishment and maintenance of multiple SAs with the same 204 selectors between a given sender and receiver. This allows the 205 implementation to associate different classes of traffic with the 206 same selector values in support of Quality of Service (QoS). 208 7. Key Management 210 OSPFv2 exchanges both multicast and unicast packets. While running 211 OSPFv2 over a broadcast interface, the authentication/confidentiality 212 required is "one to many". Since IKE is based on the Diffie-Hellman 213 key agreement protocol and works only for two communicating parties, 214 it is not possible to use IKE for providing the required "one to 215 many" authentication/confidentiality. This specification mandates 216 the usage of Manual Keying with current IPsec implementations. 217 Future specifications can explore the usage of protocols like 218 Kerberized Internet Negotiation of Keys/Group Secure Association Key 219 Management Protocol (KINK/GSAKMP) when they are widely available. In 220 manual keying, SAs are statically installed on the routers and these 221 static SAs are used to authenticate/encrypt packets. 223 The following discussion explains that it is not scalable and is 224 practically infeasible to use different security associations for 225 inbound and outbound traffic to provide the required "one to many" 226 security. Therefore, the implementations MUST use manually 227 configured keys with the same SA parameters (Security Parameter Index 228 (SPI), keys etc.,) for both inbound and outbound SAs (as shown in 229 Figure 3). 231 A | 232 SAa ------------>| 233 SAb <------------| 234 | 235 B | 236 SAb ------------>| 237 SAa <------------| Figure: 1 238 | 239 C | 240 SAa/SAb ------------>| 241 SAa/SAb <------------| 242 | 243 Broadcast 244 Network 246 If we consider communication between A and B in Figure 1, everything 247 seems to be fine. A uses security association SAa for outbound 248 packets and B uses the same for inbound packets and vice versa. Now 249 if we include C in the group and C sends a packet using SAa, then 250 only A will be able to understand it. Similarly, if C sends a packet 251 using SAb, then only B will be able to understand it. Since the 252 packets are multicast and they are going to be processed by both A 253 and B, there is no SA for C to use so that both A and B can 254 understand them. 256 A | 257 SAa ------------>| 258 SAb <------------| 259 SAc <------------| 260 | 261 B | 262 SAb ------------>| 263 SAa <------------| Figure: 2 264 SAc <------------| 265 | 266 C | 267 SAc ------------>| 268 SAa <------------| 269 SAb <------------| 270 | 271 Broadcast 272 Network 274 The problem can be solved by configuring SAs for all the nodes on 275 every other node as shown in Figure 2. So A, B, and C will use SAa, 276 SAb, and Sac, respectively, for outbound traffic. Each node will 277 lookup the SA to be used based on the source (A will use SAb and SAc 278 for packets received from B and C, respectively). This solution is 279 not scalable and practically infeasible because a large number of SAs 280 will need to be configured on each node. Also, the addition of a 281 node in the broadcast network will require the addition of another SA 282 on every other node. 284 A | 285 SAo ------------>| 286 SAi <------------| 287 | 288 B | 289 SAo ------------>| 290 SAi <------------| Figure: 3 291 | 292 C | 293 SAo ------------>| 294 SAi <------------| 295 | 296 Broadcast 297 Network 299 The problem can be solved by using the same SA parameters (SPI, Keys, 300 etc.) for both inbound (SAi) and outbound (SAo) SAs as shown in 301 Figure 3. 303 8. SA Granularity and Selectors 305 The user SHOULD be given the choice of sharing the same SA among 306 multiple interfaces or using a unique SA per interface. 308 9. Virtual Links 310 A different SA than the SA of the underlying interface MUST be 311 provided for virtual links. The source IP address of the OSPF 312 packets sent over the virtual links does not belong to the same 313 subnet as the interface running OSPFv2. The source IP address of all 314 the other OSPF packets, however, lies in the same subnet. This 315 difference in the IP source address differentiates the packets sent 316 on virtual links from other OSPFv2 interface types. 318 As the virtual link end point IP addresses are not known, it is not 319 possible to install SPD/Security Association Database (SAD) entries 320 at the time of configuration. The virtual link end point IP 321 addresses are learned during the routing table computation process. 323 The packet exchange over the virtual links starts only after the 324 discovery of the end point IP addresses. In order to protect these 325 exchanges, the routing module must install the corresponding SPD/SAD 326 entries before starting these exchanges. Note that manual SA 327 parameters are preconfigured but not installed in the SAD until the 328 end point addresses are learned. 330 10. Rekeying 332 To maintain the security of a link, the authentication and encryption 333 key values SHOULD be changed from periodically. 335 10.1. Rekeying Procedure 337 The following three-step procedure SHOULD be provided to rekey the 338 routers on a link without dropping OSPFv2 protocol packets or 339 disrupting the adjacency. 341 (1) For every router on the link, create an additional inbound SA for 342 the interface being rekeyed using a new SPI and the new key. 344 (2) For every router on the link, replace the original outbound SA 345 with one using the new SPI and key values. The SA replacement 346 operation should be atomic with respect to sending OSPFv2 packets 347 on the link so that no OSPFv2 packets are sent without 348 authentication/encryption. 350 (3) For every router on the link, remove the original inbound SA. 352 Note that all routers on the link must complete step 1 before any 353 begin step 2. Likewise, all the routers on the link must complete 354 step 2 before any begin step 3. 356 One way to control the progression from one step to the next is for 357 each router to have a configurable time constant KeyRolloverInterval. 358 After the router begins step 1 on a given link, it waits for this 359 interval and then moves to step 2. Likewise, after moving to step 2, 360 it waits for this interval and then moves to step 3. 362 In order to achieve smooth key transition, all routers on a link 363 should use the same value for KeyRolloverInterval and should initiate 364 the key rollover process within this time period. 366 At the end of this procedure, all the routers on the link will have a 367 single inbound and outbound SA for OSPFv2 with the new SPI and key 368 values. 370 10.2. KeyRolloverInterval 371 The configured value of KeyRolloverInterval should be long enough to 372 allow the administrator to change keys on all the OSPFv2 routers. As 373 this value can vary significantly depending upon the implementation 374 and the deployment, it is left to the administrator to choose the 375 appropriate value. 377 10.3. Rekeying Interval 379 This section analyzes the security provided by manual keying and 380 recommends that the encryption and authentication keys SHOULD be 381 changed at least every 90 days. 383 The weakest security provided by the security mechanisms discussed in 384 this specification is when NULL encryption (for ESP) or no encryption 385 (for AH) is used with the HMAC-MD5 authentication. Any other 386 algorithm combinations will at least be as hard to break as the ones 387 mentioned above. This is shown by the following reasonable 388 assumptions: 390 o NULL Encryption and HMAC-SHA-1 Authentication will be more secure 391 as HMAC-SHA-1 is considered to be more secure than HMAC-MD5. 393 o NON-NULL Encryption and NULL Authentication combination is not 394 applicable as this specification mandates authentication when OSPFv2 395 security is enabled. 397 o Data Encryption Security (DES) Encryption and HMAC-MD5 398 Authentication will be more secure because of the additional security 399 provided by DES. 401 o Other encryption algorithms like 3DES and the Advanced Encryption 402 Standard (AES) will be more secure than DES. 404 RFC 3562 [I4] analyzes the rekeying requirements for the TCP MD5 405 signature option. The analysis provided in RFC 3562 is also 406 applicable to this specification as the analysis is independent of 407 data patterns. 409 11. IPsec rules 411 The following set of transport mode rules can be installed in the SPD 412 to provide the authentication/confidentiality to OSPFv2 packets. 414 Outbound Rules for interfaces running OSPFv2 security: 416 No. source destination protocol action 417 1 intfPrefix any OSPF apply 419 Outbound Rules for virtual links running OSPFv2 security: 421 No. source destination protocol action 422 2 src/32 dst/32 OSPF apply 424 Inbound Rules for interfaces running OSPFv2 security: 426 No. source destination protocol action 427 3 intfPrefix any ESP/OSPF or AH/OSPF apply 428 4 intfPrefix any OSPF drop 430 Inbound Rules for virtual links running OSPFv2 security: 432 No. source destination protocol action 433 5 src/32 dst/32 ESP/OSPF or AH/OSPF apply 434 6 src/32 dst/32 OSPF drop 436 "intfPrefix" means the prefix of the interface that OSPFv2 is running 437 on. For example, if the IP address of the interface where OSPFv2 is 438 configured is 10.1.1.5/24, the value of "intfPrefix" would be 439 "10.1.1.0/24". 441 For outbound rules, action "apply" means encrypting/calculating ICV 442 and adding an ESP or AH header. For inbound rules, action "apply" 443 means decrypting/authenticating the packets and stripping the ESP or 444 AH header. 446 Rules 4 and 6 are to drop the insecure OSPFv2 packets without ESP/AH 447 headers. 449 ESP/OSPF or AH/OSPF in rules 3 and 5 mean that it is an OSPF packet 450 secured with ESP or AH. 452 Rules 1, 3 and 4 are meant to secure the unicast and multicast OSPF 453 packets that are not being exchanged over the virtual links. These 454 rules MUST only be installed in the security policy database (SPD) of 455 the interface running OSPFv2 security. 457 Rules 2, 5 and 6 are meant to secure the packets being exchanged over 458 virtual links. These rules are installed after learning the virtual 459 link end point IPv6 addresses. These rules MUST be installed on at 460 least the interfaces that are connected to the transit area for the 461 virtual link. These rules MAY alternatively be installed on all the 462 interfaces. If these rules are not installed on all the interfaces, 463 clear text or malicious OSPFv2 packets with the same source and 464 destination addresses as the virtual link end point IPv6 addresses 465 will be delivered to OSPFv2. Though OSPFv2 drops these packets 466 because they were not received on the right interface, OSPFv2 467 receives some clear text or malicious packets even when the security 468 is enabled. Installing these rules on all the interfaces insures 469 that OSPFv2 does not receive these clear text or malicious packets 470 when security is turned enabled. On the other hand, installing these 471 rules on all the interfaces increases the processing overhead on the 472 interfaces where there is no other IPsec processing. The decision of 473 installing these rules on all the interfaces or on just the 474 interfaces that are connected to the transit area is a private 475 decision and doesn't affect the interoperability in any way. Hence 476 it is an implementation choice. 478 12. Entropy of Manual Keys 479 The implementations MUST allow the administrator to configure the 480 cryptographic and authentication keys in hexadecimal format rather 481 than restricting it to a subset of ASCII characters (letters, numbers 482 etc.). A restricted character set will reduce key entropy 483 significantly as discussed in [I2]. 485 13. Replay Protection 487 Since it is not possible using the current standards to provide 488 complete replay protection while using manual keying, the proposed 489 solution will not provide protection against replay attacks. 491 Detailed analysis of various vulnerabilities of the routing protocols 492 and OSPF in particular is discussed in [I3] and [I2]. The conclusion 493 is that replay of OSPF packets can cause adjacencies to be disrupted, 494 which can lead to a DoS attack on the network. It can also cause 495 database exchange process to occur continuously thus causing CPU 496 overload as well as micro loops in the network. 498 Security Considerations 500 This memo discusses the use of IPsec AH and ESP headers in order to 501 provide security to OSPFv2 for IPv6. Hence, security permeates 502 throughout this document. 504 OSPF Security Vulnerabilities Analysis [I2] identifies OSPF 505 vulnerabilities in two scenarios -- one with no authentication or 506 simple password authentication and the other with cryptographic 507 authentication. The solution described in this specification 508 provides protection against all the vulnerabilities identified for 509 scenarios with cryptographic authentication with the following 510 exceptions: 512 Limitations of manual key: 514 This specification mandates the usage of manual keys. The following 515 are the known limitations of the usage of manual keys. 517 o As the sequence numbers cannot be negotiated, replay protection 518 can not be provided. This leaves OSPF insecure against all the 519 attacks that can be performed by replaying OSPF packets. 521 o Manual keys are usually long lived (changing them often is 522 a tedious task). This gives an attacker enough time to discover 523 the keys. 525 o As the administrator is manually configuring the keys, there is 526 a chance that the configured keys are weak (there are known weak 527 keys for DES/3DES at least). 529 Impersonating attacks: 531 The usage of the same key on all the OSPF routers connected to a link 532 leaves them all insecure against impersonating attacks if any one of 533 the OSPF routers is compromised, malfunctioning or misconfigured. 535 Detailed analysis of various vulnerabilities of routing protocols is 536 discussed in [I3]. 538 IANA Considerations 539 This document has no IANA considerations. 541 This section should be removed by the RFC Editor to final 542 publication. 544 Normative References 546 [N1] Moy, J., "OSPF Version 2", STD 54, RFC 2328, April 1998. 548 [N2] Coltun, R., Ferguson, D., and J. Moy, "OSPF for IPv6", RFC 2740, 549 December 1999. 551 [N3] Kent, S. and K. Seo, "Security Architecture for the Internet 552 Protocol", RFC 4301, December 2005. 554 [N4] Kent, S., "IP Encapsulating Security Payload (ESP)", RFC 4303, 555 December 2005. 557 [N5] Kent, S., "IP Authentication Header", RFC 4302, December 2005. 559 [N6] Eastlake 3rd, D., "Cryptographic Algorithm Implementation 560 Requirements for Encapsulating Security Payload (ESP) and 561 Authentication Header (AH)", RFC 4305, December 2005. 563 [N7] Bradner, S., "Key words for use in RFCs to Indicate Requirement 564 Levels", BCP 14, RFC 2119, March 1997. 566 Informative References 568 [I1] Kaufman, C., "Internet Key Exchange (IKEv2) Protocol", RFC 4306, 569 December 2005. 571 [I2] Jones, E. and O. Moigne, "OSPF Security Vulnerabilities 572 Analysis", Work in Progress. 574 [I3] Barbir, A., Murphy, S., and Y. Yang, "Generic Threats to Routing 575 Protocols", Work in Progress. 577 [I4] Leech, M., "Key Management Considerations for the TCP MD5 578 Signature Option", RFC 3562, July 2003. 580 [I5] Gupta, M. and N. Melam, "Authentication/Confidentiality for 581 OSPFv3", RFC 4552, June 2006. 583 Acknowledgments 585 This document is widely derived from Authentication/Confidentiality 586 to OSPFv3 [I5]. 588 Authors' Addresses 590 Mukesh Gupta 591 Tropos Networks 592 555 Del Rey Ave 593 Sunnyvale, CA 94085 594 Phone: 408-331-6889 595 EMail: mukesh.gupta@tropos.com 597 Nagavenkata Suresh Melam 598 Juniper Networks 599 1194 N. Mathilda Ave 600 Sunnyvale, CA 94089 601 Phone: 408-505-4392 602 EMail: nmelam@juniper.net 604 Full Copyright Statement 606 This document is subject to the rights, licenses and restrictions 607 contained in BCP 78, and except as set forth therein, the authors 608 retain all their rights. 610 This document and the information contained herein are provided on an 611 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 612 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 613 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 614 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 615 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 616 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 618 Intellectual Property 620 The IETF takes no position regarding the validity or scope of any 621 Intellectual Property Rights or other rights that might be claimed to 622 pertain to the implementation or use of the technology described in 623 this document or the extent to which any license under such rights 624 might or might not be available; nor does it represent that it has 625 made any independent effort to identify any such rights. Information 626 on the procedures with respect to rights in RFC documents can be 627 found in BCP 78 and BCP 79. 629 Copies of IPR disclosures made to the IETF Secretariat and any 630 assurances of licenses to be made available, or the result of an 631 attempt made to obtain a general license or permission for the use of 632 such proprietary rights by implementers or users of this 633 specification can be obtained from the IETF on-line IPR repository at 634 http://www.ietf.org/ipr. The IETF invites any interested party to 635 bring to its attention any copyrights, patents or patent 636 applications, or other proprietary rights that may cover technology 637 that may be required to implement this standard. Please address the 638 information to the IETF at ietf-ipr@ietf.org.