RFC 9978

Bidirectional Forwarding Detection (BFD) Stability

📅 published June 2026, from ietf

📮 RFC 9978: Bidirectional Forwarding Detection (BFD) Stability 💖

okay bestie, let's get into this one 🦋 It's an Experimental RFC from the IETF (the Internet Engineering Task Force, the crew that writes the rules for how the internet talks to itself 🌸). It's from June 2026, and it's written by A. Mishra (Aalyria Technologies), M. Jethanandani (Arrcus, Inc.), A. Saxena (Ciena Corporation), S. Pallagatti (Zscaler), and M. Chen (Huawei) ✨. Its ISSN is 2070-1721. It is not on the Internet Standards Track, which means it's published for people to examine, try out, and evaluate 🧪

It doesn't obsolete any earlier RFCs and doesn't update any either, so it's a fresh start 🌈

The whole point of this doc is to extend BFD (Bidirectional Forwarding Detection, the protocol that keeps an eye on whether a link is alive 👀) so it can measure stability, specifically by detecting BFD packet loss 💅

Status of This Memo ✨

This document is not an Internet Standards Track specification; it is published for examination, experimental implementation, and evaluation. 🧪

This document defines an Experimental Protocol for the Internet community. This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Not all documents approved by the IESG are candidates for any level of Internet Standard; see Section 2 of RFC 7841. 🫶

Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at https://www.rfc-editor.org/info/rfc9978. 🔗

Copyright (c) 2026 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 (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License. 💅

Table of Contents 🎀

1.  Introduction
2.  Terminology
3.  Use Cases
4.  Functionality
5.  NULL Auth Type
6.  Theory of Operation
  6.1.  Loss Measurement
  6.2.  Out-of-Order Packets
7.  Stability YANG Module
  7.1.  Data Model Overview
  7.2.  YANG Module
8.  IANA Considerations
  8.1.  Auth Type
  8.2.  IETF XML Registry
  8.3.  The "YANG Module Names" Registry
9.  Security Considerations
  9.1.  BFD NULL Auth Type Security Considerations
  9.2.  YANG Security Considerations
10. References
  10.1.  Normative References
  10.2.  Informative References
Appendix A.  Experimental Status
Appendix B.  Examples
  B.1.  Single Hop BFD Configuration
  B.2.  Use of the NULL Auth Type
Acknowledgements
Contributors
Authors' Addresses

1. Introduction 🌸

okay so BFD (Bidirectional Forwarding Detection, see [RFC5880]) works by sending and receiving BFD control packets, usually really often, over the datapath it's watching 🏃‍♀️ To avoid losing a ton of data when a datapath fails, the BFD session's Detection Time (as defined in [RFC5880]) is set to the smallest feasible value 🚨

A BFD session [RFC5880] stays in the Up state as long as it gets at least one BFD packet within the Detection Time interval. BUT here's the tea: any other packets that go missing inside that window are NOT noticed by the BFD state machinery 🫠 Catching those missed packets is a super useful sign of systemic problems or a network that's getting worse, which might be worth acting on before things break 💖

This document proposes an experimental mechanism to detect packet loss in a BFD session, and it describes BFD's datapath fault detection mechanisms too 🧚 Paired with 'receive-packet-count', which is defined in "YANG Data Model for Bidirectional Forwarding Detection (BFD)" [RFC9314], this lets operators measure how stable their BFD sessions are 📊 The reasons this is Experimental are in Appendix A 🎀 Implementations can also do extra analysis of packet loss over a time interval, but that analysis is outside the scope of this document 💅

This document does NOT propose any BFD extension for measuring data traffic loss or delay on a link or tunnel. The scope is only BFD packets 🙈

2. Terminology 📖

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here. 🔑

The reader is expected to already know BFD [RFC5880] 🧠 Specifically, the term "meticulous", as specified in "Meticulous Keyed ISAAC for Bidirectional Forwarding Detection (BFD) Optimized Authentication" [RFC9986], means that the sequence number gets incremented on every new packet that's sent 🔢

3. Use Cases 🦋

BFD (defined in [RFC5880]) can't detect any BFD packet loss if the loss doesn't last for the Detection Time 😬 This document proposes a way to detect dropped packets on the receiver 🎯 For example: if the receiver gets BFD control packet k at time t, but then gets packet k+3 at time t+10 ms, and never gets packet k+1 and/or k+2, then it has experienced packet loss 📉

This proposal lets BFD implementations generate diagnostic info about how healthy each BFD session is 🩺 That info can help predict a failure on a datapath that BFD is monitoring, giving time to take corrective action before things go sideways 🏃‍♀️💨

In a faulty datapath scenario, an operator can use BFD health info to kick off delay and loss measurement with the OAM (Operations, Administration, and Maintenance) protocol Connectivity Fault Management (CFM) [Y-1731], or with packet loss and delay measurement for MPLS networks [RFC6374], to dig deeper into the issue 🔍

4. Functionality 💅

BFD Stability measurement REQUIRES that a BFD Meticulous authentication type be configured. 🔐

The "ietf-bfd-stability" YANG data model, which is defined in this document, lets you configure BFD Stability measurement for BFD sessions by setting the 'stability' flag ⚙️ The 'lost-packet-count' leaf lets you monitor stability issues, as defined in this document, for BFD sessions that have the 'stability' flag turned on 📈

Configuring BFD Stability measurement and monitoring with methods other than the attached YANG data model is out of scope for this document 🙅‍♀️

5. NULL Auth Type 🎀

The NULL Auth Type, defined in this document, can be used to provide a meticulously increasing sequence number [RFC5880] for stability measurement 🔢 It provides NONE of the protections you'd want from authentication 💀 It's only there to give BFD Stability services to BFD sessions that otherwise don't use any authentication 🫶

If the Authentication Present (A) bit is set in the header (as defined in Section 4 of [RFC5880]) and the Authentication Type field contains 6, the Authentication Section looks like this 👇

  0                   1                   2                   3
  0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |   Auth Type   |   Auth Len    |  Auth Key ID  |   Reserved    |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |                        Sequence Number                        |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                    Figure 1: NULL Auth Type

where:

  • Auth Type (8 bits): the Authentication Type. In this case it's 6 (NULL) 🏷️
  • Auth Len (8 bits): the length of the NULL Auth Type in bytes (that's 8 bytes) 📏
  • Auth Key ID (8 bits): the authentication key ID in use for this packet. It MUST be set to zero, and it MUST be ignored on receipt 🔑
  • Reserved (8 bits): this byte MUST be set to zero on transmit, and it MUST be ignored on receipt 🫙
  • Sequence Number (32 bits): the sequence number for this packet. It goes up by one for each successive packet sent for a session. Implementations use sequence numbers (bfd.XmitAuthSeq) as defined in [RFC5880] 🔢✨

If bfd.AuthSeqKnown is 1, and the received Sequence Number field is not equal to bfd.RcvAuthSeq + 1 (in a circular number space), then the loss count goes up by the difference between the received sequence number and bfd.RcvAuthSeq, and bfd.RcvAuthSeq gets set to the received sequence number 📉

Otherwise (bfd.AuthSeqKnown is 0), bfd.AuthSeqKnown MUST be set to 1, and bfd.RcvAuthSeq MUST be set to the value of the received Sequence Number field as defined in [RFC5880], Section 6.8.1, and the packet MUST be accepted 🌱

According to Section 6.7.3 of [RFC5880], a receiver MUST discard a received packet that lies outside the range of bfd.RcvAuthSeq and bfd.RcvAuthSeq + (3 * Detect Multi). If it's inside that range but a packet is missing, it can be used to detect a loss 🕵️‍♀️ With NULL authentication, packets with sequence numbers are accepted on receipt, so an attacker with an unauthenticated sequence number could push the sequence number forward 😱 Meanwhile the real BFD neighbor, still sending packets, would have them discarded, and the session would drop 💔 To prevent this attack, the received sequence number MUST NOT be compared with bfd.RcvAuthSeq for the purpose of discarding BFD packets 🛡️

6. Theory of Operation 🧚

This mechanism lets operators measure the loss of BFD control packets 📊 To support this loss measurement, a BFD authentication type carrying a meticulously increasing sequence number is REQUIRED 🔐 Authentication types that provide meticulously increasing sequence numbers include:

  • Meticulously Keyed MD5 and SHA1, defined in [RFC5880].
  • Meticulously Keyed ISAAC, defined in [RFC9986].
  • The NULL authentication mechanism, which doesn't provide authentication but does carry a meticulously increasing sequence number, is defined in this document.

Other authentication types that provide meticulously increasing sequence numbers appropriate for this mechanism MAY be defined in future specifications 🔮

6.1. Loss Measurement 📉

Loss measurement counts the number of BFD control packets missed at the receiver during any Detection Time period (see [RFC5880], Section 6.8.4). The loss is detected by comparing the Sequence Number field in successive BFD control packets. The sequence number in each successive control packet generated on a BFD session by the transmitter is incremented by one 🔢 This loss count can then be exposed using the YANG module defined in the next section. See the discussion of out-of-order packets in Section 6.2 of this document 🎀

The first BFD Authentication Section with a non-zero sequence number, in a valid BFD control packet processed by the receiver, is used to bootstrap the logic 🥾🌈

⚠️ Heads up: the NULL Auth Type gives you NO authentication. Its only job here is stability measurement, so don't treat it as security 🙅‍♀️

(Part 1 of 5. More coming soon, bestie 💖)

6.2. Out-of-Order Packets 🦋

okay so bestie, LAGs (Link Aggregate Groups) and ECMP (Equal Cost Multipath) are lowkey the reason packets can show up out of order 🌀. The BFD packets aren't getting lost, they're just arriving in a messy sequence, but if you strictly check that sequence numbers only go up, those packets can get counted as loss 😭. Not fair!

Implementations MAY provide mechanisms where every packet that was expected during an expected interval, but arrived out of order, is NOT counted as a lost packet. Main character energy for the packets that were just running late 💅✨

7. Stability YANG Module 🌈

7.1. Data Model Overview 💖

This YANG module augments the base BFD YANG module so it can add attributes like the 'stability' flag, which is part of the BFD Stability experiment 🧪. The feature statement 'stability' has to be enabled before the implementation can say it supports BFD Stability 🎀. The model also adds a loss count, either per session or per Label Switched Path (LSP), for BFD packets that get lost 💜. It's giving organized.

   module: ietf-bfd-stability

     augment /rt:routing/rt:control-plane-protocols
               </rt:control-plane-protocol/bfd:bfd/bfd-ip-sh:ip-sh
               /bfd-ip-sh:sessions/bfd-ip-sh:session:
       +--rw stability?   boolean {stability}?
     augment /rt:routing/rt:control-plane-protocols
               /rt:control-plane-protocol/bfd:bfd/bfd-ip-mh:ip-mh
               /bfd-ip-mh:session-groups/bfd-ip-mh:session-group:
       +--rw stability?   boolean {stability}?
     augment /rt:routing/rt:control-plane-protocols
               /rt:control-plane-protocol/bfd:bfd/bfd-lag:lag
               /bfd-lag:sessions/bfd-lag:session:
       +--rw stability?   boolean {stability}?
     augment /rt:routing/rt:control-plane-protocols
               /rt:control-plane-protocol/bfd:bfd/bfd-mpls:mpls
               /bfd-mpls:session-groups/bfd-mpls:session-group:
       +--rw stability?   boolean {stability}?
     augment /rt:routing/rt:control-plane-protocols
               /rt:control-plane-protocol/bfd:bfd/bfd-ip-sh:ip-sh
               /bfd-ip-sh:sessions/bfd-ip-sh:session
               /bfd-ip-sh:session-statistics:
       +--ro lost-packet-count?   yang:counter64 {stability}?
     augment /rt:routing/rt:control-plane-protocols
               /rt:control-plane-protocol/bfd:bfd/bfd-ip-mh:ip-mh
               /bfd-ip-mh:session-groups/bfd-ip-mh:session-group
               /bfd-ip-mh:sessions/bfd-ip-mh:session-statistics:
       +--ro lost-packet-count?   yang:counter64 {stability}?
     augment /rt:routing/rt:control-plane-protocols
               /rt:control-plane-protocol/bfd:bfd/bfd-lag:lag
               /bfd-lag:sessions/bfd-lag:session/bfd-lag:member-links
               /bfd-lag:micro-bfd-ipv4/bfd-lag:session-statistics:
       +--ro lost-packet-count?   yang:counter64 {stability}?
     augment /rt:routing/rt:control-plane-protocols
               /rt:control-plane-protocol/bfd:bfd/bfd-lag:lag
               /bfd-lag:sessions/bfd-lag:session/bfd-lag:member-links
               /bfd-lag:micro-bfd-ipv6/bfd-lag:session-statistics:
       +--ro lost-packet-count?   yang:counter64 {stability}?
     augment /rt:routing/rt:control-plane-protocols
               /rt:control-plane-protocol/bfd:bfd/bfd-mpls:mpls
               /bfd-mpls:session-groups/bfd-mpls:session-group
               /bfd-mpls:sessions/bfd-mpls:session-statistics:
       +--ro lost-packet-count?   yang:counter64 {stability}?

7.2. YANG Module ✨

okay so this is the actual YANG data model 🎀 it doesn't reinvent everything, it borrows from a few other modules: "Common YANG Data Types" [RFC9911], "YANG Data Model for Key Chains" [RFC8177], "A YANG Data Model for Routing Management (NMDA Version)" [RFC8349], and "YANG Data Model for Bidirectional Forwarding Detection (BFD)" [RFC9314]. it's giving modular 💅

<CODE BEGINS> file "ietf-bfd-stability@2026-06-29.yang"
module ietf-bfd-stability {
  yang-version 1.1;
  namespace "urn:ietf:params:xml:ns:yang:ietf-bfd-stability";
  prefix bfd-s;

  import ietf-yang-types {
    prefix yang;
    reference
      "RFC 9911: Common YANG Data Types";
  }
  import ietf-routing {
    prefix rt;
    reference
      "RFC 8349: A YANG Data Model for Routing Management
       (NMDA Version)";
  }
  import ietf-bfd {
    prefix bfd;
    reference
      "RFC 9314: YANG Data Model for Bidirectional
       Forwarding Detection.";
  }
  import ietf-bfd-ip-sh {
    prefix bfd-ip-sh;
    reference
      "RFC 9314: YANG Data Model for Bidirectional
       Forwarding Detection (BFD)";
  }
  import ietf-bfd-ip-mh {
    prefix bfd-ip-mh;
    reference
      "RFC 9314: YANG Data Model for Bidirectional
       Forwarding Detection (BFD)";
  }
  import ietf-bfd-lag {
    prefix bfd-lag;
    reference
      "RFC 9314: YANG Data Model for Bidirectional
       Forwarding Detection (BFD)";
  }
  import ietf-bfd-mpls {
    prefix bfd-mpls;
    reference
      "RFC 9314: YANG Data Model for Bidirectional
       Forwarding Detection (BFD)";
  }
  import ietf-key-chain {
    prefix key-chain;
    reference
      "RFC 8177: YANG Data Model for Key Chains";
  }

  organization
    "IETF BFD Working Group";
  contact
    "WG Web:   <https://datatracker.ietf.org/wg/bfd>
     WG List:  <rtg-bfd@ietf.org>

     Authors: Mahesh Jethanandani (mjethanandani@gmail.com)
              Ashesh Mishra (mishra.ashesh@gmail.com)
              Ankur Saxena (ankurpsaxena@gmail.com)
              Santosh Pallagatti (santosh.pallagati@gmail.com)
              Mach(Guoyi) Chen (mach.chen@huawei.com).";
  description
    "This YANG module augments the base BFD YANG data model to add
     experimental attributes related to BFD Stability.
     In particular, it adds a per-session count for BFD packets
     that are lost.

     The key words 'MUST', 'MUST NOT', 'REQUIRED', 'SHALL', 'SHALL
     NOT', 'SHOULD', 'SHOULD NOT', 'RECOMMENDED', 'NOT RECOMMENDED',
     'MAY', and 'OPTIONAL' in this document are to be interpreted as
     described in BCP 14 (RFC 2119) (RFC 8174) when, and only when,
     they appear in all capitals, as shown here.

     Copyright (c) 2026 IETF Trust and the persons identified as
     authors of the code.  All rights reserved.

     Redistribution and use in source and binary forms, with or
     without modification, is permitted pursuant to, and subject to
     the license terms contained in, the Revised BSD License set
     forth in Section 4.c of the IETF Trust's Legal Provisions
     Relating to IETF Documents
     (https://trustee.ietf.org/license-info).

     This version of this YANG module is part of RFC 9978; see the
     RFC itself for full legal notices.";

  revision 2026-06-29 {
    description
      "Initial version.";
    reference
      "RFC 9978: Bidirectional Forwarding Detection (BFD) Stability";
  }

  feature stability {
    description
      "This feature enables BFD sessions to be monitored for lost
       packets.";
  }

  identity null-auth {
    base key-chain:crypto-algorithm;
    description
      "BFD NULL Auth Type defined in this document.";
    reference
      "RFC 9978: Bidirectional Forwarding Detection (BFD) Stability";
  }

  grouping lost-packet-count {
    leaf lost-packet-count {
      if-feature "stability";
      type yang:counter64;
      description
        "Number of BFD packets that were lost, where loss is
         determined by the fact that the sequence number is
         not consecutive.  This counter should be present only if
         stability is configured.";
    }
    description
      "Grouping of statistics related to BFD Stability.";
  }

  augment "/rt:routing/rt:control-plane-protocols/"
        + "rt:control-plane-protocol/bfd:bfd/bfd-ip-sh:ip-sh/"
        + "bfd-ip-sh:sessions/bfd-ip-sh:session" {
    leaf stability {
      if-feature "stability";
      type boolean;
      must "../bfd-ip-sh:authentication/bfd-ip-sh:meticulous = "
         + "'true'";
      default "false";
      description
        "If set to true, this enables the BFD session to monitor
         for stability, i.e., to watch how many packets are getting
         dropped.";
    }
    description
      "Augment the 'bfd' container to add attributes related to BFD
       Stability for IP Single Hop sessions.";
  }

  augment "/rt:routing/rt:control-plane-protocols/"
        + "rt:control-plane-protocol/bfd:bfd/bfd-ip-mh:ip-mh/"
        + "bfd-ip-mh:session-groups/bfd-ip-mh:session-group" {
    leaf stability {
      if-feature "stability";
      type boolean;
      must "../bfd-ip-mh:authentication/bfd-ip-mh:meticulous = "
         + "'true'";
      default "false";
      description
        "If set to true, this enables the BFD session to monitor
         for stability, i.e., to watch how many packets are getting
         dropped.";
    }
    description
      "Augment the 'bfd' container to add attributes related to BFD
       Stability for Multi Hop sessions.";
  }

  augment "/rt:routing/rt:control-plane-protocols/"
        + "rt:control-plane-protocol/bfd:bfd/bfd-lag:lag/"
        + "bfd-lag:sessions/bfd-lag:session" {
    leaf stability {
      if-feature "stability";
      type boolean;
      must "../bfd-lag:authentication/bfd-lag:meticulous = "
         + "'true'";
      default "false";
      description
        "If set to true, this enables the BFD session to monitor
         for stability, i.e., to watch how many packets are getting
         dropped.";
    }
    description
      "Augment the 'bfd' container to add attributes related to BFD
       Stability for LAG session.";
  }

  augment "/rt:routing/rt:control-plane-protocols/"
        + "rt:control-plane-protocol/bfd:bfd/bfd-mpls:mpls/"
        + "bfd-mpls:session-groups/bfd-mpls:session-group" {
    leaf stability {
      if-feature "stability";
      type boolean;
      must "../bfd-mpls:authentication/bfd-mpls:meticulous = "
         + "'true'";
      default "false";
      description
        "If set to true, this enables the BFD session to monitor
         for stability, i.e., to watch how many packets are getting
         dropped.";
    }
    description
      "Augment the 'bfd' container to add attributes related to BFD
       Stability for MPLS.";
  }

  augment "/rt:routing/rt:control-plane-protocols/"
        + "rt:control-plane-protocol/bfd:bfd/bfd-ip-sh:ip-sh/"
        + "bfd-ip-sh:sessions/bfd-ip-sh:session/"
        + "bfd-ip-sh:session-statistics" {
    uses lost-packet-count;
    description
      "Augment the 'bfd' container to add statistics related to BFD
       Stability for IP Single Hop sessions.";
  }

  augment "/rt:routing/rt:control-plane-protocols/"
        + "rt:control-plane-protocol/bfd:bfd/bfd-ip-mh:ip-mh/"
        + "bfd-ip-mh:session-groups/bfd-ip-mh:session-group/"
        + "bfd-ip-mh:sessions/bfd-ip-mh:session-statistics" {
    uses lost-packet-count;
    description
      "Augment the 'bfd' container to add statistics related to BFD
       Stability for IP Multi Hop sessions.";
  }

  augment "/rt:routing/rt:control-plane-protocols/"
        + "rt:control-plane-protocol/bfd:bfd/bfd-lag:lag/"
        + "bfd-lag:sessions/bfd-lag:session/bfd-lag:member-links/"
        + "bfd-lag:micro-bfd-ipv4/bfd-lag:session-statistics" {
    uses lost-packet-count;
    description
      "Augment the 'bfd' container to add statistics related to BFD
       Stability for Micro BFD sessions for IPv4.";
  }

  augment "/rt:routing/rt:control-plane-protocols/"
        + "rt:control-plane-protocol/bfd:bfd/bfd-lag:lag/"
        + "bfd-lag:sessions/bfd-lag:session/bfd-lag:member-links/"
        + "bfd-lag:micro-bfd-ipv6/bfd-lag:session-statistics" {
    uses lost-packet-count;
    description
      "Augment the 'bfd' container to add statistics related to BFD
       Stability for Micro BFD sessions for IPv6.";
  }

  augment "/rt:routing/rt:control-plane-protocols/"
        + "rt:control-plane-protocol/bfd:bfd/bfd-mpls:mpls/"
        + "bfd-mpls:session-groups/bfd-mpls:session-group/"
        + "bfd-mpls:sessions/bfd-mpls:session-statistics" {
    uses lost-packet-count;
    description
      "Augment the 'bfd' container to add statistics related to BFD
       Stability for MPLS sessions.";
  }
}
<CODE ENDS>

8. IANA Considerations ✨

okay so this doc makes three registrations 🌸 there's a new authentication type going in the "BFD Authentication Types" registry, a new URI going in the "ns" registry inside the "IETF XML" registry group [RFC3688], and a YANG module going in the "YANG Module Names" registry.

8.1. Auth Type

IANA has registered the following BFD Auth Type in the "BFD Authentication Types" registry:

Address:  6
BFD Authentication Type Name:  NULL
Reference  RFC 9978

8.2. IETF XML Registry

IANA has registered the following URI in the "ns" registry [RFC3688]:

URI:  urn:ietf:params:xml:ns:yang:ietf-bfd-stability
Registrant Contact:  The IESG
XML:  N/A; the requested URI is an XML namespace.

8.3. The "YANG Module Names" Registry

IANA has registered the following YANG module in the "YANG Module Names" registry [RFC6020]:

Name:  ietf-bfd-stability
Namespace:  urn:ietf:params:xml:ns:yang:ietf-bfd-stability
Prefix:  bfd-s
Reference:  RFC 9978

9. Security Considerations ✨

9.1. BFD NULL Auth Type Security Considerations

bestie, this part is serious 😭 using a BFD authentication mechanism that protects the BFD packets is RECOMMENDED 🔐

the security considerations of [RFC5880] for unauthenticated BFD all apply to the new NULL Auth Type 💀 the NULL Auth Type, defined in this document, gives you none of the properties you'd want for authenticating BFD packets. its whole purpose is to give BFD sessions that otherwise wouldn't use authentication a sequence number, so packet loss can be detected.

the thing is, not having a computed AuthKey/Digest over the BFD packet, while still having a sequence number, makes this authentication type susceptible to injection attacks 🙈 BFD without authentication is vulnerable to session resets, and the NULL Auth Type does not change that.

when the NULL Auth Type is used for BFD Stability purposes, maliciously injected packets that don't reset the BFD session can look like high packet loss. so sessions like multi-hop routed paths, tunnels without authentication, or MPLS Label Switched Paths (LSPs) have security guarantees that are identical to running BFD without authentication. not ideal, not ideal 🥀

9.2. YANG Security Considerations 🔐

okay bestie, this part is modeled after the template in Section 3.7.1 of [RFC9907] 💅

The "ietf-bfd-stability" YANG module is a data model built to be reached through YANG-based management protocols, like Network Configuration Protocol (NETCONF) [RFC6241] and RESTCONF [RFC8040]. These management protocols (1) have to use a secure transport layer (for example Secure Shell (SSH) [RFC4252], TLS [RFC8446], and QUIC [RFC9000]) and (2) have to use mutual authentication. no cap, the locks need to be on 🔒

NACM [RFC8341] is the thing that lets you restrict access for particular NETCONF or RESTCONF users to a preconfigured subset of all the available protocol operations and content. main character access control energy ✨

The YANG module does not define any writable, creatable, or deletable data nodes that can have an adverse impact on a BFD session. so nobody can accidentally wreck your sessions through this module 🙌

Some of the readable data nodes in this YANG module may be considered sensitive or vulnerable in some network environments, so it's important to control read access to them (for example via get, get-config, or notification) 👀 Specifically, the following subtrees and data nodes have particular sensitivities/vulnerabilities:

The model defines a read-only node that shows the number of packets that were lost. Access to this info may allow a malicious user to learn information on which links are experiencing issues 😭 Also, as stated in Section 6.2, on links such as LAG or ECMP, there is a possibility of packets being delivered out-of-order. A strict comparison of increasing sequence numbers may end up classifying those out-of-order packets as packet loss, which is a whole mess 🙈

The YANG module does not define any RPC operations. 🎀

10. References 📚

10.1. Normative References

10.2. Informative References

Appendix A. Experimental Status 🧪

This document describes an experiment that will present a candidate solution to predict whether a given BFD session [RFC5880] will continue to be stable. The experiment will use the packet lost count and the 'receive-packet-count' defined in "YANG Data Model for Bidirectional Forwarding Detection (BFD)" [RFC9314] to figure out how stable the session is. It's on the Experimental track because there are no known implementations or proof of concept yet. So the authors aren't clear on whether a simple lost count is enough to predict stability, or whether there'll need to be a more granular count 🤔

This document is classified as Experimental and is not part of the IETF Standards Track.

Appendix B. Examples 🎀

This section tries to show some examples of how the model can be configured for stability.

B.1. Single Hop BFD Configuration

This example demonstrates how a single hop BFD session can be configured to enable monitoring of a session for stability. ✨

=============== NOTE: '\' line wrapping per RFC 8792 ===============

<?xml version="1.0" encoding="UTF-8"?>
<key-chains
    xmlns="urn:ietf:params:xml:ns:yang:ietf-key-chain"
    xmlns:kc="urn:ietf:params:xml:ns:yang:ietf-key-chain">
  <key-chain>
    <name>bfd-stability-config</name>
    <description>"An example for BFD Stability configuration."</de\
scription>
    <key>
      <key-id>55</key-id>
      <lifetime>
        <send-lifetime>
          <start-date-time>2025-01-01T00:00:00Z</start-date-time>
          <end-date-time>2025-02-01T00:00:00Z</end-date-time>
        </send-lifetime>
        <accept-lifetime>
          <start-date-time>2024-12-31T23:59:55Z</start-date-time>
          <end-date-time>2025-02-01T00:00:05Z</end-date-time>
        </accept-lifetime>
      </lifetime>
      <crypto-algorithm>kc:sha-1</crypto-algorithm>
    </key>
  </key-chain>
</key-chains>
<interfaces
    xmlns="urn:ietf:params:xml:ns:yang:ietf-interfaces"
    xmlns:if-type="urn:ietf:params:xml:ns:yang:iana-if-type">
  <interface>
    <name>eth0</name>
    <type>if-type:ethernetCsmacd</type>
  </interface>
</interfaces>
<routing
    xmlns="urn:ietf:params:xml:ns:yang:ietf-routing"
    xmlns:bfd-types="urn:ietf:params:xml:ns:yang:ietf-bfd-types"
    xmlns:stability="urn:ietf:params:xml:ns:yang:ietf-bfd-stability\
">
  <control-plane-protocols>
    <control-plane-protocol>
      <type>bfd-types:bfdv1</type>
      <name>name:BFD</name>
      <bfd xmlns="urn:ietf:params:xml:ns:yang:ietf-bfd">
        <ip-sh xmlns="urn:ietf:params:xml:ns:yang:ietf-bfd-ip-sh">
          <sessions>
            <session>
              <interface>eth0</interface>
              <dest-addr>2001:db8:0:113::101</dest-addr>
              <desired-min-tx-interval>10000</desired-min-tx-interv\
al>
              <required-min-rx-interval>
                10000
              </required-min-rx-interval>
              <stability:stability>true</stability:stability>
              <authentication>
                <key-chain>bfd-stability-config</key-chain>
                <meticulous>true</meticulous>
              </authentication>
            </session>
          </sessions>
        </ip-sh>
      </bfd>
    </control-plane-protocol>
  </control-plane-protocols>
</routing>

B.2. Use of the NULL Auth Type 🎀

okay so this example shows how to set up the NULL Auth Type so you can keep an eye on a session's stability 👀✨

Heads up, the line wrapping in the example below uses '' to split long lines, per RFC 8792. 💅

=============== NOTE: '\' line wrapping per RFC 8792 ===============
<?xml version="1.0" encoding="UTF-8"?>
<key-chains
    xmlns="urn:ietf:params:xml:ns:yang:ietf-key-chain"
    xmlns:stability="urn:ietf:params:xml:ns:yang:ietf-bfd-stability\
">
  <key-chain>
    <name>bfd-stability-config</name>
    <description>"An example for BFD Stability configuration."</des\
cription>
    <key>
      <key-id>55</key-id>
      <lifetime>
        <send-lifetime>
          <start-date-time>2025-01-01T00:00:00Z</start-date-time>
          <end-date-time>2025-02-01T00:00:00Z</end-date-time>
        </send-lifetime>
        <accept-lifetime>
          <start-date-time>2024-12-31T23:59:55Z</start-date-time>
          <end-date-time>2025-02-01T00:00:05Z</end-date-time>
        </accept-lifetime>
      </lifetime>
      <crypto-algorithm>stability:null-auth</crypto-algorithm>
    </key>
  </key-chain>
</key-chains>
<interfaces
    xmlns="urn:ietf:params:xml:ns:yang:ietf-interfaces"
    xmlns:if-type="urn:ietf:params:xml:ns:yang:iana-if-type">
  <interface>
    <name>eth0</name>
    <type>if-type:ethernetCsmacd</type>
  </interface>
</interfaces>
<routing
    xmlns="urn:ietf:params:xml:ns:yang:ietf-routing"
    xmlns:bfd-types="urn:ietf:params:xml:ns:yang:ietf-bfd-types"
    xmlns:stability="urn:ietf:params:xml:ns:yang:ietf-bfd-stability\
">
  <control-plane-protocols>
    <control-plane-protocol>
      <type>bfd-types:bfdv1</type>
      <name>name:BFD</name>
      <bfd xmlns="urn:ietf:params:xml:ns:yang:ietf-bfd">
        <ip-sh xmlns="urn:ietf:params:xml:ns:yang:ietf-bfd-ip-sh">
          <sessions>
            <session>
              <interface>eth0</interface>
              <dest-addr>2001:db8:0:113::101</dest-addr>
              <desired-min-tx-interval>10000</desired-min-tx-interv\
al>
              <required-min-rx-interval>
                10000
              </required-min-rx-interval>
              <stability:stability>true</stability:stability>
              <authentication>
                <key-chain>bfd-stability-config</key-chain>
                <meticulous>true</meticulous>
              </authentication>
            </session>
          </sessions>
        </ip-sh>
      </bfd>
    </control-plane-protocol>
  </control-plane-protocols>
</routing>

Acknowledgements ✨

big thank you to the squad 🫶 The authors would like to thank Nobo Akiya, Dileep Singh, Basil Saji, Sagar Soni, Albert Fu, Peng Fang, and Mallik Mudigonda for contributing to this document. Thanks to Christian Huitema for the SECDIR review and Ebben Aries for the YANG Doctors review.

Thanks to Reshad Rehman for being the shepherd of the document. 👑

Contributors 🌸

The authors would like to acknowledge Jeff Haas as a contributor to this document. His contribution lead to significant improvements of the document. 💖 In addition, Manav Bhatia contributed to this document.

Authors' Addresses 💜

Ashesh Mishra
Aalyria Technologies
Email: ashesh@aalyria.com
Mahesh Jethanandani
Arrcus, Inc.
United States of America
Email: mjethanandani@gmail.com
Ankur Saxena
Ciena Corporation
3939 North 1st Street
San Jose, CA 95134
United States of America
Email: ankurpsaxena@gmail.com
URI:   www.ciena.com
Santosh Pallagatti
Zscaler
Bangalore 560103
Karnataka
India
Email: santosh.pallagatti@gmail.com
Mach(Guoyi) Chen
Huawei
Email: mach.chen@huawei.com

That's the whole doc, bestie! 🦋🌈

📦 where this page comes from