RFC 6039

Issues with Existing Cryptographic Protection Methods for Routing Protocols

📅 published October 2010, from ietf

RFC 6039: Issues with Existing Cryptographic Protection Methods for Routing Protocols 🎀 (Part 1 of 5)

okay bestie, so this one is an Informational RFC from October 2010 🍓 It was written by Vishwas Manral (IP Infusion), Manoj Bhatia (Alcatel-Lucent), Jeffrey Jaeggli (Nokia Inc.), and Russ White (Cisco Systems). It's published as ISSN 2070-1721 ✨ The title block doesn't list any RFC that it obsoletes or updates, so it just stands on its own 💅

Abstract

Routing protocols have gotten extended over time to use cryptographic mechanisms so that data coming from a neighboring router hasn't been messed with in transit, and so you know it really came from an authorized neighboring router 🔐

The crypto mechanisms defined so far, and the ones this doc talks about, all rely on a digest made by running a hash algorithm over the payload inside the routing protocol packet 🧚

This document goes over some limitations of the current mechanism, the problems with manual keying of these crypto algorithms, and some possible ways someone could exploit those limitations 💀

Status of This Memo

This document is not an Internet Standards Track specification. It's published for informational purposes 📖

It's a product of the Internet Engineering Task Force (IETF) and represents the consensus of the IETF community. It went through public review and got approved for publication by the Internet Engineering Steering Group (IESG). Not every document the IESG approves is a candidate for any level of Internet Standard, so check Section 2 of RFC 5741 for that 🌸

For info about this document's current status, any errata, and how to give feedback, go to http://www.rfc-editor.org/info/rfc6039 🔗

Copyright (c) 2010 IETF Trust and the persons identified as the document authors. All rights reserved 💜

This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info), as in effect on the date this document was published. Please read these carefully, because they spell out your rights and restrictions for this document 📜 Code Components pulled out of this document must include Simplified BSD License text, as described in Section 4.e of the Trust Legal Provisions, and they come without warranty, as the Simplified BSD License describes 🫶

Table of Contents

   1. Problem Statement ...............................................3
      1.1. Pre-Image vs. Collision Attacks ............................4
      1.2. Concerns about MD5 and the SHA-1 Algorithm .................4
   2. Open Shortest Path First Version 2 (OSPFv2) .....................5
      2.1. Management Issues with OSPFv2 ..............................5
      2.2. Technical Issues with OSPFv2 ...............................6
   3. Open Shortest Path First Version 3 (OSPFv3) .....................7
      3.1. Management Issues with OSPFv3 ..............................7
      3.2. Technical Issues with OSPFv3 ...............................8
   4. Intermediate System to Intermediate System Routing
      Protocol (IS-IS) ................................................9
      4.1. Management Issues with IS-IS ...............................9
      4.2. Technical Issues with IS-IS ...............................10
   5. Border Gateway Protocol (BGP-4) ................................11
      5.1. Management Issues with BGP-4 ..............................12
      5.2. Technical Issues with BGP-4 ...............................13
   6. The Routing Information Protocol (RIP) .........................13
      6.1. Technical Issues with RIP .................................14
   7. Bidirectional Forwarding Detection (BFD) .......................15
      7.1. Technical Issues with BFD .................................15
   8. Security Considerations ........................................17
   9. Acknowledgements ...............................................17
   10. References ....................................................17
      10.1. Normative References .....................................17
      10.2. Informative References ...................................18
   11. Contributor's Address .........................................21

1. Problem Statement ✨

okay so protocols like OSPF version 2 [RFC2328], OSPF version 3 [RFC5340], IS-IS [RFC1195], BGP-4 [RFC4271], and BFD [RFC5880] all have ways to make a cryptographic digest of every protocol packet they send 🦋 Usually the digest is the output of a one-way hash algorithm, like Message Digest 5 (MD5) [RFC1321], run over the packet contents. A secret key gets used as the hash base (or seed) 🔑 The receiving router then recomputes the digest using the same key the original router used, and compares it to the digest that came in, to check two things:

  • That the router that sent this packet is authorized, via the shared key, to peer with the local router and swap routing data 👑 The whole point of trusting a routing exchange protected by a shared secret is to keep falsely generated routing data from being injected into the routing system by unauthorized systems 🚫
  • That the data wasn't changed in transit between the two neighboring routers 🧐

Digest verification isn't meant to protect the confidentiality of what routers exchange 🙈 The information (entries in the routing table) can be reached through other mechanisms anyway. Plus, anyone with access to the physical media between two routers that swap routing data can capture or otherwise find out what's in those routing tables 👀

The authentication mechanisms available today have some notable limitations, though:

  • Configuring shared secret keys by hand, especially in large networks and between networks, is a major management headache 😭 In lots of cases, it's hard to replace keys without a ton of coordination or disruption.
  • Sometimes, when keys are configured manually, some forms of replay protection stop being possible. That lets someone attack the routing protocol by replaying captured routing messages 🎭

This document outlines some of the problems with manual keying of these cryptographic algorithms 🎀

1.1. Pre-Image vs. Collision Attacks

A pre-image attack is an attempt to find new data with the same hash value, so someone could find an input message that makes a hash function produce a particular output 🔍 A collision attack is different: it finds two messages with the same hash, but the attacker can't pick what those messages will be 🤷‍♀️ Feasible collision attacks against MD4, MD5, HAVAL-128, and RIPEMD have been documented in [Crypto2004] 📚

Collisions don't currently lead to any obvious or known attacks on routing protocols 🙌 Pre-image attacks could cause problems in the future, but because of the message length, there are serious limits on whether such an attack is actually feasible 💅

Protocols already have some built-in protection against collision attacks, and that's because a lot of values for fields in a protocol packet are invalid or would produce an unusable packet 🛡️ For example, in OSPF the Link State Advertisement (LSA) type can only be from 1 to 11. Any other value in that field gets the packet discarded 🗑️

Say two packets, M and M', are generated and have the same hash. The condition above makes it even harder to craft a message that's also a correct message from the protocol's point of view, since so many potential values aren't valid in the first place 🧩

1.2. Concerns about MD5 and the SHA-1 Algorithm

There are published concerns about the overall strength of the MD5 algorithm ([Dobb96a], [Dobb96b], [Wang04]) 😬 Those concerns are about MD5 in other modes (e.g., MD5 in X.509v3/PKIX digital certificates), and they aren't an attack on Keyed MD5 or on Hash-based Message Authentication Code MD5 (HMAC-MD5), which is what the current routing protocols specify 🙂 There are also published concerns about the Secure Hash Algorithm (SHA) ([Wang05], [Philip01], [Prav01], [Prav02], [Arjen05]), and about MD5 and SHA in the HMAC [RFC2104] mode ([RR07], [RR08]) 🌈

Here's the tea ☕ The National Institute of Standards and Technology (NIST) will keep supporting HMAC-SHA-1 even after 2010 [NISTHmacSHA], but it's going to drop support for SHA-1 in digital signatures. NIST also recommends that application and protocol designers move to the SHA-2 family of hash functions (i.e., SHA-224, SHA-256, SHA-384 and SHA-512) for all new applications and protocols 🔥

Still, like we said above, these attacks aren't currently applicable to the routing protocols 💖 Separately, some organizations (e.g., the US government) prefer NIST algorithms, such as the SHA family, over other algorithms like MD5 for local policy reasons 🏛️

2. Open Shortest Path First Version 2 (OSPFv2) 🌸

OSPF [RFC2328] describes using an MD5 digest with OSPF packets. MD5 keys are configured manually 🛠️ The OSPF packet header has an authentication type field, plus 64 bits of data for whatever the matching authentication scheme needs. OSPF also includes a non-decreasing sequence number in each OSPF protocol packet to protect against replay attacks 🔁

"OSPF with Digital Signatures" [RFC2154] is an Experimental RFC that describes extensions to OSPF for digitally signing its Link State Advertisements (LSAs) ✍️ The belief is that if you need stronger authentication and security, then OSPF (and the other routing protocols) has to move to full digital signatures 💪 That would allow precise authentication of the OSPF router that originated each link-state advertisement, which means much stronger integrity protection for the OSPF routing domain 🏰 However, since there have been no deployments, there's precious little operational experience with this spec, so this document doesn't cover it 🙈

2.1. Management Issues with OSPFv2 🎀

According to the OSPF specification [RFC2328], digests are applied to packets sent between adjacent neighbors, not to the routing information a router originates. Digests aren't applied at the LSA level; they're applied at the packet level 📦 [RFC2328] says that any set of OSPF routers adjacent across a single link may use a different key to build MD5 digests than the key used for MD5 digests on any other link. So MD5 keys can be configured, and changed, on a per-link basis in an OSPF network 🧶

OSPF doesn't specify a mechanism to negotiate keys, and it doesn't specify any mechanism to negotiate the hash algorithms to be used 🙅‍♀️

With all the hash algorithms floating around, plus the constant need to upgrade them, configuring the information by hand gets really tedious 😩 It's also worth noting that rekeying OSPF requires coordination among the adjacent routers 🫶

✨ That's the end of part 1 ✨

2.2. Technical Issues with OSPFv2

Okay so OSPF is actually pretty strong 💪 because it uses MD5 digests plus extra data and sequence numbers in its packets... but there are still attacks against it 😭 Let's dig in, bestie 🫶

  • The sequence number is initialized to zero when forming an adjacency with a newly discovered neighbor. When an adjacency is brought down, the sequence number is also set to zero. If the cryptographically protected packets of a router that is brought down (for administrative or other reasons) are replayed by a malicious router, traffic could be forced through the malicious router. A malicious router might then induce routing loops, or intercept or blackhole the traffic 💀
  • OSPF allows multiple packets with the same sequence number 🙈 This means it's possible to replay the same packet many times before the next legitimate packet is sent. An attacker may resend the same packet repeatedly until the next Hello packet is transmitted and received. The Hello interval, which is unknown, determines the attack window.
  • OSPF does not require the use of any particular hash algorithm 🤔 however, only the use of MD5 digests for authentication and replay protection is specified in RFC 2328. Most OSPF implementations only support MD5 in addition to Null and Simple Password authentication.

Recently, limitations in the collision-resistance properties of the MD5 and SHA-1 hash functions have been discovered, and [RFC4270] summarizes those discoveries 👀 There have been attacks against the use of MD5 as a hash. While these attacks do not directly apply to the use of MD5 in routing protocols, it is prudent to have other options available. For this reason, the general use of these algorithms should be discouraged, and [RFC5709] adds support for using SHA-1 and SHA-2 with the HMAC construct for OSPF ✨

  • OSPF on a broadcast network shares the same key between all neighbors on that broadcast network, and some OSPF packets are sent to a multicast address.

Spoofing by any malicious neighbor possessing credentials or replayable packets is therefore very easy 😩 Possession of the key itself is used as an identity validation, and no other identity check is used. A malicious neighbor could send a packet, forging the identity of the sender as being from another neighbor. There would be no way in which the victim could distinguish the identity of the packet sender. Not me being unable to tell who's texting me 🙃

  • In some OSPF implementations, neighbors on broadcast, non-broadcast multi-access (NBMA), and point-to-multipoint networks are identified by the IP address in the IP header. The IP header is not covered by the MAC in the cryptographic authentication scheme as described in RFC 2328, and an attack can be made to exploit this omission 🦋

Assume the following scenario. R1 sends an authenticated HELLO to R2. This HELLO is captured and replayed back to R1. The source IP in the IP header of the replayed packet is changed to that of R2.

R1, not finding itself in the HELLO, would deduce that the connection is not bidirectional and would bring down the adjacency. Plot twist, and not a good one 😭

3. Open Shortest Path First Version 3 (OSPFv3)

OSPFv3 [RFC5340] relies on the IP Authentication Header (AH) [RFC4302] and the IP Encapsulating Security Payload (ESP) [RFC4303] to cryptographically sign routing information passed between routers 🔐

When using ESP, the null encryption algorithm [RFC2410] is used, so the data carried in the OSPFv3 packets is signed, but not encrypted. This provides data origin authentication for adjacent routers, and data integrity (which gives the assurance that the data transmitted by a router has not changed in transit). However, it does not provide confidentiality of the information transmitted. This is acceptable because the privacy of the information being carried in the routing protocols need not be kept secret 🤷‍♀️

"Authentication/Confidentiality for OSPFv3" [RFC4552] mandates the use of ESP with null encryption for authentication, and it also does encourage the use of confidentiality to protect the privacy of the routing information transmitted, using ESP encryption. However, it only specifies the use of manual keying of routing information, as discussed in the following section 🎀

3.1. Management Issues with OSPFv3

The OSPFv3 security document ("Authentication/Confidentiality for OSPFv3" [RFC4552]) discusses, at length, the reasoning behind using manually configured keys, rather than some automated key management protocol such as IKEv2 [RFC4306]. The primary problem is the lack of a suitable key management mechanism, as OSPF adjacencies are formed on a one-to-many basis and most key management mechanisms are designed for a one-to-one communication model. This forces the system administrator to use manually configured security associations (SAs) and cryptographic keys to provide the authentication and, if desired, confidentiality services 🧑‍💻

Regarding replay protection, [RFC4552] states that:

Since it is not possible using the current standards to provide complete replay protection while using manual keying, the proposed solution will not provide protection against replay attacks.

In the OSPFv3 case, the primary administrative issue with manually configured SAs and keys is the management issue: maintaining shared sets of keys on all routers within a network. As with OSPFv2, rekeying is an infrequent event requiring coordination. [RFC4552] does not require that all OSPFv3 routers have the same key configured for every neighbor, so each set of neighbors connected to a given link could have a different key configured. While this makes it easier to change the keys (by forcing the system administrator to only change the keys on the routers on a single link), the process of manual configuration for all the routers in a network to change the keys used for OSPFv3 digests and confidentiality on a periodic basis can be difficult 😮‍💨

3.2. Technical Issues with OSPFv3

The primary technical concern with the current specifications for OSPFv3 is that when manual SA and key management is used, as specified in "Sequence Number Generation", Section 3.3.2 of [RFC4302]: "The sender assumes anti-replay is enabled as a default, unless otherwise notified by the receiver (see Section 3.4.3) or if the SA was configured using manual key management". Replaying OSPFv3 packets can induce several failures in a network, including:

  • Replaying Hello packets with an empty neighbor list can cause all the neighbor adjacencies with the sending router to be reset, disrupting network communications.
  • Replaying Hello packets from early in the designated router election process on broadcast links can cause all the neighbor adjacencies with the sending router to be reset, disrupting network communications.
  • Replaying database description (DB-Description) packets can cause all FULL neighbor adjacencies with the sending router to be reset, disrupting network communications.
  • Replaying link state request (LS-Request) packets can cause all FULL neighbor adjacencies with the sending router to be reset, disrupting network communications.
  • Capturing a full adjacency process (from two-way all the way to FULL state), and then replaying this process when the router is no longer attached, can cause a false adjacency to be formed, allowing an attacker to attract traffic 🪤
  • OSPFv3 on a broadcast network shares the same key between all neighbors on that network, and some OSPF packets are sent to a multicast address.

Spoofing by a malicious neighbor is very easy. Possession of the key itself is used as an identity check, and there is no other identity check used. A neighbor could send a packet specifying the packet came from some other neighbor, and there would be no way in which the attacked router could figure out the identity of the packet sender 🥲

4. Intermediate System to Intermediate System Routing Protocol (IS-IS)

Integrated IS-IS [RFC1195] uses HMAC-MD5 authentication with manual keying, as described in [RFC5304], and has recently been extended to provide support for using the HMAC construct along with the SHA family of cryptographic hash functions [RFC5310]. There is no provision within IS-IS to encrypt the body of a routing protocol message 🙅‍♀️

4.1. Management Issues with IS-IS

[RFC5304] states that each Link State Protocol Data Unit (LSP) generated by an intermediate system is signed with the HMAC-MD5 algorithm using a key manually defined by the network administrator. Since authentication is performed on the LSPs transmitted by an intermediate system, rather than on the packets transmitted to a specific neighbor, it is implied that all the intermediate systems within a single flooding domain must be configured with the same key in order for authentication to work correctly 🔑

The initial configuration of manual keys for authentication within an IS-IS network is simplified by a state where LSPs containing HMAC-MD5/HMAC-SHA authentication TLVs are accepted by intermediate systems without the keys, but the digest is not validated. Once keys are configured on all routers, changing those keys becomes much more difficult 😩

IS-IS [RFC1195] does not specify a mechanism to negotiate keys, nor does it specify any mechanism to negotiate the hash algorithms to be used 🙃

With the proliferation of available hash algorithms, as well as the need to upgrade the algorithms, manual configuration requires coordination among intermediate systems, which can become tedious 💅

4.2. Technical Issues with IS-IS ✨

Okay so [RFC5304] says: "This mechanism does not prevent replay attacks; however, in most cases, such attacks would trigger existing mechanisms in the IS-IS protocol that would effectively reject old information". Lowkey iconic, because the existing IS-IS mechanisms handle most replays on their own 💅

There are a few cases where those existing mechanisms would NOT effectively reject old information, though 🙈 Those are:

  • the Hello packets or the IS-IS Hellos (IIHs) that are used to discover neighbors, and
  • the Sequence Number Packets (SNPs).

As [RFC1195] describes, every Hello an intermediate system sends includes a list of known neighbors. That's how it makes sure there's two-way communication with a specific neighbor before exchanging link state databases 🫶

IS-IS doesn't give you a sequence number, bestie 😭 So IS-IS packets can be replayed, and any packet can be replayed at any point of time. As long as the keys are the same, protocol elements that wouldn't be rejected will still affect existing sessions. Not me replaying a whole session 💀

A Hello packet that has a digest inside a TLV and an empty neighbor list could get replayed, and that would restart all the adjacencies with the original transmitting intermediate system. Chaos 🌪️

A replay of an old Complete Sequence Number Packet (CSNP) could make LSPs get flooded, which causes an LSP storm. Absolutely unhinged ⚡

IS-IS specifies the use of HMAC-MD5 and HMAC-SHA-1 to protect IS-IS packets 🎀

IS-IS doesn't have a notion of Key ID. So during a key rollover, every message that comes in has to be checked for integrity against all of the keys that are valid. A denial-of-service (DoS) attack can happen when someone sends IS-IS packets with random hashes. That forces the packet to be checked for authentication against every possible key, which means way more processing. This issue has been fixed in the recent [RFC5310], which introduces Key IDs into IS-IS, so we're good now 🦋

Recently, limitations in the collision-resistance properties of the MD5 and SHA-1 hash functions were discovered, and [RFC4270] sums up those discoveries. There have been attacks against using MD5 as a hash. These attacks don't directly apply to HMAC-MD5 in IS-IS, but it's prudent to have other options available. For this reason, the general use of these algorithms should be discouraged, and [RFC5310] adds support for using HMAC-SHA with IS-IS 🌈

IS-IS on a broadcast network shares the same key between all neighbors on that network.

This makes spoofing by a malicious neighbor easy, because IS-IS packets are sent to a link-layer multicast address. Possessing the key is itself used as the authorization check. A neighbor could send a packet spoofing the identity of another neighbor, and the attacked router would have no way to tell who the malicious sender really is. > Not a fun situation, babe 😭

The Remaining Lifetime field in the LSP is not covered by the authentication. An IS-IS router can receive its own self-generated LSP segment with zero lifetime remaining. If it has a copy with a non-zero lifetime, it purges that LSP, i.e., it increments the current sequence number and floods all the segments again. This is much worse in IS-IS than in OSPF, because there is only one LSP other than the pseudonode LSPs for the LANs on which the IS-IS router is the Designated Intermediate System (DIS) 🥲

So an attacker can force the router to flood all segments -- which could be a huge number if the routing table is large. It also makes the sequence number of all the LSPs climb super fast. If the sequence number hits the maximum (0xFFFFFFFF), the IS-IS process has to shut down for around 20 minutes (the product of MaxAge + ZeroAgeLifetime) so the old LSPs can age out of all the router databases. That's a whole outage, no cap 😭💔

5. Border Gateway Protocol (BGP-4) 🌸

BGP-4 [RFC4271] uses TCP [RFC0793] to transport routing information between BGP speakers that have formed an adjacency.

[RFC2385] describes the TCP MD5 digest option, which gives BGP packets origin authentication and data integrity protection. [RFC3562] has suggestions for choosing the key length of the ad hoc Keyed MD5 mechanism specified in [RFC2385]. There's no provision for confidentiality for any of these BGP messages, so anyone can read them 👀

TCP MD5 [RFC2385] has recently been obsoleted by the new TCP Authentication Option (TCP-AO) [RFC5925]. [RFC5925] specifies the use of stronger Message Authentication Codes (MACs), protects against replays even for long-lived TCP connections, and gives more detail than TCP-MD5 on how security is associated with TCP connections. It allows rekeying during a TCP connection, assuming an out-of-band protocol or a manual mechanism provides the new keys. TCP MD5 doesn't preclude rekeying during a connection, but it doesn't require support for it either. TCP-AO also supports key changes with zero segment loss. Key changes in TCP MD5 can lose segments in transit during the changeover, or force you to try multiple keys on each received segment during the overlap, because TCP MD5 lacks an explicit Key ID. TCP does recover lost segments through retransmission, but loss can still hit performance hard 📉

However, this document only covers TCP MD5, because all current deployments are still using BGP with TCP MD5 and haven't upgraded to [RFC5925]. There isn't enough operational experience yet to evaluate the technical and management issues with this proposal 🧐

Compared to the IGP protocols we covered earlier, BGP has extra exposure because of where it's typically used: between autonomous networks under different administrative control. Routers running interior gateway protocols can all be configured under the same administrative authority, but two BGP peers may be in different administrative domains with different policies for key strength, rollover frequency, and so on. An autonomous system often has to support a large number of keys at different BGP boundaries, since each connecting AS is a different administrative entity. In practice, once set, shared secrets between BGP peers are rarely, if ever, changed 🫠

5.1. Management Issues with BGP-4 🎀

Each pair of BGP speakers forming a peering may have a different MD5 shared key. That lets keys be configured and changed independently across a large-scale network. Still, manually configuring and maintaining cryptographic keys across all BGP sessions is a real challenge in any large-scale environment 😤

Most BGP implementations will accept BGP packets with a bad digest up to the hold interval negotiated between BGP peers at peering startup. The reason is to let MD5 keys be changed with minimal impact on network operation. This technique does, however, leave a short window in which an attacker may inject BGP packets with false MD5 digests into the network and expect those packets to be accepted, even though the digests aren't valid. Yikes 💀

5.2. Technical Issues with BGP-4 🔥

BGP relies on TCP [RFC0793] to transport data between BGP speakers. BGP can count on TCP's protection against data corruption and replay to block replay attacks against BGP sessions. A lot of research has gone into whether an attacker could get past those protections, including [TcpWindow] and [Conv01]. Most router and operating system (OS) vendors have modified their TCP implementations to fix the vulnerabilities described in these references, where possible 🛠️

As mentioned earlier, MD5 is vulnerable to collision attacks and can be attacked through several means, such as those explored in [Wang04].

Sure, it can be argued that collision attacks don't have a practical application in this scenario, but the use of MD5 should be discouraged anyway 🙅‍♀️

Routers that do cryptographic processing of packets in software may be exposed to extra opportunities for DoS attacks. An attacker may be able to send enough spoofed traffic with false digests that the router's processor and memory resources get used up, leaving the router unable to do normal processing. This exposure is especially problematic between routers that aren't under unified administrative control 😩

6. The Routing Information Protocol (RIP) 🧚

The initial version of RIP was specified in STD 34 [RFC1058]. That version didn't provide any authentication or authorization of routing data, so it was vulnerable to any number of attacks against routing protocols. This limitation was one reason the protocol was moved to Historic status [RFC1923] 🥀

RIPv2 was originally specified in [RFC1388], then [RFC1723], and was finalized in STD 56 [RFC2453]. This version provides for authenticating packets with a digest. The details were first given in "RIP-2 MD5 Authentication" [RFC2082]. "RIPv2 Cryptographic Authentication" [RFC4822] obsoletes [RFC2082] and adds details on how the SHA family of hash algorithms can be used to protect RIPv2. [RFC2082] only specified the use of Keyed MD5 🌷

6.1. Technical Issues with RIP ✨

  • okay so the sequence number a router uses starts at zero when it boots up, and it gets reset to zero again whenever the neighbor goes down 😭 if a malicious router stores the cryptographically protected packets from a router that got shut down (for admin reasons or whatever), it can replay them later when the new router comes up. that means traffic gets forced through the bad router 💀 dropping those packets can cause blackholes, and forwarding the wrong ones can cause routing loops 🌀
  • RIPv2 lets multiple packets share the same sequence number 🙈 so one packet could get replayed a bunch of times before the next legit one shows up. an attacker can keep resending it until the next Hello packet gets sent and received, so the Hello interval basically decides how big the attack window is ⏳
  • RIPv2 [RFC2453] didn't specify any particular hash algorithm 🫠 then [RFC4822] came in and made HMAC-SHA1 mandatory to implement, along with Keyed MD5 as specified in [RFC2082]. Keyed MD5 was kept in the mix so it stays compatible with legacy implementations 🫶
  • "RIPv2 Cryptographic Authentication" [RFC4822] doesn't cover the UDP and IP headers, which is lowkey wild 👀 so an attacker can change some fields in those headers and the routers won't notice.

The UDP header exposure is pretty limited, since RIP only uses it to work out the length of the RIP packet. If the UDP header gets changed, RIP authentication fails, so that limits the damage 🛡️

RIP uses the source IP address from the IP header to figure out which RIP neighbor it learned the Update from. An attacker can change the source IP address to mess with the RIP routing session between two routers, R1 and R2. Here's how that goes:

Scenario 1:

R1 sends an authenticated RIP message to R2 with a cryptographic sequence number X.

The attacker then needs a packet with a higher sequence number that R2 originated, either from this session or from an earlier one.

The attacker can then replay that packet to R2 with the source IP changed to R1's.

R2 would then stop accepting any RIP Updates from R1, since those would have a lower cryptographic sequence number. After 180 seconds (or less), R2 would consider R1 timed out and bring down the RIP session 😩

Scenario 2:

R1 announces a route with cost C1 to R2. This packet can be captured by an attacker. Later, if the cost changes and R1 announces it with a different cost C2, the attacker can replay the captured packet with the source IP changed to a new arbitrary IP address, pretending to be a different router 🎭

R2 would accept this route and the router as a new gateway, and R2 would then use the non-existent router as a next hop for that network. This only works if cost C1 is less than cost C2 🙃

7. Bidirectional Forwarding Detection (BFD) 🦋

BFD is specified in [RFC5880]. Extensions to BFD for multihop [RFC5883] and single hop [RFC5881] are defined for IPv4 and IPv6. BFD is built to detect failures with the forwarding plane next hop 🔍

The BFD base spec has an optional authentication mechanism, which lets the receiver of a packet check who the source is. It depends on the peers sharing keys, and no mechanism is defined for actually generating those keys 🔑

7.1. Technical Issues with BFD 💅

  • the level of security depends on the Authentication Type being used, and the authentication algorithms defined are MD5 or SHA-1 based 😬 as mentioned earlier, MD5 and SHA-1 are both known to be vulnerable to collision attacks.
  • the BFD spec has mechanisms that let the authentication state change based on the state of a received packet 🔄 that can cause a denial-of-service attack, where a malicious authenticated packet stored from a past session gets relayed over a session that doesn't use authentication. One end then thinks authentication is enabled on the other end, so the BFD adjacency gets dropped. This is a much harder attack to pull off when meticulously keyed authentication is in use 🔐
  • BFD works on microsecond timers ⏱️ when malicious packets get sent at short intervals with the authentication bit set, it can cause a DoS attack.
  • BFD allows a mode called the echo mode 🪞 Echo packets aren't defined in the BFD spec, but they can keep the BFD session up. There are no guidelines on the properties of echo packets beyond choosing the source and destination addresses. The BFD spec recommends applying security mechanisms to prevent spoofing of these packets, but there are no guidelines on which mechanisms are appropriate.

Any security issues in echo mode will directly affect the BFD protocol and session states, and so the network stability too 😭 As far as we understand today, the potential effects and remedies are somewhat limited, though. For instance, any replay attacks would look exactly like normal forwarding from the tested router. An attack would still make a faulty link look like it's up, but there's not much that can be done about that. However, if the echo packets are guessable, it may be possible to spoof them from an external source and make BFD think a one-way link is actually bidirectional 🙀 So it's important that the echo packets contain random material that also gets checked on reception 🎲

  • BFD packets can be sent at millisecond intervals (the protocol uses timers at microsecond intervals) 🏃‍♀️ when authentication is in use, this can cause frequent sequence number wrap-around, since a 32-bit sequence number is used. That considerably reduces the security of the authentication algorithms 📉
  • limitations in the collision-resistance properties of the MD5 and SHA-1 hash functions have been discovered recently, and [RFC4270] summarizes those discoveries 📚 there have been attacks against the use of MD5 as a hash. These attacks don't directly apply to HMAC-MD5 and keyed SHA-1 in BFD, but it's prudent to have other options available 🙌 Attacks like these don't mean BFD using SHA-1 for authentication is at risk. However, it does mean SHA-1 should be replaced as soon as possible and should not be used for new applications 🚫

It's worth noting that if SHA-1 is used in the Hashed Message Authentication Code (HMAC) [RFC2104] construction, the collision attacks currently known against SHA-1 don't apply. The new attacks on SHA-1 have no impact on the security of HMAC-SHA-1 💖

There are already proposals [GenBFDAuth] that add support for HMAC with the SHA-1 and SHA-2 families of hash functions for BFD 🎀

8. Security Considerations 🔐

This document outlines security issues that come from the current methodology for manual keying of various routing protocols 🗝️ No specific changes to routing protocols are proposed here, and no new security requirements result from it.

This section is serious business, bestie. The manual keying problems above are the real deal, so take them seriously when you're deploying anything 🚨

9. Acknowledgements 🫶

We'd like to thank Sam Hartman, Ran Atkinson, Stephen Kent, and Brian Weis for their initial comments on this document 💜 Huge thanks to Merike Kaeo and Alfred Hoenes for reviewing many sections of the document and giving a lot of useful comments 🌸

10. References 📚

10.1. Normative References

[RFC0793]       Postel, J., "Transmission Control Protocol", STD 7,
                RFC 793, September 1981.

[RFC1195]       Callon, R., "Use of OSI IS-IS for routing in TCP/IP
                and dual environments", RFC 1195, December 1990.

[RFC2328]       Moy, J., "OSPF Version 2", STD 54, RFC 2328, April
                1998.

[RFC2385]       Heffernan, A., "Protection of BGP Sessions via the
                TCP MD5 Signature Option", RFC 2385, August 1998.

[RFC2453]       Malkin, G., "RIP Version 2", STD 56, RFC 2453,
                November 1998.

[RFC4271]       Rekhter, Y., Ed., Li, T., Ed., and S. Hares, Ed., "A
                Border Gateway Protocol 4 (BGP-4)", RFC 4271, January
                2006.

[RFC4302]       Kent, S., "IP Authentication Header", RFC 4302,
                December 2005.  Kent, S., "IP Authentication Header",

[RFC4303]       Kent, S., "IP Encapsulating Security Payload (ESP)",
                RFC 4303, December 2005.

[RFC4552]       Gupta, M. and N. Melam,
                "Authentication/Confidentiality for OSPFv3", RFC
                4552, June 2006.

[RFC4822]       Atkinson, R. and M. Fanto, "RIPv2 Cryptographic
                Authentication", RFC 4822, February 2007.

[RFC5340]       Coltun, R., Ferguson, D., Moy, J., and A. Lindem,
                "OSPF for IPv6", RFC 5340, July 2008.

[RFC5304]       Li, T. and R. Atkinson, "IS-IS Cryptographic
                Authentication", RFC 5304, October 2008.

[RFC5310]       Bhatia, M., Manral, V., Li, T., Atkinson, R., White,
                R., and M. Fanto, "IS-IS Generic Cryptographic
                Authentication", RFC 5310, February 2009.

10.2. Informative References 📚✨

bestie, these are the deeper-dive sources 🤓💜 Go read them if you're obsessed like me.

  • [Arjen05] Arjen K. Lenstra, "Further progress in Hashing cryptanalysis", Lucent Bell Laboratories, February 26, 2005.
  • [Conv01] Convery, et al., "BGP Vulnerability Testing: Separating Fact from FUD v1.00", NANOG 28, pp. 1-61, June 2003.
  • [Crypto2004] Xiaoyun Wang, Xuejia Lai, Dengguo Feng, and Hongbo Yu, "Collisions for hash functions MD4, MD5, HAVAL-128, and RIPEMD", Crypto 2004 Rump Session.
  • [Dobb96a] Dobbertin, H., "Cryptanalysis of MD5 Compress", Technical Report, 2 May 1996. (Presented at the Rump Session of EuroCrypt 1996.)
  • [Dobb96b] Dobbertin, H., "The Status of MD5 After a Recent Attack", CryptoBytes, Vol. 2, No. 2, Summer 1996.
  • [GenBFDAuth] Bhatia, M. and V. Manral, "BFD Generic Cryptographic Authentication", Work in Progress, June 2010.
  • [NISTHmacSHA] "NIST's Policy on Hash Functions", 2006, http://csrc.nist.gov/groups/ST/hash/policy.html.
  • [Philip01] Philip Hawkes, Michael Paddon, and Gregory G. Rose, "On Corrective Patterns for the SHA-2 Family", IACR ePrint Archive, 2004, http://eprint.iacr.org/2004/207.
  • [Prav01] Praveen Gauravaram, et al., "Collision Attacks on MD5 and SHA-1: Is this the 'Sword of Domocles' for Electronic Commerce?", Information Security Institue (ISI), Queensland University of Technology (QUT), Australia.
  • [Prav02] Praveen Gauravaram, et al., "Some thoughts on Collision Attacks in the Hash Functions Md5, SHA-0 and SHA-1", Information Security Institue (ISI), Queensland University of Technology (QUT), Australia.
  • [RFC1058] Hedrick, C., "Routing Information Protocol", RFC 1058, June 1988.
  • [RFC1321] Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321, April 1992.
  • [RFC1388] Malkin, G., "RIP Version 2 Carrying Additional Information", RFC 1388, January 1993.
  • [RFC1723] Malkin, G., "RIP Version 2 - Carrying Additional Information", RFC 1723, November 1994.
  • [RFC1923] Halpern, J. and S. Bradner, "RIPv1 Applicability Statement for Historic Status", RFC 1923, March 1996.
  • [RFC2082] Baker, F. and R. Atkinson, "RIP-2 MD5 Authentication", RFC 2082, January 1997.
  • [RFC2104] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed-Hashing for Message Authentication", RFC 2104, February 1997.
  • [RFC2154] Murphy, S., Badger, M., and B. Wellington, "OSPF with Digital Signatures", RFC 2154, June 1997.
  • [RFC2410] Glenn, R. and S. Kent, "The NULL Encryption Algorithm and Its Use With IPsec", RFC 2410, November 1998.
  • [RFC3562] Leech, M., "Key Management Considerations for the TCP MD5 Signature Option", RFC 3562, July 2003.
  • [RFC4270] Hoffman, P. and B. Schneier, "Attacks on Cryptographic Hashes in Internet Protocols", RFC 4270, November 2005.
  • [RFC4306] Kaufman, C., Ed., "Internet Key Exchange (IKEv2) Protocol", RFC 4306, December 2005.
  • [RFC5709] Bhatia, M., Manral, V., Fanto, M., White, R., Barnes, M., Li, T., and R. Atkinson, "OSPFv2 HMAC-SHA Cryptographic Authentication", RFC 5709, October 2009.
  • [RFC5880] Katz, D. and D. Ward, "Bidirectional Forwarding Detection (BFD)", RFC 5880, June 2010.
  • [RFC5881] Katz, D. and D. Ward, "Bidirectional Forwarding Detection (BFD) for IPv4 and IPv6 (Single Hop)", RFC 5881, June 2010.
  • [RFC5883] Katz, D. and D. Ward, "Bidirectional Forwarding Detection (BFD) for Multihop Paths", RFC 5883, June 2010.
  • [RFC5925] Touch, J., Mankin, A., and R. Bonica, "The TCP Authentication Option", RFC 5925, June 2010.
  • [RR07] Rechberger, C. and V. Rijmen, "On Authentication with HMAC and Non-random Properties", Financial Cryptography and Data Security, Lecture Notes in Computer Science, Volume 4886/2008, Springer-Verlag, Berlin, December 2007.
  • [RR08] Rechberger, C. and V. Rijmen, "New Results on NMAC/HMAC when Instantiated with Popular Hash Functions", Journal of Universal Computer Science, Volume 14, Number 3, pp. 347-376, 1 February 2008.
  • [TcpWindow] Watson, P., "Slipping in the Window: TCP Reset attacks", Presentation at 2004 CanSecWest, http://cansecwest.com/csw04archive.html.
  • [Wang04] Wang, X., et al., "Collisions for Hash Functions MD4, MD5, HAVAL-128 and RIPEMD", August 2004, IACR ePrint Archive, http://eprint.iacr.org/2004/199.
  • [Wang05] Wang, X., et al., "Finding Collisions in the Full SHA-1", Proceedings of Crypto 2005, Lecture Notes in Computer Science, Volume 3621, pp. 17-36, Springer-Verlag, Berlin, August 31, 2005.

11. Contributor's Address 🫶

shoutout to the contributor 💅 Here's where to find her:

Sue Hares
NextHop
USA
EMail: shares@nexthop.com

Authors' Addresses 🦋

and here are the authors, the girlies who wrote the whole thing 👑🌈

Vishwas Manral
IP Infusion, Inc.
1188 E. Arques Ave.
Sunnyvale, CA  94085
EMail: vishwas@ipinfusion.com

Manav Bhatia
Alcatel-Lucent
Bangalore
India
EMail: manav.bhatia@alcatel-lucent.com

Joel P. Jaeggli
Nokia Inc.
EMail: joel.jaeggli@nokia.com

Russ White
Cisco Systems
RTP North Carolina
USA
EMail: riw@cisco.com
📦 where this page comes from