idnits 2.17.1 draft-manral-rpsec-existing-crypto-03.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 17. -- Found old boilerplate from RFC 3978, Section 5.5 on line 653. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 630. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 637. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 643. ** 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 == The page length should not exceed 58 lines per page, but there was 1 longer page, the longest (page 13) being 60 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an Introduction section. ** There are 76 instances of too long lines in the document, the longest one being 9 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Line 237 has weird spacing: '... origin authe...' == Line 255 has weird spacing: '...graphic keys ...' == Line 268 has weird spacing: '...bor, so each ...' == The document doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (August 31, 2006) is 6448 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'RFC1995' is mentioned on line 98, but not defined == Missing Reference: 'MD5' is mentioned on line 101, but not defined == Missing Reference: 'OSPF' is mentioned on line 221, but not defined == Missing Reference: 'ESH' is mentioned on line 244, but not defined == Missing Reference: 'IKE' is mentioned on line 251, but not defined == Missing Reference: 'OSPFv3' is mentioned on line 307, but not defined == Missing Reference: 'RFC793' is mentioned on line 454, but not defined ** Obsolete undefined reference: RFC 793 (Obsoleted by RFC 9293) == Missing Reference: 'MD5-ATTACK' is mentioned on line 464, but not defined == Missing Reference: 'RFC2082' is mentioned on line 483, but not defined ** Obsolete undefined reference: RFC 2082 (Obsoleted by RFC 4822) == Unused Reference: 'RFC0793' is defined on line 546, but no explicit reference was found in the text == Outdated reference: A later version (-08) exists of draft-ietf-ospf-ospfv3-auth-07 ** Obsolete normative reference: RFC 793 (Obsoleted by RFC 9293) ** Downref: Normative reference to an Historic RFC: RFC 1058 ** Obsolete normative reference: RFC 1388 (Obsoleted by RFC 1723) ** Obsolete normative reference: RFC 1723 (Obsoleted by RFC 2453) ** Obsolete normative reference: RFC 2385 (Obsoleted by RFC 5925) ** Obsolete normative reference: RFC 2740 (Obsoleted by RFC 5340) ** Downref: Normative reference to an Informational RFC: RFC 3562 ** Obsolete normative reference: RFC 3567 (Obsoleted by RFC 5304) Summary: 15 errors (**), 0 flaws (~~), 18 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Network Working Group V. Manral 2 Internet-Draft IP Infusion 3 Expires: March 01, 2007 R. White 4 Cisco Systems 6 August 31, 2006 8 Issues with existing Cryptographic Protection Methods for Routing 9 Protocols 10 draft-manral-rpsec-existing-crypto-03 12 Status of this Memo 14 By submitting this Internet-Draft, each author represents that any 15 applicable patent or other IPR claims of which he or she is aware 16 have been or will be disclosed, and any of which he or she becomes 17 aware will be disclosed, in accordance with Section 6 of BCP 79. 19 Internet-Drafts are working documents of the Internet Engineering 20 Task Force (IETF), its areas, and its working groups. Note that 21 other groups may also distribute working documents as Internet- 22 Drafts. 24 Internet-Drafts are draft documents valid for a maximum of six months 25 and may be updated, replaced, or obsoleted by other documents at any 26 time. It is inappropriate to use Internet-Drafts as reference 27 material or to cite them other than as "work in progress." 29 The list of current Internet-Drafts can be accessed at 30 http://www.ietf.org/ietf/1id-abstracts.txt. 32 The list of Internet-Draft Shadow Directories can be accessed at 33 http://www.ietf.org/shadow.html. 35 This Internet-Draft will expire on August 31, 2006. 37 Copyright Notice 39 Copyright (C) The Internet Society (2006). 41 Abstract 43 Routing protocols often use cryptographic mechanisms to authenticate 44 data being received from a neighboring router has not been modified 45 in transit, and actually originated from the nrighboring router 46 purporting to have originating the data. Most of the cryptographic 47 mechanisms rely on hash algorithms applied to the data in the routing 48 protocol packet, which means the data is transported, in the clear, 49 along with the has signature based on the data itself. These 50 mechanisms rely on the manual configuration of the keys used to seed, 51 or build, these hash based sigantures. This document outlines some 52 of the problems with manual keying of these cryptographic algorithms. 54 Requirements Language 56 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 57 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 58 document are to be interpreted as described in RFC 2119 [RFC2119]. 60 Table of Contents 62 1. Problem Statement . . . . . . . . . . . . . . . . . . . . . 3 64 2. OSPF (OSPFv2) . . . . . . . . . . . . . . . . . . . . . . . 5 65 2.1 Management Issues with OSPF . . . . . . . . . . . . . . . 5 66 2.2 Technical Issues with OSPF . . . . . . . . . . . . . . . . 5 68 3. OSPFv3 . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 69 3.1 Management Issues with OSPFv3 . . . . . . . . . . . . . . 7 70 3.2 Technical Issues with OSPFv3 . . . . . . . . . . . . . . . 7 72 4. IS-IS . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 73 4.1 Management Issues with IS-IS . . . . . . . . . . . . . . . 9 74 4.2 Technical Issues with IS-IS . . . . . . . . . . . . . . . 9 76 5. BGP . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11 77 5.1 Management Issues with BGP . . . . . . . . . . . . . . . . 11 78 5.2 Technical Issues with BGP . . . . . . . . . . . . . . . . 11 80 6. The Routing Information Protocol (RIP) . . . . . . . . . . . 13 82 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . 14 84 8. Security Considerations . . . . . . . . . . . . . . . . . . 15 86 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 16 88 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 17 89 10.1 Normative References . . . . . . . . . . . . . . . . . . 17 90 10.2 Informative References . . . . . . . . . . . . . . . . . 18 92 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 18 94 Intellectual Property and Copyright Statements . . . . . . . 19 96 1. Problem Statement 98 Routing protocols, such as OSPF [RFC2740] [RFC2328], IS-IS [RFC1995], 99 and [BGP], rely on various mechanisms to create a cryptographic 100 digest of each transmitted routing protocol. Generally, these 101 digests are the results of a hash algorithm, such as [MD5], across 102 the contents of the packet being transmitted, using a private key as 103 the hash base (or seed). These digests are recomputed by the 104 receiving router, using the same key as the originating router used 105 to create the hash, and compared with the transmited digest to 106 verify: 108 o That the router originating this piece of data is authorized to 109 peer with the local router, and to transmit routing data. This 110 generally protects against falsely generated routing data being 111 injected into a routing system by rogue systems. 113 o That the data has not been changed while transiting between the 114 two neighboring routers. 116 These sorts of authentication methods are not generally used to 117 protect the confidentiality of information being exchanged between 118 routers, since this information (entries in the routing table) is 119 generally freely available in many other context; if anyone has 120 access to the physical media between two routers exchanging routing 121 data, they will also probably have other ways to capture or otherwise 122 discover the contents of the routing tables in those routers. 124 The main problems with the authentication mechanisms in use today 125 revolve around: 127 o Manual configuration of shared secret keys, especially in large 128 scale networks, poses a major management problem, especially as 129 there is generally no way to gracefully move from one secret key 130 to another. 132 o In some cases, when manual keys are configured, some forms of 133 replay protection are disabled, allowing the routing protocol to 134 be attacked. 136 In fact, the MD5 digest algorithm was not designed to be used in the 137 way most routing protocols are using it, which can leads to serious 138 security implications in the future. 140 A preimage attack would enable someone to find an input message that 141 causes a hash function to produce a particular output. In contrast, a 142 collision attack finds two messages with the same hash, but the attacker 143 can't pick what the hash will be. The collisions against MD4, MD5, 144 HAVAL-128, and RIPEMD were found by the Chinese researcher Xiaoyun Wang 145 with co-authors Dengguo Feng, Xuejia Lai, and Hongbo Yu. 147 The collision vunerability, does not introduce any obvious or known attacks 148 on routing protocols. However pre-image attacks could cause problems. 150 Protocols themselves have some inbuilt protection against collision 151 attacks. A lot of values for a lot fields in the protocol are invalid. For 152 example for OSPF the LSA type can be from 1 to 11. Any other value in the 153 field will result in the packet being dropped. 155 Assume two packets M and M' are generated which have the same hash. The 156 above condition will further reduce the probability of the two messages 157 also being correct messages from the protocol perspective as a lot of values 158 are themselves not valid. 160 2. OSPF (OSPFv2) 162 OSPF [RFC2328] describes the use of an MD5 digest with OSPF packets. 163 MD5 keys are manually configured. The OSPF packet Header includes an 164 authentication type field as well as 64-bits of data for use by the 165 appropriate authentication scheme. [OSPF] also provides for a non- 166 decreasing sequence number to be included in each OSPF protocol 167 packet to protect against replay attacks. 169 2.1 Management Issues with OSPF 171 According to the OSPF specification, [RFC2328], digests are applied 172 to packets transmitted between adjacent neighbors, rather than being 173 applied to the routing information originated by a router (digests 174 are not applied at the LSA level, but rather at the packet level). 175 [RFC2328] states that any set of OSPF routers adjacent across a 176 single link may use a different key to build MD5 digests than the key 177 used to build MD5 digests on any other link. Thus, MD5 keys may be 178 configured, and changed, on a per-link basis in an OSPF network. 180 [OSPF] does not specify a mechanims to negotiate keys, nor does it 181 specify any mechanism to negotiate the hash algorithms to be used. 183 With the proliferation of the number of hash algorithms, as well as 184 the need to continuously upgrade the algorithms, manually configuring 185 the information becomes very tedious. 187 2.2 Technical Issues with OSPF 189 While [OSPF] provides relatively strong protection through the 190 inclusion of MD5 sigantures, with additional data and sequence 191 numbers, in transmitted packets, there are still two possible attacks 192 against OSPF: 194 o The sequence number is initialized to zero when forming an 195 adjacency with a newly discovered neighbor, and is also set to 196 zero whenever the neighbor is brought down. If the 197 cryptographically protected packets of a router that is brought 198 down(for administrative or other reasons) are stored by a 199 malicious router. The new router could replay the packets from 200 the previous session thus forcing traffic through the malicious 201 router. Dropping of such packets by the router could result in 202 blackholes. Also wrongly forwarding packets could result in 203 routing loops. 205 o [OSPF] allows multiple packets with the same sequence number. 206 This could mean the same packet can be replayed many times before 207 the next legitimate packet is sent. An attacker may resend the 208 same packet repeatedly until the next hello packet is transmitted 209 and received, which means the hello interval determines the attack 210 window. 212 o [OSPF] does not specify the use of any particular hash algorithm, 213 however the use of only MD5 is specified in the document. Most OSPF 214 implementations only support MD5. 216 Recently, attacks on collision-resistance properties of MD5 and SHA-1 217 hash functions have been discovered; [HASH-ATTACK] summarizes the 218 discoveries. The attacks on MD5 are practical on any mordern computer. 219 For this reason the use of algorithms needs to be discouraged. 221 o [OSPF] on a broadcast network shares the same key between all neighbors 222 on a broadcast network. Some OSPF packets are sent on multicast address. 224 This allows spoofing by any malicious neighbor very easy. Possesion of 225 the key itself is used as an identity check. There is no other identity 226 check used. A neighbor could send a packet specifying the packet came 227 from some other neighbor and there would be no way in which the attacked 228 router could figure out the identity of the packet sender. 230 3. OSPFv3 232 OSPFv3 [RFC2740] relies on the IP Authentication Header described in 233 [AH] and the IP Encapsulating Payload described in [ESP] to 234 cryptographically sign routing information passed between routers. 235 When using ESP, a null encryption algorithm is used, so the data carried 236 in the OSPFv3 packets is signed, but not encrypted. This provides data 237 origin authentication for adjacent routers, and data integrity which gives 238 the assurance data transmitted by a router has not changed in transit. 239 However it does not provide confidentiality of the information transmitted. 240 [OSPF-AUTH] mandates the use of ESP w/ null encryption for authentication 241 and also does encourages the use of confidentiality to protect the privacy of 242 the routing information transmitted, using [ESP] encryption. 244 [OSPF-AUTH] describes OSPFv3's use of [AH] and [ESH], and specifies 245 that only manual keying of routing information may be used. 247 3.1 Management Issues with OSPFv3 249 [OSPF-AUTH] discusses, at length, the reasoning behind using manually 250 configured keys, rather than some automated key management protocol 251 such as [IKE] . The primary problem is that all current key 252 management mechanisms are deisgned for one-to-one correlation of 253 keys, while OSPF adjacencies are formed on a one-to-many basis. This 254 forces the system administrator to use manually configured SAs and 255 cryptographic keys to provide the authentication and, if desired, 256 confidentiality services. 258 OSPFv3 security document [OSPF-AUTH] states that 260 As it is not possible as per the current standards to provide 261 complete replay protection while using manual keying, the proposed 262 solution will not provide protection against replay attacks. 264 The primary administrative issue with manually configured SA's and keys 265 in the OSPFv3 case is the simple management issue of mantaining 266 matching sets of keys on all routers within a network. [OSPF-AUTH] does 267 not require that all OSPFv3 routers have the same key configured for every 268 neighbor, so each set of neighbors connected to a single link could have a 269 different key configured. While this makes it easier to change the keys, by 270 forcing the system administrator to only change the keys on the routers on 271 a single link, the process of manual configuration for all the routers in a 272 network to change the keys used for OSPFv3 digests and confidentiality on 273 a periodic basis can be difficult. 275 3.2 Technical Issues with OSPFv3 277 The primary technical concern with the current specifications for 278 OSPFv3 is that when manual SA and key management is used, [AH] specifies, 279 in section 3.3.2, Sequence Number Generation: "The sender assumes 280 anti-replay is enabled as a default, unless otherwise notified by the receiver 281 (see 3.4.3) or if the SA was configured using manual key management." 282 Replayed OSPFv3 packets can cause several failures in a network, 283 including: 285 o Replaying hello packets with an empty neighbor list can cause all 286 the neighbor adajcencies with the sending router to be reset, 287 disrupting network communications. 289 o Replaying hello packets from early in the designated router 290 election process on broadcast links can cause all the neighbor 291 adjacencies with the sending router to be reset, disrupting 292 network communications. 294 o Replaying database description (DB-Description) packets can cause 295 all FULL neighbor adjacencies with the sending router to be reset, 296 disrupting network communications. 298 o Replaying link state request (LS-Request) packets can cause all 299 FULL neighbor adjacencies with the sending router to be reset, 300 disrupting network communications. 302 o Capturing a full adjacency process (from two-way all the way to 303 FULL state), and then replaying this process when the router is no 304 longer attached can cause a false adjacency to be formed, allowing 305 an attacker to attract and black hole traffic. 307 o [OSPFv3] on a broadcast network shares the same key between all 308 neighbors on a broadcast network. Some OSPF packets are sent on 309 multicast address. 311 This allows spoofing by any malicious neighbor very easy. Possesion 312 of the key itself is used as an identity check. There is no other 313 identity check used. A neighbor could send a packet specifying the 314 packet came from some other neighbor and there would be no way in 315 which the attacked router could figure out the identity of the packet 316 sender. 318 4. IS-IS 320 IS-IS [RFC1195] uses HMAC-MD5 authentication with manual keying, as 321 described in [RFC3567]. There is no provision within IS-IS to 322 encrypt the body of a routing protocol message. 324 4.1 Management Issues with IS-IS 326 [RFC3567] states that each LSP generated by an intermediate system is 327 signed with the HMAC-MD5 algorithm using a key manually defined by 328 the network administrator. Since authentication is performed on the 329 LSPs transmitted by an intermediate system, rather than on the 330 packets transmitted to a specific neighbor, it is implied that all 331 the intermediate systems within a single flooding domain must be 332 configured with the same key for authentication to work correctly. 333 The initial configuration of manual keys for authentication within an 334 IS-IS network is simplified by a state where LSPs containing HMAC-MD5 335 authentication TLVs are accepted, but the digest is not validated. 336 Once an initial set of keys are configured on all routers, however, 337 changing those keys becomes much more difficult. 339 IS-IS [RFC1195] does not specify a mechanims to negotiate keys, nor does 340 it specify any mechanism to negotiate the hash algorithms to be used. 342 With the proliferation of the number of hash algorithms, as well as 343 the need to continuously upgrade the algorithms, manually configuring 344 the information becomes very tedious. 346 4.2 Technical Issues with IS-IS 348 [RFC3567] states: "This mechanism does not prevent replay attacks, 349 however, in most cases, such attacks would trigger existing 350 mechanisms in the IS-IS protocol that would effectively reject old 351 information." The few case where existing mechanisms in the IS-IS 352 protocol would not effectively reject old information is the case of 353 the hello packets (IIHs) used to discover neighbors and SNP packets. 355 As described in IS-IS [RFC1195], a list of known neighbors is 356 included in each hello transmitted by an intermediate system, to 357 ensure two-way communications with any specific neighbor before 358 exchanging link state databases. 360 IS-IS does not provide a sequence number. Hence IS-IS packets are 361 liable to replay attacks. As any packet can be replayed at any point 362 of time, as long as the keys used are the same. 364 A hello packet containing a digest within a TLV, and an emtpy 365 neighbor list, could be replayed, causing all adjacencies with the 366 original transmitting intermediate system to be restarted. 368 A replay of an old CSNP packets could cause LSP's to be flooded, thus 369 causing an LSP storm. 371 IS-IS specifies the use of the hash algorithm HMAC-MD5 to protect 372 IS-IS PDU's. 374 IS-IS does not have a notion of Key ID. During Key rollover, each 375 message received has to be checked for integrity against all keys that 376 are valid. A DoS attack may be caused by sending IS-IS packets with 377 random hashes. This will cause the IS-IS packet to be checked for 378 authentication, with all possible keys. Thus increasing the amount of 379 processing required. 381 Recently, attacks on collision-resistance properties of MD5 and SHA-1 382 hash functions have been discovered; [HASH-ATTACK] summarizes the 383 discoveries. The attacks on MD5 are practical on any mordern computer. 384 For this reason the use of algorithms needs to be discouraged. 386 HMAC's are not susceptible to any known collision-reduction attack. 387 However IS-IS should provide a way to upgrade to other stronger 388 algorithms. 390 IS-IS on a broadcast network shares the same key between all neighbors 391 on a broadcast network. Some IS-IS PDU's are sent on link-layer multicast 392 address. 394 This makes spoofing by any malicious neighbor very easy. Possession of 395 the key itself is used as an identity check. There is no other identity 396 check used. A neighbor could send a packet specifying the packet came 397 from some other neighbor and there would be no way in which the attacked 398 router could figure out the identity of the packet sender. 400 As the lifetime is not covered in the authentication, an ISIS router 401 can receive its own self generated LSP segment with zero lifetime remaining. 402 In that case, if it has a copy with non zero life time, then it purges the 403 LSP i.e. it increments the current sequence number and floods *all* the 404 segments again. Its much worse in ISIS, as there exists only one LSP 405 (other than the pseudonode LSPs for the LANs on which its the DIS). 407 This way you force the router to flood all segments, which can be quite 408 a lot if the number of routes are large. It also causes the sequence number 409 of all the LSPs to increase fast. If the sequence number increases to the 410 maximum (0xFFFFFFFF), the IS-IS process must shut down for at around 20+ 411 minutes (MaxAge + ZeroAgeLifetime) to allow the old LSPs to age out of all 412 the router databases. 414 5. BGP 416 [BGP] uses TCP [RFC793] for transporting routing information between 417 BGP speakers which have formed an adjacency, as described in 418 [RFC2385], with suggestions for choosing MD5 keys described in 419 [RFC3562]. 421 It is common to use the TCP MD5 signature optionas described in 422 [RFC2385] for providing data origin authentication and data integrity 423 protection of these BGP packets. with suggestions for choosing MD5 key 424 length described in [RFC3562]. There is no provision for confidentiality for 425 any of these BGP messages. 427 This problem is made worse by the nature of the environment where BGP is 428 typically used, between autonomous networks (under different 429 administrative control). While routers running interior gateway protocols 430 may all be configured using the same keys, and have their key rollover 431 policies coordinated or set by the same administrative authority, two BGP 432 peering BGP speakers may be in different administrative domains, with 433 different policies for key strength, rollover times, etc. An autonomous 434 system must often support a large number of keys on different BGP borders, 435 since each connecting AS represents a different administrative entity. 437 5.1 Management Issues with BGP 439 Each pair of BGP speakers forming an adjacency may have a different 440 MD5 shared key, facilitating the configuration and changing of keys 441 across a large scale network. Manual configuration and maintenance 442 of cryptographic keys on all routers is a challenge in any large scale 443 environment, however. Most BGP implementations will accept BGP 444 packets with a bad digest for the hold interval negotiated between 445 BGP peers at peering startup, allowing MD5 keys to be changed without 446 impacting the operation of the network. This technique does, 447 however, allow some short period of time during which an attacker may 448 inject BGP packets with false MD5 digests into the network, and can 449 expect those packets to be accepted, even though their MD5 digests 450 are not valid. 452 5.2 Technical Issues with BGP 454 Since BGP relies on TCP [RFC793] for transporting data between BGP 455 speakers, BGP can rely on TCP's protections against data corruption 456 and replay to prevent replay attacks against BGP sessions. A great 457 deal of research has gone into the difficulty or ease with which an 458 attacker can overcome these protections, including [TCP-WINDOW] and 459 [BGP-ATTACK]. Most implementations of BGP have modified their TCP 460 implementations to resolve the security vulnerabilities described in 461 these references, where possible. 463 However, as mentioned earilier, MD5 is vulnerable to collision attacks, and 464 can be attacked through several means, such as those explored in [MD5-ATTACK]. 465 Though it is can be argued that the collision attacks do not have a practical 466 implication in this scenario, the use of MD5 is discouraged. 468 Routers performing cryptographic processing of packets in software may 469 be easier to attack. An attacker may be able to transmit enough traffic 470 with false digests to a router that the router's processor and memory 471 resources are consumed, causing the router to be unable to perform normal 472 processing. This is particularly problematic at connections to devices 473 not under local administrative control. 475 6. The Routing Information Protocol (RIP) 477 RIP [RFC1058] does not provide for any authentication or 478 authorization of routing data, and thus is vulnerable to any of the 479 various attacks against routing protocols. 481 RIPv2 [RFC1388, RFC1723] provides for authenticating packets by 482 carrying a digest. The information is there in RIP-2 MD5 Authentication 483 [RFC2082]. 485 o The sequence number is initialized to zero, at the beginning of 486 time, and is also set to zero whenever the neighbor is brought down. 487 If the cryptographically protected packets of a router that is brought 488 down (for administrative or other reasons) are stored by a 489 malicious router. The new router could replay the packets from 490 the previous session thus forcing traffic through the malicious 491 router. Dropping of such packets by the router could result in 492 blackholes. Also wrongly forwarding packets could result in 493 routing loops. 495 o RIPv2 allows multiple packets with the same sequence number. 496 This could mean the same packet can be replayed many times before 497 the next legitimate packet is sent. An attacker may resend the 498 same packet repeatedly until the next hello packet is transmitted 499 and received, which means the hello interval determines the attack 500 window. 502 o RIPv2 does not specify the use of any particular hash algorithm,RIP 503 implementations only support MD5. MD5 is vulnerable to attacks. 505 7. IANA Considerations 507 This document makes no request of IANA. 509 Note to RFC Editor: this section may be removed on publication as an 510 RFC. 512 8. Security Considerations 514 This draft outlines security issues arising from the manual keying of 515 cryptographic keys for various routing protocols. No changes to any 516 protocols are proposed in this draft, and no new security 517 requirements result. 519 9. Acknowledgements 521 Thanks to Manav Bhatia for a thorough review and comments on the draft. 522 He has contributed a lot of text to all sections of the draft. 523 We would like to acknowledge Sam Hartman, Ran Atkinson, Steve Kent 524 and Brian Wies for their initial comments on this draft. Merike Kaeo 525 reviewed many sections of the draft and gave a lot of useful comments. 527 10. References 529 10.1 Normative References 531 [AH] Kent, S., "IP Authentication Header", 532 RFC draft-ietf-ipsec-rfc2402bis-11.txt, March 2005. 534 [BGP] Rekhter , Y., Li, T., and S. Hares, "A Border Gateway 535 Protocol 4 (BGP-4)", RFC draft-ietf-idr-bgp4-26.txt, 536 October 2004. 538 [ESP] Kent, S., "IP Encapsulating Security Payload (ESP)", 539 RFC draft-ietf-ipsec-esp-v3-10.txt, March 2005. 541 [OSPF-AUTH] 542 Gupta, M. and N. Melam, "Authentication/Confidentiality 543 for OSPFv3", RFC draft-ietf-ospf-ospfv3-auth-07.txt, 544 February 2005. 546 [RFC0793] Postel, J., "Transmission Control Protocol", STD 7, 547 RFC 793, September 1981. 549 [RFC1058] Hedrick, C., "Routing Information Protocol", RFC 1058, 550 June 1988. 552 [RFC1195] Callon, R., "Use of OSI IS-IS for routing in TCP/IP and 553 dual environments", RFC 1195, December 1990. 555 [RFC1388] Malkin, G., "RIP Version 2 Carrying Additional 556 Information", RFC 1388, January 1993. 558 [RFC1723] Malkin, G., "RIP Version 2 - Carrying Additional 559 Information", STD 56, RFC 1723, November 1994. 561 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 562 Requirement Levels", BCP 14, RFC 2119, March 1997. 564 [RFC2328] Moy, J., "OSPF Version 2", STD 54, RFC 2328, April 1998. 566 [RFC2385] Heffernan, A., "Protection of BGP Sessions via the TCP MD5 567 Signature Option", RFC 2385, August 1998. 569 [RFC2740] Coltun, R., Ferguson, D., and J. Moy, "OSPF for IPv6", 570 RFC 2740, December 1999. 572 [RFC3562] Leech, M., "Key Management Considerations for the TCP MD5 573 Signature Option", RFC 3562, July 2003. 575 [RFC3567] Li, T. and R. Atkinson, "Intermediate System to 576 Intermediate System (IS-IS) Cryptographic Authentication", 577 RFC 3567, July 2003. 579 10.2 Informative References 581 [BGP-ATTACK] Convery, S. and M. Franz, "BGP Vulnerability Testing: 582 Separating Fact from FUD v1.00", June 2003. 584 [TCP-WINDOW] Watson, T., "TCP Reset Spoofing", October 2003. 586 [HASH-ATTACK] Hoffman, P. and B. Schneier, "Attacks on Cryptographic 587 Hashes in Internet Protocols", RFC4270, November 2005. 589 Contributors Address 591 Sue Hares 592 NextHop 593 USA 595 Phone: 596 Fax: 597 Email: shares@nexthop.com 598 URI: 600 Authors' Addresses 602 Vishwas Manral 603 IPI 604 Bangalore 605 India 607 Phone: 608 Fax: 609 Email: vishwas.manral@gmail.com 611 Russ White 612 Cisco Systems 613 RTP, NC 614 USA 616 Phone: 617 Fax: 618 Email: riw@cisco.com 619 URI: 621 Intellectual Property Statement 623 The IETF takes no position regarding the validity or scope of any 624 Intellectual Property Rights or other rights that might be claimed to 625 pertain to the implementation or use of the technology described in 626 this document or the extent to which any license under such rights 627 might or might not be available; nor does it represent that it has 628 made any independent effort to identify any such rights. Information 629 on the procedures with respect to rights in RFC documents can be 630 found in BCP 78 and BCP 79. 632 Copies of IPR disclosures made to the IETF Secretariat and any 633 assurances of licenses to be made available, or the result of an 634 attempt made to obtain a general license or permission for the use of 635 such proprietary rights by implementers or users of this 636 specification can be obtained from the IETF on-line IPR repository at 637 http://www.ietf.org/ipr. 639 The IETF invites any interested party to bring to its attention any 640 copyrights, patents or patent applications, or other proprietary 641 rights that may cover technology that may be required to implement 642 this standard. Please address the information to the IETF at 643 ietf-ipr@ietf.org. 645 Disclaimer of Validity 647 This document and the information contained herein are provided on an 648 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 649 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 650 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 651 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 652 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 653 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 655 Copyright Statement 657 Copyright (C) The Internet Society (2006). This document is subject 658 to the rights, licenses and restrictions contained in BCP 78, and 659 except as set forth therein, the authors retain all their rights. 661 Acknowledgment 663 Funding for the RFC Editor function is currently provided by the 664 Internet Society.