rfc9985.original   rfc9985.txt 
Network Working Group M. Jethanandani Internet Engineering Task Force (IETF) M. Jethanandani
Internet-Draft Arrcus Request for Comments: 9985 Arrcus
Intended status: Experimental A. Mishra Category: Experimental A. Mishra
Expires: 15 May 2026 Aalyria Technologies ISSN: 2070-1721 Aalyria Technologies
J. Haas J. Haas
HPE HPE
A. Saxena A. Saxena
Ciena Corporation Ciena Corporation
M. Bhatia M. Bhatia
Google Google
11 November 2025 May 2025
Optimizing BFD Authentication Optimizing Bidirectional Forwarding Detection (BFD) Authentication
draft-ietf-bfd-optimizing-authentication-36
Abstract Abstract
This document describes an experimental optimization to BFD This document describes an experimental optimization to Bidirectional
Authentication. This optimization enables BFD to scale better when Forwarding Detection (BFD) Authentication. This optimization enables
there is a desire to use authentication where applying the same BFD to scale better when there is a desire to use authentication
authentication mechanism to every BFD Control Packet may adversely where applying the same authentication mechanism to every BFD Control
impact performance. This optimization partitions BFD Authentication Packet may adversely impact performance. This optimization
into a more computationally intensive mechanism that is applied to partitions BFD Authentication into a more computationally intensive
BFD significant changes, and a less computationally intensive (MCI) mechanism that is applied to BFD significant changes and a less
mechanism applied to the majority of BFD Control Packets. computationally intensive (LCI) mechanism that is applied to the
majority of BFD Control Packets.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This document is not an Internet Standards Track specification; it is
provisions of BCP 78 and BCP 79. published for examination, experimental implementation, and
evaluation.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months This document defines an Experimental Protocol for the Internet
and may be updated, replaced, or obsoleted by other documents at any community. This document is a product of the Internet Engineering
time. It is inappropriate to use Internet-Drafts as reference Task Force (IETF). It represents the consensus of the IETF
material or to cite them other than as "work in progress." 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.
This Internet-Draft will expire on 15 May 2026. 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/rfc9985.
Copyright Notice Copyright Notice
Copyright (c) 2025 IETF Trust and the persons identified as the Copyright (c) 2025 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents (https://trustee.ietf.org/ Provisions Relating to IETF Documents
license-info) in effect on the date of publication of this document. (https://trustee.ietf.org/license-info) in effect on the date of
Please review these documents carefully, as they describe your rights publication of this document. Please review these documents
and restrictions with respect to this document. Code Components carefully, as they describe your rights and restrictions with respect
extracted from this document must include Revised BSD License text as to this document. Code Components extracted from this document must
described in Section 4.e of the Trust Legal Provisions and are include Revised BSD License text as described in Section 4.e of the
provided without warranty as described in the Revised BSD License. Trust Legal Provisions and are provided without warranty as described
in the Revised BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction
1.1. Requirements Language . . . . . . . . . . . . . . . . . . 4 1.1. Requirements Language
1.2. Note to RFC Editor . . . . . . . . . . . . . . . . . . . 4 2. Terminology
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 3. BFD Control Packets That Require MCI Authentication
3. BFD Control Packets That Require More Computationally Intensive 3.1. Protecting BFD Significant Changes with MCI Authentication
Authentication . . . . . . . . . . . . . . . . . . . . . 5 4. Using LCI Auth Types
3.1. Protecting BFD Significant Changes with More 5. Periodic MCI Reauthentication
Computationally Intensive Authentication . . . . . . . . 6 6. Optimized Authentication Modes
4. Using Less Computationally Intensive Auth Types . . . . . . . 6 7. Signaling Optimized Authentication
5. Periodic More Computationally Intensive Reauthentication . . 6 7.1. Transmitting and Receiving Using Optimized Authentication
6. Optimized Authentication Modes . . . . . . . . . . . . . . . 7 7.2. Optimized Authentication Operations
7. Signaling Optimized Authentication . . . . . . . . . . . . . 8 8. Optimizing Authentication YANG Data Model
7.1. Transmitting and Receiving Using Optimized 8.1. Data Model Overview
Authentication . . . . . . . . . . . . . . . . . . . . . 9 8.2. Tree Diagram
7.2. Optimized Authentication Operations . . . . . . . . . . . 10 8.3. The YANG Data Model
8. Optimizing Authentication YANG Data Model . . . . . . . . . . 11 9. IANA Considerations
8.1. Data Model Overview . . . . . . . . . . . . . . . . . . . 11 9.1. IETF XML Registry
8.2. Tree Diagram . . . . . . . . . . . . . . . . . . . . . . 11 9.2. The YANG Module Names Registry
8.3. The YANG Data Model . . . . . . . . . . . . . . . . . . . 11 10. Security Considerations
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 10.1. Protocol Security Considerations
9.1. IETF XML Registry . . . . . . . . . . . . . . . . . . . . 15 10.2. YANG Security Considerations
9.2. The YANG Module Names Registry . . . . . . . . . . . . . 16 11. References
10. Security Considerations . . . . . . . . . . . . . . . . . . . 16 11.1. Normative References
10.1. Protocol Security Considerations . . . . . . . . . . . . 16 11.2. Informative References
10.2. YANG Security Considerations . . . . . . . . . . . . . . 18 Appendix A. Examples
11. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 18 A.1. Single Hop BFD Configuration
12. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 18 Appendix B. Experimental Status
13. References . . . . . . . . . . . . . . . . . . . . . . . . . 19 Acknowledgments
13.1. Normative References . . . . . . . . . . . . . . . . . . 19 Contributors
13.2. Informative References . . . . . . . . . . . . . . . . . 19 Authors' Addresses
Appendix A. Examples . . . . . . . . . . . . . . . . . . . . . . 21
A.1. Single Hop BFD Configuration . . . . . . . . . . . . . . 21
Appendix B. Experimental Status . . . . . . . . . . . . . . . . 23
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 24
1. Introduction 1. Introduction
BFD [RFC5880] authentication procedures, when enabled, authenticate BFD [RFC5880] authentication procedures, when enabled, authenticate
each control packet using the same authentication mechanism. Devices each control packet using the same authentication mechanism. Devices
implementing BFD are often resource constrained and authentication implementing BFD are often resource-constrained and authentication
may adversely impact the performance of BFD, thus discouraging the may adversely impact the performance of BFD, thus discouraging the
deployment of authentication. deployment of authentication.
When implemented in software, BFD authentication mechanisms compete When implemented in software, BFD authentication mechanisms compete
with other necessary work done by the systems implementing the with other necessary work done by the systems implementing the
protocol. When implemented using hardware acceleration, these protocol. When implemented using hardware acceleration, these
mechanisms may scale better situationally, but still impose a cost on mechanisms may scale better situationally, but they still impose a
the implementation. BFD's value is tied to its ability to scale in cost on the implementation. BFD's value is tied to its ability to
terms of numbers of sessions, and a detection time that relies on scale in terms of numbers of sessions and a detection time that
sending its control packets at a high rate. Implementers and relies on sending its control packets at a high rate. Implementers
operators are forced to evaluate tradeoffs of the benefits of and operators are forced to evaluate trade-offs of the benefits of
authentication vs. its impact on BFD performance. authentication vs. its impact on BFD performance.
The authentication mechanisms documented in [RFC5880], MD5 The authentication mechanisms documented in [RFC5880], MD5
Message-Digest Algorithm [RFC1321] and Secure Hash Algorithm (SHA-1) Message-Digest Algorithm [RFC1321], and Secure Hash Algorithm (SHA-1)
[RFC3174], are not particularly strong in a cryptographic sense. [RFC3174] are not particularly strong in a cryptographic sense.
However, they may still not appropriately scale situationally in a However, they may still not appropriately scale situationally in a
given implementation. In the future, there may be a desire to use given implementation. In the future, there may be a desire to use
stronger authentication mechanisms than those already specified, and stronger authentication mechanisms than those already specified, and
those mechanisms are likely to use even more resources. those mechanisms are likely to use even more resources.
The BFD prototocol can broadly be described as the set of procedures The BFD protocol can broadly be described as the set of procedures
that handle its state machine changes to reach the Up state, and once that handle its state machine changes to reach the Up state, and once
BFD is in the Up state sending those Up packets at the negotiated BFD is in the Up state, it will send those Up packets at the
high rate. The number of BFD Control Packets needed to signal state negotiated high rate. The number of BFD Control Packets needed to
changes (called significant changes) is very small, while the signal state changes (called significant changes) is very small,
majority of the Control Packets validate that the session remains in while the majority of the Control Packets validate that the session
the Up state. remains in the Up state.
This document describes an experimental optimization to BFD This document describes an experimental optimization to BFD
Authentication. This optimization partitions BFD Authentication into Authentication. This optimization partitions BFD Authentication into
a more computationally intensive (MCI) mechanism used to authenticate a more computationally intensive (MCI) mechanism used to authenticate
significant changes, and a less computationally intensive (LCI) significant changes, and a less computationally intensive (LCI)
mechanism applied to the majority of the BFD Control Packets that mechanism applied to the majority of the BFD Control Packets that
don't signal such significant changes. don't signal such significant changes.
The details of the motivation for experimental status are given in The details of the motivation for experimental status are given in
Appendix B. Appendix B.
1.1. Requirements Language 1.1. Requirements Language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in BCP "OPTIONAL" in this document are to be interpreted as described in
14 [RFC2119] [RFC8174] when, and only when, they appear in all BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here. capitals, as shown here.
1.2. Note to RFC Editor
This document uses several placeholder values throughout the
document. Please replace them as follows and remove this note before
publication.
RFC XXXX, where XXXX is the number assigned to this document at the
time of publication.
RFC YYYY, where YYYY is the number assigned to
[I-D.ietf-bfd-secure-sequence-numbers]
2025-11-12 with the actual date of the publication of this document.
2. Terminology 2. Terminology
The following terms used in this document have been defined in BFD The following terms used in this document have been defined in BFD
[RFC5880]. [RFC5880].
* Auth Type * Auth Type
* Detect Multiplier * Detect Multiplier
* Detection Time * Detection Time
The following terms are introduced in this document. The following terms are introduced in this document.
+==================+=========================================+ +==================+================================================+
| Term | Meaning | | Term | Meaning |
+==================+=========================================+ +==================+================================================+
| significant | State change, a demand mode change (to | | significant | A state change, demand mode change |
| change | D bit) or a poll sequence change (P or | | change | (to D bit), or poll sequence change |
| | F bit). Changes to BFD control packets | | | (P or F bit). Changes to BFD control |
| | that do not require a poll sequence, | | | packets that do not require a poll |
| | such as bfd.DetectMult are also | | | sequence, such as bfd.DetectMult, are |
| | considered as a significant change. | | | also considered a significant change. |
+------------------+-----------------------------------------+ +------------------+------------------------------------------------+
| More | The authentication mechanism applied to | | More | The authentication mechanism applied |
| Computationally | BFD Control Packets that are | | Computationally | to BFD Control Packets that are |
| Intensive (MCI) | significant changes. | | Intensive (MCI) | significant changes. |
| authentication | | | authentication | |
+------------------+-----------------------------------------+ +------------------+------------------------------------------------+
| Less | The authentication mechanism applied to | | Less | The authentication mechanism applied |
| Computationally | BFD Control Packets that are NOT | | Computationally | to BFD Control Packets that are NOT |
| Intensive (LCI) | significant changes. | | Intensive (LCI) | significant changes. |
| authentication | | | authentication | |
+------------------+-----------------------------------------+ +------------------+------------------------------------------------+
| configured MCI | Interval at which BFD control packets | | configured MCI | Interval at which BFD control packets |
| reauthentication | are retried using more computationally | | reauthentication | are retried using MCI authentication. |
| interval | intensive authentication. | | interval | |
+------------------+-----------------------------------------+ +------------------+------------------------------------------------+
Table 1 Table 1
The authentication mechanisms described in this optimization are The authentication mechanisms described in this optimization are
paired as more and less computationally intensive. While it will be paired as MCI and LCI. While it will be generally the case that the
generally the case that the relationship between these mechanisms relationship between these mechanisms will be "stronger" and "less
will be "stronger" and "less strong", this document doesn't use the strong", this document doesn't use the term "strong" to avoid
term "strong" to avoid conflation with either mechanism's relative conflation with either mechanism's relative cryptographic strength.
cryptographic strength. The relative criteria for each mechanism is The relative criteria for each mechanism is the impact on the
the impact on the implementation. implementation.
3. BFD Control Packets That Require More Computationally Intensive 3. BFD Control Packets That Require MCI Authentication
Authentication
The intention of these optimized procedures is to permit more The intention of these optimized procedures is to permit more
computationally intensive authentication for BFD state changes and computationally intensive authentication for BFD state changes and
utilize the less computationally intensive authentication mechanisms utilize the less computationally intensive authentication mechanisms
to provide protection for the session in the Up state while to provide protection for the session in the Up state while
performing less overall work. Such procedures are intended to aid performing less work overall. Such procedures are intended to aid
BFD session scaling without compromising BFD session security. BFD session scaling without compromising BFD session security.
All BFD Control Packets with the state AdminDown, Down, and Init MUST All BFD Control Packets with the state AdminDown, Down, and Init MUST
use MCI authentication. use MCI authentication.
Once the BFD state machine has reached the Up state, it will continue Once the BFD state machine has reached the Up state, it will continue
to send BFD Control Packets with MCI authentication in the Up state to send BFD Control Packets with MCI authentication in the Up state
for a period as discussed in Section 7.2. If optimized for a period as discussed in Section 7.2. If optimized
authentication mechanisms are in use, as defined in Section 6, the authentication mechanisms are in use, as defined in Section 6, the
session MAY switch to the LCI mode. session MAY switch to the LCI mode.
The contents of an Up packet must not change aside from the The contents of an Up packet must not change aside from the
Authentication Section unless MCI authentication is in use. Authentication Section unless MCI authentication is in use.
3.1. Protecting BFD Significant Changes with More Computationally 3.1. Protecting BFD Significant Changes with MCI Authentication
Intensive Authentication
This document proposes that BFD control packets that signal a state This document proposes that BFD control packets that signal a state
change, a change in demand mode (D bit), or a poll sequence (P or F change, a change in demand mode (D bit), or a poll sequence (P or F
bit change) be categorized as a "significant change". Control bit change) be categorized as a "significant change". Control
packets that do not require a poll sequence, such as bfd.DetectMult packets that do not require a poll sequence, such as bfd.DetectMult,
are also considered as a significant change. are also considered a significant change.
Such significant changes are intended to be protected by more Such significant changes are intended to be protected by more
computationally intensive authentication. computationally intensive authentication.
4. Using Less Computationally Intensive Auth Types 4. Using LCI Auth Types
The majority of packets exchanged in a BFD session in the Up state The majority of packets exchanged in a BFD session in the Up state
are not significant changes. This document proposes a new optimized are not significant changes. This document proposes a new optimized
authentication mode where packets that are not significant changes authentication mode where packets that are not significant changes
may use a less computationally intensive authentication mechanism. may use an LCI authentication mechanism.
Once the session has reached the Up state, the session can use a less Once the session has reached the Up state, the session can use an LCI
computationally intensive Auth Type derived from the format in Auth Type derived from the format in Section 7. Currently, this
Section 7. Currently, this includes: includes:
* Meticulous Keyed ISAAC authentication as described in * Meticulous Keyed ISAAC Authentication as described in [RFC9986].
[I-D.ietf-bfd-secure-sequence-numbers]. This authentication type This authentication type protects the BFD session when BFD Up
protects the BFD session when BFD Up packets do not change, packets do not change, because only the paired devices know the
because only the paired devices know the shared secret, key, and shared secret, key, and sequence number to select the ISAAC
sequence number to select the ISAAC result. result.
Other mechanisms may be defined in the future. Other mechanisms may be defined in the future.
5. Periodic More Computationally Intensive Reauthentication 5. Periodic MCI Reauthentication
When using the less computationally intensive authentication When using the LCI authentication mechanism, BFD should periodically
mechanism, BFD should periodically test the session using the MCI test the session using the MCI authentication mechanism. MCI
authentication mechanism. MCI authentication is tested using a Poll authentication is tested using a Poll sequence. To test MCI
sequence. To test MCI authentication, a Poll sequence SHOULD be authentication, a Poll sequence SHOULD be initiated by the sender
initiated by the sender using the MCI authentication mode rather than using the MCI authentication mode rather than the LCI mechanism. If
the LCI mechanism. If a control packet with the Final (F) bit is not a control packet with the Final (F) bit is not received using MCI
received using MCI authentication within twice the Detect Interval as authentication within twice the Detect Interval as would be
would be calculated by the receiving system, the session has been calculated by the receiving system, the session has been compromised,
compromised, and MUST be brought down. and it MUST be brought down.
The value "twice the Detect interval as would be calculated by the The value "twice the Detect interval as would be calculated by the
receiving system" is, roughly, twice the number of packets the local receiving system" is, roughly, twice the number of packets the local
system would transmit to the receiving system within its own Detect system would transmit to the receiving system within its own Detect
Interval. This accommodates for possible packet loss from the Interval. This accommodates for possible packet loss from the
sending system during the Poll sequence to the receiving system, plus sending system during the Poll sequence to the receiving system, plus
time for the receiving system to transmit control packet with the time for the receiving system to transmit control packet with the
Final (F) bit set to the local system. Final (F) bit set to the local system.
This "more computationally intensive reauthentication interval" for This "MCI reauthentication interval" for performing such periodic
performing such periodic tests using the more computationally tests using the MCI authentication mechanism can be configured
intensive authentication mechanism can be configured depending on the depending on the capability of the system.
capability of the system.
Most packets transmitted in a BFD session are BFD Up packets. MCI Most packets transmitted in a BFD session are BFD Up packets. MCI
authenticating a limited subset of these packets with a Poll sequence authenticating a limited subset of these packets with a Poll sequence
as described above, for example every one minute, significantly as described above, e.g., every one minute, significantly reduces the
reduces the computational demand for the system while maintaining computational demand for the system while maintaining security of the
security of the session across the configured MCI reauthentication session across the configured MCI reauthentication interval.
interval.
6. Optimized Authentication Modes 6. Optimized Authentication Modes
The cryptographic authentication mechanisms specified in Section 6.7 The cryptographic authentication mechanisms specified in Section 6.7
of BFD [RFC5880] describe enabling and disabling of authentication as of BFD [RFC5880] describe enabling and disabling of authentication as
a one time operation. "... implementations using this mechanism a one-time operation. The following is stated in Section 6.7.1 of
SHOULD only allow the authentication state to be changed at most once [RFC5880]:
without some form of intervention (so that authentication cannot be
turned on and off repeatedly simply based on the receipt of BFD | ... implementations using this method SHOULD only allow the
Control packets from remote systems)." (Section 6.7.1 of [RFC5880]) | authentication state to be changed at most once without some form
Once enabled, every packet must have Authentication Bit set and the | of intervention (so that authentication cannot be turned on and
associated Authentication Type appended (Section 4.1 of [RFC5880]). | off repeatedly simply based on the receipt of BFD Control packets
In addition, it states that an implementation SHOULD NOT allow the | from remote systems).
authentication state to be changed based on the receipt of a BFD
control packet. Once enabled, every packet must have the Authentication Bit set and
the associated Authentication Type appended (Section 4.1 of
[RFC5880]). In addition, it states that an implementation SHOULD NOT
allow the authentication state to be changed based on the receipt of
a BFD control packet.
This document proposes that an "optimized" authentication mode that This document proposes that an "optimized" authentication mode that
permits both a more computationally intensive authentication mode and permits both an MCI authentication mode and an LCI mode be used
a less computationally intensive mode to be used within the same BFD within the same BFD session. This pairing of an MCI and an LCI mode
session. This pairing of a MCI and a LCI mode of authentication is of authentication is carried in new BFD authentication types
carried in new BFD authentication types representing a given representing a given optimized authentication type pairing.
optimized authentication type pairing.
This document defines in Section 3.1 which BFD control packets This document defines which BFD control packets require MCI
require MCI authentication. A BFD control packet that fails authentication in Section 3.1. A BFD control packet that fails
authentication is discarded, or a BFD control packet that was authentication, or a BFD control packet that was supposed to be MCI-
supposed to be MCI authenticated, but was not; e.g. a significant authenticated but was not (e.g., a significant change packet), is
change packet, is discarded. However, there is no change to the discarded. However, there is no change to the state machine for BFD,
state machine for BFD, as the decision of a significant change is as the decision of a significant change is still decided by how many
still decided by how many valid consecutive packets were received. valid consecutive packets were received.
In this specification, the contents of an Up packet MUST NOT change In this specification, the contents of an Up packet MUST NOT change
aside from the Authentication Section without MCI authentication. aside from the Authentication Section without MCI authentication.
The full procedure is documented in the following sections. The full procedure is documented in the following sections.
7. Signaling Optimized Authentication 7. Signaling Optimized Authentication
When the Authentication Present (A) bit is set and the Auth Type When the Authentication Present (A) bit is set and the Auth Type
([RFC5880], Section 4.1) is a type supporting Optimized BFD ([RFC5880], Section 4.1) is a type supporting Optimized BFD
Authentication, the Auth Type signals a pairing of a more Authentication, the Auth Type signals a pairing of an MCI
computationally intensive authentication type and a less authentication type and an LCI authentication type. This pairing is
computationally intensive authentication type. This pairing is
advertised in a single Auth Type value in order to permit advertised in a single Auth Type value in order to permit
implementations to be aware that: implementations to be aware that:
* Optimized BFD procedures will be in use. * Optimized BFD procedures will be in use.
* The pairing of the MCI and LCI authentication mechanisms will be * The pairing of the MCI and LCI authentication mechanisms will be
used for that session. used for that session.
* The requirement to carry a Sequence Number. * The requirement to carry a Sequence Number.
* The current MCI or LCI mode will be carried as described below: * The current MCI or LCI mode will be carried as described below.
0 1 2 3 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 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 | Opt. Mode | | Auth Type | Auth Len | Auth Key ID | Opt. Mode |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sequence Number | | Sequence Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Authentication Specific Data ~ | Authentication Specific Data ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 1: Common Optimized BFD Authentication Section Figure 1: Common Optimized BFD Authentication Section
The values of Auth Type and Auth Len are defined in their respective The values of Auth Type and Auth Len are defined in their respective
optimized BFD authentication procedural documents. optimized BFD authentication procedural documents.
The values of the Optimized Authentication Mode field are: The values of the Optimized Authentication Mode field are:
1. When using the more computationally intensive authentication type 1. When using the MCI authentication type for optimized BFD Auth
for optimized BFD Auth Types. Types.
2. When using the less computationally intensive authentication type 2. When using the LCI authentication type for optimized BFD Auth
for optimized BFD Auth Types. Types.
Authentication Specific Data: When using the more computationally Authentication Specific Data: When using the more computationally
intensive authentication type, the remainder of the Authentication intensive authentication type, the remainder of the Authentication
Section carries that type's data. Section carries that type's data.
7.1. Transmitting and Receiving Using Optimized Authentication 7.1. Transmitting and Receiving Using Optimized Authentication
The procedures for authenticating BFD Control packets using Optimized The procedures for authenticating BFD Control packets using Optimized
Authentication is similar to the existing procedures covered in Authentication is similar to the existing procedures covered in
Section 6.7 of [RFC5880]. Optimized Authentication modes have common Section 6.7 of [RFC5880]. Optimized Authentication modes have common
procedural requirements for authentication regardless of which more procedural requirements for authentication regardless of which more
or less computationally intensive authentication modes are used. or less computationally intensive authentication modes are used.
The required value of the Auth Len field for a given Optimized The required value of the Auth Len field for a given Optimized
Authentication mode is defined in the respective specifications for Authentication mode is defined in the respective specifications for
their respective more and less computationally intensive modes. their respective MCI and LCI modes.
The following common procedures apply to authenticating BFD Control The following common procedures apply to authenticating BFD Control
packets utilizing Optimized Authentication: packets utilizing Optimized Authentication:
If the received BFD Control packet does not contain an Authentication If the received BFD Control packet does not contain an Authentication
Section ([RFC5880], Section 4.1), or the Auth Type is not a supported Section ([RFC5880], Section 4.1), or the Auth Type is not a supported
Optimized Authentication Auth Type, then the received packet MUST be Optimized Authentication Auth Type, then the received packet MUST be
discarded. discarded.
If the received BFD Control packet contains an optimized If the received BFD Control packet contains an optimized
authentication type using these procedures and the Optimized authentication type using these procedures and the Optimized
Authentication Mode field is not 1 or 2, then the received packet Authentication Mode field is not 1 or 2, then the received packet
MUST be discarded. MUST be discarded.
If bfd.SessionState is AdminDown, Down, or Init and the Optimized If bfd.SessionState is AdminDown, Down, or Init and the Optimized
Authentication Mode field is not 1, then the received packet MUST be Authentication Mode field is not 1, then the received packet MUST be
discarded. discarded.
If bfd.SessionState is Up and there is a significant change as If bfd.SessionState is Up and there is a significant change as
defined Section 3.1, and the Optimized Authentication Mode field is defined in Section 3.1, and the Optimized Authentication Mode field
not 1, then the received packet MUST be discarded. is not 1, then the received packet MUST be discarded.
If the Auth Len field is not equal to a value appropriate for the If the Auth Len field is not equal to a value appropriate for the
Optimized Authentication Mode field, the packet MUST be discarded. Optimized Authentication Mode field, the packet MUST be discarded.
If bfd.AuthSeqKnown is 1, examine the Sequence Number field. If the If bfd.AuthSeqKnown is 1, examine the Sequence Number field. If the
sequence number lies outside of the range of bfd.RcvAuthSeq+1 to sequence number lies outside of the range of bfd.RcvAuthSeq+1 to
bfd.RcvAuthSeq+(3*Detect Mult) inclusive (when treated as an unsigned bfd.RcvAuthSeq+(3*Detect Mult) inclusive (when treated as an unsigned
32-bit circular number space) the received packet MUST be discarded. 32-bit circular number space), the received packet MUST be discarded.
Otherwise (bfd.AuthSeqKnown is 0), bfd.AuthSeqKnown MUST be set to 1, Otherwise (bfd.AuthSeqKnown is 0), bfd.AuthSeqKnown MUST be set to 1,
bfd.RcvAuthSeq MUST be set to the value of the received Sequence bfd.RcvAuthSeq MUST be set to the value of the received Sequence
Number field, and the received packet MUST be accepted. Number field, and the received packet MUST be accepted.
For the specified Auth Type and Optimized Authentication Mode, For the specified Auth Type and Optimized Authentication Mode,
perform the appropriate authentication procedures. If authentication perform the appropriate authentication procedures. If authentication
succeeds, the received packet MUST be accepted. Otherwise, the succeeds, the received packet MUST be accepted. Otherwise, the
received packet MUST be discarded. received packet MUST be discarded.
7.2. Optimized Authentication Operations 7.2. Optimized Authentication Operations
As noted in Section 3.1, when using optimized BFD procedures, more As noted in Section 3.1, when using optimized BFD procedures, MCI
computationally intensive authentication is used in the BFD state authentication is used in the BFD state machine to bring a BFD
machine to bring a BFD session to the Up state or to make any change session to the Up state or to make any change of the BFD parameters
of the BFD parameters as carried in the BFD Control packet when in as carried in the BFD Control packet when in the Up state.
the Up state.
Once the BFD session has reached the Up state, the BFD Up state MUST Once the BFD session has reached the Up state, the BFD Up state MUST
be signaled to the remote BFD system using the MCI authentication be signaled to the remote BFD system using the MCI authentication
mode for an interval that is at least the Detection Time before mode for an interval that is at least the Detection Time before
switching to the LCI authentication mode. This is to permit switching to the LCI authentication mode. This is to permit
mechanisms such as Meticulous Keyed ISAAC for BFD Authentication mechanisms such as Meticulous Keyed ISAAC for BFD Optimized
[I-D.ietf-bfd-secure-sequence-numbers], or other approved less Authentication [RFC9986] or other approved, less intensive
intensive authentication mechanisms, to be bootstrapped before authentication mechanisms to be bootstrapped before switching to the
switching to the LCI mode. LCI mode.
It is RECOMMENDED that when using optimized authentication that It is RECOMMENDED that when using optimized authentication that
implementations switch from MCI authentication to LCI authentication implementations switch from MCI authentication to LCI authentication
mode after an interval that is at least the Detection Time. In the mode after an interval that is at least the Detection Time. In the
circumstances where a BFD session successfully reaches the Up state circumstances where a BFD session successfully reaches the Up state
with MCI authentication, but there are problems with the LCI with MCI authentication, but there are problems with the LCI
authentication, this will permit the remote system to tear down the authentication, this will permit the remote system to tear down the
session as quickly as possible. session as quickly as possible.
BFD sessions using optimized authentication that succeed in reaching BFD sessions using optimized authentication that succeed in reaching
the Up state using MCI authentication and fail using LCI the Up state using MCI authentication and fail using LCI
authentication SHOULD bring the issue to the attention of the authentication SHOULD bring the issue to the attention of the
operator. Further, implementations MAY wish to throttle session operator. Furthermore, implementations MAY wish to throttle session
restarts. restarts.
It is further RECOMMENDED that BFD implementations using optimized It is further RECOMMENDED that BFD implementations using optimized
authentication defer notifying their client that the session has authentication defer notifying their client that the session has
reached the Up state until it has transitioned to using the LCI reached the Up state until it has transitioned to using the LCI
authentication mode. In the event where LCI authentication is authentication mode. In the event where LCI authentication is
failing in the protocol, this avoids propagating the failed failing in the protocol, this avoids propagating the failed
transitions to the LCI mode to their clients. transitions to the LCI mode to their clients.
8. Optimizing Authentication YANG Data Model 8. Optimizing Authentication YANG Data Model
8.1. Data Model Overview 8.1. Data Model Overview
The YANG 1.1 [RFC7950] model defined in this document augments the The YANG 1.1 [RFC7950] data model defined in this document augments
"ietf-bfd" module to add data nodes relevant to the management of the the "ietf-bfd" module to add data nodes relevant to the management of
feature defined in this document. It adds an interval value that the feature defined in this document. It adds an interval value that
specifies how often the BFD session should be re-authenticated using specifies how often the BFD session should be reauthenticated using
more computationally intensive authentication once it is in the Up more computationally intensive authentication once it is in the Up
state. state.
8.2. Tree Diagram 8.2. Tree Diagram
The tree diagram for the YANG modules defined in this document use The tree diagram for the YANG modules defined in this document use
annotations defined in YANG Tree Diagrams. [RFC8340]. annotations defined in YANG Tree Diagrams [RFC8340].
module: ietf-bfd-opt-auth module: ietf-bfd-opt-auth
augment /rt:routing/rt:control-plane-protocols augment /rt:routing/rt:control-plane-protocols
/rt:control-plane-protocol/bfd:bfd/bfd-ip-sh:ip-sh /rt:control-plane-protocol/bfd:bfd/bfd-ip-sh:ip-sh
/bfd-ip-sh:sessions/bfd-ip-sh:session /bfd-ip-sh:sessions/bfd-ip-sh:session
/bfd-ip-sh:authentication: /bfd-ip-sh:authentication:
+--rw reauth-interval? uint32 +--rw reauth-interval? uint32
augment /rt:routing/rt:control-plane-protocols augment /rt:routing/rt:control-plane-protocols
/rt:control-plane-protocol/bfd:bfd/bfd-ip-mh:ip-mh /rt:control-plane-protocol/bfd:bfd/bfd-ip-mh:ip-mh
skipping to change at page 11, line 48 skipping to change at line 484
/bfd-lag:sessions/bfd-lag:session/bfd-lag:authentication: /bfd-lag:sessions/bfd-lag:session/bfd-lag:authentication:
+--rw reauth-interval? uint32 +--rw reauth-interval? uint32
augment /rt:routing/rt:control-plane-protocols augment /rt:routing/rt:control-plane-protocols
/rt:control-plane-protocol/bfd:bfd/bfd-mpls:mpls /rt:control-plane-protocol/bfd:bfd/bfd-mpls:mpls
/bfd-mpls:session-groups/bfd-mpls:session-group /bfd-mpls:session-groups/bfd-mpls:session-group
/bfd-mpls:authentication: /bfd-mpls:authentication:
+--rw reauth-interval? uint32 +--rw reauth-interval? uint32
8.3. The YANG Data Model 8.3. The YANG Data Model
This YANG module imports modules defined in YANG Key Chain [RFC8177], This YANG module imports modules defined in "YANG Data Model for Key
A YANG Data Model for Routing Management (NMDA version) [RFC8349], Chains" [RFC8177], "A YANG Data Model for Routing Management (NMDA
and YANG Data Model for Bidirectional Forwarding Detection (BFD) Version)" [RFC8349], and "YANG Data Model for Bidirectional
[RFC9314]. Forwarding Detection (BFD)" [RFC9314].
Implementations supporting the optimization procedures defined in Implementations supporting the optimization procedures defined in
this document enable optimization by using one of the newly defined this document enable optimization by using one of the newly defined
key-chain crypto-algorithms defined in this YANG module. key-chain crypto-algorithms defined in this YANG module.
<CODE BEGINS> file "ietf-bfd-opt-auth@2025-11-12.yang" <CODE BEGINS> file "ietf-bfd-opt-auth@2026-05-19.yang"
module ietf-bfd-opt-auth { module ietf-bfd-opt-auth {
yang-version 1.1; yang-version 1.1;
namespace "urn:ietf:params:xml:ns:yang:ietf-bfd-opt-auth"; namespace "urn:ietf:params:xml:ns:yang:ietf-bfd-opt-auth";
prefix "bfd-oa"; prefix bfd-oa;
import ietf-routing { import ietf-routing {
prefix "rt"; prefix rt;
reference reference
"RFC 8349: A YANG Data Model for Routing Management "RFC 8349: A YANG Data Model for Routing Management
(NMDA version)"; (NMDA version).";
} }
import ietf-bfd { import ietf-bfd {
prefix bfd; prefix bfd;
reference reference
"RFC 9314: YANG Data Model for Bidirectional "RFC 9314: YANG Data Model for Bidirectional
Forwarding Detection (BFD)."; Forwarding Detection (BFD).";
} }
import ietf-bfd-ip-sh { import ietf-bfd-ip-sh {
prefix bfd-ip-sh; prefix bfd-ip-sh;
reference reference
"RFC 9314: YANG Data Model for Bidirectional "RFC 9314: YANG Data Model for Bidirectional
Forwarding Detection (BFD)."; Forwarding Detection (BFD).";
} }
import ietf-bfd-ip-mh { import ietf-bfd-ip-mh {
prefix bfd-ip-mh; prefix bfd-ip-mh;
reference reference
"RFC 9314: YANG Data Model for Bidirectional "RFC 9314: YANG Data Model for Bidirectional
Forwarding Detection (BFD)."; Forwarding Detection (BFD).";
} }
import ietf-bfd-lag { import ietf-bfd-lag {
prefix bfd-lag; prefix bfd-lag;
reference reference
"RFC 9314: YANG Data Model for Bidirectional "RFC 9314: YANG Data Model for Bidirectional
Forwarding Detection (BFD)."; Forwarding Detection (BFD).";
} }
import ietf-bfd-mpls { import ietf-bfd-mpls {
prefix bfd-mpls; prefix bfd-mpls;
reference reference
"RFC 9314: YANG Data Model for Bidirectional "RFC 9314: YANG Data Model for Bidirectional
Forwarding Detection (BFD)."; Forwarding Detection (BFD).";
} }
organization organization
"IETF BFD Working Group"; "IETF Bidirectional Forwarding Detection (BFD) Working Group";
contact contact
"WG Web: <http://tools.ietf.org/wg/bfd> "WG Web: <http://tools.ietf.org/wg/bfd>
WG List: <rtg-bfd@ietf.org> WG List: <rtg-bfd@ietf.org>
Authors: Mahesh Jethanandani (mjethanandani@gmail.com) Authors: Mahesh Jethanandani (mjethanandani@gmail.com)
Ashesh Mishra (ashesh@aalyria.com) Ashesh Mishra (ashesh@aalyria.com)
Ankur Saxena (ankurpsaxena@gmail.com) Ankur Saxena (ankurpsaxena@gmail.com)
Manav Bhatia (mnvbhatia@google.com) Manav Bhatia (mnvbhatia@google.com)
Jeffrey Haas (jhaas@juniper.net)."; Jeffrey Haas (jhaas@juniper.net).";
description description
"This YANG module augments the base BFD YANG model to add "This YANG module augments the base BFD YANG module to add
attributes related to the experimental BFD Optimized attributes related to the experimental BFD Optimized
Authentication. Authentication.
Copyright (c) 2025 IETF Trust and the persons identified as 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. authors of the code. All rights reserved.
Redistribution and use in source and binary forms, with or Redistribution and use in source and binary forms, with or
without modification, is permitted pursuant to, and subject to without modification, is permitted pursuant to, and subject to
the license terms contained in, the Revised BSD License set the license terms contained in, the Revised BSD License set
forth in Section 4.c of the IETF Trust's Legal Provisions forth in Section 4.c of the IETF Trust's Legal Provisions
Relating to IETF Documents Relating to IETF Documents
(https://trustee.ietf.org/license-info). (https://trustee.ietf.org/license-info).
This version of this YANG module is part of RFC XXXX This version of this YANG module is part of RFC 9985
(https://www.rfc-editor.org/info/rfcXXXX); see the RFC itself (https://www.rfc-editor.org/info/rfc9985); see the RFC itself
for full legal notices. for full legal notices.";
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.";
revision "2025-11-12" { revision "2026-05-19" {
description description
"Initial Version."; "Initial Version.";
reference reference
"RFC XXXX: Optimizing BFD Authentication."; "RFC 9985: Optimizing BFD Authentication.";
} }
feature optimized-auth { feature optimized-auth {
description description
"Indicates that the implementation supports optimized "Indicates that the implementation supports optimized
authentication."; authentication.";
reference reference
"RFC XXXX: Optimizing BFD Authentication."; "RFC 9985: Optimizing BFD Authentication.";
} }
grouping bfd-opt-auth-config { grouping bfd-opt-auth-config {
description description
"Grouping for BFD Optimized Authentication Parameters."; "Grouping for BFD Optimized Authentication Parameters.";
leaf reauth-interval { leaf reauth-interval {
type uint32; type uint32;
units "seconds"; units "seconds";
default "60"; default "60";
description description
skipping to change at page 14, line 37 skipping to change at line 616
A value of zero means that we do not do periodic A value of zero means that we do not do periodic
reauthentication using the more computationally intensive reauthentication using the more computationally intensive
authentication method. authentication method.
This value SHOULD have jitter applied to it to avoid This value SHOULD have jitter applied to it to avoid
self-synchronization during expensive authentication self-synchronization during expensive authentication
operations."; operations.";
} }
} }
augment "/rt:routing/rt:control-plane-protocols" + augment "/rt:routing/rt:control-plane-protocols"
"/rt:control-plane-protocol/bfd:bfd/bfd-ip-sh:ip-sh" + + "/rt:control-plane-protocol/bfd:bfd/bfd-ip-sh:ip-sh"
"/bfd-ip-sh:sessions/bfd-ip-sh:session" + + "/bfd-ip-sh:sessions/bfd-ip-sh:session"
"/bfd-ip-sh:authentication" { + "/bfd-ip-sh:authentication" {
uses bfd-opt-auth-config; uses bfd-opt-auth-config;
description description
"Augment the 'authentication' container for single hop BFD "Augment the 'authentication' container for single hop BFD
module to add attributes related to BFD optimized module to add attributes related to BFD optimized
authentication."; authentication.";
} }
augment "/rt:routing/rt:control-plane-protocols/" + augment "/rt:routing/rt:control-plane-protocols"
"rt:control-plane-protocol/bfd:bfd/bfd-ip-mh:ip-mh/" + + "/rt:control-plane-protocol/bfd:bfd/bfd-ip-mh:ip-mh"
"bfd-ip-mh:session-groups/bfd-ip-mh:session-group/" + + "/bfd-ip-mh:session-groups/bfd-ip-mh:session-group"
"bfd-ip-mh:authentication" { + "/bfd-ip-mh:authentication" {
uses bfd-opt-auth-config; uses bfd-opt-auth-config;
description description
"Augment the 'authentication' container for multi-hop BFD "Augment the 'authentication' container for multi-hop BFD
module to add attributes related to BFD optimized module to add attributes related to BFD optimized
authentication."; authentication.";
} }
augment "/rt:routing/rt:control-plane-protocols/" + augment "/rt:routing/rt:control-plane-protocols"
"rt:control-plane-protocol/bfd:bfd/bfd-lag:lag/" + + "/rt:control-plane-protocol/bfd:bfd/bfd-lag:lag"
"bfd-lag:sessions/bfd-lag:session/" + + "/bfd-lag:sessions/bfd-lag:session"
"bfd-lag:authentication" { + "/bfd-lag:authentication" {
uses bfd-opt-auth-config; uses bfd-opt-auth-config;
description description
"Augment the 'authentication' container for BFD over LAG "Augment the 'authentication' container for BFD over LAG
module to add attributes related to BFD optimized module to add attributes related to BFD optimized
authentication."; authentication.";
} }
augment "/rt:routing/rt:control-plane-protocols/" + augment "/rt:routing/rt:control-plane-protocols"
"rt:control-plane-protocol/bfd:bfd/bfd-mpls:mpls/" + + "/rt:control-plane-protocol/bfd:bfd/bfd-mpls:mpls"
"bfd-mpls:session-groups/bfd-mpls:session-group/" + + "/bfd-mpls:session-groups/bfd-mpls:session-group"
"bfd-mpls:authentication" { + "/bfd-mpls:authentication" {
uses bfd-opt-auth-config; uses bfd-opt-auth-config;
description description
"Augment the 'authentication' container for BFD over MPLS "Augment the 'authentication' container for BFD over MPLS
module to add attributes related to BFD optimized module to add attributes related to BFD optimized
authentication."; authentication.";
} }
} }
<CODE ENDS> <CODE ENDS>
9. IANA Considerations 9. IANA Considerations
This documents requests the assignment of one URI and one YANG model. IANA has assigned one URI and one YANG module as described in this
section.
9.1. IETF XML Registry 9.1. IETF XML Registry
This document registers one URIs in the "ns" subregistry of the "IETF IANA has registered the following URI in the "ns" registry within the
XML" registry [RFC3688]. Following the format in [RFC3688], the "IETF XML Registry" group [RFC3688]:
following registration is requested:
URI: urn:ietf:params:xml:ns:yang:ietf-bfd-opt-auth URI: urn:ietf:params:xml:ns:yang:ietf-bfd-opt-auth
Registrant Contact: The IESG Registrant Contact: The IESG
XML: N/A, the requested URI is an XML namespace. XML: N/A; the requested URI is an XML namespace.
9.2. The YANG Module Names Registry 9.2. The YANG Module Names Registry
This document registers one YANG modules in the "YANG Module Names" IANA has registered the following YANG module in the "YANG Module
registry [RFC6020]. Following the format in [RFC6020], the following Names" registry [RFC6020] within the "YANG Parameters" registry
registrations are requested: group:
name: ietf-bfd-opt-auth Name: ietf-bfd-opt-auth
namespace: urn:ietf:params:xml:ns:yang:ietf-bfd-opt-auth Maintained by IANA: No
prefix: bfd-oa Namespace: urn:ietf:params:xml:ns:yang:ietf-bfd-opt-auth
maintained by IANA: No Prefix: bfd-oa
reference: RFC XXXX Reference: RFC 9985
10. Security Considerations 10. Security Considerations
10.1. Protocol Security Considerations 10.1. Protocol Security Considerations
Devices implementing BFD are often resource constrained, whether in a Devices implementing BFD are often resource-constrained, whether in a
single session, or a multidimensional set of scaled sessions. single session or a multidimensional set of scaled sessions. Desired
Desired detection intervals for the BFD sessions, and their number, detection intervals for the BFD sessions, and their number, are
are common scaling considerations for BFD implementations. Security common scaling considerations for BFD implementations. Security
mechanisms also impact the performance of implementations, whether in mechanisms also impact the performance of implementations, whether in
software or hardware, due to the use of additional computational software or hardware, due to the use of additional computational
resources these mechanisms use. resources these mechanisms use.
The optimized procedures in this document provide a different level The optimized procedures in this document provide a different level
of resistance to attack than methods using a single authentication of resistance to attack than methods using a single authentication
mechanism: mechanism:
* The more computationally intensive authentication mechanisms used * The MCI authentication mechanisms used for optimized
for optimized authentication are expected to have similar authentication are expected to have similar cryptographic strength
cryptographic strength acceptable for BFD for authenticating the acceptable for BFD for authenticating the entire session, as
entire session, as described in [RFC5880]. described in [RFC5880].
* When the BFD state machine is attempting to move from the Down * When the BFD state machine is attempting to move from the Down
state to the Up state, the more computationally intensive state to the Up state, the MCI authentication mechanism is
authentication mechanism is intended to protect vs. attempts to intended to protect vs. attempt to inappropriately start BFD
inappropriately start BFD sessions. sessions.
* When the BFD state machine is in the Up state, the more * When the BFD state machine is in the Up state, the MCI
computationally intensive authentication mechanism is intended to authentication mechanism is intended to protect vs. attempt to
protect vs. attempts to change BFD session parameters or to reset change BFD session parameters or to reset the BFD session.
the BFD session.
* When the BFD state machine is in the Up state, the less * When the BFD state machine is in the Up state, the LCI
computationally intensive authentication mechanism is intended to authentication mechanism is intended to provide resistance to
provide resistance to keeping a BFD session in the Up state keeping a BFD session in the Up state inappropriately. Since the
inappropriately. Since the procedures for changing BFD state procedures for changing BFD state require the MCI mechanism and
require the more computationally intensive mechanism and the less the LCI mechanism requires that the contents of the Control Packet
computationally intensive mechanism requires that the contents of in the Up state not change its contents, the only thing that
the Control Packet in the Up state not change its contents, the successfully spoofing such packets can do is keep the session Up.
only thing that successfully spoofing such packets can do is keep
the session Up.
* The periodic more computationally intensive re-authentication * The periodic, MCI reauthentication procedure provides protection
procedure provides protection against long-term successful against long-term successful spoofing of the LCI authentication
spoofing of the less computationally intensive authentication
mechanism. mechanism.
In other words, the intention of optimized BFD procedures is to make In other words, the intention of optimized BFD procedures is to make
it difficult to reset or inappropriately start BFD sessions. it difficult to reset or inappropriately start BFD sessions.
However, protecting against keeping the session Up is seen as a less However, protecting against keeping the session Up is seen as a less
interesting attack and can receive less protection. interesting attack and can receive less protection.
The recent escalating series of attacks on MD5 and SHA-1 described in The recent escalating series of attacks on MD5 and SHA-1 described in
Finding Collisions in the Full SHA-1 [SHA-1-attack1] and New Finding Collisions in the Full SHA-1 [SHA-1-attack1] and New
Collision Search for SHA-1 [SHA-1-attack2] raise concerns about their Collision Search for SHA-1 [SHA-1-attack2] raise concerns about their
remaining useful lifetime as outlined in Updated Security remaining useful lifetime as outlined in Updated Security
Considerations for the MD5 Message-Digest and the HMAC-MD5 Algorithm Considerations for the MD5 Message-Digest and the HMAC-MD5 Algorithm
[RFC6151] and Security Considerations for the SHA-0 and SHA-1 [RFC6151] and Security Considerations for the SHA-0 and SHA-1
Message-Digest Algorithm [RFC6194]. If replaced by stronger Message-Digest Algorithm [RFC6194]. If replaced by stronger
algorithms the computational overhead will make the task of algorithms, the computational overhead will make the task of
authenticating every packet even more difficult to achieve. authenticating every packet even more difficult to achieve.
The procedures described in this document provide a mechanism which The procedures described in this document provide a mechanism that
could enable implementations to leverage stronger security to address could enable implementations to leverage stronger security to address
the concerns above when strong authentication is required. However, the concerns above when strong authentication is required. However,
this requires operators to evaluate the tradeoffs of the less this requires operators to evaluate the trade-offs of the less
computationally intensive mechanisms adequately address their desired computationally intensive mechanisms to adequately address their
security stance. desired security stance.
Keys generated and distributed out of band for the purposes described Keys generated and distributed out of band for the purposes described
in this specification are generally limited in the security they can in this specification are generally limited in the security they can
provide. It is essential that these keys are selected well, and provide. It is essential that these keys are selected well and
protected when stored. protected when stored.
10.2. YANG Security Considerations 10.2. YANG Security Considerations
This section is modeled after the template described in Section 3.7 This section is modeled after the template described in Section 3.7.1
of [I-D.ietf-netmod-rfc8407bis]. of [RFC9907].
The "ietf-bfd-opt-auth" YANG module defines a data model that is The "ietf-bfd-opt-auth" YANG module defines a data model that is
designed to be accessed via YANG-based management protocols, such as designed to be accessed via YANG-based management protocols, such as
NETCONF [RFC6241] or RESTCONF [RFC8040]. These YANG-based management the Network Configuration Protocol (NETCONF) [RFC6241] and RESTCONF
protocols (1) have to use a secure transport layer (e.g., SSH [RFC8040]. These YANG-based management protocols (1) have to use a
[RFC4252] TLS [RFC8446], and QUIC [RFC9000]) and (2) have to use secure transport layer (e.g., Secure Shell (SSH) [RFC4252], TLS
mutual authentication. [RFC8446], and QUIC [RFC9000]) and (2) have to use mutual
authentication.
The Network Configuration Access Control Model (NACM) [RFC8341] The Network Configuration Access Control Model (NACM) [RFC8341]
provides the means to restrict access for particular NETCONF or provides the means to restrict access for particular NETCONF or
RESTCONF users to a preconfigured subset of all available NETCONF or RESTCONF users to a preconfigured subset of all available NETCONF or
RESTCONF protocol operations and content. RESTCONF protocol operations and content.
There are a number of data nodes defined in this YANG module that are There are a number of data nodes defined in this YANG module that are
writable/creatable/deletable (i.e., "config true", which is the writable/creatable/deletable (i.e., "config true", which is the
default). All writable data nodes are likely to be sensitive or default). All writable data nodes are likely to be sensitive or
vulnerable in some network environments. Write operations (e.g., vulnerable in some network environments. Write operations (e.g.,
edit-config) and delete operations to these data nodes without proper edit-config) and delete operations to these data nodes without proper
protection or authentication can have a negative effect on network protection or authentication can have a negative effect on network
operations. The following subtrees and data nodes have particular operations. The following subtrees and data nodes have particular
sensitivities/vulnerabilities: sensitivities/vulnerabilities:
* 'reauth-interval' specifies the interval in Up state, after which * 'reauth-interval' specifies the interval in Up state, after which
more computationally intensive authentication SHOULD be performed MCI authentication SHOULD be performed to prevent a Person-in-the-
to prevent a Person-In-The-Middle (PITM) attack. If this interval Middle (PITM) attack. If this interval is set very low, the
is set very low, the utility of these optimization procedures is utility of these optimization procedures is lessened. If this
lessened. If this interval is set very high, attacks detected by interval is set very high, attacks detected by the MCI
the more computationally intensive authentication mechanisms may authentication mechanisms may happen overly late.
happen overly late.
There are no particularly sensitive readable data nodes. There are no particularly sensitive readable data nodes.
There are no RPC operations defined in this model. There are no RPC operations defined in this model.
11. Contributors 11. References
The authors of this document would like to acknowledge Reshad Rahman
as a contributor to this document.
12. Acknowledgments
The authors would like to thank Qiufang Ma, Stephen Farrell, and Acee
Lindem for providing directorate review of this document.
13. References
13.1. Normative References 11.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997, DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>. <https://www.rfc-editor.org/info/rfc2119>.
[RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688,
DOI 10.17487/RFC3688, January 2004, DOI 10.17487/RFC3688, January 2004,
<https://www.rfc-editor.org/info/rfc3688>. <https://www.rfc-editor.org/info/rfc3688>.
skipping to change at page 19, line 51 skipping to change at line 845
Routing Management (NMDA Version)", RFC 8349, Routing Management (NMDA Version)", RFC 8349,
DOI 10.17487/RFC8349, March 2018, DOI 10.17487/RFC8349, March 2018,
<https://www.rfc-editor.org/info/rfc8349>. <https://www.rfc-editor.org/info/rfc8349>.
[RFC9314] Jethanandani, M., Ed., Rahman, R., Ed., Zheng, L., Ed., [RFC9314] Jethanandani, M., Ed., Rahman, R., Ed., Zheng, L., Ed.,
Pallagatti, S., and G. Mirsky, "YANG Data Model for Pallagatti, S., and G. Mirsky, "YANG Data Model for
Bidirectional Forwarding Detection (BFD)", RFC 9314, Bidirectional Forwarding Detection (BFD)", RFC 9314,
DOI 10.17487/RFC9314, September 2022, DOI 10.17487/RFC9314, September 2022,
<https://www.rfc-editor.org/info/rfc9314>. <https://www.rfc-editor.org/info/rfc9314>.
13.2. Informative References 11.2. Informative References
[I-D.ietf-bfd-secure-sequence-numbers]
DeKok, A., Jethanandani, M., Agarwal, S., Mishra, A., and
J. Haas, "Meticulous Keyed ISAAC for BFD Optimized
Authentication", Work in Progress, Internet-Draft, draft-
ietf-bfd-secure-sequence-numbers-27, 16 October 2025,
<https://datatracker.ietf.org/doc/html/draft-ietf-bfd-
secure-sequence-numbers-27>.
[I-D.ietf-netmod-rfc8407bis]
Bierman, A., Boucadair, M., and Q. Wu, "Guidelines for
Authors and Reviewers of Documents Containing YANG Data
Models", Work in Progress, Internet-Draft, draft-ietf-
netmod-rfc8407bis-28, 5 June 2025,
<https://datatracker.ietf.org/doc/html/draft-ietf-netmod-
rfc8407bis-28>.
[RFC1321] Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321, [RFC1321] Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321,
DOI 10.17487/RFC1321, April 1992, DOI 10.17487/RFC1321, April 1992,
<https://www.rfc-editor.org/info/rfc1321>. <https://www.rfc-editor.org/info/rfc1321>.
[RFC2026] Bradner, S., "The Internet Standards Process -- Revision [RFC2026] Bradner, S., "The Internet Standards Process -- Revision
3", BCP 9, RFC 2026, DOI 10.17487/RFC2026, October 1996, 3", BCP 9, RFC 2026, DOI 10.17487/RFC2026, October 1996,
<https://www.rfc-editor.org/info/rfc2026>. <https://www.rfc-editor.org/info/rfc2026>.
[RFC3174] Eastlake 3rd, D. and P. Jones, "US Secure Hash Algorithm 1 [RFC3174] Eastlake 3rd, D. and P. Jones, "US Secure Hash Algorithm 1
skipping to change at page 21, line 22 skipping to change at line 895
[RFC8341] Bierman, A. and M. Bjorklund, "Network Configuration [RFC8341] Bierman, A. and M. Bjorklund, "Network Configuration
Access Control Model", STD 91, RFC 8341, Access Control Model", STD 91, RFC 8341,
DOI 10.17487/RFC8341, March 2018, DOI 10.17487/RFC8341, March 2018,
<https://www.rfc-editor.org/info/rfc8341>. <https://www.rfc-editor.org/info/rfc8341>.
[RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol [RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol
Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018,
<https://www.rfc-editor.org/info/rfc8446>. <https://www.rfc-editor.org/info/rfc8446>.
[RFC8792] Watsen, K., Auerswald, E., Farrel, A., and Q. Wu,
"Handling Long Lines in Content of Internet-Drafts and
RFCs", RFC 8792, DOI 10.17487/RFC8792, June 2020,
<https://www.rfc-editor.org/info/rfc8792>.
[RFC9000] Iyengar, J., Ed. and M. Thomson, Ed., "QUIC: A UDP-Based [RFC9000] Iyengar, J., Ed. and M. Thomson, Ed., "QUIC: A UDP-Based
Multiplexed and Secure Transport", RFC 9000, Multiplexed and Secure Transport", RFC 9000,
DOI 10.17487/RFC9000, May 2021, DOI 10.17487/RFC9000, May 2021,
<https://www.rfc-editor.org/info/rfc9000>. <https://www.rfc-editor.org/info/rfc9000>.
[RFC9907] Bierman, A., Boucadair, M., Ed., and Q. Wu, "Guidelines
for Authors and Reviewers of Documents Containing YANG
Data Models", BCP 216, RFC 9907, DOI 10.17487/RFC9907,
March 2026, <https://www.rfc-editor.org/info/rfc9907>.
[RFC9986] DeKok, A., Jethanandani, M., Agarwal, S., Mishra, A., and
J. Haas, "Meticulous Keyed ISAAC for Bidirectional
Forwarding Detection (BFD) Optimized Authentication",
RFC 9986, May 2026,
<https://www.rfc-editor.org/info/rfc9986>.
[SHA-1-attack1] [SHA-1-attack1]
Wang, X., Yin, Y., and H. Yu, "Finding Collisions in the Wang, X., Yin, Y., and H. Yu, "Finding Collisions in the
Full SHA-1", 2005. Full SHA-1", 2005.
[SHA-1-attack2] [SHA-1-attack2]
Wang, X., Yao, A., and F. Yao, "New Collision Search for Wang, X., Yao, A., and F. Yao, "New Collision Search for
SHA-1", 2005. SHA-1", 2005.
Appendix A. Examples Appendix A. Examples
This section tries to show some examples in how the model can be This section tries to show some examples in how the model can be
configured. configured.
A.1. Single Hop BFD Configuration A.1. Single Hop BFD Configuration
This example demonstrates how a Single Hop BFD session can be This example demonstrates how a Single Hop BFD session can be
configured for optimized authentication. configured for optimized authentication. Note that line wrapping is
used per [RFC8792].
=============== NOTE: '\' line wrapping per RFC 8792 =============== =============== NOTE: '\' line wrapping per RFC 8792 ===============
<?xml version="1.0" encoding="UTF-8"?> <?xml version="1.0" encoding="UTF-8"?>
<key-chains <key-chains
xmlns="urn:ietf:params:xml:ns:yang:ietf-key-chain" xmlns="urn:ietf:params:xml:ns:yang:ietf-key-chain"
xmlns:opt-auth="urn:ietf:params:xml:ns:yang:ietf-bfd-opt-auth" xmlns:opt-auth="urn:ietf:params:xml:ns:yang:ietf-bfd-opt-auth"
xmlns:bfd-mki="urn:ietf:params:xml:ns:yang:ietf-bfd-met-keyed-i\ xmlns:bfd-mki="urn:ietf:params:xml:ns:yang:ietf-bfd-met-keyed-i\
saac"> saac">
<key-chain> <key-chain>
skipping to change at page 23, line 35 skipping to change at line 1022
This document describes an experiment that presents a candidate This document describes an experiment that presents a candidate
solution to update BFD Authentication that is currently specified in solution to update BFD Authentication that is currently specified in
[RFC5880]. This experiment is intended to provide additional [RFC5880]. This experiment is intended to provide additional
insights into what happens when the optimized authentication insights into what happens when the optimized authentication
mechanism defined in this document is used. Here are the reasons why mechanism defined in this document is used. Here are the reasons why
this document is on the Experimental track: this document is on the Experimental track:
* In the initial stages of the document, there were significant * In the initial stages of the document, there were significant
participation and reviews from the working group. Since then, participation and reviews from the working group. Since then,
there has been considerable changes to the document, e.g. the use there has been considerable changes to the document, e.g., the use
of ISAAC, allowing for ISAAC bootstrapping when a BFD session of ISAAC, allowing for ISAAC bootstrapping when a BFD session
comes up and use of a single Auth Type to indicate use of comes up and use of a single Auth Type to indicate use of
optimized authentication etc. These changes did not get optimized authentication, etc. These changes did not get
significant review from the working group and therefore does not significant review from the working group and therefore do not
meet the bar set in Section 4.1.1 of [RFC2026] meet the bar set in Section 4.1.1 of [RFC2026].
* There are no known implementations at this time. * There are no known implementations at this time.
* The work in this document could become very valuable in the * The work in this document could become very valuable in the
future, especially if the need for deploying BFD authentication at future, especially if the need for deploying BFD authentication at
scale becomes a reality. scale becomes a reality.
This document is classified as Experimental and is not part of the This document is classified as Experimental and is not part of the
IETF Standards Track. Implementations based on this document should IETF Standards Track. Implementations based on this document should
not be considered as compliant with BFD [RFC5880]. not be considered as compliant with BFD [RFC5880].
Acknowledgments
The authors would like to thank Qiufang Ma, Stephen Farrell, and Acee
Lindem for providing directorate reviews of this document.
Contributors
The authors of this document would like to acknowledge Reshad Rahman
as a contributor to this document.
Authors' Addresses Authors' Addresses
Mahesh Jethanandani Mahesh Jethanandani
Arrcus Arrcus
United States of America United States of America
Email: mjethanandani@gmail.com Email: mjethanandani@gmail.com
Ashesh Mishra Ashesh Mishra
Aalyria Technologies Aalyria Technologies
Email: ashesh@aalyria.com Email: ashesh@aalyria.com
Jeffrey Haas Jeffrey Haas
HPE HPE
Email: jhaas@juniper.net Email: jhaas@pfrc.org
Ankur Saxena Ankur Saxena
Ciena Corporation Ciena Corporation
3939 N 1st Street 3939 N 1st Street
San Jose, CA 95134 San Jose, CA 95134
United States of America United States of America
Email: ankurpsaxena@gmail.com Email: ankurpsaxena@gmail.com
Manav Bhatia Manav Bhatia
Google Google
 End of changes. 97 change blocks. 
364 lines changed or deleted 340 lines changed or added

This html diff was produced by rfcdiff 1.48.