idnits 2.17.1 draft-ietf-ospf-ospfv3-auth-08.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 648. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 659. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 670. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 670. ** 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 : ---------------------------------------------------------------------------- No issues found here. 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 (February 2006) is 6607 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 188 looks like a reference -- Missing reference section? 'N1' on line 75 looks like a reference -- Missing reference section? 'N2' on line 331 looks like a reference -- Missing reference section? 'N5' on line 85 looks like a reference -- Missing reference section? 'N4' on line 86 looks like a reference -- Missing reference section? 'N3' on line 199 looks like a reference -- Missing reference section? 'I1' on line 88 looks like a reference -- Missing reference section? 'N6' on line 188 looks like a reference -- Missing reference section? 'I4' on line 434 looks like a reference -- Missing reference section? 'I2' on line 527 looks like a reference -- Missing reference section? 'I3' on line 558 looks like a reference Summary: 3 errors (**), 0 flaws (~~), 2 warnings (==), 18 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-ietf-ospf-ospfv3-auth-08.txt N. Melam 5 Expires: Aug 2006 Juniper Networks 6 February 2006 8 Authentication/Confidentiality for OSPFv3 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/mechanisms to provide 36 authentication/confidentiality to OSPFv3 using an IPv6 AH/ESP 37 Extension Header. 39 Copyright Notice 40 Copyright (C) The Internet Society (2006). 42 Conventions used in this document 44 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 45 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 46 document are to be interpreted as described in RFC-2119 [N7]. 48 Table of Contents 50 1. Introduction...................................................2 51 2. Transport Mode vs Tunnel Mode..................................3 52 3. Authentication.................................................3 53 4. Confidentiality................................................3 54 5. Distinguishing OSPFv3 from OSPFv2..............................4 55 6. IPsec Requirements.............................................4 56 7. Key Management.................................................5 57 8. SA Granularity and Selectors...................................7 58 9. Virtual Links..................................................7 59 10. Rekeying......................................................9 60 10.1 Rekeying Procedure........................................9 61 10.2 KeyRolloverInterval.......................................9 62 10.3 Rekeying Interval........................................10 63 11. IPsec Protection Barrier and SPD.............................10 64 12. Entropy of manual keys.......................................11 65 13. Replay Protection............................................12 66 Security Considerations..........................................12 67 IANA Considerations..............................................13 68 Normative References.............................................13 69 Informative References...........................................13 70 Acknowledgments..................................................14 71 Authors' Addresses...............................................14 73 1. Introduction 75 OSPF (Open Shortest Path First) Version 2 [N1] defines the fields 76 AuType and Authentication in its protocol header to provide security. 77 In OSPF for IPv6 (OSPFv3) [N2], both of the authentication fields 78 were removed from OSPF headers. OSPFv3 relies on the IPv6 79 Authentication Header (AH) and IPv6 Encapsulating Security Payload 80 (ESP) to provide integrity, authentication and/or confidentiality. 82 This document describes how IPv6 AH/ESP extension headers can be used 83 to provide authentication/confidentiality to OSPFv3. 85 It is assumed that the reader is familiar with OSPFv3 [N2], AH [N5], 86 ESP [N4], the concept of security associations, tunnel and transport 87 mode of IPsec and the key management options available for AH and ESP 88 (manual keying [N3] and Internet Key Exchange (IKE)[I1]). 90 2. Transport Mode vs Tunnel Mode 92 The transport mode Security Association (SA) is generally used 93 between two hosts or routers/gateways when they are acting as hosts. 94 The SA must be a tunnel mode SA if either end of the security 95 association is a router/gateway. Two hosts MAY establish a tunnel 96 mode SA between themselves. OSPFv3 packets are exchanged between 97 routers. However, since the packets are locally delivered, the 98 routers assume the role of hosts in the context of tunnel mode SA. 99 All implementations confirming to this specification MUST support 100 Transport mode SA to provide required IPsec security to OSPFv3 101 packets. They MAY also support Tunnel mode SA to provide required 102 IPsec security to OSPFv3 packets. 104 3. Authentication 106 Implementations conforming to this specification MUST support 107 Authentication for OSPFv3. 109 In order to provide authentication to OSPFv3, implementations MUST 110 support ESP and MAY support AH. 112 If ESP in transport mode is used, it will only provide authentication 113 to OSPFv3 protocol packet excluding the IPv6 header, extension 114 headers and options. 116 If AH in transport mode is used, it will provide authentication to 117 OSPFv3 protocol packet, selected portions of IPv6 header, selected 118 portions of extension headers and selected options. 120 When OSPFv3 authentication is enabled, 122 O OSPFv3 packets that are not protected with AH or ESP MUST be 123 silently discarded. 125 O OSPFv3 packets that fail the authentication checks MUST be 126 silently discarded. 128 4. Confidentiality 130 Implementations conforming to this specification SHOULD support 131 confidentiality for OSPFv3. 133 If confidentiality is provided, ESP MUST be used. 135 When OSPFv3 confidentiality is enabled, 136 O OSPFv3 packets that are not protected with ESP MUST be silently 137 discarded. 139 O OSPFv3 packets that fail the confidentiality checks MUST be 140 silently discarded. 142 5. Distinguishing OSPFv3 from OSPFv2 144 The IP/IPv6 Protocol Type for OSPFv2 and OSPFv3 is the same (89) and 145 OSPF distinguishes them based on the OSPF header version number. 146 However, current IPsec standards do not allow using arbitrary 147 protocol specific header fields as the selectors. Therefore, the 148 OSPF version field in the OSPF header cannot be used in order to 149 distinguish OSPFv3 packets from OSPFv2 packets. As OSPFv2 is only 150 for IPv4 and OSPFv3 is only for IPv6, version field in IP header can 151 be used to distinguish OSPFv3 packets from OSPFv2 packets. 153 6. IPsec Requirements 155 In order to implement this specification, the following IPsec 156 capabilities are required. 158 Transport Mode 159 IPsec in transport mode MUST be supported. [N3] 161 Multiple SPDs 162 The implementation MUST support multiple SPDs with a SPD selection 163 function that provides an ability to choose a specific SPD based 164 on interface. [N3] 166 Selectors 167 The implementation MUST be able to use source address, destination 168 address, protocol and direction as selectors in the SPD. 170 Interface ID tagging 171 The implementation MUST be able to tag the inbound packets with 172 the ID of the interface (physical or virtual) via which it 173 arrived. [N3] 175 Manual key support 176 Manually configured keys MUST be able to secure the specified 177 traffic. [N3] 179 Encryption and Authentication Algorithms 180 The implementation MUST NOT allow the user to choose stream 181 ciphers as the encryption algorithm for securing OSPFv3 packets 182 since the stream ciphers are not suitable for manual keys. 184 Except when in conflict with the above statement, the Keywords 185 "MUST", "MUST NOT", "REQUIRED", "SHOULD" and "SHOULD NOT" that 186 appear in the [N6] document for algorithms to be supported are to 187 be interpreted as described in [N7] for OSPFv3 support as well. 189 Dynamic IPsec rule configuration 190 The routing module SHOULD be able to configure, modify and delete 191 IPsec rules on the fly. This is needed mainly for securing 192 virtual links. 194 Encapsulation of ESP packet 195 IP encapsulation of ESP packets MUST be supported. For 196 simplicity, UDP encapsulation of ESP packets SHOULD NOT be used. 198 Different SAs for different DSCPs 199 As per [N3], the IPsec implementation MUST support the 200 establishment and maintenance of multiple SAs with the same 201 selectors between a given sender and receiver. This allows the 202 implementation to associate different classes of traffic with same 203 selector values in support of QoS. 205 7. Key Management 207 OSPFv3 exchanges both multicast and unicast packets. While running 208 OSPFv3 over a broadcast interface, the authentication/confidentiality 209 required is "one to many". Since IKE is based on the Diffie-Hellman 210 key agreement protocol and works only for two communicating parties, 211 it is not possible to use IKE for providing the required "one to 212 many" authentication/confidentiality. This specification mandates 213 the usage of Manual Keying to work with the current IPsec 214 implementations. Future specifications can explore the usage of 215 protocols like KINK/GSAKMP when they are widely available. In manual 216 keying, SAs are statically installed on the routers and these static 217 SAs are used to authenticate/encrypt packets. 219 The following discussion explains that it is not scalable and is 220 practically infeasible to use different security associations for 221 inbound and outbound traffic to provide the required "one to many" 222 security. Therefore, the implementations MUST use manually 223 configured keys with the same SA parameters (SPI, keys etc.,) for 224 both inbound and outbound SA (as shown in Figure 3). 226 A | 227 SAa ------------>| 228 SAb <------------| 229 | 230 B | 231 SAb ------------>| 232 SAa <------------| Figure: 1 233 | 234 C | 235 SAa/SAb ------------>| 236 SAa/SAb <------------| 237 | 238 Broadcast 239 Network 241 If we consider communication between A and B in Figure 1, everything 242 seems to be fine. A uses security association SAa for outbound 243 packets and B uses the same for inbound packets and vice versa. Now 244 if we include C in the group and C sends a packet using SAa then only 245 A will be able to understand it. Similarly, if C sends a packet 246 using SAb then only B will be able to understand it. Since the 247 packets are multicast and they are going to be processed by both A 248 and B, there is no SA for C to use so that both A and B can 249 understand them. 251 A | 252 SAa ------------>| 253 SAb <------------| 254 SAc <------------| 255 | 256 B | 257 SAb ------------>| 258 SAa <------------| Figure: 2 259 SAc <------------| 260 | 261 C | 262 SAc ------------>| 263 SAa <------------| 264 SAb <------------| 265 | 266 Broadcast 267 Network 269 The problem can be solved by configuring SAs for all the nodes on 270 every other node as shown in Figure 2. So A, B and C will use SAa, 271 SAb and SAc respectively for outbound traffic. Each node will lookup 272 the SA to be used based on the source (A will use SAb and SAc for 273 packets received from B and C respectively). This solution is not 274 scalable and practically infeasible because a large number of SAs 275 will need to be configured on each node. Also, the addition of a 276 node in the broadcast network will require the addition of another SA 277 on every other node. 279 A | 280 SAo ------------>| 281 SAi <------------| 282 | 283 B | 284 SAo ------------>| 285 SAi <------------| Figure: 3 286 | 287 C | 288 SAo ------------>| 289 SAi <------------| 290 | 291 Broadcast 292 Network 294 The problem can be solved by using the same SA parameters (SPI, Keys 295 etc.,) for both inbound (SAi) and outbound (SAo) SAs as shown in 296 Figure 3. 298 8. SA Granularity and Selectors 300 The user SHOULD be given the choice of sharing the same SA among 301 multiple interfaces or using a unique SA per interface. 303 OSPFv3 supports running multiple instances over one interface using 304 the "Instance Id" field contained in the OSPFv3 header. As IPsec 305 does not support arbitrary fields in protocol header to be used as 306 the selectors, it is not possible to use different SAs for different 307 OSPFv3 instances running over the same interface. Therefore, all 308 OSPFv3 instances running over the same interface will have to use the 309 same SA. In OSPFv3 RFC terminology, SAs are per-link and not per- 310 interface. 312 9. Virtual Links 313 A different SA than the SA of the underlying interface MUST be 314 provided for virtual links. Packets sent on virtual links use 315 unicast non-link local IPv6 addresses as the IPv6 source address 316 while packets sent on other interfaces use multicast and unicast link 317 local addresses. This difference in the IPv6 source address 318 differentiates the packets sent on virtual links from other OSPFv3 319 interface types. 321 As the virtual link end point IPv6 addresses are not known, it is not 322 possible to install SPD/SAD entries at the time of configuration. 323 The virtual link end point IPv6 addresses are learned during the 324 routing table computation process. The packet exchange over the 325 virtual links starts only after the discovery of the end point IPv6 326 addresses. In order to protect these exchanges, the routing module 327 must install the corresponding SPD/SAD entries before starting these 328 exchanges. Note that manual SA parameters are preconfigured but not 329 installed in the SAD until the end point addresses are learned. 331 According to the OSPFv3 RFC [N2], the virtual neighbor's IP address 332 is set to the first prefix with the "LA-bit" set from the list of 333 prefixes in intra-area-prefix-LSAs originated by the virtual 334 neighbor. But when it comes to choosing the source address for the 335 packets that are sent over the virtual link, the RFC simply suggests 336 using one of the router's own global IPv6 addresses. In order to 337 install the required security rules for virtual links, the source 338 address also needs to be predictable. Hence, routers that implement 339 this specification MUST change the way the source and destination 340 addresses are chosen for packets exchanged over virtual links when 341 IPsec is enabled. 343 The first IPv6 address with the "LA-bit" set in the list of prefixes 344 advertised in intra-area-prefix-LSAs in the transit area MUST be used 345 as the source address for packets exchanged over the virtual link. 346 When multiple intra-area-prefix-LSAs are originated they are 347 considered as being concatenated and are ordered by ascending Link 348 State ID. 350 The first IPv6 address with the "LA-bit" set in the list of prefixes 351 received in intra-area-prefix-LSAs from the virtual neighbor in the 352 transit area MUST be used as the destination address for packets 353 exchanged over the virtual link. When multiple intra-area-prefix- 354 LSAs are received they are considered as being concatenated and are 355 ordered by ascending Link State ID. 357 This makes both the source and destination addresses of packets 358 exchanged over the virtual link predictable when IPsec is enabled. 360 10. Rekeying 362 To maintain the security of a link, the authentication and encryption 363 key values SHOULD be changed from periodically. 365 10.1 Rekeying Procedure 367 The following three-step procedure SHOULD be provided to rekey the 368 routers on a link without dropping OSPFv3 protocol packets or 369 disrupting the adjacency. 371 (1) For every router on the link, create an additional inbound SA for 372 the interface being rekeyed using a new SPI and the new key. 374 (2) For every router on the link, replace the original outbound SA 375 with one using the new SPI and key values. The SA replacement 376 operation should be atomic with respect to sending OSPFv3 packets 377 on the link so that no OSPFv3 packets are sent without 378 authentication/encryption. 380 (3) For every router on the link, remove the original inbound SA. 382 Note that all routers on the link must complete step 1 before any 383 begin step 2. Likewise, all the routers on the link must complete 384 step 2 before any begin step 3. 386 One way to control the progression from one step to the next is for 387 each router to have a configurable time constant KeyRolloverInterval. 388 After the router begins step 1 on a given link, it waits for this 389 interval and then moves to step 2. Likewise, after moving to step 2, 390 it waits for this interval and then moves to step 3. 392 In order to achieve smooth key transition, all routers on a link 393 should use the same value for KeyRolloverInterval and should initiate 394 the key rollover process within this time period. 396 At the end of this procedure, all the routers on the link will have a 397 single inbound and outbound SA for OSPFv3 with the new SPI and key 398 values. 400 10.2 KeyRolloverInterval 402 The configured value of KeyRolloverInterval should be long enough to 403 allow the administrator to change keys on all the OSPFv3 routers. As 404 this value can vary significantly depending upon the implementation 405 and the deployment, it is left to the administrator to choose the 406 appropriate value. 408 10.3 Rekeying Interval 410 This section analyzes the security provided by manual keying and 411 recommends that the encryption and authentication keys SHOULD be 412 changed at least every 90 days. 414 The weakest security provided by the security mechanisms discussed in 415 this specification is when NULL encryption (for ESP) or no encryption 416 (for AH) is used with the HMAC-MD5 authentication. Any other 417 algorithm combinations will at least be as hard to break as the ones 418 mentioned above. This is shown by the following reasonable 419 assumptions: 421 O NULL Encryption and HMAC-SHA-1 Authentication will be more secure 422 as HMAC-SHA-1 is considered to be more secure than HMAC-MD5. 424 O NON-NULL Encryption and NULL Authentication is not applicable as 425 this specification mandates authentication when OSPFv3 security is 426 enabled. 428 O DES Encryption and HMAC-MD5 Authentication will be more secure 429 because of the additional security provided by DES. 431 O Other encryption algorithms like 3DES and AES will be more secure 432 than DES. 434 RFC 3562 [I4] analyzes the rekeying requirements for the TCP MD5 435 signature option. The analysis provided in this RFC is also 436 applicable to this specification as the analysis is independent of 437 data patterns. 439 11. IPsec Protection Barrier and SPD 441 The IPsec protection barrier MUST BE around the OSPF protocol. 442 Therefore, all the inbound and outbound OSPF traffic goes through 443 IPsec processing. 445 The SPD selection function MUST return a SPD with the following rule 446 for all the interfaces that have OSPFv3 447 authentication/confidentiality disabled. 449 No. source destination protocol action 450 1 any any OSPF bypass 452 The SPD selection function MUST return a SPD with the following rules 453 for all the interfaces that have OSPFv3 454 authentication/confidentiality enabled. 456 No. source destination protocol action 457 2 fe80::/10 any OSPF protect 458 3 fe80::/10 any ESP/OSPF or AH/OSPF protect 459 4 src/128 dst/128 OSPF protect 460 5 src/128 dst/128 ESP/OSPF or AH/OSPF protect 462 For rules 2 and 4, action "protect" means encrypting/calculating ICV 463 and adding an ESP or AH header. For rules 3 and 5, action "protect" 464 means decrypting/authenticating the packets and stripping the ESP or 465 AH header. 467 Rule 1 will bypass the OSPFv3 packets without any IPsec processing on 468 the interfaces that have OSPFv3 authentication/confidentiality 469 disabled. 471 Rules 2 and 4 will drop the inbound OSPFv3 packets that have not been 472 secured with ESP/AH headers. 474 ESP/OSPF or AH/OSPF in rules 3 and 5 mean that it is an OSPF packet 475 secured with ESP or AH. 477 Rules 2 and 3 are meant to secure the unicast and multicast OSPF 478 packets that are not being exchanged over the virtual links. 480 Rules 4 and 5 are meant to secure the packets being exchanged over 481 virtual links. These rules are installed after learning the virtual 482 link end point IPv6 addresses. These rules MUST be installed in the 483 SPD for the interfaces that are connected to the transit area for the 484 virtual link. These rules MAY alternatively be installed on all the 485 interfaces. If these rules are not installed on all the interfaces, 486 clear text or malicious OSPFv3 packets with the same source and 487 destination addresses as the virtual link end point IPv6 addresses 488 will be delivered to OSPFv3. Though OSPFv3 drops these packets 489 because they were not received on the right interface, OSPFv3 490 receives some clear text or malicious packets even when the security 491 is enabled. Installing these rules on all the interfaces insures 492 that OSPFv3 does not receive these clear text or malicious packets 493 when security is turned enabled. On the other hand, installing these 494 rules on all the interfaces increases the processing overhead on the 495 interfaces where there is no other IPsec processing. The decision of 496 installing these rules on all the interfaces or on just the 497 interfaces that are connected to the transit area is a private 498 decision and doesn't affect the interoperability in any way. Hence 499 it is an implementation choice. 501 12. Entropy of manual keys 502 The implementations MUST allow the administrator to configure the 503 cryptographic and authentication keys in hexadecimal format rather 504 than restricting it to a subset of ASCII characters (letters, numbers 505 etc). A restricted character set will reduce key entropy 506 significantly as discussed in [I2]. 508 13. Replay Protection 510 Since it is not possible using the current standards to provide 511 complete replay protection while using manual keying, the proposed 512 solution will not provide protection against replay attacks. 514 Detailed analysis of various vulnerabilities of the routing protocols 515 and OSPF in particular is discussed in [I3] and [I2]. The conclusion 516 is that "Replay of OSPF packets can cause adjacencies to be 517 disrupted, which can lead to a DoS attack on the network. It can also 518 cause database exchange process to occur continuously thus causing 519 CPU overload as well as micro loops in the network". 521 Security Considerations 523 This memo discusses the use of IPsec AH and ESP headers in order to 524 provide security to OSPFv3 for IPv6. Hence security permeates 525 throughout this document. 527 OSPF Security Vulnerabilities Analysis [I2] identifies OSPF 528 vulnerabilities in two scenarios - One with no authentication or 529 simple password authentication and the other with cryptographic 530 authentication. The solution described in this specification 531 provides protection against all the vulnerabilities identified for 532 scenarios with cryptographic authentication with the following 533 exceptions: 535 Limitations of manual key: 536 This specification mandates the usage of manual keys. The following 537 are the known limitations of the usage of manual keys. 539 O As the sequence numbers can not be negotiated, replay protection 540 can not be provided. This leaves OSPF insecure against all the 541 attacks that can be performed by replaying OSPF packets. 543 O Manual keys are usually long lived (changing them often is 544 a tedious task). This gives an attacker enough time to discover 545 the keys. 547 O As the administrator is manually configuring the keys, there is 548 a chance that the configured keys are weak (there are known weak 549 keys for DES/3DES at least). 551 Impersonating Attacks: 553 The usage of the same key on all the OSPF routers connected to a link 554 leaves them all insecure against impersonating attacks if any one of 555 the OSPF routers is compromised, malfunctioning or misconfigured. 557 Detailed analysis of various vulnerabilities of routing protocols is 558 discussed in [I3]. 560 IANA Considerations 561 This document has no IANA considerations. 563 This section should be removed by the RFC Editor to final 564 publication. 566 Normative References 568 N1. Moy, J., "OSPF version 2", RFC 2328, April 1998. 570 N2. Coltun, R., Ferguson, D. and J. Moy, "OSPF for IPv6", RFC 2740, 571 December 1999. 573 N3. Kent, S. and K. Seo, "Security Architecture for the Internet 574 Protocol", RFC 4301, December 2005. 576 N4. Kent, S., "IP Encapsulating Security Payload (ESP)", RFC 4303, 577 December 2005. 579 N5. Kent, S., "IP Authentication Header (AH)", RFC 4302, December 580 2005. 582 N6. Eastlake, D., "Cryptographic Algorithm Implementation Requirements 583 For ESP And AH", RFC 4305, December 2005. 585 N7. Bradner, S., "Key words for use in RFCs to Indicate Requirement 586 Level", BCP 14, RFC 2119, March 1997. 588 N8. Frankel, S., Glenn, R. and S. Kelly, "The AES-CBC Cipher Algorithm 589 and Its Use with IPsec", RFC 3602, September 2003. 591 N9. Madson, C. and R. Glenn, "The Use of HMAC-SHA-1-96 within ESP and 592 AH", RFC 2404, November 1998. 594 Informative References 596 I1. Kaufman, C., "The Internet Key Exchange (IKEv2) Protocol", RFC 597 4306, December 2005. 599 I2. Jones, E. and O. Moigne, "OSPF Security Vulnerabilities Analysis", 600 draft-ietf-rpsec-ospf-vuln-01.txt, work in progress. 602 I3. Barbir, A., Murphy, S. and Y. Yang, "Generic Threats to Routing 603 Protocols", draft-ietf-rpsec-routing-threats-07.txt, work in 604 progress. 606 I4. Leech, M., "Key Management Considerations for the TCP MD5 607 Signature Option", RFC 3562, July 2003. 609 Acknowledgments 611 Authors would like to extend sincere thanks to Marc Solsona, Janne 612 Peltonen, John Cruz, Dhaval Shah, Abhay Roy, Paul Wells, Vishwas 613 Manral and Sam Hartman for providing useful information and critiques 614 in order to write this memo. Authors would like to extend special 615 thanks to Acee Lindem for lots of editorial changes. 617 We would also like to thank IPsec and OSPF WG people to provide 618 valuable review comments. 620 Authors' Addresses 622 Mukesh Gupta 623 Tropos Networks 624 555 Del Rey Ave 625 Sunnyvale, CA 94085 626 Phone: 408-331-6889 627 Email: mukesh.gupta@tropos.com 629 Nagavenkata Suresh Melam 630 Juniper Networks 631 1194 N. Mathilda Ave 632 Sunnyvale, CA 94089 633 Phone: 408-505-4392 634 Email: nmelam@juniper.net 636 Full copyright statement 638 This document is subject to the rights, licenses and restrictions 639 contained in BCP 78, and except as set forth therein, the authors 640 retain all their rights. 642 This document and the information contained herein are provided on an 643 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 644 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 645 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 646 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 647 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 648 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 650 Intellectual Property 652 The IETF takes no position regarding the validity or scope of any 653 Intellectual Property Rights or other rights that might be claimed to 654 pertain to the implementation or use of the technology described in 655 this document or the extent to which any license under such rights 656 might or might not be available; nor does it represent that it has 657 made any independent effort to identify any such rights. Information 658 on the procedures with respect to rights in RFC documents can be 659 found in BCP 78 and BCP 79. 661 Copies of IPR disclosures made to the IETF Secretariat and any 662 assurances of licenses to be made available, or the result of an 663 attempt made to obtain a general license or permission for the use of 664 such proprietary rights by implementers or users of this 665 specification can be obtained from the IETF on-line IPR repository at 666 http://www.ietf.org/ipr. The IETF invites any interested party to 667 bring to its attention any copyrights, patents or patent 668 applications, or other proprietary rights that may cover technology 669 that may be required to implement this standard. Please address the 670 information to the IETF at ietf-ipr@ietf.org.