idnits 2.17.1 draft-ietf-opsec-routing-protocols-crypto-issues-07.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. 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 == 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 (September 2010) is 4965 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: 3 errors (**), 0 flaws (~~), 2 warnings (==), 6 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Internet-Draft Routing Protocol Protection Issues September 2010 3 Network Working Group Vishwas Manral 4 Internet-Draft IP Infusion 5 Intended Status: Informational Manav Bhatia 6 Expires: March 1, 2011 Alcatel-Lucent 7 Joel Jaeggli 8 Checkpoint Software 9 Russ White 10 Cisco Systems 11 September 1, 2010 13 Issues with existing Cryptographic Protection Methods for Routing 14 Protocols 16 draft-ietf-opsec-routing-protocols-crypto-issues-07.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 This Internet-Draft will expire on March 1, 2011. 50 Copyright Notice 52 Copyright (c) 2010 IETF Trust and the persons identified as the 53 document authors. All rights reserved. 55 This document is subject to BCP 78 and the IETF Trust's Legal 56 Provisions Relating to IETF Documents 57 (http://trustee.ietf.org/license-info) in effect on the date of 58 publication of this document. Please review these documents 59 carefully, as they describe your rights and restrictions with respect 60 to this document. Code Components extracted from this document must 61 include Simplified BSD License text as described in Section 4.e of 62 the Trust Legal Provisions and are provided without warranty as 63 described in the Simplified BSD License. 65 Abstract 67 Routing protocols have over time been extended to use cryptographic 68 mechanisms to validate data being received from a neighboring router 69 to ensure that: 71 o It has not been modified in transit. 72 o Actually originated from an authorized neighboring router. 74 The cryptographic mechanisms defined to date and described in this 75 document rely on a digest produced with a hash algorithm applied to 76 the payload encapsulated in the routing protocol packet. 78 This document outlines some of the limitations of the current 79 mechanism, problems with manual keying of these cryptographic 80 algorithms, and possible vectors for the exploitation of these 81 limitations. 83 Conventions used in this document 85 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 86 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 87 document are to be interpreted as described in RFC 2119. [RFC2119] 89 Table of Contents 91 1. Problem Statement..............................................3 92 1.1 MD5 Pre-Image vs Collision Attacks.........................4 93 1.2 Concerns about MD5 and the SHA-1 Algorithm.................4 94 2. Open Shortest Path First Version 2 (OSPFv2)....................5 95 2.1 Management Issues with OSPFv2..............................5 96 2.2 Technical Issues with OSPFv2...............................6 97 3. Open Shortest Path First Version 3(OSPFv3).....................7 98 3.1 Management Issues with OSPFv3..............................7 99 3.2 Technical Issues with OSPFv3...............................8 100 4. Intermediate System to Intermediate System Routing Protocol (IS- 101 IS)...............................................................9 102 4.1 Management Issues with IS-IS...............................9 103 4.2 Technical Issues with IS-IS...............................10 105 5. Border Gateway Protocol (BGP-4)...............................11 106 5.1 Management Issues with BGP-4..............................12 107 5.2 Technical Issues with BGP-4...............................12 108 6. The Routing Information Protocol (RIP)........................13 109 6.1 Technical Issues with RIP.................................13 110 7. Bidirectional Forwarding Detection (BFD)......................14 111 7.1 Technical Issues with BFD.................................15 112 8. Security Considerations.......................................16 113 9. Acknowledgements..............................................16 114 10. IANA Considerations..........................................16 115 11. References...................................................16 116 11.1 Normative References.....................................16 117 11.2 Informative References...................................17 118 Contributor's Address............................................20 119 Author's Addresses...............................................20 121 1. Problem Statement 123 Protocols, such as OSPF version 2 [RFC2328], version 3 [RFC5340], IS- 124 IS [RFC1195], BGP-4 [RFC4271] and BFD [RFC5880], employ various 125 mechanisms to create a cryptographic digest of each transmitted 126 protocol packet. Traditionally, these digests are the results of a 127 one-way hash algorithm, such as Message Digest 5 (MD5) [RFC1321], 128 across the contents of the packet being transmitted. A secret key is 129 used as the hash base (or seed). The digest is then recomputed by 130 the receiving router, using the same key as the original router used 131 to create the hash, then compared with the transmitted digest to 132 verify: 134 o That the router originating this packet is authorized via the 135 shared key mechanism to peer with the local router, and exchange 136 routing data. The implicit trust of routing protocol exchange 137 protected by a shared secret is intended to protect against the 138 injection of falsely generated routing data into the routing system 139 by unauthorized systems. 141 o That the data has not been altered in transit between the 142 two neighboring routers. 144 Digest verification schemes are not intended to protect the 145 confidentiality of information being exchanged between routers. The 146 information (entries in the routing table) is potentially available 147 through other mechanisms; Moreover, access to the physical media 148 between two routers exchanging routing data, will confer the ability 149 to capture or otherwise discover the contents of the routing tables 150 in those routers. 152 Authentication mechanisms defined today have notable limitations: 154 o Manual configuration of shared secret keys, especially in large 155 networks and between networks, poses a major management problem. 156 In many cases it is challenging to replace keys without significant 157 coordination or disruption. 159 o In some cases, when manual keys are configured, some forms of 160 replay protection are no longer possible , allowing the routing 161 protocol to be attacked through the replay of captured routing 162 messages. 164 This document outlines some of the problems with manual keying of 165 these cryptographic algorithms. 167 1.1 MD5 Pre-Image vs Collision Attacks 169 A preimage attack (An attempt to find new data with the same hash 170 value) would enable someone to find an input message that causes a 171 hash function to produce a particular output. In contrast, a 172 collision attack finds two messages with the same hash, but the 173 attacker can't pick what the message will be. Feasible collision 174 attacks against MD4, MD5, HAVAL-128, and RIPEMD have been documented 175 in [CRYPTO-04]. 177 The ability to produce a collision does not currently introduce any 178 obvious or known attacks on routing protocols. Pre-image attacks have 179 the potential to cause problems in the future albeit due to the 180 message length there are serious limitations to the feasibility of 181 mounting such an attack. 183 Protocols themselves have some built-in protection against collision 184 attacks. This is because a lot of values for fields in a protocol 185 packet are invalid or will produce an unusable packet. For example, 186 in OSPF the Link State Advertisement (LSA) type can be from 1 to 11. 187 Any other value in the field will result in the packet being 188 discarded. 190 Assume two packets M and M' are generated which have the same hash. 191 The above condition will further reduce the ability to produce a 192 message which is also a correct message from the protocol 193 perspective, as a lot of potential values are themselves not valid. 195 1.2 Concerns about MD5 and the SHA-1 Algorithm 197 There are published concerns about the overall strength of the MD5 198 algorithm ([Dobb96a], [Dobb96b], [Wang04]). While those published 199 concerns apply to the use of MD5 in other modes (e.g., use of MD5 200 X.509v3/PKIX digital certificates), they are not an attack upon 201 Keyed-MD5, and Hash-based Message Authentication Code MD5 (HMAC-MD5) 202 which is what the current routing protocols have specified. There 203 are also published concerns about the Secure Hash Algorithm (SHA) 204 algorithm ([Wang05], [Philip01], [Prav01], [Prav02], [Arjen05]) and 205 also concerns about the MD5 and SHA algorithms in the HMAC [RFC2104] 206 mode ([RR07], [RR08]). National Institute of Standards and Technology 207 (NIST) will be supporting HMAC-SHA-1 even after 2010 [NIST-HMAC-SHA], 208 whereas it will drop support for SHA-1 in digital signatures. NIST 209 also recommends application and protocol designers to move to SHA-2 210 family of hash functions (i.e., SHA-224, SHA-256, SHA-384 and SHA- 211 512) for all new applications and protocols. 213 However, as explained above such attacks are currently not applicable 214 to the routing protocols. Separately, some organisations (e.g., the 215 US government) prefer NIST algorithms, such as the SHA family, over 216 other algorithms (like MD5) for local policy reasons. 218 2. Open Shortest Path First Version 2 (OSPFv2) 220 OSPF [RFC2328] describes the use of an MD5 digest with OSPF packets. 221 MD5 keys are manually configured. The OSPF packet Header includes an 222 authentication type field as well as 64 bits of data for use by the 223 appropriate authentication scheme. OSPF also provides for a non- 224 decreasing sequence number to be included in each OSPF protocol 225 packet to protect against replay attacks. 227 OSPF with Digital Signatures [RFC2154] is an experimental RFC that 228 describes extensions to OSPF to digitally sign its link-state 229 advertisements (LSAs). It is believed that if stronger authentication 230 and security is required then OSPF (and the other routing protocols) 231 must migrate to using full digital signatures. Doing this would 232 enable precise authentication of the OSPF router originating each 233 OSPF link-state advertisement, and thereby providing much stronger 234 integrity protection for the OSPF routing domain. However since there 235 have been no deployments there is precious little operational 236 experience with this standard and is hence not covered in this 237 document. 239 2.1 Management Issues with OSPFv2 241 According to the OSPF specification [RFC2328], digests are applied to 242 packets transmitted between adjacent neighbors, rather than being 243 applied to the routing information originated by a router (digests 244 are not applied at the LSA level, but rather at the packet level). 245 [RFC2328] states that any set of OSPF routers adjacent across a 246 single link may use a different key to build MD5 digests than the key 247 used to build MD5 digests on any other link. Thus, MD5 keys may be 248 configured, and changed, on a per-link basis in an OSPF network. 250 OSPF does not specify a mechanism to negotiate keys, nor does it 251 specify any mechanism to negotiate the hash algorithms to be used. 253 With the proliferation of the number of hash algorithms, as well as 254 the need to continuously upgrade the algorithms, manually configuring 255 the information becomes very tedious. It should also be noted that 256 rekeying OSPF requires coordination among the adjacent routers. 258 2.2 Technical Issues with OSPFv2 260 While OSPF provides relatively strong protection through the 261 inclusion of MD5 digests, with additional data and a sequence numbers 262 in transmitted packets, there are still attacks against OSPF: 264 o The sequence number is initialized to zero when forming an 265 adjacency with a newly discovered neighbor. When an adjacency is 266 brought down the sequence number is also set to zero. If the 267 cryptographically protected packets of a router that is brought 268 down (for administrative or other reasons) are replayed by a 269 malicious router, traffic could be forced through the malicious 270 router. A malicious router might then induce routing loops, 271 intercept or blackhole the traffic. 273 o OSPF allows multiple packets with the same sequence number. 274 This means that the possibility exists to replay the same packet 275 many times before the next legitimate packet is sent. An attacker 276 may resend the same packet repeatedly until the next hello packet 277 is transmitted and received. The Hello interval which is unknown 278 determines the attack window. 280 o OSPF does not require the use of any particular hash algorithm, 281 however the use of only MD5 digests for authentication and replay 282 protection is specified in the document. Most OSPF implementations 283 only support MD5 in addition to Null and Simple Password 284 authentication. 286 Recently, limitations in collision-resistance properties of the 287 MD5 and SHA-1 hash functions have been discovered; [RFC4270] 288 summarizes the discoveries. There have been attacks against the 289 use of MD5 as a hash; while these attacks do not directly apply to 290 the use of MD5 in routing protocols, it is prudent to have other 291 options available. For this reason the general use of these 292 algorithms should to be discouraged and for this reason [RFC5709] 293 adds support for using SHA-1 and SHA-2 with the HMAC construct 294 for OSPF. 296 o OSPF on a broadcast network shares the same key between all 297 neighbors on that broadcast network. Some OSPF packets are sent to 298 a multicast address. 300 Spoofing by any malicious neighbor possessing credentials or 301 replayable packets is therefore very easy. Possession of the key 302 itself is used as an identity validation and no other identity 303 check is used. A malicious neighbor could send a packet forging 304 the identity as being from an other neighbor. There would be no 305 way in which the victim could distinguish the identity of the 306 packet sender. 308 o In some OSPF implementations neighbors on broadcast, non-broadcast 309 multi-access (NBMA) and point-to-multipoint networks are 310 identified by the IP address in the IP header. The IP header is 311 not covered by the MAC in the cryptographic authentication scheme 312 as described in RFC 2328, and an attack can be made to exploit 313 this omission. 315 Assume the following scenario. 317 R1 sends an authenticated HELLO to R2. This HELLO is captured 318 and replayed back to R1. The source IP in the IP header of the 319 replayed packet is changed to that of R2. 321 R1, not finding itself in HELLO would deduce that the connection 322 is not bidirectional and would bring down the adjacency. 324 3. Open Shortest Path First Version 3(OSPFv3) 326 OSPFv3 [RFC5340] relies on the IP Authentication Header (AH) 327 [RFC4302] and the IP Encapsulating Security Payload (ESP) [RFC4303] 328 to cryptographically sign routing information passed between routers. 330 When using ESP, the null encryption algorithm [RFC2410] is used, so 331 the data carried in the OSPFv3 packets is signed, but not encrypted. 332 This provides data origin authentication for adjacent routers, and 333 data integrity which gives the assurance that the data transmitted by 334 a router has not changed in transit. However it does not provide 335 confidentiality of the information transmitted which is acceptable as 336 privacy of the information being carried in the routing protocols 337 need not be kept secret. 339 Authentication/Confidentiality for OSPFv3 [RFC4552] mandates the use 340 of ESP with null encryption for authentication and also does 341 encourage the use of confidentiality to protect the privacy of the 342 routing information transmitted, using ESP encryption. It however 343 only specifies the use of manual keying of routing information as 344 discussed in the following section. 346 3.1 Management Issues with OSPFv3 348 The OSPFv3 security document - Authentication/Confidentiality for 349 OSPFv3 [RFC4552] discusses, at length, the reasoning behind using 350 manually configured keys, rather than some automated key management 351 protocol such as IKEv2 [RFC4306]. The primary problem is the lack of 352 suitable key management mechanism, as OSPF adjacencies are formed on 353 a one-to-many basis and most key management mechanisms are designed 354 for a one-to-one communication model. This forces the system 355 administrator to use manually configured security associations (SAs) 356 and cryptographic keys to provide the authentication and, if desired, 357 confidentiality services. 359 Regarding replay protection [RFC4552] states that: 361 As it is not possible as per the current standards to provide 362 complete replay protection while using manual keying, the proposed 363 solution will not provide protection against replay attacks. 365 The primary administrative issue with manually configured SAs and 366 keys in the OSPFv3 case is the management issues, maintaining shared 367 sets of keys on all routers within a network. As with OSPFv2 368 rekeying is an infrequent event requiring coordination. [RFC4552] 369 does not require that all OSPFv3 routers have the same key configured 370 for every neighbor, so each set of neighbors connected to a given 371 link could have a different key configured. While this makes it 372 easier to change the keys, by forcing the system administrator to 373 only change the keys on the routers on a single link, the process of 374 manual configuration for all the routers in a network to change the 375 keys used for OSPFv3 digests and confidentiality on a periodic basis 376 can be difficult. 378 3.2 Technical Issues with OSPFv3 380 The primary technical concern with the current specifications for 381 OSPFv3 is that when manual security association (SA) and key 382 management is used as [RFC4302] specifies, in section 3.3.2, Sequence 383 Number Generation: "The sender assumes anti-replay is enabled as a 384 default, unless otherwise notified by the receiver (see 3.4.3) or if 385 the SA was configured using manual key management." Replaying OSPFv3 386 packets can induce several failures in a network, including: 388 o Replaying hello packets with an empty neighbor list can cause all 389 the neighbor adjacencies with the sending router to be reset, 390 disrupting network communications. 392 o Replaying hello packets from early in the designated router 393 election process on broadcast links can cause all the neighbor 394 adjacencies with the sending router to be reset, disrupting 395 network communications. 397 o Replaying database description (DB-Description) packets can cause 398 all FULL neighbor adjacencies with the sending router to be reset, 399 disrupting network communications. 401 o Replaying link state request (LS-Request) packets can cause all 402 FULL neighbor adjacencies with the sending router to be reset, 403 disrupting network communications. 405 o Capturing a full adjacency process (from two-way all the way to 406 FULL state), and then replaying this process when the router is no 407 longer attached can cause a false adjacency to be formed, allowing 408 an attacker to attract traffic. 410 o OSPFv3 on a broadcast network shares the same key between all 411 neighbors on that network. Some OSPF packets are sent to a 412 multicast address. 414 Spoofing by a malicious neighbor is very easy. Possession of the 415 key itself is used as an identity check. There is no other 416 identity check used. A neighbor could send a packet specifying the 417 packet came from some other neighbor and there would be no way in 418 which the attacked router could figure out the identity of the 419 packet sender. 421 4. Intermediate System to Intermediate System Routing Protocol (IS-IS) 423 Integrated IS-IS [RFC1195] uses HMAC-MD5 (Hashed Message 424 Authentication Code MD5) authentication with manual keying, as 425 described in [RFC5304] and has recently been extended to provide 426 support for using the HMAC construct along with the Secure Hash 427 Algorithm (SHA) [RFC5310] family of cryptographic hash functions. 428 There is no provision within IS-IS to encrypt the body of a routing 429 protocol message. 431 4.1 Management Issues with IS-IS 433 [RFC5304] states that each Link State Packet (LSP) generated by an 434 intermediate system is signed with the HMAC-MD5 algorithm using a key 435 manually defined by the network administrator. Since authentication 436 is performed on the LSPs transmitted by an intermediate system, 437 rather than on the packets transmitted to a specific neighbor, it is 438 implied that all the intermediate systems within a single flooding 439 domain must be configured with the same key for authentication to 440 work correctly. 442 The initial configuration of manual keys for authentication within an 443 IS-IS network is simplified by a state where LSPs containing HMAC- 444 MD5/HMAC-SHA authentication TLVs are accepted by intermediate systems 445 without the keys, but the digest is not validated. Once keys are 446 configured on all routers, changing those keys becomes much more 447 difficult. 449 IS-IS [RFC1195] does not specify a mechanism to negotiate keys, nor 450 does it specify any mechanism to negotiate the hash algorithms to be 451 used. 453 With the proliferation of available hash algorithms, as well as the 454 need to upgrade the algorithms, manual configuration requires 455 coordination among intermediate systems which can become tedious. 457 4.2 Technical Issues with IS-IS 459 [RFC5304] states: "This mechanism does not prevent replay attacks, 460 however, in most cases, such attacks would trigger existing 461 mechanisms in the IS-IS protocol that would effectively reject old 462 information." 464 The few cases where existing mechanisms in the IS-IS protocol would 465 not effectively reject old information is the case of Hello packets 466 or the Intermediate System to Intermediate System Hellos (IIHs) that 467 are used to discover neighbors, and the Sequence Number 468 Packets(SNPs). 470 As described in IS-IS [RFC1195], a list of known neighbors is 471 included in each Hello transmitted by an intermediate system, to 472 ensure two-way communications with any specific neighbor before 473 exchanging link state databases. 475 IS-IS does not provide a sequence number. IS-IS packets are 476 vulnerable to replay attacks; any packet can be replayed at any point 477 of time. So long as the keys used are the same, protocol elements 478 that would not be rejected will affect existing sessions. 480 A hello packet containing a digest within a TLV, and an empty 481 neighbor list, could be replayed, resulting in all adjacencies with 482 the original transmitting intermediate system to be restarted. 484 A replay of an old Complete Sequence Number Packet (CSNP) could cause 485 LSPs to be flooded, resulting in an LSP storm. 487 IS-IS specifies the use of the HMAC-MD5 and HMAC-SHA-1 to protect 488 IS-IS packets. 490 IS-IS does not have a notion of Key ID. During key rollover, each 491 message received has to be checked for integrity against all keys 492 that are valid. A Denial of Service (DoS) attack may be induced by 493 sending IS-IS packets with random hashes. This will cause the IS-IS 494 packet to be checked for authentication with all possible keys, 495 increasing the amount of processing required. This issue however has 496 been fixed in the recent [RFC5310] which introduces the concept of 497 Key IDs in IS-IS. 499 Recently, limitations in collision-resistance properties of the 500 MD5 and SHA-1 hash functions have been discovered; [RFC4270] 501 summarizes the discoveries. There have been attacks against the 502 use of MD5 as a hash; while these attacks do not directly apply to 503 the use of HMAC-MD5 in IS-IS, it is prudent to have other options 504 available. For this reason the general use of these algorithms should 505 to be discouraged and [RFC5310] adds support for using HMAC-SHA with 506 IS-IS. 508 IS-IS on a broadcast network shares the same key between all 509 neighbors on that network. 511 This makes spoofing by a malicious neighbor easy since IS-IS packets 512 are sent to a link layer multicast address. Possession of the Key 513 itself is used as an authorization check. A neighbor could send a 514 packet spoofing the identity of a neighbor and there would be no way 515 in which the attacked router could discern the identity of the 516 malicious packet sender. 518 The Remaining Lifetime field in the LSP is not covered by the 519 authentication. An IS-IS router can receive its own self generated 520 LSP segment with zero lifetime remaining. In that case, if it has a 521 copy with non-zero lifetime, it purges that LSP i.e., it increments 522 the current sequence number and floods all the segments again. This 523 is much worse in IS-IS compared to OSPF, because there is only one 524 LSP other than the pseudonode LSPs for the LANs on which it is the 525 Designated Intermediate System (DIS). 527 This way an attacker can force the router to flood all segments, 528 potentially a large number if the number of routes is large. It also 529 causes the sequence number of all the LSPs to increase fast. If the 530 sequence number increases to the maximum (0xFFFFFFFF), the IS-IS 531 process must shut down for around 20+ minutes (the product of MaxAge 532 + ZeroAgeLifetime) to allow the old LSPs to age out of all the router 533 databases. 535 5. Border Gateway Protocol (BGP-4) 537 BGP-4 [RFC4271] uses TCP [RFC0793] for transporting routing 538 information between BGP speakers which have formed an adjacency. 540 [RFC2385] describes the use of TCP MD5 digest option for providing 541 packet origin authentication and data integrity protection of BGP 542 packets. [RFC3562] provides suggestions for choosing the key length 543 of the ad-hoc keyed-MD5 mechanism specified in [RFC2385]. There is no 544 provision for confidentiality for any of these BGP messages. 546 The IETF has recently obsoleted TCP-MD5 [RFC2385] with a new TCP 547 Authentication Option [RFC5925]. [RFC5925] specifies the use of 548 stronger Message Authentication Codes (MACs), protects against 549 replays even for long lived TCP connections, and provides more 550 details on the association of security with TCP connections than TCP- 551 MD5. It allows rekeying during a TCP connection, assuming that an 552 out-of-band protocol or manual mechanism provides the new keys. Note 553 that TCP MD5 does not preclude rekeying during a connection, but does 554 not require its support either. Further, TCP-AO supports key changes 555 with zero segment loss, whereas key changes in TCP MD5 can lose 556 segments in transit during the changeover or require trying multiple 557 keys on each received segment during key use overlap because it lacks 558 an explicit key ID. Although TCP recovers lost segments through 559 retransmission, loss can have a substantial impact on performance. 561 This document however still covers only TCP-MD5 as all current 562 deployments are still using BGP with TCP-MD5 and have not upgraded to 563 [RFC5925]. There isn't enough operational experience present to 564 evaluate the technical and management issues with this proposal yet. 566 Compared to previously described IGP protocols, BGP has additional 567 exposure due to the nature of the environment where it is typically 568 used, namely between autonomous networks (under different 569 administrative control).While routers running interior gateway 570 protocols may all be configured with the same administrative 571 authority, two BGP peers may be in different administrative domains, 572 having different policies for key strength, rollover frequency, etc. 573 An autonomous system must often support a large number of keys at 574 different BGP boundaries, as each connecting AS represents a 575 different administrative entity. In practice once set, shared secrets 576 between BGP peers are rarely if ever changed. 578 5.1 Management Issues with BGP-4 580 Each pair of BGP speakers forming a peering may have a different 581 MD5 shared key facilitating the independent configuration and 582 changing of keys across a large scale network. Manual configuration 583 and maintenance of cryptographic keys across all BGP sessions is a 584 challenge in any large scale environment. 586 Most BGP implementations will accept BGP packets with a bad digest up 587 to the hold interval negotiated between BGP peers at peering startup, 588 in order to allow for MD5 keys to be changed with minimal impact on 589 operation of the network. This technique does, however, allow some 590 short period of time, during which an attacker may inject BGP packets 591 with false MD5 digests into the network and can expect those packets 592 to be accepted, even though the MD5 digest is not valid. 594 5.2 Technical Issues with BGP-4 596 BGP relies on TCP [RFC0793] for transporting data between BGP 597 speakers. BGP can rely on TCP's protection against data corruption 598 and replay to preclude replay attacks against BGP sessions. A great 599 deal of research has gone into the feasibility of an attacker 600 overcoming these protections, including [TCP-WINDOW] and [Conv01]. 601 Most router and Operating System (OS) vendors have modified their TCP 602 implementations to resolve the security vulnerabilities described in 603 these references, where possible. 605 As mentioned earlier, MD5 is vulnerable to collision attacks, and can 606 be attacked through several means, such as those explored in 607 [Wang04]. 609 Though it can be argued that the collision attacks do not have a 610 practical application in this scenario, the use of MD5 should be 611 discouraged. 613 Routers performing cryptographic processing of packets in software 614 may be exposed to additional opportunities for DoS attacks. An 615 attacker may be able to transmit enough spoofed traffic with false 616 digests that the router's processor and memory resources are 617 consumed, causing the router to be unable to perform normal 618 processing. This exposure is particularly problematic between routers 619 not under unified administrative control. 621 6. The Routing Information Protocol (RIP) 623 The initial version of RIP was specified in STD34 [RFC1058]. This 624 version did not provide for any authentication or authorization of 625 routing data, and thus was vulnerable to any of a number of attacks 626 against routing protocols. This limitation was one reason why this 627 protocol was moved to Historic status [RFC1923]. 629 RIPv2, originally specified in [RFC1388], then [RFC1723], was 630 finalized in STD56 [RFC2453]. This version of the protocol provides 631 for authenticating packets with a digest. The details thereof 632 have initially been provided in "RIP-2 MD5 Authentication" [RFC2082]; 633 "RIPv2 Cryptographic Authentication" [RFC4822] obsoletes [RFC2082] 634 and adds details of how the SHA family of hash algorithms can be used 635 to protect RIPv2. [RFC2082] only specified the use of Keyed MD5. 637 6.1 Technical Issues with RIP 639 o The sequence number used by a router is initialized to zero, at 640 startup, and is also set to zero whenever the neighbor is brought 641 down. If the cryptographically protected packets of a router that 642 is brought down (for administrative or other reasons) are stored 643 by a malicious router, the new router could replay the packets 644 from the previous session thus forcing traffic through the 645 malicious router. Dropping of such packets by the router could 646 result in blackholes. Also forwarding wrong packets could 647 result in routing loops. 649 o RIPv2 allows multiple packets with the same sequence number. 650 This could mean the same packet may be replayed many times before 651 the next legitimate packet is sent. An attacker may resend the 652 same packet repeatedly until the next Hello packet is transmitted 653 and received, which means the hello interval therefore determines 654 the attack window. 656 o RIPv2 [RFC2453] does not specify the use of any particular hash 657 algorithm. Currently, RIP implementations support keyed MD5 658 [RFC2082] and [RFC4822] adds support for using HMAC-SHA for RIP. 660 o RIPv2 Cryptographic Authentication [RFC4822] does not cover the 661 UDP and the IP headers. It is therefore possible for an attacker 662 to modify some fields in the above headers without routers 663 becoming aware of it. 665 There is limited exposure to modification of the UDP header as 666 the RIP protocol uses only it to compute the length of the RIP 667 packet. Changes introduced in the UDP header would cause RIP 668 authentication to fail the RIP authentication, limiting exposure. 670 RIP uses the source IP address from the IP header to determine 671 which RIP neighbor it has learnt the RIP Update from. Changing 672 the source IP address can be used by an attacker to disrupt the 673 RIP routing sessions between two routers R1 and R2, as shown in 674 the following examples: 676 Scenario 1: 678 R1 sends an authenticated RIP message to R2 with a cryptographic 679 sequence num X. 681 The attacker then needs a higher sequence number packet originated 682 by R2 either from this session, or from some earlier session. 684 The attacker can then replay this packet to R2 by changing the 685 source IP to that of R1. 687 R2 would then no longer accept any more RIP Updates from R1 as 688 those would have a lower cryptographic sequence number. After 180 689 seconds (or less), R2 would consider R1 timed out and bring down 690 the RIP session. 692 Scenario 2: 694 R1 announces a route with cost C1 to R2. This packet can be 695 captured by an attacker. Later, if this cost changes and R1 696 announces this with a different cost C2, the attacker can replay 697 the captured packet, modifying the source IP to a new 698 arbitrary IP address thereby masquerading as a different router. 700 R2 will accept this route and the router as a new gateway, and 701 R2 would then use the non existent router as a next hop for that 702 network. This would only be effective if the cost C1 is less than 703 C2. 705 7. Bidirectional Forwarding Detection (BFD) 707 BFD is specified in the document [RFC5880]. Extensions to BFD for 708 Multi-hop [RFC5883] and single hop [RFC5881] are defined for IPv4 and 709 IPv6. It is designed to detect failure with the forwarding plane next 710 hop. 712 BFD base specifies an optional authentication mechanism which can be 713 used by receiver of a packet to be able to authenticate the source of 714 the packet. It relies on the fact that the keys are shared between 715 the peers and no mechanism is defined for the actual Key generation. 717 7.1 Technical Issues with BFD 719 o The level of security provided is based on the Authentication Type 720 used. However the authentication algorithms defined are MD5 or 721 SHA-1 based. As mentioned earlier MD5 and SHA-1 are both known to 722 be vulnerable to collision attacks. 724 o BFD specification mentions mechanisms to allow for the change of 725 authentication state based on the state of a received packet. This 726 can cause a denial of service attack where a malicious 727 authenticated packet (stored from a past session) can be relayed 728 over a session which does not use authentication. This causes one 729 end to assume that authentication is enabled at the other end and 730 hence the BFD adjacency is dropped. This would be a harder attack 731 to put forth when meticulously keyed authentication is in use. 733 o BFD works on microsecond timers. When malicious packets are sent 734 at very small duration of time, with the authentication bit set, 735 it can cause a DoS attack. 737 o BFD allows a mode called the echo mode. Echo packets are not 738 defined in the BFD specification, though they can keep the BFD 739 session up. There are no guidelines on the properties of the echo 740 packets beyond the choice of the source and destination addresses, 741 and while the BFD specification recommends applying security 742 mechanisms to prevent spoofing of these packets, there are no 743 guidelines on what type of mechanisms are appropriate. 745 Any security issues in the echo mode will directly affect the BFD 746 protocol and session states and hence the network stability. The 747 potential effects and remedies as understood today are somewhat 748 limited, however. For instance, any replay attacks would be 749 indistinguishable from normal forwarding of the tested router. An 750 attack would still cause a faulty link to be believed to be up, 751 but there is little that can be be done about it. However, if the 752 echo packets are guessable it may be possible to spoof from an 753 external source and cause BFD to believe that a one-way link is 754 really bidirectional. As a result it is important that the echo 755 packets contain random material that is also checked upon 756 reception. 758 o BFD packets can be sent at millisecond intervals (the protocol 759 uses timers at microsecond intervals). When using authentication 760 this can cause frequent Sequence Number wrap-around as a 32-bit 761 sequence number is used, thus considerably reducing the security 762 of the authentication algorithms. 764 o Recently, limitations in collision-resistance properties of the 765 MD5 and SHA-1 hash functions have been discovered; [RFC4270] 766 summarizes the discoveries. There have been attacks against the 767 use of MD5 as a hash; while these attacks do not directly apply to 768 the use of HMAC-MD5 and keyed SHA-1 in BFD, it is prudent to have 769 other options available. Such attacks do not mean that BFD using 770 SHA-1 for authentication is at risk. However, it does mean that 771 SHA-1 should be replaced as soon as possible and should not be used 772 for new applications. 774 It should be noted that if SHA-1 is used in the Hashed Message 775 Authentication Code (HMAC) [RFC2104] construction then collision 776 attacks currently known against SHA-1 do not apply. The new attacks 777 on SHA-1 have no impact on the security of HMAC-SHA-1. 779 There are already proposals [GEN-BFD-AUTH] that add support for 780 HMAC with SHA-1 and SHA-2 family of hash functions for BFD. 782 8. Security Considerations 784 This draft outlines security issues arising from the current 785 methodology for manual keying of various routing protocols. No 786 specific changes to routing protocols are proposed in this draft, 787 likewise no new security requirements result. 789 9. Acknowledgements 791 We would like to acknowledge Sam Hartman, Ran Atkinson, Stephen Kent 792 and Brian Weis for their initial comments on this draft. Thanks to 793 Merike Kaeo and Alfred Hoenes for reviewing many sections of the 794 draft and providing lot of useful comments. 796 10. IANA Considerations 798 This document places no requests to IANA. 800 Note to RFC Editor: this section may be removed on publication as an 801 RFC. 803 11. References 805 11.1 Normative References 807 [RFC0793] Postel, J., "Transmission Control Protocol", STD 7, 808 RFC 793, September 1981. 810 [RFC1195] Callon, R., "Use of OSI IS-IS for routing in TCP/IP and 811 dual environments", RFC 1195, December 1990. 813 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 814 Requirement Levels", BCP 14, RFC 2119, March 1997. 816 [RFC2328] Moy, J., "OSPF Version 2", STD 54, RFC 2328, April 1998. 818 [RFC2385] Heffernan, A., "Protection of BGP Sessions via the TCP 819 MD5 Signature Option", RFC 2385, August 1998. 821 [RFC2453] Malkin, G., "RIP Version 2", RFC 2453, November 1998. 823 [RFC5340] Coltun, R., Ferguson, D., Moy, J., and Lindem, A., "OSPF 824 for IPv6", RFC 5340, July 2008. 826 [RFC5304] Li, T. and Atkinson, R., "Intermediate System to 827 Intermediate System (IS-IS) Cryptographic 828 Authentication", RFC 5304, October 2008. 830 [RFC5310] Bhatia, M., et. al., "IS-IS Generic Cryptographic 831 Authentication", RFC 5310, February 2009 833 [RFC4271] Rekhter , Y., Li, T., and S. Hares, "A Border Gateway 834 Protocol 4 (BGP-4)", RFC 4271, January 2006. 836 [RFC4302] Kent, S., "IP Authentication Header", 837 RFC 4302, December 2005. 839 [RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)", 840 RFC 4303, December 2005. 842 [RFC4552] Gupta, M. and N. Melam, "Authentication/Confidentiality 843 for OSPFv3", RFC 4552, January 2006. 845 [RFC4822] Atkinson, R. and Fanto, M., "RIPv2 Cryptographic 846 Authentication", RFC 4822, February 2007. 848 11.2 Informative References 850 [Arjen05] Arjen K. Lenstra, "Further progress in Hashing 851 cryptanalysis", Lucent Bell Laboratories, February 26, 852 2005. 854 [Conv01] Convery, S. and M. Franz, "BGP Vulnerability Testing: 855 Separating Fact from FUD v1.00", June 2003. 857 [CRYPTO-04] Xiaoyun Wang, Xuejia Lai, Dengguo Feng and Hongbo Yu, 858 "Collisions for hash functions MD4, MD5, HAVAL-128, and 859 RIPEMD", Crypto 2004 Rump Session. 861 [Dobb96a] Dobbertin, H, "Cryptanalysis of MD5 Compress", Technical 862 Report, 2 May 1996. (Presented at the Rump Session of 863 EuroCrypt 1996.) 865 [Dobb96b] Dobbertin, H, "The Status of MD5 After a Recent Attack", 866 CryptoBytes, Vol. 2, No. 2, Summer 1996. 868 [GEN-BFD-AUTH] Bhatia, Manav and Manral, Vishwas, "BFD Generic 869 Cryptographic Authentication", Work in Progress 871 [NIST-HMAC-SHA] "NIST's Policy on Hash Functions", 2006. Available 872 online at http://csrc.nist.gov/groups/ST/hash/policy.html 874 [Philip01] Philip Hawkes1, Michael Paddon1, and Gregory G. Rose, "On 875 Corrective Patterns for the SHA-2 Family", Qualcomm 876 Australia 878 [Prav01] Praveen Gauravaram, et. al., "Collision Attacks on MD5 879 and SHA-1: Is this the 'Sword of Domocles' for Electronic 880 Commerce?", Information Security Institue (ISI), 881 Queensland University of Technology (QUT), Australia 883 [Prav02] Praveen Gauravaram, et. al., "Some thoughts on Collision 884 Attacks in the Hash Functions Md5, SHA-0 and SHA-1", 885 Information Security Institue (ISI), Queensland 886 University of Technology (QUT), Australia 888 [RFC1058] Hedrick, C., "Routing Information Protocol", RFC 1058, 889 June 1988. 891 [RFC1321] Rivest, R., "The MD5 Message-Digest Algorithm", RFC 892 1321, April 1992. 894 [RFC1388] Malkin, G., "RIP Version 2 Carrying Additional 895 Information", RFC 1388, January 1993. 897 [RFC1723] Malkin, G., "RIP Version 2 - Carrying Additional 898 Information", STD 56, RFC 1723, November 1994. 900 [RFC1923] Halpern, J. and Bradner, S., "RIPv1 Applicability 901 Statement for Historic Status", RFC 1923, March 1996. 903 [RFC2082] Baker, F. and Atkinson, R., "RIP-2 MD5 904 Authentication", RFC 2082, January 1997 906 [RFC2104] Krawczyk, H., et. al., "HMAC: Keyed-Hashing for Message 907 Authentication", RFC 2104, February 1997 909 [RFC2154] Murphy, S., et. al., "OSPF with Digital Signatures", RFC 910 2154, June 1997 912 [RFC2410] Kent, S. and Glenn, R., "The NULL Encryption Algorithm 913 and Its Use With IPsec", RFC 2410, November 1998 915 [RFC3562] Leech, M., "Key Management Considerations for the TCP 916 MD5 Signature Option", RFC 3562, July 2003. 918 [RFC4270] Hoffman, P. and B. Schneier, "Attacks on Cryptographic 919 Hashes in Internet Protocols", RFC 4270, November 2005. 921 [RFC4306] Kaufman, C., "The Internet Key Exchange (IKEv2) 922 Protocol", RFC 4306, December 2005. 924 [RFC5709] Bhatia, M. et. al, "OSPFv2 HMAC-SHA Cryptographic 925 Authentication", RFC 5709, October 2009. 927 [RFC5880] Katz, D. and D. Ward, "Bidirectional Forwarding 928 Detection", RFC 5880, June 2010 930 [RFC5881] Katz, D. and D. Ward, "Bidirectional Forwarding 931 Detection (BFD) for IPv4 and IPv6 (Single Hop), RFC 5881, 932 June 2010 934 [RFC5883] Katz, D. and D. Ward, "Bidirectional Forwarding Detection 935 (BFD) for Multihop Paths", RFC 5883, June 2010 937 [RFC5925] Touch, J. et. al., "The TCP Authentication Option", 938 RFC 5925, June 2010 940 [RR07] Rechberger, C. and V. Rijmen, "On Authentication with 941 HMAC and Non-random Properties", Financial Cryptography 942 and Data Security, Lecture Notes in Computer Science, 943 Volume 4886/2008, Springer-Verlag, Berlin, December 944 2007. 946 [RR08] Rechberger, C. and V. Rijmen, "New Results on NMAC/HMAC 947 when Instantiated with Popular Hash Functions", Journal 948 of Universal Computer Science, Volume 14, Number 3, pp. 949 347-376, 1 February 2008. 951 [TCP-WINDOW] Watson, T., "TCP Reset Spoofing", October 2003. 953 [Wang04] Wang, X., et alia, "Collisions for Hash Functions MD4, 954 MD5, HAVAL-128, and RIPEMD", August 2004, IACR, 955 http://eprint.iacr.org/2004/199 957 [Wang05] Wang, X., et alia, "Finding Collisions in the Full SHA- 958 1" Proceedings of Crypto 2005, Lecture Notes in Computer 959 Science, Volume 3621, pp. 17-36, Springer-Verlag, 960 Berlin, August 31, 2005. 962 Contributor's Address 964 Sue Hares 965 NextHop 966 USA 967 Email: shares@nexthop.com 969 Author's Addresses 971 Vishwas Manral 972 IP Infusion 973 Almora, Uttarakhand 974 India 975 Email: vishwas@ipinfusion.com 977 Manav Bhatia 978 Alcatel-Lucent 979 Bangalore 980 India 981 Email: manav.bhatia@alcatel-lucent.com 983 Joel P. Jaeggli 984 Check Point Software 985 Email: jjaeggli@checkpoint.com 987 Russ White 988 Cisco Systems 989 RTP North Carolina 990 USA 991 Email: riw@cisco.com