rfc9985xml2.original.xml   rfc9985.xml 
<?xml version="1.0" encoding="US-ASCII"?> <?xml version='1.0' encoding='UTF-8'?>
<?rfc toc="yes"?> <?xml-model href="rfc7991bis.rnc"?>
<?rfc tocompact="yes"?>
<?rfc tocdepth="3"?> <!DOCTYPE rfc [
<?rfc tocindent="yes"?> <!ENTITY nbsp "&#160;">
<?rfc symrefs="yes"?> <!ENTITY zwsp "&#8203;">
<?rfc sortrefs="yes"?> <!ENTITY nbhy "&#8209;">
<?rfc comments="yes"?> <!ENTITY wj "&#8288;">
<?rfc inline="yes"?> ]>
<?rfc compact="yes"?>
<?rfc subcompact="no"?> <rfc xmlns:xi="http://www.w3.org/2001/XInclude" category="exp" docName="draft-ie
<rfc tf-bfd-optimizing-authentication-36" number="9985" updates="" obsoletes="" ipr="
category="exp" trust200902" submissionType="IETF" consensus="true" tocInclude="true" tocDepth="
docName="draft-ietf-bfd-optimizing-authentication-36" 3" symRefs="true" sortRefs="true" version="3" xml:lang="en">
ipr="trust200902"
submissionType="IETF"
consensus="true">
<front> <front>
<title abbrev="BFD Authentication Optimization">Optimizing BFD <!-- [rfced] We have updated the title of the document to expand
Authentication</title> "BFD". Also, note that RFCs containing YANG usually follow the
pattern of "A YANG Data Model for <Foo>". Given this, please let
us know if/how the title may be further updated.
<author fullname="Mahesh Jethanandani" initials="M." Original:
surname="Jethanandani"> Optimizing BFD Authentication
Current:
Optimizing Bidirectional Forwarding Detection (BFD) Authentication
Perhaps:
A YANG Data Model for Optimizing Bidirectional Forwarding
Detection (BFD) Authentication
-->
<title abbrev="BFD Authentication Optimization">Optimizing Bidirectional For
warding Detection (BFD)
Authentication</title>
<seriesInfo name="RFC" value="9985"/>
<author fullname="Mahesh Jethanandani" initials="M." surname="Jethanandani">
<organization>Arrcus</organization> <organization>Arrcus</organization>
<address> <address>
<postal> <postal>
<street/> <country>United States of America</country>
<city/>
<region/>
<code/>
<country>USA</country>
</postal> </postal>
<phone/>
<facsimile/>
<email>mjethanandani@gmail.com</email> <email>mjethanandani@gmail.com</email>
<uri/>
</address> </address>
</author> </author>
<author fullname="Ashesh Mishra" initials="A" surname="Mishra"> <author fullname="Ashesh Mishra" initials="A" surname="Mishra">
<organization>Aalyria Technologies</organization> <organization>Aalyria Technologies</organization>
<address> <address>
<postal>
<street/>
<city/>
<region/>
<code/>
<country/>
</postal>
<phone/>
<email>ashesh@aalyria.com</email> <email>ashesh@aalyria.com</email>
</address> </address>
</author> </author>
<!--[rfced] Jeffery, we updated your email address to
"jhaas@pfrc.org". Your affiliation is listed "HPE"; please let us
know if an update is needed or if this is okay as is.
-->
<author fullname="Jeffrey Haas" initials="J." surname="Haas"> <author fullname="Jeffrey Haas" initials="J." surname="Haas">
<organization>HPE</organization> <organization>HPE</organization>
<address> <address>
<email>jhaas@juniper.net</email> <email>jhaas@pfrc.org</email>
</address> </address>
</author> </author>
<author fullname="Ankur Saxena" initials="A" surname="Saxena"> <author fullname="Ankur Saxena" initials="A" surname="Saxena">
<organization>Ciena Corporation</organization> <organization>Ciena Corporation</organization>
<address> <address>
<postal> <postal>
<street>3939 N 1st Street</street> <street>3939 N 1st Street</street>
<city>San Jose</city> <city>San Jose</city>
<region>CA</region> <region>CA</region>
<code>95134</code> <code>95134</code>
<country>USA</country> <country>United States of America</country>
</postal> </postal>
<phone/>
<facsimile/>
<email>ankurpsaxena@gmail.com</email> <email>ankurpsaxena@gmail.com</email>
<uri/>
</address> </address>
</author> </author>
<author fullname="Manav Bhatia" initials="M." surname="Bhatia">
<author fullname="Manav Bhatia " initials="M." surname="Bhatia ">
<organization>Google</organization> <organization>Google</organization>
<address> <address>
<postal> <postal>
<street>Doddanekkundi</street> <street>Doddanekkundi</street>
<city>Bangalore</city> <city>Bangalore</city>
<code>560048</code> <code>560048</code>
<country>India</country> <country>India</country>
</postal> </postal>
<email>mnvbhatia@google.com</email> <email>mnvbhatia@google.com</email>
</address> </address>
</author> </author>
<date year="2025" month="May"/>
<area>RTG</area>
<workgroup>bfd</workgroup>
<date/>
<keyword>BFD</keyword> <keyword>BFD</keyword>
<keyword>authentication</keyword> <keyword>authentication</keyword>
<abstract> <abstract>
<t> <t>
This document describes an experimental optimization to BFD Authenticatio n. This document describes an experimental optimization to Bidirectional For warding Detection (BFD) Authentication.
This optimization enables BFD to scale better when there is a desire to This optimization enables BFD to scale better when there is a desire to
use authentication where applying the same authentication mechanism to use authentication where applying the same authentication mechanism to
every BFD Control Packet may adversely impact performance. every BFD Control Packet may adversely impact performance.
This optimization partitions BFD Authentication into a more This optimization partitions BFD Authentication into a more
computationally intensive mechanism that is applied to BFD significant computationally intensive (MCI) mechanism that is applied to BFD signific
changes, and a less computationally intensive mechanism applied to the ant
changes and a less computationally intensive (LCI) mechanism that is appl
ied to the
majority of BFD Control Packets. majority of BFD Control Packets.
</t> </t>
</abstract> </abstract>
</front> </front>
<middle> <middle>
<section anchor="introduction" title="Introduction"> <section anchor="introduction">
<name>Introduction</name>
<t><xref target="RFC5880">BFD</xref> authentication procedures, when enabl ed, <t><xref target="RFC5880">BFD</xref> authentication procedures, when enabl ed,
authenticate each control packet using the same authentication mechanism. authenticate each control packet using the same authentication mechanism.
Devices implementing BFD are often resource constrained and authentication Devices 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.</t> deployment of authentication.</t>
<t>When implemented in software, BFD authentication mechanisms compete <t>When implemented in software, BFD authentication mechanisms compete
with other necessary work done by the systems implementing the protocol. with other necessary work done by the systems implementing the protocol.
When implemented using hardware acceleration, these mechanisms may scale When implemented using hardware acceleration, these mechanisms may scale
better situationally, but still impose a cost on the implementation. better situationally, but they still impose a cost on the implementation.
BFD's value is tied to its ability to scale in terms of numbers of BFD's value is tied to its ability to scale in terms of numbers of
sessions, and a detection time that relies on sending its control packets sessions and a detection time that relies on sending its control packets
at a high rate. Implementers and operators are forced to evaluate at a high rate. Implementers and operators are forced to evaluate
tradeoffs of the benefits of authentication vs. its impact on BFD trade-offs of the benefits of authentication vs. its impact on BFD
performance.</t> performance.</t>
<t>The authentication mechanisms documented in <xref target="RFC5880"/>, <t>The authentication mechanisms documented in <xref target="RFC5880"/>,
<xref target="RFC1321">MD5 Message-Digest Algorithm </xref> and <xref target="RFC1321">MD5 Message-Digest Algorithm </xref>, and
<xref target="RFC3174">Secure Hash Algorithm (SHA-1)</xref>, are not <xref target="RFC3174">Secure Hash Algorithm (SHA-1)</xref> are not
particularly strong in a cryptographic sense. However, they may still not particularly strong in a cryptographic sense. However, they may still not
appropriately scale situationally in a given implementation. In the appropriately scale situationally in a given implementation. In the
future, there may be a desire to use stronger authentication mechanisms future, there may be a desire to use stronger authentication mechanisms
than those already specified, and those mechanisms are likely to use even than those already specified, and those mechanisms are likely to use even
more resources.</t> more resources.</t>
<t>The BFD protocol can broadly be described as the set of procedures
<t>The BFD prototocol can broadly be described as the set of procedures
that handle its state machine changes to reach the Up state, and once BFD 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 high rate. is in the Up state, it will send those Up packets at the negotiated high r ate.
The number of BFD Control Packets needed to signal state changes (called The number of BFD Control Packets needed to signal state changes (called
significant changes) is very small, while the majority of the Control significant changes) is very small, while the majority of the Control
Packets validate that the session remains in the Up state.</t> Packets validate that the session remains in the Up state.</t>
<t>This document describes an experimental optimization to BFD <t>This document describes an experimental optimization to BFD
Authentication. This optimization partitions BFD Authentication into a Authentication. This optimization partitions BFD Authentication into a
more computationally intensive (MCI) mechanism used to authenticate more computationally intensive (MCI) mechanism used to authenticate
significant changes, and a less computationally intensive (LCI) mechanism significant changes, and a less computationally intensive (LCI) mechanism
applied to the majority of the BFD Control Packets that don't signal such applied to the majority of the BFD Control Packets that don't signal such
significant changes.</t> significant changes.</t>
<t>The details of the motivation for experimental status are given in <t>The details of the motivation for experimental status are given in
<xref target="experiment"/>.</t> <xref target="experiment"/>.</t>
<section>
<section title="Requirements Language"> <name>Requirements Language</name>
<t>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 <xref target="RFC2119"/>
<xref target="RFC8174"/> when, and only when, they appear in
all capitals, as shown here.</t>
</section>
<section anchor="note-to-rfc-editor" title="Note to RFC Editor">
<t>
This document uses several placeholder values throughout the
document. Please replace them as follows and remove this
note before publication.
</t>
<t>
RFC XXXX, where XXXX is the number assigned to this document
at the time of publication.
</t>
<t>
RFC YYYY, where YYYY is the number assigned to <xref
target="I-D.ietf-bfd-secure-sequence-numbers"/>
</t>
<t> <t>
2025-11-12 with the actual date of the publication of this The key words "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>", "<bcp14>REQU
document. IRED</bcp14>", "<bcp14>SHALL</bcp14>", "<bcp14>SHALL
</t> NOT</bcp14>", "<bcp14>SHOULD</bcp14>", "<bcp14>SHOULD NOT</bcp14>", "<bcp14>
RECOMMENDED</bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>",
"<bcp14>MAY</bcp14>", and "<bcp14>OPTIONAL</bcp14>" in this document are to
be interpreted as
described in BCP&nbsp;14 <xref target="RFC2119"/> <xref target="RFC8174"/>
when, and only when, they appear in all capitals, as shown here.
</t>
</section> </section>
</section> </section>
<section>
<section title="Terminology"> <name>Terminology</name>
<t>The following terms used in this document have been defined in <t>The following terms used in this document have been defined in
<xref target="RFC5880">BFD</xref>.</t> <xref target="RFC5880">BFD</xref>.</t>
<ul spacing="normal">
<t><list style="symbols"> <li>
<t>Auth Type</t> <t>Auth Type</t>
<t>Detect Multiplier</t> </li>
<t>Detection Time</t> <li>
</list></t> <t>Detect Multiplier</t>
</li>
<li>
<t>Detection Time</t>
</li>
</ul>
<t>The following terms are introduced in this document.</t> <t>The following terms are introduced in this document.</t>
<!-- [rfced] Would you like to use a definition list format for the
terminology listed in Section 2 as opposed to a table? See one
example entry below.
<texttable style="full"> Perhaps:
<ttcol>Term</ttcol> significant change: A state change, demand mode change (to D bit),
<ttcol>Meaning</ttcol> or poll sequence change (P or F bit). Changes to BFD control
<c>significant change</c> packets that do not require a poll sequence, such as
<c> bfd.DetectMult, are also considered a significant change.
State change, a demand mode change (to D bit) or a poll -->
<table>
<thead>
<tr>
<th>Term</th>
<th>Meaning</th>
</tr>
</thead>
<tbody>
<tr>
<td>significant change</td>
<td>
A state change, demand mode change (to D bit), or poll
sequence change (P or F bit). Changes to BFD control packets that sequence change (P or F bit). Changes to BFD control packets that
do not require a poll sequence, such as bfd.DetectMult are also do not require a poll sequence, such as bfd.DetectMult, are also
considered as a significant change. considered a significant change.
</c> </td>
<c>More Computationally Intensive (MCI) authentication</c> </tr>
<c> <tr>
<td>More Computationally Intensive (MCI) authentication</td>
<td>
The authentication mechanism applied to BFD Control Packets that are The authentication mechanism applied to BFD Control Packets that are
significant changes. significant changes.
</c> </td>
<c>Less Computationally Intensive (LCI) authentication</c> </tr>
<c> <tr>
<td>Less Computationally Intensive (LCI) authentication</td>
<td>
The authentication mechanism applied to BFD Control Packets that are The authentication mechanism applied to BFD Control Packets that are
NOT significant changes. NOT significant changes.
</c> </td>
<c>configured MCI reauthentication interval</c> </tr>
<c> <tr>
<td>configured MCI reauthentication interval</td>
<td>
Interval at which BFD control packets are retried using Interval at which BFD control packets are retried using
more computationally intensive authentication. MCI authentication.
</c> </td>
</texttable> </tr>
</tbody>
</table>
<t> <t>
The authentication mechanisms described in this optimization are paired The authentication mechanisms described in this optimization are paired
as more and less computationally intensive. While it will be generally as MCI and LCI. While it will be generally
the case that the relationship between these mechanisms will be the case that the relationship between these mechanisms will be
"stronger" and "less strong", this document doesn't use the term "stronger" and "less strong", this document doesn't use the term
"strong" to avoid conflation with either mechanism's relative "strong" to avoid conflation with either mechanism's relative
cryptographic strength. The relative criteria for each mechanism is the cryptographic strength. The relative criteria for each mechanism is the
impact on the implementation. impact on the implementation.
</t> </t>
</section> </section>
<section anchor="strong_authentication">
<section anchor="strong authentication" title="BFD Control Packets That <name>BFD Control Packets That Require MCI Authentication</name>
Require More Computationally Intensive Authentication">
<!-- <!--
<t> <t>
For purposes of this document, "strong authentication" refers to BFD For purposes of this document, "strong authentication" refers to BFD
authentication mechanisms such as those already defined for use with BFD. authentication mechanisms such as those already defined for use with BFD.
For example, MD5 and SHA1 For example, MD5 and SHA1
(<xref target="RFC5880" section="6.7"/>). (<xref target="RFC5880" section="6.7"/>).
</t> </t>
--> -->
<t> <t>
The intention of these optimized procedures is to permit more The intention of these optimized procedures is to permit more
computationally intensive computationally intensive
authentication for BFD state changes and utilize the less authentication for BFD state changes and utilize the less
computationally intensive authentication mechanisms to provide computationally intensive authentication mechanisms to provide
protection for the session in the Up state while performing less protection for the session in the Up state while performing less
overall work. Such procedures are intended to aid BFD session scaling work overall. Such procedures are intended to aid BFD session scaling
without compromising BFD session security. without compromising BFD session security.
</t> </t>
<t>All BFD Control Packets with the state AdminDown, Down, and Init <t>All BFD Control Packets with the state AdminDown, Down, and Init
MUST use MCI authentication.</t> <bcp14>MUST</bcp14> use MCI authentication.</t>
<t>Once the BFD state machine has reached the Up state, it will continue <t>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 for a period as discussed in to send BFD Control Packets with MCI authentication in the Up state for a period as discussed in
<xref target="operations"/>. If optimized authentication mechanisms are <xref target="operations"/>. If optimized authentication mechanisms are
in use, as defined in <xref target="optimized modes"/>, the session MAY in use, as defined in <xref target="optimized_modes"/>, the session <bcp14 >MAY</bcp14>
switch to the LCI mode.</t> switch to the LCI mode.</t>
<t>The contents of an Up packet must not change aside from the <t>The contents of an Up packet must not change aside from the
Authentication Section unless MCI authentication is in use.</t> Authentication Section unless MCI authentication is in use.</t>
<section anchor="significant_changes">
<section anchor="significant changes" title="Protecting BFD Significant <name>Protecting BFD Significant Changes with MCI Authentication</name>
Changes with More Computationally Intensive Authentication"> <t>
<t>
This document proposes that BFD control packets that signal a This document proposes that BFD control packets that signal a
state change, a change in demand mode (D bit), or a poll sequence state change, a change in demand mode (D bit), or a poll sequence
(P or F bit change) be categorized as a "significant (P or F bit change) be categorized as a "significant
change". Control packets that do not require a poll sequence, change". Control packets that do not require a poll sequence,
such as bfd.DetectMult are also considered as a such as bfd.DetectMult, are also considered a
significant change. significant change.
</t> </t>
<t> <t>
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.
</t> </t>
</section> </section>
</section> </section>
<section anchor="optimized_type">
<section anchor="optimized type" title="Using Less Computationally Intensive <name>Using LCI Auth Types</name>
Auth Types">
<t> <t>
The majority of packets exchanged in a BFD session in the Up state are The majority of packets exchanged in a BFD session in the Up state are
not significant changes. This document proposes a new optimized not significant changes. This document proposes a new optimized
authentication mode where packets that are not significant changes may authentication mode where packets that are not significant changes may
use a less computationally intensive authentication mechanism. use an LCI authentication mechanism.
</t> </t>
<t> <t>
Once the session has reached the Up state, the session can Once the session has reached the Up state, the session can
use a less computationally intensive Auth Type derived from use an LCI Auth Type derived from
the format in <xref target="signaling"/>. the format in <xref target="signaling"/>.
Currently, this includes: Currently, this includes:
<ul> </t>
<li> <ul>
Meticulous Keyed ISAAC authentication as described in <li>
<xref target="I-D.ietf-bfd-secure-sequence-numbers"/>. Meticulous Keyed ISAAC Authentication as described in
<xref target="RFC9986"/>.
This authentication type protects the BFD session when BFD Up This authentication type protects the BFD session when BFD Up
packets do not change, because only the paired devices know the packets do not change, because only the paired devices know the
shared secret, key, and sequence number to select the ISAAC shared secret, key, and sequence number to select the ISAAC
result. result.
</li> </li>
</ul> </ul>
</t>
<t> <t>
Other mechanisms may be defined in the future. Other mechanisms may be defined in the future.
</t> </t>
</section> </section>
<section>
<section title="Periodic More Computationally Intensive Reauthentication"> <name>Periodic MCI Reauthentication</name>
<t> <t>
When using the less computationally intensive authentication When using the LCI authentication
mechanism, BFD should periodically test the session using the MCI mechanism, BFD should periodically test the session using the MCI
authentication mechanism. MCI authentication is tested using a authentication mechanism. MCI authentication is tested using a
Poll sequence. To test MCI authentication, a Poll sequence SHOULD Poll sequence. To test MCI authentication, a Poll sequence <bcp14>SHOULD </bcp14>
be initiated by the sender using the MCI authentication mode rather be initiated by the sender using the MCI authentication mode rather
than the LCI mechanism. If a control packet than the LCI mechanism. If a control packet
with the Final (F) bit is not received using MCI authentication with the Final (F) bit is not received using MCI authentication
within twice the Detect Interval as would be calculated by the within twice the Detect Interval as would be calculated by the
receiving system, the session has been compromised, and MUST be brought receiving system, the session has been compromised, and it <bcp14>MUST</b cp14> be brought
down. down.
</t> </t>
<t> <t>
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 sending Interval. This accommodates for possible packet loss from the sending
system during the Poll sequence to the receiving system, plus time for system during the Poll sequence to the receiving system, plus time for
the receiving system to transmit control packet with the Final (F) bit the receiving system to transmit control packet with the Final (F) bit
set to the local system. set to the local system.
</t> </t>
<t> <t>
This "more computationally intensive reauthentication interval" for This "MCI reauthentication interval" for
performing such periodic tests using the more computationally intensive performing such periodic tests using the MCI
authentication mechanism can be configured depending on the capability authentication mechanism can be configured depending on the capability
of the system. of the system.
</t> </t>
<t> <t>
Most packets transmitted in a BFD session are BFD Up packets. Most packets transmitted in a BFD session are BFD Up packets.
MCI authenticating a limited subset of these packets with a Poll MCI authenticating a limited subset of these packets with a Poll
sequence as described above, for example every one minute, sequence as described above, e.g., every one minute,
significantly reduces the computational demand for the system significantly reduces the computational demand for the system
while maintaining security of the session across the while maintaining security of the session across the
configured MCI reauthentication interval. configured MCI reauthentication interval.
</t> </t>
</section> </section>
<section anchor="optimized_modes">
<section anchor="optimized modes" title="Optimized Authentication Modes"> <name>Optimized Authentication Modes</name>
<t>The cryptographic authentication mechanisms specified in <xref <t>The cryptographic authentication mechanisms specified in <xref
target="RFC5880" section="6.7">BFD</xref> describe enabling and disabling target="RFC5880" section="6.7">BFD</xref> describe enabling and
of disabling of authentication as a one-time operation. The following is stat
authentication as a one time operation. ed in <xref target="RFC5880" section="6.7.1"/>:</t>
"... implementations using this mechanism SHOULD only allow the
<blockquote>... implementations using this method <bcp14>SHOULD</bcp14> on
ly allow the
authentication state to be changed at most once without some form of authentication state to be changed at most once without some form of
intervention (so that authentication cannot be turned on and off intervention (so that authentication cannot be turned on and off
repeatedly simply based on the receipt of BFD Control packets from remote repeatedly simply based on the receipt of BFD Control packets from remote
systems)." (<xref target="RFC5880" section="6.7.1"/>) systems).</blockquote>
Once enabled, every packet must have Authentication Bit set and the <!-- [rfced] What does "it" refer to in the sentence below?
Current:
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.
Perhaps:
In addition, Section 6.7.1 of [RFC5800] states that an
implementation SHOULD NOT allow the authentication state to be
changed based on the receipt of a BFD control packet.
-->
<t>Once enabled, every packet must have the Authentication Bit set and the
associated Authentication Type appended (<xref target="RFC5880" section="4 .1"/>). associated Authentication Type appended (<xref target="RFC5880" section="4 .1"/>).
In addition, it states that an In addition, it states that an
implementation SHOULD NOT allow the authentication state to be changed implementation <bcp14>SHOULD NOT</bcp14> allow the authentication state to be changed
based on the receipt of a BFD control packet.</t> based on the receipt of a BFD control packet.</t>
<t> <t>
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 a permits both an MCI authentication mode and an LCI mode be used within th
less computationally intensive mode to be used within the same BFD e same BFD
session. This pairing of a MCI and a LCI mode of authentication is session. This pairing of an MCI and an LCI mode of authentication is
carried in new BFD authentication types representing a given optimized carried in new BFD authentication types representing a given optimized
authentication type pairing. authentication type pairing.
</t> </t>
<t> <t>
This document defines in <xref target="significant changes"/> This document defines which BFD control packets require MCI authenticatio
which BFD control packets require MCI authentication. n in <xref target="significant_changes"/>.
A BFD control packet that fails 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 authenticated, but was not; e.g. a significant supposed to be MCI-authenticated but was not (e.g., a significant
change packet, is discarded. However, there is no change to change packet), is discarded. However, there is no change to
the state machine for BFD, as the decision of a significant the state machine for BFD, as the decision of a significant
change is still decided by how many valid consecutive packets change is still decided by how many valid consecutive packets
were received. were received.
</t> </t>
<t> <t>
In this specification, the contents of an Up packet MUST NOT change In this specification, the contents of an Up packet <bcp14>MUST NOT</bcp1 4> change
aside from the Authentication Section without MCI aside from the Authentication Section without MCI
authentication. The full procedure is documented in the following authentication. The full procedure is documented in the following
sections. sections.
</t> </t>
</section> </section>
<section anchor="signaling">
<name>Signaling Optimized Authentication</name>
<!-- [rfced] May we rephrase the third bullet point in this list for improved
readability in relation to the lead-in sentence?
<section anchor="signaling" title="Signaling Optimized Authentication"> Current:
This pairing is advertised in a single Auth Type value in order to
permit implementations to be aware that:
* Optimized BFD procedures will be in use.
* The pairing of the MCI and LCI authentication mechanisms will be used for t
hat
session.
* The requirement to carry a Sequence Number.
* The current MCI or LCI mode will be carried as described below:
Perhaps:
This pairing is advertised in a single Auth Type value in order to permit
implementations to be aware that:
* Optimized BFD procedures will be in use.
* The pairing of the MCI and LCI authentication mechanisms will be used for t
hat
session.
* There is a requirement to carry a Sequence Number.
* The current MCI or LCI mode will be carried as described below.
-->
<t> <t>
When the When the
Authentication Present (A) bit is set and the Auth Type Authentication Present (A) bit is set and the Auth Type
(<xref target="RFC5880" section="4.1" sectionFormat="comma"/>) (<xref target="RFC5880" section="4.1" sectionFormat="comma"/>)
is a type supporting Optimized BFD Authentication, the Auth Type signals a is a type supporting Optimized BFD Authentication, the Auth Type signals a
pairing of a more computationally intensive authentication type and a pairing of an MCI authentication type and an LCI authentication type. Th
less computationally intensive authentication type. This pairing is is 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:
<ul>
<li>Optimized BFD procedures will be in use.</li>
<li>The pairing of the MCI and LCI
authentication mechanisms will be used for that session.</li>
<li>The requirement to carry a Sequence Number.</li>
<li>The current MCI or LCI mode will be carried as described below:</l
i>
</ul>
</t> </t>
<ul>
<t> <li>Optimized BFD procedures will be in use.</li>
<figure <li>The pairing of the MCI and LCI
align="center" title="Common Optimized BFD Authentication Section"> authentication mechanisms will be used for that session.</li>
<artwork><![CDATA[ <li>The requirement to carry a Sequence Number.</li>
0 1 2 3 <li>The current MCI or LCI mode will be carried as described below.</li>
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 </ul>
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ <figure>
| Auth Type | Auth Len | Auth Key ID | Opt. Mode | <name>Common Optimized BFD Authentication Section</name>
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ <artwork align="center"><![CDATA[
| Sequence Number | 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
| Authentication Specific Data ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Auth Type | Auth Len | Auth Key ID | Opt. Mode |
]]></artwork> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
</figure> | Sequence Number |
</t> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Authentication Specific Data ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+]]></artwork>
</figure>
<!-- <!--
<t> <t>
The Meticulous Keyed MD5 (<xref target="RFC5880" section="6.7.3"/>), The Meticulous Keyed MD5 (<xref target="RFC5880" section="6.7.3"/>),
Meticulous Keyed SHA-1 (<xref target="RFC5880" section="6.7.4"/>), Meticulous Keyed SHA-1 (<xref target="RFC5880" section="6.7.4"/>),
and Meticulous Keyed ISAAC Authentication (<xref target="I-D.ietf-bfd-sec ure-sequence-numbers" section="5"/>) and Meticulous Keyed ISAAC Authentication (<xref target="I-D.ietf-bfd-sec ure-sequence-numbers" section="5"/>)
Sections define the fourth octet of their respective PDUs as "Reserved". Sections define the fourth octet of their respective PDUs as "Reserved".
When used as the more computationally intensive authentication mechanism When used as the more computationally intensive authentication mechanism
for new optimized authentication Auth Codes, the for new optimized authentication Auth Codes, the
"Reserved" field of the PDU is repurosed as the "Optimized "Reserved" field of the PDU is repurosed as the "Optimized
Authentication Mode" field. Authentication Mode" field.
</t> </t>
--> -->
<!-- [rfced] We are unable to parse the following text. May we rephrase for
clarity?
Original:
The values of the Optimized Authentication Mode field are:
1. When using the more computationally intensive authentication type
for optimized BFD Auth Types.
2. When using the less computationally intensive authentication type
for optimized BFD Auth Types.
Perhaps:
The values of the Optimized Authentication Mode field are:
1. The MCI authentication type for optimized BFD Auth Types.
2. The LCI authentication type for optimized BFD Auth Types.
-->
<t> <t>
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.
</t> </t>
<t> <t>
The values of the Optimized Authentication Mode field are: The values of the Optimized Authentication Mode field are:
<ol> </t>
<ol>
<li> <li>
When using the more computationally intensive authentication type When using the MCI authentication type
for optimized BFD Auth Types. for optimized BFD Auth Types.
</li> </li>
<li> <li>
When using the less computationally intensive authentication type When using the LCI authentication type
for optimized BFD Auth Types. for optimized BFD Auth Types.
</li> </li>
</ol> </ol>
</t>
<t> <t>
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.
</t> </t>
<section>
<section title="Transmitting and Receiving Using Optimized Authentication" <name>Transmitting and Receiving Using Optimized Authentication</name>
>
<t> <t>
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
<xref target="RFC5880" section="6.7"/>. <xref target="RFC5880" section="6.7"/>.
Optimized Authentication modes have common procedural requirements for Optimized Authentication modes have common procedural requirements for
authentication regardless of which more or less computationally authentication regardless of which more or less computationally
intensive authentication modes are used. intensive authentication modes are used.
</t> </t>
<t> <t>
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.
</t> </t>
<t> <t>
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:
<!-- [rfced] Should the following text be formatted as a list as shown below?
Original:
The following common procedures apply to authenticating BFD Control
packets utilizing Optimized 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
Optimized Authentication Auth Type, then the received packet MUST be
discarded.
If the received BFD Control packet contains an optimized
authentication type using these procedures and the Optimized
Authentication Mode field is not 1 or 2, then the received packet
MUST be discarded.
If bfd.SessionState is AdminDown, Down, or Init and the Optimized
Authentication Mode field is not 1, then the received packet MUST be
discarded.
If bfd.SessionState is Up and there is a significant change as
defined in Section 3.1, and the Optimized Authentication Mode field
is not 1, then the received packet MUST be discarded.
If the Auth Len field is not equal to a value appropriate for the
Optimized Authentication Mode field, the packet MUST be discarded.
If bfd.AuthSeqKnown is 1, examine the Sequence Number field. If the
sequence number lies outside of the range of bfd.RcvAuthSeq+1 to
bfd.RcvAuthSeq+(3*Detect Mult) inclusive (when treated as an unsigned
32-bit circular number space), the received packet MUST be discarded.
Perhaps:
The following common procedures apply to authenticating BFD Control
packets utilizing Optimized 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
Optimized Authentication Auth Type, then the received packet MUST be
discarded.
* If the received BFD Control packet contains an optimized
authentication type using these procedures and the Optimized
Authentication Mode field is not 1 or 2, then the received packet
MUST be discarded.
* If bfd.SessionState is AdminDown, Down, or Init and the Optimized
Authentication Mode field is not 1, then the received packet MUST be
discarded.
* If bfd.SessionState is Up and there is a significant change as
defined in Section 3.1, and the Optimized Authentication Mode field
is not 1, then the received packet MUST be discarded.
* If the Auth Len field is not equal to a value appropriate for the
Optimized Authentication Mode field, the packet MUST be discarded.
* If bfd.AuthSeqKnown is 1, examine the Sequence Number field. If the
sequence number lies outside of the range of bfd.RcvAuthSeq+1 to
bfd.RcvAuthSeq+(3*Detect Mult) inclusive (when treated as an unsigned
32-bit circular number space), the received packet MUST be discarded.
-->
</t> </t>
<t> <t>
If the received BFD Control packet does not contain an If the received BFD Control packet does not contain an
Authentication Section (<xref target="RFC5880" sectionFormat="comma" se ction="4.1"/>), or Authentication Section (<xref target="RFC5880" sectionFormat="comma" se ction="4.1"/>), or
the Auth Type is not a supported Optimized Authentication Auth Type, the Auth Type is not a supported Optimized Authentication Auth Type,
then the received packet MUST be discarded. then the received packet <bcp14>MUST</bcp14> be discarded.
</t> </t>
<t> <t>
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. <bcp14>MUST</bcp14> be discarded.
</t> </t>
<t> <t>
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 <bcp14>MUS T</bcp14> be
discarded. discarded.
</t> </t>
<t> <t>
If bfd.SessionState is Up and there is a significant change as defined If bfd.SessionState is Up and there is a significant change as defined
<xref target="significant changes"/>, and the Optimized Authentication in <xref target="significant_changes"/>, and the Optimized Authenticati
Mode field is not 1, then the received packet MUST be discarded. on
</t> Mode field is not 1, then the received packet <bcp14>MUST</bcp14> be di
scarded.
</t>
<t> <t>
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 <bcp14>MUST</bcp14> be discarded.
</t> </t>
<t> <t>
<!-- [rfced] May we rephrase the sentence below for clarity and easier
readability?
Original:
If the sequence number lies outside of the range of bfd.RcvAuthSeq+1
to bfd.RcvAuthSeq+(3*Detect Mult) inclusive (when treated as an
unsigned 32-bit circular number space) the received packet
MUST be discarded.
Perhaps:
If the sequence number lies outside of the inclusive range of
bfd.RcvAuthSeq+1 to bfd.RcvAuthSeq+(3*Detect Mult) when treated as an
unsigned 32-bit circular number space, the received 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 <bcp14>MUST</bcp14> be discarded.
</t> </t>
<t> <t>
Otherwise (bfd.AuthSeqKnown is 0), bfd.AuthSeqKnown MUST be set to 1, Otherwise (bfd.AuthSeqKnown is 0), bfd.AuthSeqKnown <bcp14>MUST</bcp14
bfd.RcvAuthSeq MUST be set to the value of the received Sequence > be set to 1,
Number field, and the received packet MUST be accepted. bfd.RcvAuthSeq <bcp14>MUST</bcp14> be set to the value of the received
Sequence
Number field, and the received packet <bcp14>MUST</bcp14> be accepted.
</t> </t>
<t> <t>
For the specified Auth Type and Optimized Authentication Mode, perform For the specified Auth Type and Optimized Authentication Mode, perform
the appropriate authentication procedures. If authentication the appropriate authentication procedures. If authentication
succeeds, the received packet MUST be accepted. Otherwise, the succeeds, the received packet <bcp14>MUST</bcp14> be accepted. Otherw
received packet MUST be discarded. ise, the
</t> received packet <bcp14>MUST</bcp14> be discarded.
</t>
</section> </section>
<section anchor="operations" title="Optimized Authentication Operations"> <section anchor="operations">
<t> <name>Optimized Authentication Operations</name>
As noted in <xref target="significant changes"/>, <t>
when using optimized BFD procedures, more computationally intensive As noted in <xref target="significant_changes"/>,
when using optimized BFD procedures, MCI
authentication is used in the BFD state machine to bring a BFD session authentication is used in the BFD state machine to bring a BFD session
to the Up state or to make any change of the BFD parameters as carried to the Up state or to make any change of the BFD parameters as carried
in the BFD Control packet when in the Up state. in the BFD Control packet when in the Up state.
</t> </t>
<t>
<t> Once the BFD session has reached the Up state, the BFD Up state <bcp14>
Once the BFD session has reached the Up state, the BFD Up state MUST MUST</bcp14>
be signaled to the remote BFD system using the MCI authentication mode for be signaled to the remote BFD system using the MCI authentication mode for
an interval that is at least the Detection Time before switching to an interval that is at least the Detection Time before switching to
the LCI authentication mode. This is to permit mechanisms such as the LCI authentication mode. This is to permit mechanisms such as
<xref target="I-D.ietf-bfd-secure-sequence-numbers"> <xref target="RFC9986">
Meticulous Keyed ISAAC for BFD Authentication</xref>, Meticulous Keyed ISAAC for BFD Optimized Authentication</xref>
or other approved less intensive authentication mechanisms, to be or other approved, less intensive authentication mechanisms to be
bootstrapped before switching to the LCI mode. bootstrapped before switching to the LCI mode.
</t> </t>
<t>
<t> It is <bcp14>RECOMMENDED</bcp14> that when using optimized authenticati
It is RECOMMENDED that when using optimized authentication that on that
implementations switch from MCI authentication to LCI implementations switch from MCI authentication to LCI
authentication mode after an interval that authentication mode after an interval that
is at least the Detection Time. In the circumstances where a BFD is at least the Detection Time. In the circumstances where a BFD
session successfully reaches the Up state with MCI authentication, session successfully reaches the Up state with MCI authentication,
but there are problems with the LCI authentication, this will but there are problems with the LCI authentication, this will
permit the remote system to tear down the session as quickly as permit the remote system to tear down the session as quickly as
possible. possible.
</t> </t>
<t>
<t>
BFD sessions using optimized authentication that succeed in reaching th e BFD sessions using optimized authentication that succeed in reaching th e
Up state using MCI authentication and fail using LCI authentication Up state using MCI authentication and fail using LCI authentication
SHOULD bring the issue to the attention of the operator. Further, <bcp14>SHOULD</bcp14> bring the issue to the attention of the operator.
implementations MAY wish to throttle session restarts. Furthermore,
</t> implementations <bcp14>MAY</bcp14> wish to throttle session restarts.
</t>
<t> <t>
It is further RECOMMENDED that BFD implementations using optimized It is further <bcp14>RECOMMENDED</bcp14> that BFD implementations using
optimized
authentication defer notifying their client that the session has reache d authentication defer notifying their client that the session has reache d
the Up state until it has transitioned to using the LCI 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 transitions failing in the protocol, this avoids propagating the failed transitions
to the LCI mode to their clients. to the LCI mode to their clients.
</t> </t>
</section> </section>
</section> </section>
<section anchor="opt-auth-yang-model">
<section anchor="opt-auth-yang-model" title="Optimizing Authentication YANG <name>Optimizing Authentication YANG Data Model</name>
Data Model"> <section anchor="data-model-overview">
<section anchor="data-model-overview" title="Data Model Overview"> <name>Data Model Overview</name>
<t> <t>
The <xref target="RFC7950">YANG 1.1</xref> model defined in The <xref target="RFC7950">YANG 1.1</xref> data model defined in
this document augments the "ietf-bfd" module to add this document augments the "ietf-bfd" module to add
data nodes relevant to the management of the feature defined in this data nodes relevant to the management of the feature defined in this
document. It adds an interval value that specifies how often the BFD document. It adds an interval value that specifies how often the BFD
session should be re-authenticated using more computationally session should be reauthenticated using more computationally
intensive authentication once it is in the Up state. intensive authentication once it is in the Up state.
</t> </t>
</section> </section>
<section anchor="tree-diagram" title="Tree Diagram"> <section anchor="tree-diagram">
<t> <name>Tree Diagram</name>
<t>
The tree diagram for the YANG modules defined in this The tree diagram for the YANG modules defined in this
document use annotations defined in <xref document use annotations defined in <xref target="RFC8340">YANG Tree Di
target="RFC8340">YANG Tree Diagrams.</xref>. agrams</xref>.
</t> </t>
<t> <sourcecode type="yangtree">
<figure>
<artwork><![CDATA[
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
/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:
+--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-lag:lag /rt:control-plane-protocol/bfd:bfd/bfd-lag:lag
/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</sourcecode>
]]></artwork>
</figure>
</t>
</section> </section>
<section anchor="the-yang-model" title="The YANG Data Model"> <section anchor="the-yang-model">
<t> <name>The YANG Data Model</name>
This YANG module imports modules defined in <xref target="RFC8177">YANG <!-- [rfced] RFC 8177 doesn't appear to be referenced in the
Key YANG Module. Please review and let us know if/how we should
Chain </xref>, <xref target="RFC8349">A YANG Data Model for update the module or if this reference should be removed.
Routing Management (NMDA version)</xref>, and <xref
target="RFC9314">YANG Data Model for Bidirectional Forwarding Current:
Detection (BFD)</xref>. This YANG module imports modules defined in YANG Data Model for Key
</t> Chains [RFC8177], A YANG Data Model for Routing Management (NMDA
<t> Version) [RFC8349], and YANG Data Model for Bidirectional Forwarding
Detection (BFD) [RFC9314].
-->
<t>
This YANG module imports modules defined in "<xref format="title" targe
t="RFC8177"/>" <xref target="RFC8177"/>, "<xref format="title" target="RFC8349"/
>" <xref target="RFC8349"/>, and "<xref format="title" target="RFC9314"/>" <xref
target="RFC9314"/>.
</t>
<t>
Implementations supporting the optimization procedures defined in Implementations supporting the optimization procedures defined in
this document enable optimization by using one of the newly this document enable optimization by using one of the newly
defined key-chain crypto-algorithms defined in this YANG module. defined key-chain crypto-algorithms defined in this YANG module.
</t> </t>
<t>
<figure> <!--[rfced] The YANG module (Section 8.3) has been updated as shown
<artwork><![CDATA[ below per the formatting option of pyang. Please let us know of
<CODE BEGINS> file "ietf-bfd-opt-auth@2025-11-12.yang" any concerns.
- Removed the quote marks from prefixes "bfd-oa" and "rt".
- Moved the plus signs and slashes to the beginning of the
lines within in the augment blocks.
-->
<sourcecode markers="true" name="ietf-bfd-opt-auth@2026-05-19.yang" type
="yang"><![CDATA[
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 line 768 skipping to change at line 882
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.";
} }
} }]]></sourcecode>
<CODE ENDS>
]]></artwork>
</figure>
</t>
</section> </section>
</section> </section>
<section anchor="IANA">
<section anchor="IANA" title="IANA Considerations"> <name>IANA Considerations</name>
<t> <t>
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 sectio n.
</t> </t>
<section anchor="ietf-xml-registry" title="IETF XML Registry"> <section anchor="ietf-xml-registry">
<t> <name>IETF XML Registry</name>
This document registers one URIs in the "ns"
subregistry of the "IETF XML" registry <xref
target="RFC3688"/>. Following the format in <xref
target="RFC3688"/>, the following registration is requested:
</t>
<t> <t>
<figure> IANA has registered the following URI in the "ns"
<artwork> registry within the "IETF XML Registry" group <xref target="RFC3688"/>:
<![CDATA[ </t>
URI: urn:ietf:params:xml:ns:yang:ietf-bfd-opt-auth
Registrant Contact: The IESG <dl spacing="compact" newline="false">
XML: N/A, the requested URI is an XML namespace. <dt>URI:</dt><dd>urn:ietf:params:xml:ns:yang:ietf-bfd-opt-auth</dd>
]]> <dt>Registrant Contact:</dt><dd>The IESG</dd>
</artwork> <dt>XML:</dt><dd>N/A; the requested URI is an XML namespace.</dd>
</figure> </dl>
</t>
</section> </section>
<section anchor="yang-module-names" title="The YANG Module Names Registry" <section anchor="yang-module-names">
> <name>The YANG Module Names Registry</name>
<t>
This document registers one YANG modules in the "YANG Module
Names" registry <xref target="RFC6020"/>. Following the
format in <xref target="RFC6020"/>, the following
registrations are requested:
</t>
<t> <t>
<figure> IANA has registered the following YANG module in the "YANG Module
<artwork> Names" registry <xref target="RFC6020"/> within the "YANG Parameters" r
<![CDATA[ egistry group:
name: ietf-bfd-opt-auth </t>
namespace: urn:ietf:params:xml:ns:yang:ietf-bfd-opt-auth
prefix: bfd-oa <dl spacing="compact" newline="false">
maintained by IANA: No <dt>Name:</dt><dd>ietf-bfd-opt-auth</dd>
reference: RFC XXXX <dt>Maintained by IANA:</dt><dd>No</dd>
]]> <dt>Namespace:</dt><dd>urn:ietf:params:xml:ns:yang:ietf-bfd-opt-auth</d
</artwork> d>
</figure> <dt>Prefix:</dt><dd>bfd-oa</dd>
</t> <dt>Reference:</dt><dd>RFC 9985</dd>
</dl>
</section> </section>
</section> </section>
<section anchor="Security">
<section anchor="Security" title="Security Considerations"> <name>Security Considerations</name>
<section anchor="Protocol Security" title="Protocol Security Consideration <section anchor="Protocol_Security">
s"> <name>Protocol Security Considerations</name>
<t> <t>
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 detection intervals for the BFD sessions, and their number, Desired detection intervals for the BFD sessions, and their number,
are common scaling considerations for BFD implementations. Security are 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.
</t> </t>
<t>
<t>
The optimized procedures in this document provide a different level of The optimized procedures in this document provide a different level of
resistance to attack than methods using a single authentication resistance to attack than methods using a single authentication
mechanism: mechanism:
<ul> </t>
<li> <ul>
The more computationally intensive authentication mechanisms used <li>
The MCI authentication mechanisms used
for optimized authentication are expected to have similar for optimized authentication are expected to have similar
cryptographic strength acceptable for BFD for authenticating the cryptographic strength acceptable for BFD for authenticating the
entire session, as described in <xref target="RFC5880"/>. entire session, as described in <xref target="RFC5880"/>.
</li> </li>
<li> <li>
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 intended to protect vs. attempts to authentication mechanism is intended to protect vs. attempt to
inappropriately start BFD sessions. inappropriately start BFD sessions.
</li> </li>
<li> <li>
When the BFD state machine is in the Up state, the more When the BFD state machine is in the Up state, the MCI authenticati
computationally intensive authentication mechanism is intended to on mechanism is intended to
protect vs. attempts to change BFD session parameters or to reset protect vs. attempt to change BFD session parameters or to reset
the BFD session. the BFD session.
</li> </li>
<li> <li>
When the BFD state machine is in the Up state, the less <!-- [rfced] May we rephrase the following sentence to avoid repetition of
computationally intensive authentication mechanism is intended "contents"?
Current:
Since the procedures for changing BFD state require the more
computationally intensive mechanism and the less computationally
intensive mechanism requires that the contents of the Control Packet
in the Up state not change its contents, the only thing that
successfully spoofing such packets can do is keep the session Up.
Perhaps:
Since the procedures for changing BFD state require the MCI mechanism
and the LCI mechanism requires that the contents of the Control Packet
in the Up state remain unchanged, the only thing that successfully
spoofing such packets can do is keep the session Up.
-->
When the BFD state machine is in the Up state, the LCI authenticati
on mechanism is intended
to provide resistance to keeping a BFD session in the Up state to provide resistance to keeping a BFD session in the Up state
inappropriately. Since the procedures for changing BFD state inappropriately. Since the procedures for changing BFD state
require the more computationally intensive mechanism and the less require the MCI mechanism and the LCI mechanism requires that the c
computationally intensive mechanism requires that the contents of ontents of
the Control Packet in the Up state not change its contents, the the Control Packet in the Up state not change its contents, the
only thing that successfully spoofing such packets can do is keep only thing that successfully spoofing such packets can do is keep
the session Up. the session Up.
</li> </li>
<li> <li>
The periodic more computationally intensive re-authentication The periodic, MCI reauthentication
procedure provides protection against long-term successful procedure provides protection against long-term successful
spoofing of the less computationally intensive authentication spoofing of the LCI authentication
mechanism. mechanism.
</li> </li>
</ul> </ul>
</t> <t>
<t>
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. However, it difficult to reset or inappropriately start BFD sessions. However,
protecting against keeping the session Up is seen as a less 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.
</t> </t>
<t>The recent escalating series of attacks on MD5
<t>The recent escalating series of attacks on MD5
and SHA-1 described in <xref target="SHA-1-attack1">Finding Collisions and SHA-1 described in <xref target="SHA-1-attack1">Finding Collisions
in the Full SHA-1 </xref> and <xref target="SHA-1-attack2">New Collision in the Full SHA-1 </xref> and <xref target="SHA-1-attack2">New Collision
Search for SHA-1 </xref> raise concerns about their remaining useful Search for SHA-1 </xref> raise concerns about their remaining useful
lifetime as outlined in <xref target="RFC6151">Updated Security lifetime as outlined in <xref target="RFC6151">Updated Security
Considerations for the MD5 Message-Digest and the HMAC-MD5 Algorithm Considerations for the MD5 Message-Digest and the HMAC-MD5 Algorithm
</xref> and <xref target="RFC6194">Security Considerations for the SHA-0 </xref> and <xref target="RFC6194">Security Considerations for the SHA -0
and SHA-1 Message-Digest Algorithm </xref>. If replaced by stronger and SHA-1 Message-Digest Algorithm </xref>. 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.</t> authenticating every packet even more difficult to achieve.</t>
<t>The procedures described in this document provide a mechanism that
<t>The procedures described in this document provide a mechanism which
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.
this requires operators to evaluate the tradeoffs of the less However,
computationally intensive mechanisms adequately address their desired this requires operators to evaluate the trade-offs of the less
computationally intensive mechanisms to adequately address their desired
security stance.</t> security stance.</t>
<t>Keys generated and distributed out of band for the purposes described
<t>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.</t> protected when stored.</t>
</section> </section>
<section anchor="YANG Security" title="YANG Security Considerations"> <section anchor="YANG_Security">
<t> <name>YANG Security Considerations</name>
This section is modeled after the template described in Section 3.7 <t>
of <xref target="I-D.ietf-netmod-rfc8407bis"/>. <!-- [rfced] FYI - We have updated the following text to point to
</t> Section 3.7.1 instead of Section 3.7 in order to match the
<t> Security Considerations Section Template as shown in RFC 9907.
Original:
This section is modeled after the template described in Section 3.7
of [I-D.ietf-netmod-rfc8407bis].
Current:
This section is modeled after the template described in Section 3.7.1 of
[RFC9907].
-->
This section is modeled after the template described in <xref section="
3.7.1" target="RFC9907"/>.
</t>
<t>
The "ietf-bfd-opt-auth" YANG module defines a data model that The "ietf-bfd-opt-auth" YANG module defines a data model that
is designed to be accessed via YANG-based management protocols, such is designed to be accessed via YANG-based management protocols, such
as <xref target="RFC6241">NETCONF</xref> or <xref target="RFC8040">REST CONF</xref>. as the Network Configuration Protocol (NETCONF) <xref target="RFC6241"/ > and RESTCONF <xref target="RFC8040"/>.
These YANG-based management protocols (1) have to use a secure These YANG-based management protocols (1) have to use a secure
transport layer (e.g., <xref target="RFC4252">SSH</xref> transport layer (e.g., Secure Shell (SSH) <xref target="RFC4252"/>,
<xref target="RFC8446">TLS</xref>, and <xref target="RFC9000">QUIC</xre TLS <xref target="RFC8446"/>, and QUIC <xref target="RFC9000"/>)
f>)
and (2) have to use mutual authentication. and (2) have to use mutual authentication.
</t> </t>
<t>
<t> The Network Configuration Access Control Model (NACM)
The Network Configuration Access Control Model <xref target="RFC8341"/> provides the means to restrict
<xref target="RFC8341">(NACM)</xref> provides the means to restrict
access for particular NETCONF or RESTCONF users to a preconfigured access for particular NETCONF or RESTCONF users to a preconfigured
subset of all available NETCONF or RESTCONF protocol operations and subset of all available NETCONF or RESTCONF protocol operations and
content. content.
</t> </t>
<t>
<t>
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:
</t> </t>
<ul>
<ul> <li>
<li>
'reauth-interval' specifies the interval in Up state, after 'reauth-interval' specifies the interval in Up state, after
which more computationally intensive authentication SHOULD be which MCI authentication <bcp14>SHOULD</bcp14> be
performed to prevent a Person-In-The-Middle (PITM) attack. If this performed to prevent a Person-in-the-Middle (PITM) attack. If this
interval is set very low, the utility of these optimization interval is set very low, the utility of these optimization
procedures is lessened. If this interval is set very high, attacks procedures is lessened. If this interval is set very high, attacks
detected by the more computationally intensive authentication detected by the MCI authentication
mechanisms may happen overly late. mechanisms may happen overly late.
</li> </li>
</ul> </ul>
<t>
<t>
There are no particularly sensitive readable data nodes. There are no particularly sensitive readable data nodes.
</t> </t>
<t>
<t>
There are no RPC operations defined in this model. There are no RPC operations defined in this model.
</t> </t>
</section> </section>
</section> </section>
<section title="Contributors" anchor="contributors">
<t>
The authors of this document would like to acknowledge Reshad
Rahman as a contributor to this document.
</t>
</section>
<section title="Acknowledgments">
<t>The authors would like to thank Qiufang Ma, Stephen Farrell, and Acee L
indem for providing directorate review of this document.</t>
</section>
</middle> </middle>
<back> <back>
<references title="Normative References"> <references>
<?rfc include="reference.RFC.2119.xml"?> <name>References</name>
<?rfc include='reference.RFC.3688.xml'?> <references>
<?rfc include='reference.RFC.5880.xml'?> <name>Normative References</name>
<?rfc include='reference.RFC.6020.xml'?> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.2
<?rfc include='reference.RFC.7950.xml'?> 119.xml"/>
<?rfc include='reference.RFC.8174.xml'?> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.3
<?rfc include='reference.RFC.8177.xml'?> 688.xml"/>
<?rfc include='reference.RFC.8349.xml'?> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5
<?rfc include='reference.RFC.9314.xml'?> 880.xml"/>
</references> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.6
020.xml"/>
<references title="Informative References"> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7
<reference anchor="SHA-1-attack1"> 950.xml"/>
<front> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
<title>Finding Collisions in the Full SHA-1</title> 174.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
<author initials="X." surname="Wang"> 177.xml"/>
<organization/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
</author> 349.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9
<author initials="Y." surname="Yin"> 314.xml"/>
<organization/> </references>
<references>
<address> <name>Informative References</name>
<postal> <!-- [rfced] References
<street/>
<city/>
<region/>
<code/>
<country/>
</postal>
<phone/>
<facsimile/>
<email/>
<uri/>
</address>
</author>
<author initials="H." surname="Yu">
<organization/>
<address>
<postal>
<street/>
<city/>
<region/>
<code/>
<country/>
</postal>
<phone/>
<facsimile/>
<email/>
<uri/>
</address>
</author>
<date year="2005"/>
</front>
</reference>
<reference anchor="SHA-1-attack2">
<front>
<title>New Collision Search for SHA-1</title>
<author initials="X." surname="Wang">
<organization/>
</author>
<author initials="A." surname="Yao">
<organization/>
<address>
<postal>
<street/>
<city/>
<region/>
<code/>
<country/>
</postal>
<phone/>
<facsimile/>
<email/>
<uri/>
</address>
</author>
<author initials="F." surname="Yao"> a) For [SHA-1-attack1]: We found an open access version of this paper:
<organization/> https://link.springer.com/chapter/10.1007/11535218_2. May we update this
reference to point to this version?
<address> Current:
<postal> [SHA-1-attack1]
<street/> Wang, X., Yin, Y., and H. Yu, "Finding Collisions in the
Full SHA-1", 2005.
<city/> Perhaps:
[SHA-1-attack1]
Wang, X., Yin, Y., and H. Yu, "Finding Collisions in the
Full SHA-1", Advances in Cryptology - CRYPTO 2005, Lecture
Notes in Computer Science, vol. 3621, pp. 17-36,
DOI 10.1007/11535218_2, 2005,
<https://doi.org/10.1007/11535218_2>.
<region/> b) For [SHA-1-attack2]: We were unable to find a source that matched this
reference's information. We did find a presentation for the NIST Cryptographic
Hash Workshop from the authors listed in this reference:
https://csrc.nist.gov/csrc/media/events/first-cryptographic-hash-workshop/docume
nts/wang_sha1-new-result.pdf.
Is there a specific paper this reference is supposed to be pointing to? Or is
this presentation the correct source?
-->
<reference anchor="SHA-1-attack1">
<front>
<title>Finding Collisions in the Full SHA-1</title>
<author initials="X." surname="Wang">
<organization/>
</author>
<author initials="Y." surname="Yin">
<organization/>
</author>
<author initials="H." surname="Yu">
<organization/>
</author>
<date year="2005"/>
</front>
</reference>
<code/> <!-- Possible updated XML for [SHA-1-attack1]
<reference anchor="SHA-1-attack1">
<front>
<title>Finding Collisions in the Full SHA-1</title>
<author initials="X." surname="Wang">
<organization/>
</author>
<author initials="Y." surname="Yin">
<organization/>
</author>
<author initials="H." surname="Yu">
<organization/>
</author>
<date year="2005"/>
</front>
<refcontent>Advances in Cryptology - CRYPTO 2005, Lecture Notes in Com
puter Science, vol. 3621, pp. 17-36</refcontent>
<seriesInfo name="DOI" value="10.1007/11535218_2"/>
</reference>
-->
<reference anchor="SHA-1-attack2">
<front>
<title>New Collision Search for SHA-1</title>
<author initials="X." surname="Wang">
<organization/>
</author>
<author initials="A." surname="Yao">
<organization/>
</author>
<author initials="F." surname="Yao">
<organization/>
</author>
<date year="2005"/>
</front>
</reference>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.1
321.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.2
026.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.3
174.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.6
151.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.6
194.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
340.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.4
252.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.6
241.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
040.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
341.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
446.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.87
92.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9
000.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9
907.xml"/>
<country/> <!-- companion document
</postal> draft-ietf-bfd-secure-sequence-numbers-27
In RFC-EDITOR as of 5/15/26
-->
<reference anchor="RFC9986" target="https://www.rfc-editor.org/info/rfc9986">
<front>
<title>
Meticulous Keyed ISAAC for Bidirectional Forwarding Detection (BFD) Optimized Au
thentication
</title>
<author fullname="Alan DeKok" initials="A." surname="DeKok">
<organization>InkBridge Networks</organization>
</author>
<author fullname="Mahesh Jethanandani" initials="M." surname="Jethanandani">
<organization>Kloud Services</organization>
</author>
<author fullname="Sonal Agarwal" initials="S." surname="Agarwal">
<organization>Cisco Systems, Inc</organization>
</author>
<author fullname="Ashesh Mishra" initials="A." surname="Mishra">
<organization>Aalyria Technologies</organization>
</author>
<author fullname="Jeffrey Haas" initials="J." surname="Haas">
<organization>HPE</organization>
</author>
<date month="May" year="2026"/>
</front>
<seriesInfo name="RFC" value="9986"/>
</reference>
</references>
</references>
<section anchor="examples">
<name>Examples</name>
<t>
This section tries to show some examples in how the model can
be configured.
</t>
<section anchor="example-a.1.1">
<name>Single Hop BFD Configuration</name>
<t>
<phone/> <!--[rfced] Appendix A
<facsimile/> a) FYI: We added the following sentence to Appendix A.1 with
a corresponding reference entry for RFC 8792 in the Informative
References section.
<email/> Original:
This example demonstrates how a Single Hop BFD session can be
configured for optimized authentication.
<uri/> Current:
</address> This example demonstrates how a Single Hop BFD session can be
</author> configured for optimized authentication. Note that line wrapping
is used per [RFC8792].
<date year="2005"/> b) When running xmllint on the XML schema, we received the following
</front> error. Are any changes needed to the schema, or is it ok as is?
</reference>
<?rfc include='reference.RFC.1321.xml'?> Error:
<?rfc include='reference.RFC.2026.xml'?> Extra content at the end of the document
<?rfc include='reference.RFC.3174.xml'?> <interfaces
<?rfc include='reference.RFC.6151.xml'?> ^
<?rfc include='reference.RFC.6194.xml'?> -->
<?rfc include='reference.RFC.8340.xml'?>
<?rfc include='reference.RFC.4252.xml'?>
<?rfc include='reference.RFC.6241.xml'?>
<?rfc include='reference.RFC.8040.xml'?>
<?rfc include='reference.RFC.8341.xml'?>
<?rfc include='reference.RFC.8446.xml'?>
<?rfc include='reference.RFC.9000.xml'?>
<?rfc include='reference.I-D.ietf-netmod-rfc8407bis.xml'?>
<?rfc include='reference.I-D.ietf-bfd-secure-sequence-numbers.xml'?>
</references>
<section anchor="examples" title="Examples">
<t>
This section tries to show some examples in how the model can
be configured.
</t>
<section anchor="example-a.1.1" title="Single Hop BFD Configuration">
<t>
This example demonstrates how a Single Hop BFD session can This example demonstrates how a Single Hop BFD session can
be configured for optimized authentication. be configured for optimized authentication. Note that line wrapping is
</t> used per <xref target="RFC8792"/>.
<t> </t>
<figure> <sourcecode type="xml"><![CDATA[
<artwork><![CDATA[
=============== 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>
<name>bfd-auth-config</name> <name>bfd-auth-config</name>
skipping to change at line 1265 skipping to change at line 1377
<key-chain>bfd-auth-config</key-chain> <key-chain>bfd-auth-config</key-chain>
<opt-auth:reauth-interval>30</opt-auth:reauth-inter\ <opt-auth:reauth-interval>30</opt-auth:reauth-inter\
val> val>
</authentication> </authentication>
</session> </session>
</sessions> </sessions>
</ip-sh> </ip-sh>
</bfd> </bfd>
</control-plane-protocol> </control-plane-protocol>
</control-plane-protocols> </control-plane-protocols>
</routing> </routing>]]></sourcecode>
]]>
</artwork>
</figure>
</t>
</section> </section>
</section> </section>
<section anchor="experiment" title="Experimental Status"> <section anchor="experiment">
<name>Experimental Status</name>
<t> <t>
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
<xref target="RFC5880"/>. This experiment is intended to <xref target="RFC5880"/>. This experiment is intended to
provide additional insights into what happens when the provide additional insights into what happens when the
optimized authentication mechanism defined in this document is optimized authentication mechanism defined in this document is
used. Here are the reasons why this document is on the Experimental track : used. Here are the reasons why this document is on the Experimental track :
<t><list style="symbols"> </t>
<t> <ul spacing="normal">
<li>
<t>
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, there participation and reviews from the working group.
has been considerable changes to the document, e.g. the use of ISAAC, <!-- [rfced] Is the following intended to be a list of 3 items? Please
let us know how we may update for clarity.
Current:
Since then, there has been considerable changes to the document,
e.g., the use of ISAAC, allowing for ISAAC bootstrapping when a BFD
session comes up and use of a single Auth Type to indicate use of
optimized authentication etc.
Perhaps:
Since then, there have been considerable changes to the document,
such as the use of ISAAC, the allowance for ISAAC bootstrapping
when a BFD session comes up, and the use of a single Auth Type to
indicate optimized authentication.
-->
Since then, there
has been considerable changes to the document, e.g., the use of ISAAC,
allowing for ISAAC bootstrapping when a BFD session comes up and use allowing for ISAAC bootstrapping when a BFD session comes up and use
of a single Auth Type to indicate use of optimized authentication of a single Auth Type to indicate use of optimized authentication,
etc. These changes did not get significant review from the working etc. These changes did not get significant review from the working
group and therefore does not meet the bar set in Section 4.1.1 of group and therefore do not meet the bar set in
<xref target="RFC2026"/> <xref target="RFC2026" section="4.1.1"/>.
</t> </t>
<t> </li>
<li>
<t>
There are no known implementations at this time. There are no known implementations at this time.
</t> </t>
<t> </li>
<li>
<t>
The work in this document could become very valuable in the future, The work in this document could become very valuable in the future,
especially if the need for deploying BFD authentication at scale especially if the need for deploying BFD authentication at scale
becomes a reality. becomes a reality.
</t> </t>
</list></t> </li>
</t> </ul>
<t> <t>
This document is classified as Experimental and is not part of This document is classified as Experimental and is not part of
the IETF Standards Track. Implementations based on this the IETF Standards Track. Implementations based on this
document should not be considered as compliant with <xref document should not be considered as compliant with <xref target="RFC5880
target="RFC5880">BFD</xref>. ">BFD</xref>.
</t> </t>
</section> </section>
<section numbered="false">
<name>Acknowledgments</name>
<t>The authors would like to thank <contact fullname="Qiufang Ma"/>,
<contact fullname="Stephen Farrell"/>, and <contact fullname="Acee
Lindem"/> for providing directorate reviews of this document.</t>
</section>
<section anchor="contributors" numbered="false">
<name>Contributors</name>
<t>
The authors of this document would like to acknowledge <contact
fullname="Reshad Rahman"/> as a contributor to this document.
</t>
</section>
<!-- [rfced] We updated <artwork> to <sourcecode> in several sections.
Please review and confirm that this is correct.
In addition, please consider whether the "type" attribute of any sourcecode
element has been set correctly.
The current list of preferred values for "type" is available at
https://www.rfc-editor.org/materials/sourcecode-types.txt. If the current
list does not contain an applicable type, feel free to suggest additions
for consideration. Note that it is also acceptable to leave the "type"
attribute not set.
-->
<!-- [rfced] Some author comments are present in the XML. Please confirm that no
updates related to these comments are outstanding. Note that the comments will
be deleted prior to publication.
-->
<!-- [rfced] FYI - We have added expansions for abbreviations upon first use per
Section 3.6 of RFC 7322 ("RFC Style Guide"). Additionally, some expansions in
the document have been abbreviated after they are introduced. Please review each
expansion in the document carefully to ensure correctness.
-->
<!-- [rfced] Please review the "Inclusive Language" portion of the online Style
Guide <https://www.rfc-editor.org/styleguide/part2/#inclusive_language> and let
us know if any changes are needed. Updates of this nature typically result in
more precise language, which is helpful for readers.
Note that our script did not flag any words in particular, but this should still
be reviewed as a best practice.
-->
<!-- [rfced] Terminology
a) We have received guidance from Benoit Claise and the YANG
Doctors that "YANG module" and "YANG data model" are preferred.
We have updated the text to use these forms. Please review.
b) We note that the following terms are used inconsistently. Please
review and let us know which form you prefer to use throughout the document for
consistency. If there are no objections, we will use the form on the right.
BFC Control Packet vs. BFD Control packet vs. BFD control packet
BFD Authentication vs. BFD authentication
Poll sequence vs. poll sequence
Single Hop BFD vs. single hop BFD
Detection Time vs. detection time
c) Are the terms "Authentication Present (A) bit" and "Authentication Bit"
referring to two different things? If they are used interchangeably, may we
update as follows to match Section 4.1 of RFC 5880?
Original (Authentication Present (A) bit):
When the Authentication Present (A) bit is set and the Auth Type
([RFC5880], Section 4.1) is a type supporting Optimized BFD
Authentication, the Auth Type signals a pairing of an MCI
authentication type and an LCI authentication type.
Original (Authentication Bit):
Once enabled, every packet must have the Authentication Bit set and
the associated Authentication Type appended (Section 4.1 of
[RFC5880]).
Perhaps (Authentication Bit):
Once enabled, every packet must have the Authentication Present (A) bit set
and the associated Authentication Type appended (Section 4.1 of [RFC5880]).
-->
</back> </back>
</rfc> </rfc>
 End of changes. 201 change blocks. 
656 lines changed or deleted 921 lines changed or added

This html diff was produced by rfcdiff 1.48.