idnits 2.17.1 draft-ietf-opsec-routing-protocols-crypto-issues-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** The document seems to lack a License Notice according IETF Trust Provisions of 28 Dec 2009, Section 6.b.i or Provisions of 12 Sep 2009 Section 6.b -- however, there's a paragraph with a matching beginning. Boilerplate error? (You're using the IETF Trust Provisions' Section 6.b License Notice from 12 Feb 2009 rather than one of the newer Notices. See https://trustee.ietf.org/license-info/.) 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 14) 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 and authors Copyright Line does not match the current year == Line 133 has weird spacing: '...ot been alter...' == Line 140 has weird spacing: '..., will conf...' == Line 157 has weird spacing: '...ich has poten...' == Line 170 has weird spacing: '...message will ...' == Line 175 has weird spacing: '...llision does ...' == (4 more instances...) == The document doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- The document seems to contain a disclaimer for pre-RFC5378 work, and may have content which was first submitted before 10 November 2008. The disclaimer is necessary when there are original authors that you have been unable to contact, or if some do not wish to grant the BCP78 rights to the IETF Trust. If you are able to get all authors (current and original) to grant those rights, you can and should remove the disclaimer; otherwise, the disclaimer is needed and you can ignore this comment. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (November 2009) is 5266 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 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: 4 errors (**), 0 flaws (~~), 9 warnings (==), 6 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Internet-Draft Routing Protocol Protection Issues November 2009 3 Network Working Group Vishwas Manral 4 Internet-Draft IP Infusion 5 Intended Status: Informational Manav Bhatia 6 Expires: May 11, 2010 Alcatel-Lucent 7 Joel Jaeggli 8 Checkpoint Software 9 Russ White 10 Cisco Systems 11 November 11, 2009 13 Issues with existing Cryptographic Protection Methods for Routing 14 Protocols 16 draft-ietf-opsec-routing-protocols-crypto-issues-02.txt 18 Status of this Memo 20 This Internet-Draft is submitted to IETF in full conformance with the 21 provisions of BCP 78 and BCP 79. This document may contain material 22 from IETF Documents or IETF Contributions published or made publicly 23 available before November 10, 2008. The person(s) controlling the 24 copyright in some of this material may not have granted the IETF 25 Trust the right to allow modifications of such material outside the 26 IETF Standards Process. Without obtaining an adequate license from 27 the person(s) controlling the copyright in such materials, this 28 document may not be modified outside the IETF Standards Process, and 29 derivative works of it may not be created outside the IETF Standards 30 Process, except to format it for publication as an RFC or to 31 translate it into languages other than English. 33 Internet-Drafts are working documents of the Internet Engineering 34 Task Force (IETF), its areas, and its working groups. Note that other 35 groups may also distribute working documents as Internet-Drafts. 37 Internet-Drafts are draft documents valid for a maximum of six months 38 and may be updated, replaced, or obsoleted by other documents at any 39 time. It is inappropriate to use Internet-Drafts as reference 40 material or to cite them other than as "work in progress." 42 The list of current Internet-Drafts can be accessed at 43 http://www.ietf.org/1id-abstracts.html 45 The list of Internet-Draft Shadow Directories can be accessed at 46 http://www.ietf.org/shadow.html. 48 Copyright Notice 50 Copyright (c) 2009 IETF Trust and the persons identified as the 51 document authors. All rights reserved. 53 This document is subject to BCP 78 and the IETF Trust's Legal 54 Provisions Relating to IETF Documents in effect on the date of 55 publication of this document (http://trustee.ietf.org/license-info). 56 Please review these documents carefully, as they describe your rights 57 and restrictions with respect to this document. 59 Abstract 61 Routing protocols have over time been extended to use cryptographic 62 mechanisms to validate data being received from a neighboring router 63 to ensure that: 65 o it has not been modified in transit. 66 o actually originated from an authorized neighboring router . 68 The cryptographic mechanisms defined to date and described in this 69 document rely on a digest produced with a hash algorithm applied to 70 the payload encapsulated in the routing protocol packet. 72 This document outlines some of the limitations of the current 73 mechanism, problems with manual keying of these cryptographic 74 algorithms, and possible vectors for the exploitation of these 75 limitations. 77 Conventions used in this document 79 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 80 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 81 document are to be interpreted as described in RFC 2119. [RFC2119] 83 Table of Contents 85 1. Problem Statement..............................................3 86 1.1 MD5 Pre-Image vs Collision Attacks.........................4 87 2. Open Shortest Path First (OSPFv2)..............................4 88 2.1 Management Issues with OSPF................................4 89 2.2 Technical Issues with OSPF.................................5 90 3. Open Shortest Path First (OSPFv3)..............................6 91 3.1 Management Issues with OSPFv3..............................7 92 3.2 Technical Issues with OSPFv3...............................7 93 4. Intermediate System to Intermediate System Routing Protocol (IS- 94 IS)...............................................................8 95 4.1 Management Issues with IS-IS...............................8 96 4.2 Technical Issues with IS-IS................................9 97 5. Border Gateway Protocol (BGP-4)...............................10 98 5.1 Management Issues with BGP-4..............................11 99 5.2 Technical Issues with BGP-4...............................11 100 6. The Routing Information Protocol (RIP)........................11 101 6.1 Technical Issues with RIP.................................12 102 7. Bidirectional Forwarding Detection (BFD)......................13 103 7.1 Technical Issues with BFD.................................13 105 8. Security Considerations.......................................14 106 9. Acknowledgements..............................................14 107 10. IANA Considerations..........................................14 108 11. References...................................................14 109 11.1 Normative References.....................................14 110 11.2 Informative References...................................15 111 12. Contributor's Address........................................16 112 13. Author's Addresses...........................................16 114 1. Problem Statement 116 Routing protocols, such as OSPF version 2 [RFC2328], version 3 117 [RFC5340], IS-IS [RFC1195], and BGP-4 [RFC4271], employ various 118 mechanisms to create a cryptographic digest of each transmitted 119 routing protocol. Traditionally, these digests are the results of a 120 one-way hash algorithm, such as MD5 [RFC1321], across the contents of 121 the packet being transmitted. A secret key is used as the hash base 122 (or seed). The digest is then recomputed by the receiving router, 123 using the same key as the original router used to create the hash, 124 then compared with the transmitted digest to verify: 126 o That the router originating this packet is authorized via the 127 shared key mechanism to peer with the local router, and exchange 128 routing data. The implicit trust of routing protocol exchange 129 protected by a shared secret is intended to protect against the 130 injection of falsely generated routing data being injected into 131 the routing system by unauthorized systems. 133 o That the data has not been altered in transit between the 134 two neighboring routers. 136 Digest verification schemes are not intended to protect the 137 confidentiality of information being exchanged between routers. The 138 information (entries in the routing table) is potentially available 139 through other mechanisms ; Morever, access to the physical media 140 between two routers exchanging routing data, will confer the 141 ability to capture or otherwise discover the contents of the routing 142 tables in those routers. 144 Authentication mechanisms defined today have notable limitations: 146 o Manual configuration of shared secret keys, especially in large 147 networks and between networks, poses a major management problem. 148 In many cases it is challenging to replace keys without significant 149 coordination or disruption. 151 o In some cases, when manual keys are configured, some forms of 152 replay protection are no longer possible , allowing the routing 153 protocol to be attacked though the replay of captured routing 154 messages. 156 o The MD5 digest algorithm was not designed to be used in the way 157 most routing protocols are using it. which has potentially serious 158 future implications. 160 This document outlines some of the problems with manual keying of 161 these cryptographic algorithms. 163 1.1 164 MD5 Pre-Image vs Collision Attacks 166 A preimage attack (An attempt to find new data with the same hash 167 value) would enable someone to find an input message that 168 causes a hash function to produce a particular output. In contrast, a 169 collision attack finds two messages with the same hash, but the 170 attacker can't pick what the message will be. Feasible collision 171 attacks against MD4, MD5, HAVAL-128, and RIPEMD were found by the 172 Chinese researcher Xiaoyun Wang with co-authors Dengguo Feng, Xuejia 173 Lai, and Hongbo Yu. 175 The ability to produce a collision does not currently introduce any 176 obvious or known attacks on routing protocols. Pre-image attacks have 177 the potential to cause problems in the future albiet due to the 178 message length there are serious limitations to the feasibility of 179 mounting such an attack. 181 Protocols themselves have some built-in protection against collision. 182 A lot of values for fields in a protocol are invalid or will produce 183 an unusable packet. For example, in OSPF the LSA type can be from 1 184 to 11. Any other value in the field will result in the packet being 185 discarded. 187 Assume two packets M and M' are generated which have the same hash. 188 The above condition will further reduce the ability to produce a 189 message which is also a correct message from the protocol 190 perspective, as a lot of potential values are themselves not valid. 192 2. 193 Open Shortest Path First (OSPFv2) 195 OSPF [RFC2328] describes the use of an MD5 digest with OSPF packets. 196 MD5 keys are manually configured. The OSPF packet Header includes an 197 authentication type field as well as 64 bits of data for use by the 198 appropriate authentication scheme. OSPF also provides for a non- 199 decreasing sequence number to be included in each OSPF protocol 200 packet to protect against replay attacks. 202 2.1 203 Management Issues with OSPF 205 According to the OSPF specification [RFC2328], digests are applied 206 to packets transmitted between adjacent neighbors, rather than being 207 applied to the routing information originated by a router (digests 208 are not applied at the LSA level, but rather at the packet level). 210 [RFC2328] states that any set of OSPF routers adjacent across a 211 single link may use a different key to build MD5 digests than the key 212 used to build MD5 digests on any other link. Thus, MD5 keys may be 213 configured, and changed, on a per-link basis in an OSPF network. 215 OSPF does not specify a mechanisms to negotiate keys, nor does it 216 specify any mechanism to negotiate the hash algorithms to be used. 218 With the proliferation of the number of hash algorithms, as well as 219 the need to continuously upgrade the algorithms, manually configuring 220 the information becomes very tedious. It should also be noted that 221 rekeying OSFP requires coordination among the adjacent routers. 223 2.2 224 Technical Issues with OSPF 226 While OSPF provides relatively strong protection through the 227 inclusion of MD5 signatures, with additional data and a sequence 228 numbers in transmitted packets, there are still attacks against OSPF: 230 o The sequence number is initialized to zero when forming an 231 adjacency with a newly discovered neighbor. When an adjacency is 232 brought down the sequence number is also set to zero. If the 233 cryptographically protected packets of a router that is brought 234 down (for administrative or other reasons) are replayed by a 235 malicious router traffic could be forced through the malicious 236 router. A malicious router might then induce routing loops, 237 intercept or blackhole the traffic. 239 o OSPF allows multiple packets with the same sequence number. 240 This means that the possibility exists to replay the same packet 241 many times before the next legitimate packet is sent. An attacker 242 may resend the same packet repeatedly until the next hello packet 243 is transmitted and received. The Hello interval which is unknown 244 determines the attack window. 246 o OSPF does not require the use of any particular hash algorithm, 247 however the use of only MD5 digests for authentication and replay 248 protection is specified in the document. Most OSPF implementations 249 only support MD5 in addition to Null and Simple Password 250 authentication. 252 Recently, limitations in collision-resistance properties of the 253 MD5 and SHA-1 hash functions have been discovered; [RFC4270] 254 summarizes the discoveries. Attacks on many applications of MD5 255 are practical on modern computers. For this reason the general use 256 of these algorithms should to be discouraged. 258 o OSPF on a broadcast network shares the same key between all 259 neighbors on that broadcast network. Some OSPF packets are sent to 260 a multicast address. 262 Spoofing by any malicious neighbor possessing credentials or 263 replayable packets is therefore very easy. Possession of the key 264 itself is used as an identity validation and no other identity 265 check is used. A malicious neighbor could send a packet forging 266 the identity as being from an other neighbor. There would be no 267 way in which the victim could distinguish the identity of the 268 packet sender. 270 o OSPF neighbors on broadcast, NBMA and point-to-multipoint 271 networks are identified by the IP address in the IP header. 272 The IP header is not covered by the MAC in the cryptographic 273 authentication scheme as described in RFC 2328, and an attack can 274 be made to exploit this omission. 276 Assume the following scenario. 278 R1 sends an authenticated HELLO to R2. This HELLO is captured 279 and replayed back to R1. The source IP in the IP header of the 280 replayed packet is changed to that of R2. 282 R1, not finding itself in HELLO would deduce that the connection 283 is not bidirectional and would bring down the adjacency. 285 3. 286 Open Shortest Path First (OSPFv3) 288 OSPFv3 [RFC5340] relies on the IP Authentication Header [RFC4302] 289 and the IP Encapsulating Payload [RFC4303] to cryptographically sign 290 routing information passed between routers. 292 When using ESP, the null encryption algorithm [RFC2410] is used, so 293 the data carried in the OSPFv3 packets is signed, but not encrypted. 294 This provides data origin authentication for adjacent routers, and 295 data integrity which gives the assurance data transmitted by a router 296 has not changed in transit. 298 However it does not provide confidentiality of the information 299 transmitted. [RFC4552] mandates the use of ESP with null encryption 300 for authentication and also does encourage the use of confidentiality 301 to protect the privacy of the routing information transmitted, using 302 ESP encryption. 304 Authentication/Confidentiality for OSPFv3 [RFC4552] mandates the use 305 of ESP with null encryption for authentication and also does 306 encourage the use of confidentiality to protect the privacy of the 307 routing information transmitted, using ESP encryption. It however 308 only specifies the use of manual keying of routing information as 309 discussed in the following section. 311 3.1 312 Management Issues with OSPFv3 314 The OSPFv3 security document - Authentication/Confidentiality for 315 OSPFv3 [RFC4552] discusses, at length, the reasoning behind using 316 manually configured keys, rather than some automated key management 317 protocol such as IKEv2 [RFC4306]. The primary problem is that all 318 current key management mechanisms are designed for a one-to-one 319 correlation of keys, while OSPF adjacencies are formed on a one-to- 320 many basis. This forces the system administrator to use manually 321 configured SAs and cryptographic keys to provide the authentication 322 and, if desired, confidentiality services. 324 Regarding replay protection [RFC4552] states that: 326 As it is not possible as per the current standards to provide 327 complete replay protection while using manual keying, the proposed 328 solution will not provide protection against replay attacks. 330 The primary administrative issue with manually configured SAs and 331 keys in the OSPFv3 case is the management issues, maintaining shared 332 sets of keys on all routers within a network. As with OSPFv2 333 rekeying is an infrequent event requiring coordination. [RFC4552] 334 does not require that all OSPFv3 routers have the same key configured 335 for every neighbor, so each set of neighbors connected to a given 336 link could have a different key configured. While this makes it 337 easier to change the keys, by forcing the system administrator to 338 only change the keys on the routers on a single link, the process of 339 manual configuration for all the routers in a network to change the 340 keys used for OSPFv3 digests and confidentiality on a periodic basis 341 can be difficult. 343 3.2 344 Technical Issues with OSPFv3 346 The primary technical concern with the current specifications for 347 OSPFv3 is that when manual SA and key management is used as [RFC4302] 348 specifies, in section 3.3.2, Sequence Number Generation: "The sender 349 assumes anti-replay is enabled as a default, unless otherwise 350 notified by the receiver (see 3.4.3) or if the SA was configured 351 using manual key management." Replaying OSPFv3 packets can induce 352 several failures in a network, including: 354 o Replaying hello packets with an empty neighbor list can cause all 355 the neighbor adjacencies with the sending router to be reset, 356 disrupting network communications. 358 o Replaying hello packets from early in the designated router 359 election process on broadcast links can cause all the neighbor 360 adjacencies with the sending router to be reset, disrupting 361 network communications. 363 o Replaying database description (DB-Description) packets can cause 364 all FULL neighbor adjacencies with the sending router to be reset, 365 disrupting network communications. 367 o Replaying link state request (LS-Request) packets can cause all 368 FULL neighbor adjacencies with the sending router to be reset, 369 disrupting network communications. 371 o Capturing a full adjacency process (from two-way all the way to 372 FULL state), and then replaying this process when the router is no 373 longer attached can cause a false adjacency to be formed, allowing 374 an attacker to attract traffic. 376 o OSPFv3 on a broadcast network shares the same key between all 377 neighbors on that network. Some OSPF packets are sent to a 378 multicast address. 380 Spoofing by a malicious neighbor is very easy. Possession of the 381 key itself is used as an identity check. There is no other 382 identity check used. A neighbor could send a packet specifying the 383 packet came from some other neighbor and there would be no way in 384 which the attacked router could figure out the identity of the 385 packet sender. 387 4. 388 Intermediate System to Intermediate System Routing Protocol (IS-IS) 390 Integrated IS-IS [RFC1195] uses HMAC-MD5 (Hashed Message 391 Authentication Code MD5) authentication with manual keying, as 392 described in [RFC5304] and has recently been extended to provide 393 support for using the HMAC construct along with the Secure Hash 394 Algorithm (SHA) [RFC5310] family of cryptographic hash functions. 395 There is no provision within IS-IS to encrypt the body of a routing 396 protocol message. 398 4.1 399 Management Issues with IS-IS 401 [RFC5304] states that each LSP generated by an intermediate system is 402 signed with the HMAC-MD5 algorithm using a key manually defined by 403 the network administrator. Since authentication is performed on the 404 LSPs transmitted by an intermediate system, rather than on the 405 packets transmitted to a specific neighbor, it is implied that all 406 the intermediate systems within a single flooding domain must be 407 configured with the same key for authentication to work correctly. 408 The initial configuration of manual keys for authentication within an 409 IS-IS network is simplified by a state where LSPs containing HMAC-MD5 410 authentication TLVs are accepted by internmediate systems without the 411 keys, but the digest is not validated. Once keys are configured on 412 all routers, changing those keys becomes much more difficult. 414 IS-IS [RFC1195] does not specify a mechanism to negotiate keys, nor 415 does it specify any mechanism to negotiate the hash algorithms to be 416 used. 418 With the proliferation of available hash algorithms, as well as 419 the need to upgrade the algorithms, manually configuration requires 420 coordination among intermediate systems which can become tedious. 422 4.2 423 Technical Issues with IS-IS 425 [RFC5304] states: "This mechanism does not prevent replay attacks, 426 however, in most cases, such attacks would trigger existing 427 mechanisms in the IS-IS protocol that would effectively reject old 428 information." 430 There are a few cases where existing mechanisms in the IS-IS 431 protocol would not effectively reject old information is the case of 432 hello packets (IIHs) used to discover neighbors, and SNP packets. 434 As described in IS-IS [RFC1195], a list of known neighbors is 435 included in each hello transmitted by an intermediate system, to 436 ensure two-way communications with any specific neighbor before 437 exchanging link state databases. 439 IS-IS does not provide a sequence number. IS-IS packets are 440 vulnerable to replay attacks; any packet can be replayed at any point 441 of time. So long as the keys used are the same, protocol elements 442 that would not be rejected will affect existing sessions. 444 A hello packet containing a digest within a TLV, and an empty 445 neighbor list, could be replayed, resulting in all adjacencies with 446 the original transmitting intermediate system to be restarted. 448 A replay of an old CSNP packets could cause LSPs to be flooded, thus 449 causing an LSP storm. 451 IS-IS specifies the use of the hash algorithm HMAC-MD5 to protect 452 IS-IS PDUs. 454 IS-IS does not have a notion of Key ID. During key rollover, each 455 message received has to be checked for integrity against all keys 456 that are valid. A DoS attack may be induced by sending IS-IS packets 457 with random hashes. This will cause the IS-IS packet to be checked 458 for authentication with all possible keys, increasing the amount of 459 processing required. 461 Recently, attacks on the collision-resistance property of the MD5 and 462 SHA-1 hash functions have been discovered; [RFC4270] summarizes the 463 discoveries. The attacks on MD5 are practical on any modern computer. 464 For this reason, the use of these algorithms should be deprecated. 466 HMACs are not susceptible to known collision-reduction attacks. 467 IS-IS implementations should provide a way to upgrade to other 468 algorithms should the need arise. 470 IS-IS on a broadcast network shares the same key between all 471 neighbors on that network. 473 This makes spoofing by a malicious neighbor easy since IS-IS PDUs are 474 sent to a link layer multicast address. Possession of the key itself 475 is used as an authorization check. A neighbor could send a packet 476 spoofing the identity of a neighbor and there would be no way in 477 which the attacked router could discern the identity of the malicious 478 packet sender. 480 The Remaining Lifetime field in the LSP is not covered by the 481 authentication. An IS-IS router can receive its own self generated 482 LSP segment with zero lifetime remaining. In that case, if it has a 483 copy with non-zero lifetime, it purges that LSP i.e., it increments 484 the current sequence number and floods all the segments again. This 485 is much worse in IS-IS compared to OSPF, because there is only one 486 LSP other than the pseudonode LSPs for the LANs on which it is the 487 Designated Intermediate System (DIS). 489 This way an attacker can force the router to flood all segments, 490 potentially a large number if the number of routes is large. It also 491 causes the sequence number of all the LSPs to increase fast. If the 492 sequence number increases to the maximum (0xFFFFFFFF), the IS-IS 493 process must shut down for around 20+ minutes (the product of MaxAge 494 + ZeroAgeLifetime) to allow the old LSPs to age out of all the router 495 databases. 497 5. 498 Border Gateway Protocol (BGP-4) 500 BGP-4 [RFC4271] uses TCP [RFC0793] for transporting routing 501 information between BGP speakers which have formed an adjacency. 503 [RFC2385] describes the use of TCP MD5 signature option for providing 504 packet origin authentication and data integrity protection of BGP 505 packets. [RFC3562] provides suggestions for choosing the key length 506 of the ad-hoc keyed-MD5 mechanism specified in [RFC2385]. There is no 507 provision for confidentiality for any of these BGP messages. 509 BGP relative to previously described IGP protocols has additional 510 exposure due to the nature of the environment where it is typically 511 used, namely between autonomous networks (under different 512 administrative control). While routers running interior gateway 513 protocols may all be configured with the same administrative 514 authority, two BGP peers may be in different administrative domains, 515 having different policies for key strength, rollover frequency, etc. 516 An autonomous system must often support a large number of keys at 517 different BGP boundries, as each connecting AS represents a different 518 administrative entity. In practice once set, shared secrets between 519 BGP peers are rarely if ever changed. 521 5.1 522 Management Issues with BGP-4 524 Each pair of BGP speakers forming an adjacency may have a different 525 MD5 shared key facilitating the independent configuration and 526 changing of keys across a large scale network. Manual configuration 527 and maintenance of cryptographic keys across all BGP sessions is a 528 challenge in any large scale environment. 530 Most BGP implementations will accept BGP packets with a bad digest up 531 to the hold interval negotiated between BGP peers at peering startup, 532 in order to allow for MD5 keys to be changed with minimal impact on 533 operation of the network. This technique does, however, allow some 534 short period of time, during which an attacker may inject BGP packets 535 with false MD5 digests into the network and can expect those packets 536 to be accepted, even though the MD5 digest is not valid. 538 5.2 539 Technical Issues with BGP-4 541 BGP relies on TCP [RFC0793] for transporting data between BGP 542 speakers. BGP can rely on TCP's protections against data corruption 543 and replay to preclude replay attacks against BGP sessions. A great 544 deal of research has gone into the feasibility of an attacker 545 overcoming these protections, including [TCP-WINDOW] and 546 [BGP-ATTACK]. Most router and Operating System (OS) vendors have 547 modified their TCP implementations to resolve the security 548 vulnerabilities described in these references, where possible. 550 As mentioned earlier, MD5 is vulnerable to collision attacks, and can 551 be attacked through several means, such as those explored in [MD5- 552 ATTACK]. 554 Though it can be argued that the collision attacks do not have a 555 practical application in this scenario, the use of MD5 should be 556 discouraged. 558 Routers performing cryptographic processing of packets in software 559 may be exposed to additional opportunities for DoS attacks. An 560 attacker may be able to transmit enough spoofed traffic with false 561 digests that the router's processor and memory resources are 562 consumed, causing the router to be unable to perform normal 563 processing. This exposure is particularly problematic between routers 564 not under unified administrative control. 566 6. 567 The Routing Information Protocol (RIP) 569 The initial version of RIP was specified in STD34 [RFC1058]. This 570 version did not provide for any authentication or authorization of 571 routing data, and thus was vulnerable to any of a number of attacks 572 against routing protocols. This limitation was one reason why this 573 protocol was moved to Historic status [RFC1923]. 575 RIPv2, originally specified in [RFC1388], then [RFC1723], was 576 finalized in STD56 [RFC2453]. This version of the protocol provides 577 for authenticating packets with a digest. The details thereof 578 have initially been provided in "RIP-2 MD5 Authentication" [RFC2082]; 579 "RIPv2 Cryptographic Authentication" [RFC4822] obsoletes [RFC2082] 580 and adds details of how the SHA family of hash algorithms can be used 581 to protect RIPv2. [RFC2082] only specified the use of Keyed MD5. 583 6.1 584 Technical Issues with RIP 586 o The sequence number used by a router is initialized to zero, at 587 startup, and is also set to zero whenever the neighbor is brought 588 down. If the cryptographically protected packets of a router that 589 is brought down (for administrative or other reasons) are stored 590 by a malicious router, the new router could replay the packets 591 from the previous session thus forcing traffic through the 592 malicious router. Dropping of such packets by the router could 593 result in blackholes. Also forwarding wrong packets could 594 result in routing loops. 596 o RIPv2 allows multiple packets with the same sequence number. 597 This could mean the same packet may be replayed many times before 598 the next legitimate packet is sent. An attacker may resend the 599 same packet repeatedly until the next hello packet is transmitted 600 and received, which means the hello interval therefore determines 601 the attack window. 603 o RIPv2 [RFC2453] does not specify the use of any particular hash 604 algorithm. Currently, RIP implementations only support keyed MD5 605 [RFC2082]. 607 o RIPv2 Cryptographic Authentication [RFC4822] does not cover the 608 UDP and the IP headers. It is therefore possible for an attacker 609 to modify some fields in the above headers without routers 610 becoming aware of it. 612 There is limited exposure to modification of the UDP header as 613 the RIP protocol uses only it to compute the length of the RIP 614 packet. Changes introduced in the UDP header would cause RIP 615 authentication to fail the RIP authentication, limiting exposure. 617 RIP uses the source IP address from the IP header to determine 618 which RIP neighbor it has learnt the RIP Update from. Changing 619 the source IP address can be used by an attacker to disrupt the 620 RIP routing sessions between two routers R1 and R2, as shown in 621 the following examples: 623 Scenario 1: 625 R1 sends an authenticated RIP message to R2 with a cryptographic 626 sequence num X. 628 The attacker then needs a higher sequence number packet from the 629 LAN. It could also be a packet originated by R2 either from this 630 session, or from some earlier session. 632 The attacker can then replay this packet to R2 by changing the 633 source IP to that of R1. 635 R2 would then no longer accept any more RIP Updates from R1 as 636 those would have a lower cryptographic sequence number. After 180 637 seconds (or less), R2 would consider R1 timed out and bring down 638 the RIP session. 640 Scenario 2: 642 R1 announces a route with cost C1 to R2. This packet can be 643 captured by an attacker. Later, if this cost changes and R1 644 announces this with a different cost C2, the attacker can replay 645 the captured packet, modifying the source IP to a new 646 arbitrary IP address thereby masquerading as a different router. 648 R2 will accept this route and the router as a new gateway, and 649 R2 would then use the non existent router as a next hop for that 650 network. This would only be effective if the cost C1 is less than 651 C2. 653 7. 654 Bidirectional Forwarding Detection (BFD) 656 BFD is specified in the document [BFD-BASE]. Extensions to BFD for 657 Multi-hop [BFD-MULTI] and single hop [BFD-1HOP] are defined for IPv4 658 and IPv6. It is designed to detect failure with the forwarding plane 659 nexthop. 661 BFD base specifies an optional authentication mechanism which can be 662 used by receiver of a packet to be able to authenticate the source of 663 the packet. It relies on the fact that the keys are shared between 664 the peers and no mechanism is defined for the actual Key generation. 666 7.1 667 Technical Issues with BFD 669 o The level of security provided is based on the Authentication Type 670 used. However the authentication algorithms defined are MD5 or 671 SHA-1 based. As mentioned earlier MD5 and SHA-1 are both known to 672 be vulnerable to collision attacks. 674 o BFD spec mentions mechanisms to allow for the change of 675 authentication state based on the state of a received packet. This 676 can cause a denial of service attack where a malicious 677 authenticated packet (stored from a past session) can be relayed 678 over a session which does not use authentication. This causes one 679 end to assume that authentication is enabled at the other end and 680 hence the BFD adjacency is dropped. This would be a harder attack 681 to put forth when meticulously keyed authentication is in use. 683 o BFD works on microsecond timers. When malicious packets are sent 684 at very small duration of time, with the authentication bit set, 685 it can cause a DoS attack. 687 o BFD allows a mode called the echo mode. Echo packets are not 688 defined in the BFD specification, though they can keep the BFD 689 session UP. There are no guidelines on the properties of the echo 690 packets. Any security issues in the echo mode or packets will 691 directly effect the BFD protocol and session states and hence the 692 network stability. 694 o BFD packets can be sent at millisecond intervals (the protocol 695 uses timers at microsecond intervals). When using authentication 696 this can cause frequent Sequence Number wrap-around as a 32-bit 697 sequence number is used, thus considerably reducing the security 698 of the authentication algorithms. 700 8. 701 Security Considerations 703 This draft outlines security issues arising from the current 704 methodology for manual keying of various routing protocols. No 705 specific changes to routing protocols are proposed in this draft, 706 likewise no new security requirements result. 708 9. 709 Acknowledgements 711 We would like to acknowledge Sam Hartman, Ran Atkinson, Steve Kent 712 and Brian Weis for their initial comments on this draft. Thanks to 713 Merike Kaeo and Alfred Hoenes for reviewing many sections of the 714 draft and providing lot of useful comments. 716 10. 717 IANA Considerations 719 This document places no requests to IANA. 721 Note to RFC Editor: this section may be removed on publication as an 722 RFC. 724 11. 725 References 727 11.1 728 Normative References 730 [RFC0793] Postel, J., "Transmission Control Protocol", STD 7, 731 RFC 793, September 1981. 733 [RFC1195] Callon, R., "Use of OSI IS-IS for routing in TCP/IP and 734 dual environments", RFC 1195, December 1990. 736 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 737 Requirement Levels", BCP 14, RFC 2119, March 1997. 739 [RFC2328] Moy, J., "OSPF Version 2", STD 54, RFC 2328, April 1998. 741 [RFC2385] Heffernan, A., "Protection of BGP Sessions via the TCP 742 MD5 Signature Option", RFC 2385, August 1998. 744 [RFC2453] Malkin, G., "RIP Version 2", RFC 2453, November 1998 746 [RFC5340] Coltun, R., Ferguson, D., Moy, J., and Lindem, A., "OSPF 747 for IPv6", RFC 5340, July 2008. 749 [RFC5304] Li, T. and Atkinson, R., "Intermediate System to 750 Intermediate System (IS-IS) Cryptographic 751 Authentication", RFC 5304, October 2008. 753 [RFC5310] Bhatia, M., et. al., "IS-IS Generic Cryptographic 754 Authentication", RFC 5310, February 2009 756 [RFC4271] Rekhter , Y., Li, T., and S. Hares, "A Border Gateway 757 Protocol 4 (BGP-4)", RFC 4271, January 2006. 759 [RFC4302] Kent, S., "IP Authentication Header", 760 RFC 4302, December 2005. 762 [RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)", 763 RFC 4303, December 2005. 765 [RFC4552] Gupta, M. and N. Melam, "Authentication/Confidentiality 766 for OSPFv3", RFC 4552, January 2006 768 [RFC4822] R. Atkinson and M. Fanto, "RIPv2 Cryptographic 769 Authentication", RFC 4822, February 2007 771 11.2 772 Informative References 774 [RFC1058] Hedrick, C., "Routing Information Protocol", RFC 1058, 775 June 1988. 777 [RFC1321] Rivest, R., "The MD5 Message-Digest Algorithm", RFC 778 1321, April 1992 780 [RFC1388] Malkin, G., "RIP Version 2 Carrying Additional 781 Information", RFC 1388, January 1993. 783 [RFC1723] Malkin, G., "RIP Version 2 - Carrying Additional 784 Information", STD 56, RFC 1723, November 1994. 785 [RFC1923] Halpern, J. and Bradner, S., "RIPv1 Applicability 786 Statement for Historic Status", RFC 1923, March 1996 788 [RFC2082] Baker, F. and Atkinson, R., "RIP-2 MD5 789 Authentication", RFC 2082, January 1997 791 [RFC2410] Kent, S. and Glenn, R., "The NULL Encryption Algorithm 792 and Its Use With IPsec", RFC 2410, November 1998 794 [RFC3562] Leech, M., "Key Management Considerations for the TCP 795 MD5 Signature Option", RFC 3562, July 2003. 797 [RFC4270] Hoffman, P. and B. Schneier, "Attacks on Cryptographic 798 Hashes in Internet Protocols", RFC 4270, November 2005. 800 [RFC4306] Kaufman, C., "The Internet Key Exchange (IKEv2) 801 Protocol", RFC 4306, December 2005 803 [BGP-ATTACK] Convery, S. and M. Franz, "BGP Vulnerability Testing: 804 Separating Fact from FUD v1.00", June 2003. 806 [TCP-WINDOW] Watson, T., "TCP Reset Spoofing", October 2003. 808 [MD5-ATTACK] Wang, X. et al., "Collisions for Hash Functions MD4, 809 MD5, HAVAL-128 and RIPEMD", August 2004, 810 http://eprint.iacr.org/2004/199 812 [BFD-BASE] Katz, D. and D. Ward, "Bidirectional Forwarding 813 Detection", draft-ietf-bfd-base, August 2009 815 [BFD-1HOP] Katz, D. and D. Ward, "BFD for IPv4 and IPv6 (Single 816 Hop), draft-ietf-bfd-v4v6-1hop, August 2009 818 [BFD-MULTI] Katz, D. and D. Ward, "BFD for Multihop Paths", 819 draft-ietf-bfd-multihop, August 2009 821 Contributor's Address 823 Sue Hares 824 NextHop 825 USA 826 Email: shares@nexthop.com 828 Author's Addresses 830 Vishwas Manral 831 IP Infusion 832 Almora, Uttarakhand 833 India 834 Email: vishwas@ipinfusion.com 836 Manav Bhatia 837 Alcatel-Lucent 838 Bangalore, India 839 Email: manav.bhatia@alcatel-lucent.com 841 Joel P. Jaeggli 842 Check Point Software 843 Email: jjaeggli@checkpoint.com 845 Russ White 846 Cisco Systems 847 RTP North Carolina 848 USA 849 Email: riw@cisco.com