idnits 2.17.1 draft-manral-rpsec-existing-crypto-05.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 22. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 745. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 756. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 763. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 769. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == The page length should not exceed 58 lines per page, but there was 1 longer page, the longest (page 12) being 60 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an Introduction section. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust Copyright Line does not match the current year == The document doesn't use any RFC 2119 keywords, yet has text resembling 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 (February 2008) is 5886 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- ** Obsolete normative reference: RFC 793 (Obsoleted by RFC 9293) ** Obsolete normative reference: RFC 2385 (Obsoleted by RFC 5925) ** Obsolete normative reference: RFC 2740 (Obsoleted by RFC 5340) ** Obsolete normative reference: RFC 3567 (Obsoleted by RFC 5304) -- Obsolete informational reference (is this intentional?): RFC 1388 (Obsoleted by RFC 1723) -- Obsolete informational reference (is this intentional?): RFC 1723 (Obsoleted by RFC 2453) -- Obsolete informational reference (is this intentional?): RFC 2082 (Obsoleted by RFC 4822) -- Obsolete informational reference (is this intentional?): RFC 4306 (Obsoleted by RFC 5996) Summary: 6 errors (**), 0 flaws (~~), 3 warnings (==), 11 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Internet-Draft Routing Protocol Protection Issues February 2008 3 Network Working Group Vishwas Manral 4 Internet-Draft IP Infusion 5 Expires: August 2008 Russ White 6 Intended Status: Informational Cisco Systems 7 Manav Bhatia 8 Alcatel-Lucent 10 Issues with existing Cryptographic Protection Methods for Routing 11 Protocols 13 draft-manral-rpsec-existing-crypto-05.txt 15 Status of this Memo 17 Distribution of this memo is unlimited. 19 By submitting this Internet-Draft, each author represents that any 20 applicable patent or other IPR claims of which he or she is aware 21 have been or will be disclosed, and any of which he or she becomes 22 aware will be disclosed, in accordance with Section 6 of BCP 79. 24 Internet-Drafts are working documents of the Internet Engineering 25 Task Force (IETF), its areas, and its working groups. Note that other 26 groups may also distribute working documents as Internet-Drafts. 28 Internet-Drafts are draft documents valid for a maximum of six months 29 and may be updated, replaced, or obsoleted by other documents at any 30 time. It is inappropriate to use Internet-Drafts as reference 31 material or to cite them other than as "work in progress." 33 The list of current Internet-Drafts can be accessed at 34 http://www.ietf.org/1id-abstracts.html 36 The list of Internet-Draft Shadow Directories can be accessed at 37 http://www.ietf.org/shadow.html. 39 Abstract 41 Routing protocols are designed to use cryptographic mechanisms to 42 authenticate data being received from a neighboring router to ensure 43 that it has not been modified in transit, and actually originated 44 from the neighboring router purporting to have originating the data. 45 Most of the cryptographic mechanisms defined to date rely on hash 46 algorithms applied to the data in the routing protocol packet, which 47 means the data is transported, in the clear, along with a signature 48 based on the data itself. These mechanisms rely on the manual 49 configuration of the keys used to seed, or build, these hash based 50 signatures. This document outlines some of the problems with manual 51 keying of these cryptographic algorithms. 53 Conventions used in this document 55 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 56 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 57 document are to be interpreted as described in RFC 2119 [RFC2119] 59 Table of Contents 61 1. Problem Statement..............................................2 62 2. Open Shortest Path First (OSPFv2)..............................4 63 2.1 Management Issues with OSPF................................4 64 2.2 Technical Issues with OSPF.................................4 65 3. Open Shortest Path First (OSPFv3)..............................5 66 3.1 Management Issues with OSPFv3..............................6 67 3.2 Technical Issues with OSPFv3...............................6 68 4. Intermediate System to Intermediate System Routing Protocol (IS- 69 IS)...............................................................7 70 4.1 Management Issues with IS-IS...............................7 71 4.2 Technical Issues with IS-IS................................8 72 5. Border Gateway Protocol (BGP-4)................................9 73 5.1 Management Issues with BGP-4..............................10 74 5.2 Technical Issues with BGP-4...............................10 75 6. The Routing Information Protocol (RIP)........................10 76 7. Security Considerations.......................................12 77 8. Acknowledgements..............................................12 78 9. IANA Considerations...........................................12 79 10. References...................................................12 80 10.1 Normative References.....................................12 81 10.2 Informative References...................................13 82 11. Contributor's Address........................................14 83 12. Author's Addresses...........................................14 85 1. 86 Problem Statement 88 Routing protocols, such as OSPF [RFC2740] [RFC2328], IS-IS [RFC1195], 89 and BGP-4 [RFC4271], rely on various mechanisms to create a 90 cryptographic digest of each transmitted routing protocol. 91 Traditionally, these digests are the results of a hash algorithm, 92 such as MD5 [RFC1321], across the contents of the packet being 93 transmitted, using a secret key as the hash base (or seed). These 94 digests are recomputed by the receiving router, using the same key as 95 the originating router used to create the hash, and compared with the 96 transmitted digest to verify: 98 o That the router originating this piece of data is authorized to 99 peer with the local router, and to transmit routing data. This 100 generally protects against falsely generated routing data being 101 injected into a routing system by rogue systems. 103 o That the data has not been changed while transiting between the 104 two neighboring routers. 106 These sorts of authentication methods are not generally used to 107 protect the confidentiality of information being exchanged between 108 routers, since this information (entries in the routing table) is 109 generally freely available in many other context; if anyone has 110 access to the physical media between two routers exchanging routing 111 data, they will also probably have other ways to capture or otherwise 112 discover the contents of the routing tables in those routers. 114 The main problems with the authentication mechanisms defined today 115 revolve around: 117 o Manual configuration of shared secret keys, especially in large 118 scale networks, poses a major management problem, especially as 119 there is generally no way to gracefully move from one secret key 120 to another. 122 o In some cases, when manual keys are configured, some forms of 123 replay protection are disabled, allowing the routing protocol to 124 be attacked. 126 In fact, the MD5 digest algorithm was not designed to be used in the 127 way most routing protocols are using it, which can lead to serious 128 security implications in the future. 130 A preimage attack would enable someone to find an input message that 131 causes a hash function to produce a particular output. In contrast, a 132 collision attack finds two messages with the same hash, but the 133 attacker can't pick what the hash will be. Feasible collision attacks 134 against MD4, MD5, HAVAL-128, and RIPEMD were found by the Chinese 135 researcher Xiaoyun Wang with co-authors Dengguo Feng, Xuejia Lai, and 136 Hongbo Yu. 138 The collision vulnerability does not introduce any obvious or known 139 attacks on routing protocols. However pre-image attacks could cause 140 problems. 142 Protocols themselves have some built-in protection against collision 143 attacks. A lot of values for a lot of fields in the protocol are 144 invalid. For example, for OSPF the LSA type can be from 1 to 11. Any 145 other value in the field will result in the packet being dropped. 147 Assume two packets M and M' are generated which have the same hash. 148 The above condition will further reduce the probability of the two 149 messages also being correct messages from the protocol perspective, 150 as a lot of values are themselves not valid. 152 2. 153 Open Shortest Path First (OSPFv2) 155 OSPF [RFC2328] describes the use of an MD5 digest with OSPF packets. 156 MD5 keys are manually configured. The OSPF packet Header includes an 157 authentication type field as well as 64 bits of data for use by the 158 appropriate authentication scheme. OSPF also provides for a non- 159 decreasing sequence number to be included in each OSPF protocol 160 packet to protect against replay attacks. 162 2.1 163 Management Issues with OSPF 165 According to the OSPF specification [RFC2328], digests are applied 166 to packets transmitted between adjacent neighbors, rather than being 167 applied to the routing information originated by a router (digests 168 are not applied at the LSA level, but rather at the packet level). 169 [RFC2328] states that any set of OSPF routers adjacent across a 170 single link may use a different key to build MD5 digests than the key 171 used to build MD5 digests on any other link. Thus, MD5 keys may be 172 configured, and changed, on a per-link basis in an OSPF network. 174 OSPF does not specify a mechanisms to negotiate keys, nor does it 175 specify any mechanism to negotiate the hash algorithms to be used. 177 With the proliferation of the number of hash algorithms, as well as 178 the need to continuously upgrade the algorithms, manually configuring 179 the information becomes very tedious. 181 2.2 182 Technical Issues with OSPF 184 While OSPF provides relatively strong protection through the 185 inclusion of MD5 signatures, with additional data and sequence 186 numbers in transmitted packets, there are still two possible attacks 187 against OSPF: 189 o The sequence number is initialized to zero when forming an 190 adjacency with a newly discovered neighbor, and is also set to 191 zero whenever the neighbor is brought down. If the 192 cryptographically protected packets of a router that is brought 193 down (for administrative or other reasons) are stored by a 194 malicious router, the new router could replay the packets from 195 the previous session, thus forcing traffic through the malicious 196 router. Dropping of such packets by the router could result in 197 blackholes. Also forwarding wrong packets could result in 198 routing loops. 200 o OSPF allows multiple packets with the same sequence number. 201 This could mean the same packet can be replayed many times before 202 the next legitimate packet is sent. An attacker may resend the 203 same packet repeatedly until the next hello packet is transmitted 204 and received, which means the hello interval determines the attack 205 window. 207 o OSPF does not specify the use of any particular hash algorithm, 208 however the use of only MD5 is specified in the document. Most 209 OSPF implementations only support MD5. 211 Recently, attacks on the collision-resistance property of the MD5 212 and SHA-1 hash functions have been discovered; [RFC4270] 213 summarizes the discoveries. The attacks on MD5 are practical on 214 any modern computer. For this reason the use of these algorithms 215 needs to be discouraged. 217 o OSPF on a broadcast network shares the same key between all 218 neighbors on a that network. Some OSPF packets are sent to a 219 multicast address. 221 This allows spoofing by any malicious neighbor very easy. 222 Possession of the key itself is used as an identity check. There 223 is no other identity check used. A neighbor could send a packet 224 specifying the packet came from some other neighbor and there 225 would be no way in which the attacked router could figure out the 226 identity of the packet sender. 228 o OSPF neighbors on broadcast, NBMA and point-to-multipoint 229 networks are identified by the IP address in the IP header. 230 Because the IP header is not covered by the MAC in the 231 cryptographic authentication scheme as described in RFC 2328, an 232 attack can be made exploiting this vulnerability. 234 Assume the following scenario. 236 R1 sends an authenticated HELLO to R2. This HELLO is captured 237 and replayed back to R1, changing the source IP in the IP header 238 to that of R2. 240 R1 not finding itself in HELLO would deduce that the connection is 241 not bidirectional and would bring down the adjacency. 243 3. 244 Open Shortest Path First (OSPFv3) 246 OSPFv3 [RFC2740] relies on the IP Authentication Header described in 247 [RFC4302] and the IP Encapsulating Payload described in [RFC4303] to 248 cryptographically sign routing information passed between routers. 249 When using ESP, the null encryption algorithm [RFC2410] is used, so 250 the data carried in the OSPFv3 packets is signed, but not encrypted. 251 This provides data origin authentication for adjacent routers, and 252 data integrity which gives the assurance data transmitted by a router 253 has not changed in transit. 255 However it does not provide confidentiality of the information 256 transmitted. [RFC4552] mandates the use of ESP with null encryption 257 for authentication and also does encourage the use of confidentiality 258 to protect the privacy of the routing information transmitted, using 259 ESP encryption. 261 [RFC4552] describes OSPFv3's use of AH and ESP, and specifies 262 that only manual keying of routing information may be used. 264 3.1 265 Management Issues with OSPFv3 267 The OSPFv3 security document [RFC4552] discusses, at length, the 268 reasoning behind using manually configured keys, rather than some 269 automated key management protocol such as IKEv2 [RFC4306]. The 270 primary problem is that all current key management mechanisms are 271 designed for a one-to-one correlation of keys, while OSPF adjacencies 272 are formed on a one-to-many basis. This forces the system 273 administrator to use manually configured SAs and cryptographic keys 274 to provide the authentication and, if desired, confidentiality 275 services. 277 [RFC4552] states that 279 As it is not possible as per the current standards to provide 280 complete replay protection while using manual keying, the proposed 281 solution will not provide protection against replay attacks. 283 The primary administrative issue with manually configured SA's and 284 keys in the OSPFv3 case is the simple management issue of maintaining 285 matching sets of keys on all routers within a network. [RFC4552] 286 does not require that all OSPFv3 routers have the same key configured 287 for every neighbor, so each set of neighbors connected to a single 288 link could have a different key configured. While this makes it 289 easier to change the keys, by forcing the system administrator to 290 only change the keys on the routers on a single link, the process of 291 manual configuration for all the routers in a network to change the 292 keys used for OSPFv3 digests and confidentiality on a periodic basis 293 can be difficult. 295 3.2 296 Technical Issues with OSPFv3 298 The primary technical concern with the current specifications for 299 OSPFv3 is that when manual SA and key management is used as [RFC4302] 300 specifies, in section 3.3.2, Sequence Number Generation: "The sender 301 assumes anti-replay is enabled as a default, unless otherwise 302 notified by the receiver (see 3.4.3) or if the SA was configured 303 using manual key management." Replayed OSPFv3 packets can cause 304 several failures in a network, including: 306 o Replaying hello packets with an empty neighbor list can cause all 307 the neighbor adjacencies with the sending router to be reset, 308 disrupting network communications. 310 o Replaying hello packets from early in the designated router 311 election process on broadcast links can cause all the neighbor 312 adjacencies with the sending router to be reset, disrupting 313 network communications. 315 o Replaying database description (DB-Description) packets can cause 316 all FULL neighbor adjacencies with the sending router to be reset, 317 disrupting network communications. 319 o Replaying link state request (LS-Request) packets can cause all 320 FULL neighbor adjacencies with the sending router to be reset, 321 disrupting network communications. 323 o Capturing a full adjacency process (from two-way all the way to 324 FULL state), and then replaying this process when the router is no 325 longer attached can cause a false adjacency to be formed, allowing 326 an attacker to attract and black hole traffic. 328 o OSPFv3 on a broadcast network shares the same key between all 329 neighbors on that network. Some OSPF packets are sent to a 330 multicast address. 332 This allows spoofing by any malicious neighbor very easy. 333 Possession of the key itself is used as an identity check. There 334 is no other identity check used. A neighbor could send a packet 335 specifying the packet came from some other neighbor and there 336 would be no way in which the attacked router could figure out the 337 identity of the packet sender. 339 4. 340 Intermediate System to Intermediate System Routing Protocol (IS-IS) 342 Integrated IS-IS [RFC1195] uses HMAC-MD5 authentication with manual 343 keying, as described in [RFC3567]. There is no provision within IS-IS 344 to encrypt the body of a routing protocol message. 346 4.1 347 Management Issues with IS-IS 349 [RFC3567] states that each LSP generated by an intermediate system is 350 signed with the HMAC-MD5 algorithm using a key manually defined by 351 the network administrator. Since authentication is performed on the 352 LSPs transmitted by an intermediate system, rather than on the 353 packets transmitted to a specific neighbor, it is implied that all 354 the intermediate systems within a single flooding domain must be 355 configured with the same key for authentication to work correctly. 356 The initial configuration of manual keys for authentication within an 357 IS-IS network is simplified by a state where LSPs containing HMAC-MD5 358 authentication TLVs are accepted, but the digest is not validated. 359 Once an initial set of keys is configured on all routers, however, 360 changing those keys becomes much more difficult. 362 IS-IS [RFC1195] does not specify a mechanism to negotiate keys, nor 363 does it specify any mechanism to negotiate the hash algorithms to be 364 used. 366 With the proliferation of the number of hash algorithms, as well as 368 the need to continuously upgrade the algorithms, manually configuring 369 the information becomes very tedious. 371 4.2 372 Technical Issues with IS-IS 374 [RFC3567] states: "This mechanism does not prevent replay attacks, 375 however, in most cases, such attacks would trigger existing 376 mechanisms in the IS-IS protocol that would effectively reject old 377 information." The few cases where existing mechanisms in the IS-IS 378 protocol would not effectively reject old information is the case of 379 hello packets (IIHs) used to discover neighbors, and SNP packets. 381 As described in IS-IS [RFC1195], a list of known neighbors is 382 included in each hello transmitted by an intermediate system, to 383 ensure two-way communications with any specific neighbor before 384 exchanging link state databases. 386 IS-IS does not provide a sequence number. Hence IS-IS packets are 387 liable to replay attacks; any packet can be replayed at any point 388 of time, as long as the keys used are the same. 390 A hello packet containing a digest within a TLV, and an empty 391 neighbor list, could be replayed, causing all adjacencies with the 392 original transmitting intermediate system to be restarted. 394 A replay of an old CSNP packets could cause LSPs to be flooded, thus 395 causing an LSP storm. 397 IS-IS specifies the use of the hash algorithm HMAC-MD5 to protect 398 IS-IS PDUs. 400 IS-IS does not have a notion of Key ID. During Key rollover, each 401 message received has to be checked for integrity against all keys 402 that are valid. A DoS attack may be caused by sending IS-IS packets 403 with random hashes. This will cause the IS-IS packet to be checked 404 for authentication with all possible keys, thus increasing the amount 405 of processing required. 407 Recently, attacks on the collision-resistance property of the MD5 and 408 SHA-1 hash functions have been discovered; [RFC4270] summarizes the 409 discoveries. The attacks on MD5 are practical on any modern computer. 410 For this reason, the use of these algorithms needs to be discouraged. 412 HMACs are not susceptible to any known collision-reduction attack. 414 However, IS-IS should provide a way to upgrade to other stronger 415 algorithms. 417 IS-IS on a broadcast network shares the same key between all 418 neighbors on that network. 420 This makes spoofing by any malicious neighbor very easy since IS-IS 421 PDUs are sent to a link layer multicast address. Possession of the 422 key itself is used as an identity check and no other identity check 423 is performed. A neighbor could send a packet specifying the packet 424 came from some other neighbor and there would be no way in which the 425 attacked router could figure out the identity of the packet sender. 427 As the lifetime is not covered in the authentication, an IS-IS router 428 can receive its own self generated LSP segment with zero lifetime 429 remaining. In that case, if it has a copy with non-zero lifetime, it 430 purges that LSP i.e., it increments the current sequence number and 431 floods all the segments again. This is much worse in IS-IS, as there 432 exists only one LSP other than the pseudonode LSPs for the LANs on 433 which it is the Designated Intermediate System (DIS). 435 This way an attack can force the router to flood all segments, which 436 can be quite a lot if the number of routes is large. It also causes 437 the sequence number of all the LSPs to increase fast. If the sequence 438 number increases to the maximum (0xFFFFFFFF), the IS-IS process must 439 shut down for around 20+ minutes (MaxAge + ZeroAgeLifetime) to allow 440 the old LSPs to age out of all the router databases. 442 5. 443 Border Gateway Protocol (BGP-4) 445 BGP-4 [RFC4271] uses TCP [RFC0793] for transporting routing 446 information between BGP speakers which have formed an adjacency. 448 [RFC2385] describes the use of TCP MD5 signature option for providing 449 data origin authentication and data integrity protection of these BGP 450 packets, and [RFC3562] gives suggestions for choosing the key length 451 for the ad-hoc keyed-MD5 mechanism specified in [RFC2385]. There is 452 no provision for confidentiality for any of these BGP messages. 454 This problem is made worse by the nature of the environment where BGP 455 is typically used, between autonomous networks (under different 456 administrative control). While routers running interior gateway 457 protocols may all be configured using the same keys, and have their 458 key rollover policies coordinated or set by the same administrative 459 authority, two BGP peering BGP speakers may be in different 460 administrative domains, with different policies for key strength, 461 rollover times, etc. An autonomous system must often support a large 462 number of keys on different BGP borders, since each connecting AS 463 represents a different administrative entity. 465 5.1 466 Management Issues with BGP-4 468 Each pair of BGP speakers forming an adjacency may have a different 469 MD5 shared key, facilitating the configuration and changing of keys 470 across a large scale network. Manual configuration and maintenance 471 of cryptographic keys on all routers is a challenge in any large 472 scale environment, however. Most BGP implementations will accept BGP 473 packets with a bad digest for the hold interval negotiated between 474 BGP peers at peering startup, allowing MD5 keys to be changed without 475 impacting the operation of the network. This technique does, 476 however, allow some short period of time, during which an attacker 477 may inject BGP packets with false MD5 digests into the network and 478 can expect those packets to be accepted, even though their MD5 479 digests are not valid. 481 5.2 482 Technical Issues with BGP-4 484 Since BGP relies on TCP [RFC0793] for transporting data between BGP 485 speakers, BGP can rely on TCP's protections against data corruption 486 and replay to prevent replay attacks against BGP sessions. A great 487 deal of research has gone into the difficulty or ease with which an 488 attacker can overcome these protections, including [TCP-WINDOW] and 489 [BGP-ATTACK]. Most implementations of BGP have modified their TCP 490 implementations to resolve the security vulnerabilities described in 491 these references, where possible. 493 However, as mentioned earlier, MD5 is vulnerable to collision 494 attacks, and can be attacked through several means, such as those 495 explored in [MD5-ATTACK]. 497 Though it can be argued that the collision attacks do not have a 498 practical implication in this scenario, the use of MD5 is 499 discouraged. 501 Routers performing cryptographic processing of packets in software 502 may be easier to attack. An attacker may be able to transmit enough 503 traffic with false digests to a router that the router's processor 504 and memory resources are consumed, causing the router to be unable to 505 perform normal processing. This is particularly problematic at 506 connections to devices not under local administrative control. 508 6. 509 The Routing Information Protocol (RIP) 511 The initial version of RIP was specified in STD34 [RFC1058]. This 512 version did not provide for any authentication or authorization of 513 routing data, and thus was vulnerable to any of the various attacks 514 against routing protocols. This was one of the reasons why this 515 protocol has been moved to Historic status long ago [RFC1923]. 517 RIPv2, originally specified in [RFC1388], then [RFC1723], has been 518 finalized in STD56 [RFC2453]. This version of the protocol provides 519 for authenticating packets by carrying a digest. The details thereof 520 have initially been provided in "RIP-2 MD5 Authentication" [RFC2082]; 521 "RIPv2 Cryptographic Authentication" [RFC4822] obsoletes [RFC2082] 522 and adds details of how the SHA family of hash algorithms can be used 523 to protext RIPv2, whereas [RFC2082] only specified the use of Keyed 524 MD5. 526 o The sequence number is initialized to zero, at the beginning of 527 time, and is also set to zero whenever the neighbor is brought 528 down. If the cryptographically protected packets of a router that 529 is brought down (for administrative or other reasons) are stored 530 by a malicious router, the new router could replay the packets 531 from the previous session thus forcing traffic through the 532 malicious router. Dropping of such packets by the router could 533 result in blackholes. Also forwarding wrong packets could 534 result in routing loops. 536 o RIPv2 allows multiple packets with the same sequence number. 537 This could mean the same packet can be replayed many times before 538 the next legitimate packet is sent. An attacker may resend the 539 same packet repeatedly until the next hello packet is transmitted 540 and received, which means the hello interval determines the attack 541 window. 543 o RIPv2 does not specify the use of any particular hash algorithm. 544 Currently, RIP implementations only support keyed MD5 [RFC2082]. 545 MD5 is vulnerable to attacks [MD5-ATTACK]. 547 o RIPv2 Cryptographic Authentication [RFC4822] does not cover the 548 UDP and the IP headers. It is thus possible for an attacker to 549 modify the fields in the above headers without any of the routers 550 getting to know about it. 552 There isn't much that can be done by modifying the UDP header as 553 RIP only uses it to compute the length of the RIP packet. Any 554 changes introduced in the UDP header would fail the RIP 555 authentication, and this attack will thus, not work. 557 However, RIP uses the source IP address from the IP header to 558 determine the RIP neighbor from which it has learnt the RIP 559 Updates. This can be used by an attacker to disrupt the RIP 560 routing sessions between two routers R1 and R2, as shown in the 561 following examples: 563 Scenario 1: 565 R1 sends an authenticated RIP message to R2 with a cryptographic 566 sequence num X. 568 The attacker merely needs get hold of a higher sequence number 569 packet from the LAN. It could also be a packet originated by R2 570 either from this session, or from some earlier session. 572 The attacker can then replay this packet to R2 by changing the 573 source IP to that of R1. 575 R2 would now no longer accept any more RIP Updates from R1 as 577 those would have a lower cryptographic sequence number. After 180 578 secs (or less), R2 would time out R1 and bring down the RIP 579 session. 581 Scenario 2: 583 R1 announces a route with cost C1 to R2. This packet can be 584 captured by an attacker. Later, if this cost changes and R1 585 announces this with some other cost C2, the attacker can replay 586 the captured packet by modifying the source IP to some new 587 arbitrary IP address. It can this way masquerade as some other 588 router. 590 R2 will accept this route and the router as a new gateway, and 591 would use the non existent router as a next hop for that network. 592 This would obviously only work if C1 < C2. 594 7. 595 Security Considerations 597 This draft outlines security issues arising from the manual keying of 598 cryptographic keys for various routing protocols. No changes to any 599 protocols are proposed in this draft, and no new security 600 requirements result. 602 8. 603 Acknowledgements 605 We would like to acknowledge Sam Hartman, Ran Atkinson, Steve Kent 606 and Brian Weis for their initial comments on this draft. Thanks to 607 Merike Kaeo and Alfred Hoenes for reviewing many sections of the 608 draft and providing lot of useful comments. 610 9. 611 IANA Considerations 613 This document places no requests to IANA. 615 Note to RFC Editor: this section may be removed on publication as an 616 RFC. 618 10. 619 References 621 10.1 622 Normative References 624 [RFC0793] Postel, J., "Transmission Control Protocol", STD 7, 625 RFC 793, September 1981. 627 [RFC1195] Callon, R., "Use of OSI IS-IS for routing in TCP/IP and 628 dual environments", RFC 1195, December 1990. 630 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 631 Requirement Levels", BCP 14, RFC 2119, March 1997. 633 [RFC2328] Moy, J., "OSPF Version 2", STD 54, RFC 2328, April 1998. 635 [RFC2385] Heffernan, A., "Protection of BGP Sessions via the TCP 636 MD5 Signature Option", RFC 2385, August 1998. 638 [RFC2453] Malkin, G., "RIP Version 2", RFC 2453, November 1998 640 [RFC2740] Coltun, R., Ferguson, D., and J. Moy, "OSPF for IPv6", 641 RFC 2740, December 1999. 643 [RFC3567] Li, T. and R. Atkinson, "Intermediate System to 644 Intermediate System (IS-IS) Cryptographic 645 Authentication", RFC 3567, July 2003. 647 [RFC4271] Rekhter , Y., Li, T., and S. Hares, "A Border Gateway 648 Protocol 4 (BGP-4)", RFC 4271, January 2006. 650 [RFC4302] Kent, S., "IP Authentication Header", 651 RFC 4302, December 2005. 653 [RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)", 654 RFC 4303, December 2005. 656 [RFC4552] Gupta, M. and N. Melam, "Authentication/Confidentiality 657 for OSPFv3", RFC 4552, January 2006 659 [RFC4822] R. Atkinson and M. Fanto, "RIPv2 Cryptographic 660 Authentication", RFC 4822, February 2007 662 10.2 663 Informative References 665 [RFC1058] Hedrick, C., "Routing Information Protocol", RFC 1058, 666 June 1988. 668 [RFC1321] Rivest, R., "The MD5 Message-Digest Algorithm", RFC 669 1321, April 1992 671 [RFC1388] Malkin, G., "RIP Version 2 Carrying Additional 672 Information", RFC 1388, January 1993. 674 [RFC1723] Malkin, G., "RIP Version 2 - Carrying Additional 675 Information", STD 56, RFC 1723, November 1994. 676 [RFC1923] Halpern, J. and Bradner, S., "RIPv1 Applicability 677 Statement for Historic Status", RFC 1923, March 1996 679 [RFC2082] Baker, F. and Atkinson, R., "RIP-2 MD5 680 Authentication", RFC 2082, January 1997 682 [RFC2410] Kent, S. and Glenn, R., "The NULL Encryption Algorithm 683 and Its Use With IPsec", RFC 2410, November 1998 685 [RFC3562] Leech, M., "Key Management Considerations for the TCP 686 MD5 Signature Option", RFC 3562, July 2003. 688 [RFC4270] Hoffman, P. and B. Schneier, "Attacks on Cryptographic 689 Hashes in Internet Protocols", RFC 4270, November 2005. 691 [RFC4306] Kaufman, C., "The Internet Key Exchange (IKEv2) 692 Protocol", RFC 4306, December 2005 694 [BGP-ATTACK] Convery, S. and M. Franz, "BGP Vulnerability Testing: 695 Separating Fact from FUD v1.00", June 2003. 697 [TCP-WINDOW] Watson, T., "TCP Reset Spoofing", October 2003. 699 [MD5-ATTACK] Wang, X. et al., "Collisions for Hash Functions MD4, 700 MD5, HAVAL-128 and RIPEMD", August 2004, 701 http://eprint.iacr.org/2004/199 703 11. 704 Contributor's Address 706 Sue Hares 707 NextHop 708 USA 709 Email: shares@nexthop.com 711 12. 712 Author's Addresses 714 Manav Bhatia 715 Alcatel-Lucent 716 Bangalore, India 717 Email: manav@alcatel-lucent.com 719 Vishwas Manral 720 IP Infusion 721 Almora, Uttarakhand 722 India 723 Email: vishwas@ipinfusion.com 725 Russ White 726 Cisco Systems 727 RTP North Carolina 728 USA 729 Email: riw@cisco.com 731 Full Copyright Statement 733 Copyright (C) The IETF Trust (2008). 735 This document is subject to the rights, licenses and restrictions 736 contained in BCP 78, and except as set forth therein, the authors 737 retain all their rights. 739 This document and the information contained herein are provided on an 740 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 741 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 742 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 743 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 744 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 745 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 747 Intellectual Property 749 The IETF takes no position regarding the validity or scope of any 750 Intellectual Property Rights or other rights that might be claimed 751 to pertain to the implementation or use of the technology described 752 in this document or the extent to which any license under such rights 753 might or might not be available; nor does it represent that it has 754 made any independent effort to identify any such rights. Information 755 on the procedures with respect to rights in RFC documents can be 756 found in BCP 78 and BCP 79. 758 Copies of IPR disclosures made to the IETF Secretariat and any 759 assurances of licenses to be made available, or the result of an 760 attempt made to obtain a general license or permission for the use 761 of such proprietary rights by implementers or users of this 762 specification can be obtained from the IETF on-line IPR repository 763 at http://www.ietf.org/ipr. 765 The IETF invites any interested party to bring to its attention any 766 copyrights, patents or patent applications, or other proprietary 767 rights that may cover technology that may be required to implement 768 this standard. Please address the information to the IETF at ietf- 769 ipr@ietf.org.