RFC 7492

RFC 7492: Analysis of Bidirectional Forwarding Detection (BFD) Security According to the Keying and Authentication for Routing Protocols (KARP) Design Guidelines 💖

okay so this one's from the IETF, published in March 2015 📅. It's Category: Informational (ISSN 2070-1721), so it's published for info, not as a standard. It was written by M. Bhatia (Ionos Networks), D. Zhang (Huawei), and M. Jethanandani (Ciena Corporation). It doesn't list anything it obsoletes or updates, so it's a standalone vibe 🫶

Abstract ✨

this doc analyzes the Bidirectional Forwarding Detection (BFD) protocol using the guidelines in Section 4.2 of RFC 6518, "Keying and Authentication for Routing Protocols (KARP) Design Guidelines" 🎀

Status of This Memo 📝

bestie, this is NOT an Internet Standards Track spec. It's published for informational purposes only 💅

it's a product of the IETF, so it reflects the consensus of the IETF community. It got public review and was approved for publication by the Internet Engineering Steering Group (IESG). Not every IESG-approved doc is a candidate for any level of Internet Standard, so check Section 2 of RFC 5741 for that 🤓

for the current status, errata, and how to send feedback, go to http://www.rfc-editor.org/info/rfc7492 🌸

Copyright Notice 🌈

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

this doc is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) as they stand on the publication date. Please actually read them, because they explain your rights and restrictions for this doc 🙈 Any Code Components pulled out of this doc must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions, and they come without warranty as described in the Simplified BSD License 🧚

Table of Contents 🍓

1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
2.  Requirements to Meet  . . . . . . . . . . . . . . . . . . . .   3
3.  Current State of Security Methods . . . . . . . . . . . . . .   3
4.  Impacts of BFD Replays  . . . . . . . . . . . . . . . . . . .   5
5.  Impact of New Authentication Requirements . . . . . . . . . .   6
6.  Considerations for Improvement  . . . . . . . . . . . . . . .   7
7.  Security Considerations . . . . . . . . . . . . . . . . . . .   7
8.  References  . . . . . . . . . . . . . . . . . . . . . . . . .   8
  8.1.  Normative References  . . . . . . . . . . . . . . . . . .   8
  8.2.  Informative References  . . . . . . . . . . . . . . . . .   8
Acknowledgements  . . . . . . . . . . . . . . . . . . . . . . . .   9
Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .   9

---

1. Introduction 💖

okay so this doc does a gap analysis of where Bidirectional Forwarding Detection [RFC5880] stands, measured against the KARP Design Guidelines [RFC6518]. The OPSEC working group already looked at the crypto issues with BFD in "Issues with Existing Cryptographic Protection Methods for Routing Protocols" [RFC6039], so this is the follow-up era 🎀

the existing BFD specs give you a basic security setup. There's a Key ID, so the key securing a packet can be swapped on demand 🔑 But the two algorithms for integrity protection of control packets, MD5 and SHA-1, have both been shown to be subject to collision attacks. Yikes 💀

routing protocols like "RIPv2 Cryptographic Authentication" [RFC4822], "IS-IS Generic Cryptographic Authentication" [RFC5310], and "OSPFv2 HMAC-SHA Cryptographic Authentication" [RFC5709] have started using BFD for liveliness checks 🦋 Here's the problem: if the routing protocols move to a stronger algorithm but BFD is still on a weaker one, an attacker can take down BFD and that takes down the routing protocol with it. So BFD needs to match the routing protocols in algorithm strength. No cap, that's the whole drama 😭

and while BFD uses a non-decreasing, per-packet sequence number to protect itself from intra-connection replay attacks, it's still open to inter-session replay attacks 🙈

2. Requirements to Meet 🎀

there are a few requirements from Section 4 of [RFC6862] that BFD, as defined in BFD [RFC5880], doesn't meet yet 🥺

• Replay Protection: BFD gives an incomplete intra-session replay attack protection and no inter-session replay attack protection at all. That creates big denial-of-service opportunities 💀
• Strong Algorithms: the crypto algorithms BFD uses for message authentication are MD5 or SHA-1 based. Both are known to be vulnerable to collision attacks. "BFD Generic Cryptographic Authentication" [BFD-CRYPTO] and "Authenticating BFD using HMAC-SHA-2 procedures" [BFD-HMAC] together propose a fix: Hashed Message Authentication Code (HMAC) with the SHA-2 family of hash functions for BFD 🔥
• Preventing DoS Attacks: BFD packets can be sent at millisecond intervals, and the protocol uses timers at microsecond intervals. When malicious packets get sent at short intervals with the authentication bit set, it can cause a DoS attack. BFD has no lightweight mechanism to address this yet, and it's one of the reasons BFD authentication still isn't widely deployed in the field 😩

the rest of the doc explains how these requirements fall short and proposes ways to address them 💅

3. Current State of Security Methods 🦋

okay so BFD [RFC5880] describes five authentication mechanisms for integrity protection of BFD control packets: Simple Password, Keyed MD5 [RFC1321], Meticulous Keyed MD5, Keyed SHA-1, and Meticulous Keyed SHA-1 🧩 With Simple Password, every control packet is tied to a password sent in plain text. Anyone eavesdropping on the traffic can easily learn the password and compromise that BFD session 🙈

with Keyed MD5 and Meticulous Keyed MD5, BFD nodes use shared secret keys to generate Keyed MD5 digests for control packets. Same energy for Keyed SHA-1 and Meticulous Keyed SHA-1, except they generate Keyed SHA-1 digests 🔐

here's the detail that matters: in the keyed authentication mechanisms, every BFD control packet carries a non-decreasing, 32-bit sequence number to resist replay attacks ✨ In Keyed MD5 and Keyed SHA-1, the sequence number only has to increase occasionally. But in Meticulous Keyed MD5 and Meticulous Keyed SHA-1, it has to increase with every successive packet. That's the difference, bestie 💜

there's also limited key updating. Every authenticated BFD control packet has a Key ID that says which key hashed it 🗝️ The catch is that no mechanism is described for a smooth key rollover, so BFD routers have no real guidance on moving from one key to the other 😬

BFD session timers are defined with microsecond granularity, and it's common in practice to send BFD packets at millisecond intervals ⏱️ The cryptographic sequence number space is only 32 bits, so a sequence number used in a BFD session can hit its maximum and roll over in a pretty short window. For example, if the sequence number goes up by one every 3.3 milliseconds, it hits its max in less than 24 weeks 📉 That can open the door to inter-session replay attacks, especially when BFD uses the non-meticulous authentication modes. this is giving vulnerability era 🌈

also, when authentication is in use, BFD drops every packet outside the limited range (3 times the Detection Time multiplier) 🚫 So with meticulous authentication modes, a replayed BFD packet gets rejected if it can't fit into a relatively short window (3 times the detection interval of the session). That makes replaying packets harder 😤 But in a non-meticulous mode, those windows can be huge, since sequence numbers only go up occasionally, which makes replay attacks easier to pull off .

in a BFD session, each node picks a 32-bit discriminator to identify itself, so a session is identified by two discriminators 🪪 If a node randomly picks a new discriminator for each new session and uses authentication to secure its control packets, inter-session replay attacks get mitigated to some extent. The problem is that in existing BFD demultiplexing mechanisms, the discriminators for a new session can be predictable. In some deployments, the discriminators of BFD routers are decided by the destination and source addresses. So if a BFD router's sequence number rolls over for some reason (e.g., reboot), the discriminators for the new session end up identical to the ones from the previous session. Replaying becomes pretty simple from there 😭

BFD also allows a mode called echo mode. Echo packets aren't defined in the BFD spec, though they can keep the BFD session up 🪞 The echo packet format is local to the sending side, and there are no guidelines on its properties beyond the choice of source and destination addresses. The BFD spec does recommend applying security mechanisms to prevent spoofing of these packets, but there's no guidance on which mechanisms are appropriate 🤷‍♀️

4. Impacts of BFD Replays ✨

okay so BFD cannot meet the requirements of inter-session or intra-session replay protection, and this section is all about what that actually means for real networks 🫶 it's giving "uh oh" energy, bestie 😭

When cryptographic authentication mechanisms are adopted for BFD, a non-decreasing, 32-bit-long sequence number is used. In the Keyed MD5 and the Keyed SHA-1 mechanisms, the sequence member is not required to increase for every packet. So an attacker can keep replaying packets carrying the latest sequence number until the sequence number finally gets updated 💀 not me replaying the same packet over and over lol. This issue is eliminated in the Meticulous Keyed MD5 and the Meticulous Keyed SHA-1 mechanisms ✨ that's the glow-up. Still, a sequence number can hit its maximum and roll over inside a session. Without support from an automatic key management mechanism, the BFD session is vulnerable to replay attacks sent before the roll over. An attacker can replay a packet with a sequence number larger than the current one. If that replayed packet gets accepted, the victim rejects the legal packets whose sequence members are less than the one in the replayed packet. Which means the attacker gets a good chance to bring down the BFD session 😭🔥 This kind of attack assumes the attacker has access to the link when the BFD session runs on a point-to-point link, or can inject packets for a BFD session with multiple hops.

Also, the BFD specification lets the authentication state change based on the state of a received packet. For instance, according to BFD [RFC5880], if an accepted packet's state is down, the receiver needs to transfer its own state to down as well. So a carefully chosen replayed packet can cause a serious denial-of-service attack 🥀

BFD does not provide any solution for inter-session replay attacks. If two subsequent BFD sessions use an identical discriminator pair and the same cryptographic key to secure control packets, it's pretty intuitive that an attacker could use a malicious authenticated packet (stored from the past session) to pull off interconnection replay attacks 🙈

Any security issues in the BFD echo mode directly affect the BFD protocol and session states, and therefore network stability. For instance, any replay attacks would be indistinguishable from normal forwarding of the tested router. An attack could still make a faulty link look up, and honestly there's not much that can be done about it 😤 However, if the echo packets are guessable, it may be possible to spoof them from an external source and make BFD believe a one-way link is really bidirectional. So it's important that the echo packets contain random material that is also checked on reception ✨🔐

5. Impact of New Authentication Requirements 🎀

BFD can run in software or hardware. Hardware implementations run BFD at a much smaller timeout, typically in the order of a few milliseconds. For instance, with a timeout of 3.3 milliseconds, a BFD session is required to send or receive 3 packets every 10 milliseconds 😳 Software implementations typically run with a timeout in the hundreds of milliseconds.

Also, it's not common to find hardware support for computing the authentication data for a BFD session, in hardware or software. In the Keyed MD5 and Keyed SHA-1 implementations, where the sequence number does not increase with every packet, software can be used to compute the authentication data. This is true if the time between sequence number increases is long enough to compute the data in software. The ability to compute the hash in software is difficult with Meticulous Keyed MD5 and Meticulous Keyed SHA-1 if the time interval between transmits or between receives is small. And it gets worse if hundreds or thousands of sessions need the hash recomputed every few milliseconds 😭

Smaller, cheaper boxes that need to support a few hundred BFD sessions also tend to use a slower CPU. That CPU runs the entire control plane software on top of supporting the BFD sessions. As a general rule, no more than 40-45% of the CPU can be dedicated to supporting BFD. Adding hash computation for every BFD session can easily push the CPU past the 40-45% limit, even with just a few tens of sessions 💀 On higher-end boxes with faster, more CPU cores, the expectation is that thousands of sessions need support, but the number of BFD sessions with authentication that the CPU can handle is still in the hundreds 🥹

Implementors SHOULD assess the impact of authenticating BFD sessions on their platform 💅

Wait, correction: that sentence in the original doesn't use a BCP 14 key word, so it stays lowercase. Here's the corrected line:

Implementors should assess the impact of authenticating BFD sessions on their platform 💅

6. Considerations for Improvement 🌈

okay this section suggests changes that could improve the protection of BFD 🦋

The security risks brought by SHA-1 and MD5 are well understood. But when you use a stronger digest algorithm, like SHA-2, the extra computing overhead can seriously hurt BFD performance 😩 To balance the need for a strong algorithm against that overhead, Galois Message Authentication Code (GMAC) can be a candidate option. It's relatively effective and has been supported by IPsec for data origin authentication ✨ More detailed info is in "The Use of Galois Message Authentication Code (GMAC) in IPsec ESP and AH" [RFC4543].

There's been some hallway conversation about only using BFD cryptographic authentication when some data in the BFD payload changes. The other BFD packets could be sent and received without authentication enabled 👀 Most BFD packets have no state change attached to them, so limiting authentication to packets that affect a BFD session's state would let more sessions be authenticated. That could really help routers, since they wouldn't have to compute and verify the authentication digest for packets arriving at millisecond intervals 🫶 This proposal needs more discussion in the BFD working group, but it's totally a direction BFD could look at 💖

7. Security Considerations 🔐

This document discusses vulnerabilities in the existing BFD protocol and suggests possible mitigations 😤

When analyzing improvements for BFD, the ability to repel a replay attack is discussed. For example, increasing the sequence number to a 64-bit value makes the wrap-around time much longer, and a replay attack can be easily prevented 👑

Mindful of how much stronger algorithms can affect BFD performance, the document suggests GMAC as a possible candidate for the MAC function 🦋

8. References 📚

8.1. Normative References 💜

[RFC1321] Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321, April 1992, <http://www.rfc-editor.org/info/rfc1321>.

[RFC5880] Katz, D. and D. Ward, "Bidirectional Forwarding Detection (BFD)", RFC 5880, June 2010, <http://www.rfc-editor.org/info/rfc5880>.

[RFC6039] Manral, V., Bhatia, M., Jaeggli, J., and R. White, "Issues with Existing Cryptographic Protection Methods for Routing Protocols", RFC 6039, October 2010, <http://www.rfc-editor.org/info/rfc6039>.

8.2. Informative References 🌸

[BFD-CRYPTO] Bhatia, M., Manral, V., Zhang, D., and M. Jethanandani, "BFD Generic Cryptographic Authentication", Work in Progress, draft-ietf-bfd-generic-crypto-auth-06, April 2014.

[BFD-HMAC] Zhang, D., Bhatia, M., Manral, V., and M. Jethanandani, "Authenticating BFD using HMAC-SHA-2 procedures", Work in Progress, draft-ietf-bfd-hmac-sha-05, July 2014.

[RFC4543] McGrew, D. and J. Viega, "The Use of Galois Message Authentication Code (GMAC) in IPsec ESP and AH", RFC 4543, May 2006, <http://www.rfc-editor.org/info/rfc4543>.

[RFC4822] Atkinson, R. and M. Fanto, "RIPv2 Cryptographic Authentication", RFC 4822, February 2007, <http://www.rfc-editor.org/info/rfc4822>.

[RFC5310] Bhatia, M., Manral, V., Li, T., Atkinson, R., White, R., and M. Fanto, "IS-IS Generic Cryptographic Authentication", RFC 5310, February 2009, <http://www.rfc-editor.org/info/rfc5310>.

[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, <http://www.rfc-editor.org/info/rfc5709>.

[RFC6518] Lebovitz, G. and M. Bhatia, "Keying and Authentication for Routing Protocols (KARP) Design Guidelines", RFC 6518, February 2012, <http://www.rfc-editor.org/info/rfc6518>.

[RFC6862] Lebovitz, G., Bhatia, M., and B. Weis, "Keying and Authentication for Routing Protocols (KARP) Overview, Threats, and Requirements", RFC 6862, March 2013, <http://www.rfc-editor.org/info/rfc6862>.

Acknowledgements 🫶

We would like to thank Alexander Vainshtein for his comments on this document 💕

Authors' Addresses 🎀

Manav Bhatia Ionos Networks Bangalore India

EMail: manav@ionosnetworks.com

---

Dacheng Zhang Huawei

EMail: dacheng.zhang@gmail.com

---

Mahesh Jethanandani Ciena Corporation 3939 North 1st Street San Jose, CA 95134 United States

Phone: 408.904.2160 Fax: 408.436.5582 EMail: mjethanandani@gmail.com