idnits 2.17.1 draft-ietf-ospf-ospfv3-auth-07.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1.a on line 15. -- Found old boilerplate from RFC 3978, Section 5.5 on line 635. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 646. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 657. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 657. ** The document seems to lack an RFC 3978 Section 5.1 IPR Disclosure Acknowledgement -- however, there's a paragraph with a matching beginning. Boilerplate error? ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** The document seems to lack an RFC 3978 Section 5.4 Reference to BCP 78 -- however, there's a paragraph with a matching beginning. Boilerplate error? ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. ** The document uses RFC 3667 boilerplate or RFC 3978-like boilerplate instead of verbatim RFC 3978 boilerplate. After 6 May 2005, submission of drafts without verbatim RFC 3978 boilerplate is not accepted. The following non-3978 patterns matched text found in the document. That text should be removed or replaced: By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (February 2005) is 7010 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 178 looks like a reference -- Missing reference section? 'N1' on line 74 looks like a reference -- Missing reference section? 'N2' on line 320 looks like a reference -- Missing reference section? 'N5' on line 84 looks like a reference -- Missing reference section? 'N4' on line 85 looks like a reference -- Missing reference section? 'N3' on line 190 looks like a reference -- Missing reference section? 'I1' on line 87 looks like a reference -- Missing reference section? 'N6' on line 177 looks like a reference -- Missing reference section? 'I4' on line 422 looks like a reference -- Missing reference section? 'I2' on line 516 looks like a reference -- Missing reference section? 'I3' on line 546 looks like a reference Summary: 7 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 Nokia 4 Document: draft-ietf-ospf-ospfv3-auth-07.txt N. Melam 5 Expires: August 2005 Nokia 6 February 2005 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 RFC 3668. 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. (2004) 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..................................2 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......................................................8 60 10.1 Rekeying Procedure........................................8 61 10.2 KeyRolloverInterval.......................................9 62 10.3 Rekeying Interval.........................................9 63 11. IPsec rules..................................................10 64 12. Entropy of manual keys.......................................11 65 13. Replay Protection............................................11 66 Security Considerations..........................................11 67 Normative References.............................................12 68 Informative References...........................................13 69 Acknowledgments..................................................13 70 Authors' Addresses...............................................14 72 1. Introduction 74 OSPF (Open Shortest Path First) Version 2 [N1] defines fields AuType 75 and Authentication in its protocol header in order to provide 76 security. In OSPF for IPv6 (OSPFv3) [N2], both of the authentication 77 fields were removed from OSPF headers. OSPFv3 relies on the IPv6 78 Authentication Header (AH) and IPv6 Encapsulating Security Payload 79 (ESP) to provide integrity, authentication and/or confidentiality. 81 This document describes how IPv6 AH/ESP extension headers can be used 82 to provide authentication/confidentiality to OSPFv3. 84 It is assumed that the reader is familiar with OSPFv3 [N2], AH [N5], 85 ESP [N4], the concept of security associations, tunnel and transport 86 mode of IPsec and the key management options available for AH and ESP 87 (manual keying [N3] and Internet Key Exchange (IKE)[I1]). 89 2. Transport Mode vs Tunnel Mode 91 Transport mode Security Association (SA) is generally used between 92 two hosts or routers/gateways when they are acting as hosts. SA must 93 be a tunnel mode SA if either end of the security association is a 94 router/gateway. Two hosts MAY establish a tunnel mode SA between 95 themselves. OSPFv3 packets are exchanged between the routers but as 96 the packets are destined to the routers, the routers act like hosts 97 in this case. All implementations confirming to this specification 98 MUST support Transport mode SA to provide required IPsec security to 99 OSPFv3 packets. They MAY also support Tunnel mode SA to provide 100 required IPsec security to OSPFv3 packets. 102 3. Authentication 104 Implementations conforming to this specification MUST support 105 Authentication for OSPFv3. 107 In order to provide authentication to OSPFv3, ESP MUST be supported 108 and AH MAY be supported by the implementation. 110 If ESP in transport mode is used, it will provide authentication to 111 only OSPFv3 protocol headers but not to the IPv6 header, extension 112 headers and options. 114 If AH in transport mode is used, it will provide authentication to 115 OSPFv3 protocol headers, selected portions of IPv6 header, selected 116 portions of extension headers and selected options. 118 When OSPFv3 authentication is enabled, 120 O OSPFv3 packets that are not protected with AH or ESP MUST be 121 silently discarded. 123 O OSPFv3 packets that fail the authentication checks MUST be 124 silently discarded. 126 4. Confidentiality 128 Implementations conforming to this specification SHOULD support 129 confidentiality for OSPFv3. 131 If confidentiality is provided, ESP MUST be used. 133 When OSPFv3 confidentiality is enabled, 135 O OSPFv3 packets that are not protected with ESP MUST be silently 136 discarded. 138 O OSPFv3 packets that fail the confidentiality checks MUST be 139 silently discarded. 141 5. Distinguishing OSPFv3 from OSPFv2 143 The IP/IPv6 Protocol Type for OSPFv2 and OSPFv3 is same (89) and 144 OSPF distinguishes them based on the OSPF header version number. 145 However current IPsec standards do not allow using arbitrary protocol 146 specific header fields as the selectors. Therefore, in order to 147 distinguish OSPFv3 packets from the OSPFv2 packets, OSPF version 148 field in the OSPF header cannot be used. As OSPFv2 is only for IPv4 149 and OSPFv3 is only for IPv6, version field in IP header can be used 150 to distinguish OSPFv3 packets from OSPFv2 packets. 152 6. IPsec Requirements 154 In order to implement this specification, the following IPsec 155 capabilities are required. 157 Transport Mode 158 IPsec in transport mode MUST be supported. [N3] 160 Traffic Selectors 161 The implementation MUST be able to use interface index, source 162 address, destination address, protocol and direction for choosing 163 the right security action. 165 Manual key support 166 Manually configured keys MUST be able to secure the specified 167 traffic. [N3] 169 Encryption and Authentication Algorithms 171 The implementation MUST NOT allow the user to choose stream 172 ciphers as the encryption algorithm for securing OSPFv3 packets 173 as the stream ciphers are not suitable for manual keys. 175 Except when in conflict with the above statement, Keywords 176 "MUST", "MUST NOT", "REQUIRED", "SHOULD" and "SHOULD NOT" that 177 appear in the [N6] document for algorithms to be supported are to 178 be interpreted as described in [N7] for OSPFv3 support too. 180 Dynamic IPsec rule configuration 181 Routing module SHOULD be able to configure, modify and delete 182 IPsec rules on the fly. This is needed mainly for securing 183 virtual links. 185 Encapsulation of ESP packet 186 IP encapsulation of ESP packets MUST be supported. For 187 simplicity, UDP encapsulation of ESP packets SHOULD NOT be used. 189 Different SAs for different DSCPs 190 As per [N3], IPsec implementation MUST support the establishment 191 and maintenance of multiple SAs between given sender and receiver, 192 with the same selectors. This allows the implementation to put 193 traffic of different classes, but with same selector values, on 194 different SAs to support QoS appropriately. 196 7. Key Management 198 OSPFv3 exchanges both multicast and unicast packets. While running 199 OSPFv3 over a broadcast interface, the authentication/confidentiality 200 required is "one to many". Since IKE is based on the Diffie-Hellman 201 key agreement protocol and works only for two communicating parties, 202 it is not possible to use IKE for providing the required "one to 203 many" authentication/confidentiality. This specification mandates 204 the usage of Manual Keying to work with the current IPsec 205 implementations. Future specifications can explore the usage of 206 protocols like KINK/GSAKMP as and when they are widely available. In 207 manual keying SAs are statically installed on the routers and these 208 static SAs are used to authenticate/encrypt the packets. 210 The following discussion explains that it is not scalable and 211 practically infeasible to use different security associations for 212 inbound and outbound traffic in order to provide the required "one to 213 many" security. Therefore, the implementations MUST use manually 214 configured keys with same SA for inbound and outbound traffic (as 215 shown in Figure 3). 217 A | 218 SAa ------------>| 219 SAb <------------| 220 | 221 B | 222 SAb ------------>| 223 SAa <------------| Figure: 1 224 | 225 C | 226 SAa/SAb ------------>| 227 SAa/SAb <------------| 228 | 229 Broadcast 230 Network 232 If we consider communication between A and B in Figure 1, everything 233 seems to be fine. A uses security association SAa for outbound 234 packets and B uses the same for inbound packets and vice versa. Now 235 if we include C in the group and C sends a packet out using SAa then 236 only A will be able to understand it or if C sends the packets out 237 using SAb then only B will be able to understand it. Since the 238 packets are multicast packets and they are going to be processed by 239 both A and B, there is no SA for C to use so that A and B both can 240 understand it. 242 A | 243 SAa ------------>| 244 SAb <------------| 245 SAc <------------| 246 | 247 B | 248 SAb ------------>| 249 SAa <------------| Figure: 2 250 SAc <------------| 251 | 252 C | 253 SAc ------------>| 254 SAa <------------| 255 SAb <------------| 256 | 257 Broadcast 258 Network 260 The problem can be solved by configuring SAs for all the nodes on all 261 the nodes as shown in Figure 2. So A, B and C will use SAa, SAb and 262 SAc respectively for outbound traffic. Each node will lookup the SA 263 to be used based on the source (A will use SAb and SAc for packets 264 received from B and C respectively). This solution is not scalable 265 and practically infeasible because every node will need to be 266 configured with a large number of SAs and addition of a node in the 267 network will cause addition of another SA on all the nodes. 269 A | 270 SAs ------------>| 271 SAs <------------| 272 | 273 B | 274 SAs ------------>| 275 SAs <------------| Figure: 3 276 | 278 C | 279 SAs ------------>| 280 SAs <------------| 281 | 282 Broadcast 283 Network 285 The problem can also be solved by using the same SA for inbound and 286 outbound traffic as shown in Figure 3. 288 8. SA Granularity and Selectors 290 The user SHOULD be given a choice to share the same SA among multiple 291 interfaces or using unique SA per interface. 293 OSPFv3 supports running multiple instances over one interface using 294 the "Instance Id" field contained in the OSPFv3 header. As IPsec 295 does not support arbitrary fields in protocol header to be used as 296 the selectors, it is not possible to use different SAs for different 297 instances of OSPFv3 running over the same interface. Therefore, all 298 the instances of OSPFv3 running over the same interface will have to 299 use the same SA. In OSPFv3 RFC terminology, SAs are per-link and not 300 per-interface. 302 9. Virtual Links 304 Different SA than the SA of underlying interface MUST be provided for 305 virtual links. Packets sent out on virtual links use unicast non- 306 link local IPv6 addresses as the IPv6 source address and all the 307 other packets use multicast and unicast link local addresses. This 308 difference in the IPv6 source address is used in order to 309 differentiate the packets sent on interfaces and virtual links. 311 As the end point IP addresses of the virtual links are not known at 312 the time of configuration, the secure channel for these packets needs 313 to be set up dynamically. The end point IP addresses of virtual 314 links are learned during the routing table build up process. The 315 packet exchange over the virtual links starts only after the 316 discovery of end point IP addresses. In order to provide security to 317 these exchanges, the routing module should setup a secure IPsec 318 channel dynamically once it acquires the required information. 320 According to the OSPFv3 RFC [N2], the virtual neighbor's IP address 321 is set to the first prefix with the "LA-bit" set from the list of 322 prefixes in intra-area-prefix-LSAs originated by the virtual 323 neighbor. But when it comes to choosing the source address for the 324 packets that are sent over the virtual link, the RFC simply suggests 325 using one of the router's own site-local or global IPv6 addresses. 326 In order to install the required security rules for virtual links, 327 the source address also needs to be predictable. So the routers that 328 implement this specification MUST change the way the source and 329 destination addresses are chosen for the packets exchanged over 330 virtual links when the security is enabled on that virtual link. 332 The first IPv6 address with the "LA-bit" set in the list of prefixes 333 advertised in intra-area-prefix-LSAs in the transit area MUST be used 334 as the source address for packets exchanged over the virtual link. 335 When multiple intra-area-prefix-LSAs are originated they are 336 considered as being concatenated and are ordered by ascending Link 337 State ID. 339 The first IPv6 address with the "LA-bit" set in the list of prefixes 340 received in intra-area-prefix-LSAs from the virtual neighbor in the 341 transit area MUST be used as the destination address for packets 342 exchanged over the virtual link. When multiple intra-area-prefix- 343 LSAs are received they are considered as being concatenated and are 344 ordered by ascending Link State ID. 346 This makes both the source and destination addresses of the packets 347 exchanged over the virtual link, predictable on both the routers for 348 security purposes. 350 10. Rekeying 352 To maintain the security of a link, the authentication and encryption 353 key values SHOULD be changed from time to time. 355 10.1 Rekeying Procedure 357 The following three-step procedure SHOULD be provided to rekey the 358 routers on a link without dropping OSPFv3 protocol packets or 359 disrupting the adjacency. 361 (1) For every router on the link, create an additional inbound SA for 362 the interface being rekeyed using a new SPI and the new key. 364 (2) For every router on the link, replace the original outbound SA 365 with one using the new SPI and key values. The SA replacement 366 operation should be atomic with respect to sending OSPFv3 packets 367 on the link so that no OSPFv3 packets are sent without 368 authentication/encryption. 370 (3) For every router on the link, remove the original inbound SA. 372 Note that all the routers on the link must complete step 1 before any 373 begin step 2. Likewise, all the routers on the link must complete 374 step 2 before any begin step 3. 376 One way to control the progression from one step to the next is for 377 each router to have a configurable time constant KeyRolloverInterval. 378 After the router begins step 1 on a given link, it waits for this 379 interval and then moves to step 2. Likewise, after moving to step 2, 380 it waits for this interval and then moves to step 3. 382 In order to achieve smooth key transition, all the routers on a link 383 should use the same value for KeyRolloverInterval, and should 384 initiate the key rollover process within this time period. 386 At the end of this procedure, all the routers will have a single 387 inbound and outbound SA for OSPFv3 on the link with the new SPI and 388 key values. 390 10.2 KeyRolloverInterval 392 The configured value of KeyRolloverInterval should be long enough to 393 allow the administrator to change keys on all the involved routers. 394 As this value can vary significantly depending upon the 395 implementation and the deployment, it is left to the administrator to 396 choose the appropriate value. 398 10.3 Rekeying Interval 400 This section analyzes the security provided by the manual keying and 401 recommends that the encryption and authentication keys SHOULD be 402 changed at least every 90 days. 404 The weakest security provided by the security mechanisms discussed in 405 this specification is when NULL encryption (for ESP) or no encryption 406 (for AH) is used with the HMAC-MD5 authentication. Any other 407 algorithm combinations will at least be as hard to break as the one 408 mentioned above as shown by the following examples: 410 O NULL Encryption and HMAC-SHA-1 Authentication will be more secure 411 as HMAC-SHA-1 is considered to be more secure than HMAC-MD5 413 O NON-NULL Encryption and NULL Authentication is not applicable as 414 this specification mandates the authentication when OSPFv3 security 415 is enabled 417 O DES Encryption and HMAC-MD5 Authentication will be more secure 418 because of the additional security provided by DES 419 O Other encryption algorithms like 3DES, AES will be more secure than 420 DES 422 RFC 3562 [I4] analyzes the rekeying requirements for the TCP MD5 423 signature option. The analysis provided in this RFC is also 424 applicable to OSPFv3 security specification as the analysis is 425 independent of data patterns. 427 11. IPsec rules 429 The following set of transport mode rules can be installed in a 430 typical IPsec implementation to provide the 431 authentication/confidentiality to OSPFv3 packets. 433 Outbound Rules for interface running OSPFv3 security: 435 No. source destination protocol action 436 1 fe80::/10 any OSPF apply 438 Outbound Rules for virtual links running OSPFv3 security: 440 No. source destination protocol action 441 2 src/128 dst/128 OSPF apply 443 Inbound Rules for interface running OSPFv3 security: 445 No. source destination protocol action 446 3 fe80::/10 any ESP/OSPF or AH/OSPF apply 447 4 fe80::/10 any OSPF drop 449 Inbound Rules for virtual links running OSPFv3 security: 451 No. source destination protocol action 452 5 src/128 dst/128 ESP/OSPF or AH/OSPF apply 453 6 src/128 dst/128 OSPF drop 455 For outbound rules, action "apply" means encrypting/calculating ICV 456 and adding ESP or AH header. For inbound rules, action "apply" means 457 decrypting/authenticating the packets and stripping ESP or AH header. 459 Rules 4 and 6 are to drop the insecure OSPFv3 packets without ESP/AH 460 headers. 462 ESP/OSPF or AH/OSPF in rules 3 and 5 mean that it is an OSPF packet 463 secured with ESP or AH. 465 Rules 1, 3 and 4 are meant to secure the unicast and multicast OSPF 466 packets that are not being exchanged over the virtual links. These 467 rules MUST be installed only in the security policy database (SPD) of 468 the interface running OSPFv3 security. 470 Rules 2, 5 and 6 are meant to secure the packets being exchanged over 471 virtual links. These rules are dynamically installed after learning 472 the end point IP addresses of a virtual link. These rules MUST be 473 installed on at least the interfaces that are connected to the 474 transit area for the virtual link. These rules MAY alternatively be 475 installed on all the interfaces. If these rules are not installed on 476 all the interfaces, clear text or malicious OSPFv3 packets with same 477 source and destination addresses as virtual link end point addresses 478 will be delivered to OSPFv3. Though OSPFv3 drops these packets 479 because they were not received on the right interface, OSPFv3 480 receives some clear text or malicious packets even when the security 481 is on. Installing these rules on all the interfaces insures that 482 OSPFv3 does not receive these clear text or malicious packets when 483 security is turned on. On the other hand installing these rules on 484 all the interfaces increases the processing overhead on the 485 interfaces where there is no IPsec processing otherwise. The 486 decision of installing these rules on all the interfaces or on just 487 the interfaces that are connected to the transit area is a private 488 decision and doesn't affect the interoperability in any way. So this 489 decision is left to the implementers. 491 12. Entropy of manual keys 492 The implementations MUST allow the administrator to configure the 493 cryptographic and authentication keys in hexadecimal format instead 494 of restricting it a subset of ASCII characters (letters, numbers 495 etc). Otherwise the entropy of the keys reduces significantly as 496 discussed in [I2]. 498 13. Replay Protection 500 As it is not possible as per the current standards to provide 501 complete replay protection while using manual keying, the proposed 502 solution will not provide protection against replay attacks. 504 Detailed analysis of various vulnerabilities of the routing protocols 505 and OSPF in particular is discussed in [I3] and [I2], but it can be 506 summarized that "Replay of OSPF packets can cause adjacencies to be 507 disrupted, which can lead to DoS attack on the network. It can also 508 cause database exchange process to occur continuously thus causing 509 CPU overload as well as micro loops in the network". 511 Security Considerations 512 This memo discusses the use of IPsec AH and ESP headers in order to 513 provide security to OSPFv3 for IPv6. Hence security permeates 514 throughout this document. 516 OSPF Security Vulnerabilities Analysis [I2] identifies OSPF 517 vulnerabilities in two scenarios - One with no authentication or 518 simple password authentication and the other with cryptographic 519 authentication. The solution described in this specification 520 provides security against all the vulnerabilities identified for 521 scenario with cryptographic authentication with the following 522 exceptions: 524 Limitations of manual key: 525 This specification mandates the usage of manual keys. The following 526 are the known limitations of the usage of manual keys. 528 O As the sequence numbers can not be negotiated, replay protection 529 can not be provided. This leaves OSPF insecure against all the 530 attacks that can be performed by replaying OSPF packets. 532 O Manual keys are usually long lived (changing them very often is 533 a tedious task). This gives an attacker enough time to discover 534 the keys. 536 O As the administrator is manually configuring the keys, there is 537 a chance that the configured keys are weak (there are known weak 538 keys for DES/3DES at least). 540 Impersonating Attacks: 541 The usage of the same key on all the routers on the same link for 542 securing OSPF leaves it insecure against impersonating attacks if one 543 of the routers is compromised, malfunctioning or misconfigured. 545 Detailed analysis of various vulnerabilities of the routing protocols 546 is discussed in [I3]. 548 Normative References 550 N1. Moy, J., "OSPF version 2", RFC 2328, April 1998. 552 N2. Coltun, R., Ferguson, D. and J. Moy, "OSPF for IPv6", RFC 2740, 553 December 1999. 555 N3. Kent, S. and K. Seo, "Security Architecture for the Internet 556 Protocol", RFC XXXX, date [Note to RFC-Editor: Replace XXXX with 557 the number of the RFC 2401 replacement]. 559 N4. Kent, S., "IP Encapsulating Security Payload (ESP)", RFC XXXY, 560 date [Note to RFC-Editor: Replace XXXY with the number of the RFC 561 2406 replacement]. 563 N5. Kent, S., "IP Authentication Header (AH)", RFC XXXZ, date [Note to 564 RFC-Editor: Replace XXXZ with the number of the RFC 2402 565 replacement]. 567 N6. Eastlake, D., "Cryptographic Algorithm Implementation Requirements 568 For ESP And AH", RFC XXYY, date [Note to RFC-Editor: Replace XXYY 569 with the number of the RFC that the draft draft-ietf-ipsec-esp-ah- 570 algorithms-02.txt gets]. 572 N7. Bradner, S., "Key words for use in RFCs to Indicate Requirement 573 Level", BCP 14, RFC 2119, March 1997. 575 N8. Frankel, S., Glenn, R. and S. Kelly, "The AES-CBC Cipher Algorithm 576 and Its Use with IPsec", RFC 3602, September 2003. 578 N9. Madson, C. and R. Glenn, "The Use of HMAC-SHA-1-96 within ESP and 579 AH", RFC 2404, November 1998. 581 Informative References 583 I1. Kaufman, C., "The Internet Key Exchange (IKEv2) Protocol", RFC 584 XXZZ, date [Note to RFC-Editor: Replace XXZZ with the number of the 585 RFC 2409 replacement]. 587 I2. Jones, E. and O. Moigne, "OSPF Security Vulnerabilities Analysis", 588 draft-ietf-rpsec-ospf-vuln-01.txt, work in progress. 590 I3. Barbir, A., Murphy, S. and Y. Yang, "Generic Threats to Routing 591 Protocols", draft-ietf-rpsec-routing-threats-07.txt, work in 592 progress. 594 I4. Leech, M., "Key Management Considerations for the TCP MD5 595 Signature Option", RFC 3562, July 2003. 597 Acknowledgments 599 Authors would like to extend sincere thanks to Marc Solsona, Janne 600 Peltonen, John Cruz, Dhaval Shah, Abhay Roy, Paul Wells and Vishwas 601 Manral for providing useful information and critiques in order to 602 write this memo. 604 We would also like to thank IPsec and OSPF WG people to provide 605 valuable review comments. 607 Authors' Addresses 609 Mukesh Gupta 610 Nokia 611 313 Fairchild Drive 612 Mountain View, CA 94043 613 Phone: 650-625-2264 614 Email: Mukesh.Gupta@nokia.com 616 Nagavenkata Suresh Melam 617 Nokia 618 313 Fairchild Drive 619 Mountain View, CA 94043 620 Phone: 650-625-2949 621 Email: Nagavenkata.Melam@nokia.com 623 Full copyright statement 625 Copyright (C) The Internet Society (2004). This document is subject 626 to the rights, licenses and restrictions contained in BCP 78 and 627 except as set forth therein, the authors retain all their rights. 629 This document and the information contained herein are provided on an 630 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 631 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 632 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 633 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 634 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 635 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 637 Intellectual Property 639 The IETF takes no position regarding the validity or scope of any 640 Intellectual Property Rights or other rights that might be claimed to 641 pertain to the implementation or use of the technology described in 642 this document or the extent to which any license under such rights 643 might or might not be available; nor does it represent that it has 644 made any independent effort to identify any such rights. Information 645 on the procedures with respect to rights in RFC documents can be 646 found in BCP 78 and BCP 79. 648 Copies of IPR disclosures made to the IETF Secretariat and any 649 assurances of licenses to be made available, or the result of an 650 attempt made to obtain a general license or permission for the use of 651 such proprietary rights by implementers or users of this 652 specification can be obtained from the IETF on-line IPR repository at 653 http://www.ietf.org/ipr. The IETF invites any interested party to 654 bring to its attention any copyrights, patents or patent 655 applications, or other proprietary rights that may cover technology 656 that may be required to implement this standard. Please address the 657 information to the IETF at ietf-ipr@ietf.org.