<?xmlversion="1.0" encoding="US-ASCII"?> <?rfc toc="yes"?> <?rfc tocompact="yes"?> <?rfc tocdepth="3"?> <?rfc tocindent="yes"?> <?rfc symrefs="yes"?> <?rfc sortrefs="yes"?> <?rfc comments="yes"?> <?rfc inline="yes"?> <?rfc compact="yes"?> <?rfc subcompact="no"?>version='1.0' encoding='UTF-8'?> <?xml-model href="rfc7991bis.rnc"?> <!DOCTYPE rfc [ <!ENTITY nbsp " "> <!ENTITY zwsp "​"> <!ENTITY nbhy "‑"> <!ENTITY wj "⁠"> ]> <rfc xmlns:xi="http://www.w3.org/2001/XInclude" category="exp" docName="draft-ietf-bfd-optimizing-authentication-36" number="9985" updates="" obsoletes="" ipr="trust200902" submissionType="IETF"consensus="true">consensus="true" tocInclude="true" tocDepth="3" symRefs="true" sortRefs="true" version="3" xml:lang="en"> <front> <!-- [rfced] We have updated the title of the document to expand "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. Original: 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">OptimizingBFDBidirectional Forwarding Detection (BFD) Authentication</title> <seriesInfo name="RFC" value="9985"/> <author fullname="Mahesh Jethanandani" initials="M." surname="Jethanandani"> <organization>Arrcus</organization> <address> <postal><street/> <city/> <region/> <code/> <country>USA</country><country>United States of America</country> </postal><phone/> <facsimile/><email>mjethanandani@gmail.com</email><uri/></address> </author> <author fullname="Ashesh Mishra" initials="A" surname="Mishra"> <organization>Aalyria Technologies</organization> <address><postal> <street/> <city/> <region/> <code/> <country/> </postal> <phone/><email>ashesh@aalyria.com</email> </address> </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"> <organization>HPE</organization> <address><email>jhaas@juniper.net</email><email>jhaas@pfrc.org</email> </address> </author> <author fullname="Ankur Saxena" initials="A" surname="Saxena"> <organization>Ciena Corporation</organization> <address> <postal> <street>3939 N 1st Street</street> <city>San Jose</city> <region>CA</region> <code>95134</code><country>USA</country><country>United States of America</country> </postal><phone/> <facsimile/><email>ankurpsaxena@gmail.com</email><uri/></address> </author> <author fullname="ManavBhatia "Bhatia" initials="M."surname="Bhatia ">surname="Bhatia"> <organization>Google</organization> <address> <postal> <street>Doddanekkundi</street> <city>Bangalore</city> <code>560048</code> <country>India</country> </postal> <email>mnvbhatia@google.com</email> </address> </author><date/><date year="2025" month="May"/> <area>RTG</area> <workgroup>bfd</workgroup> <keyword>BFD</keyword> <keyword>authentication</keyword> <abstract> <t> This document describes an experimental optimization toBFDBidirectional Forwarding Detection (BFD) Authentication. This optimization enables BFD to scale better when there is a desire to use authentication where applying the same authentication mechanism to every BFD Control Packet may adversely impact performance. This optimization partitions BFD Authentication into a more computationally intensive (MCI) mechanism that is applied to BFD significantchanges,changes and a less computationally intensive (LCI) mechanism that is applied to the majority of BFD Control Packets. </t> </abstract> </front> <middle> <sectionanchor="introduction" title="Introduction">anchor="introduction"> <name>Introduction</name> <t><xref target="RFC5880">BFD</xref> authentication procedures, when enabled, authenticate each control packet using the same authentication mechanism. Devices implementing BFD are oftenresource constrainedresource-constrained and authentication may adversely impact the performance of BFD, thus discouraging the deployment of authentication.</t> <t>When implemented in software, BFD authentication mechanisms compete with other necessary work done by the systems implementing the protocol. When implemented using hardware acceleration, these mechanisms may scale 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 ofsessions,sessions and a detection time that relies on sending its control packets at a high rate. Implementers and operators are forced to evaluatetradeoffstrade-offs of the benefits of authentication vs. its impact on BFD performance.</t> <t>The authentication mechanisms documented in <xref target="RFC5880"/>, <xref target="RFC1321">MD5 Message-Digest Algorithm</xref></xref>, and <xref target="RFC3174">Secure Hash Algorithm(SHA-1)</xref>,(SHA-1)</xref> are not particularly strong in a cryptographic sense. However, they may still not appropriately scale situationally in a given implementation. In the future, there may be a desire to use stronger authentication mechanisms than those already specified, and those mechanisms are likely to use even more resources.</t> <t>The BFDprototocolprotocol can broadly be described as the set of procedures that handle its state machine changes to reach the Up state, and once BFD is in the Upstate sendingstate, it will send those Up packets at the negotiated high rate. The number of BFD Control Packets needed to signal state changes (called significant changes) is very small, while the majority of the Control Packets validate that the session remains in the Up state.</t> <t>This document describes an experimental optimization to BFD Authentication. This optimization partitions BFD Authentication into a more computationally intensive (MCI) mechanism used to authenticate significant changes, and a less computationally intensive (LCI) mechanism applied to the majority of the BFD Control Packets that don't signal such significant changes.</t> <t>The details of the motivation for experimental status are given in <xref target="experiment"/>.</t><section title="Requirements Language"> <t>The<section> <name>Requirements Language</name> <t> The key words"MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY","<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>", "<bcp14>REQUIRED</bcp14>", "<bcp14>SHALL</bcp14>", "<bcp14>SHALL NOT</bcp14>", "<bcp14>SHOULD</bcp14>", "<bcp14>SHOULD NOT</bcp14>", "<bcp14>RECOMMENDED</bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>", "<bcp14>MAY</bcp14>", and"OPTIONAL""<bcp14>OPTIONAL</bcp14>" in this document are to be interpreted as described inBCP 14BCP 14 <xref target="RFC2119"/> <xref target="RFC8174"/> when, and only when, they appear in all capitals, as shownhere.</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> 2025-11-12 with the actual date of the publication of this document.here. </t> </section> </section><section title="Terminology"><section> <name>Terminology</name> <t>The following terms used in this document have been defined in <xref target="RFC5880">BFD</xref>.</t><t><list style="symbols"><ul spacing="normal"> <li> <t>Auth Type</t> </li> <li> <t>Detect Multiplier</t> </li> <li> <t>Detection Time</t></list></t></li> </ul> <t>The following terms are introduced in this document.</t><texttable style="full"> <ttcol>Term</ttcol> <ttcol>Meaning</ttcol> <c>significant change</c> <c> State change,<!-- [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. Perhaps: significant change: A state change, demand mode change (to Dbit)bit), orapoll sequence change (P or F bit). Changes to BFD control packets that do not require a poll sequence, such asbfd.DetectMultbfd.DetectMult, are also considered a significant change. --> <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 do not require a poll sequence, such as bfd.DetectMult, are also considered a significant change.</c> <c>More</td> </tr> <tr> <td>More Computationally Intensive (MCI)authentication</c> <c>authentication</td> <td> The authentication mechanism applied to BFD Control Packets that are significant changes.</c> <c>Less</td> </tr> <tr> <td>Less Computationally Intensive (LCI)authentication</c> <c>authentication</td> <td> The authentication mechanism applied to BFD Control Packets that are NOT significant changes.</c> <c>configured</td> </tr> <tr> <td>configured MCI reauthenticationinterval</c> <c>interval</td> <td> Interval at which BFD control packets are retried usingmore computationally intensiveMCI authentication.</c> </texttable></td> </tr> </tbody> </table> <t> The authentication mechanisms described in this optimization are paired asmoreMCI andless computationally intensive.LCI. While it will be generally the case that the relationship between these mechanisms will be "stronger" and "less strong", this document doesn't use the term "strong" to avoid conflation with either mechanism's relative cryptographic strength. The relative criteria for each mechanism is the impact on the implementation. </t> </section> <sectionanchor="strong authentication" title="BFDanchor="strong_authentication"> <name>BFD Control Packets That RequireMore Computationally Intensive Authentication">MCI Authentication</name> <!-- <t> For purposes of this document, "strong authentication" refers to BFD authentication mechanisms such as those already defined for use with BFD. For example, MD5 and SHA1 (<xref target="RFC5880" section="6.7"/>). </t> --> <t> The intention of these optimized procedures is to permit more computationally intensive authentication for BFD state changes and utilize the less computationally intensive authentication mechanisms to provide protection for the session in the Up state while performing lessoverall work.work overall. Such procedures are intended to aid BFD session scaling without compromising BFD session security. </t> <t>All BFD Control Packets with the state AdminDown, Down, and InitMUST<bcp14>MUST</bcp14> use MCI authentication.</t> <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 <xref target="operations"/>. If optimized authentication mechanisms are in use, as defined in <xreftarget="optimized modes"/>,target="optimized_modes"/>, the sessionMAY<bcp14>MAY</bcp14> switch to the LCI mode.</t> <t>The contents of an Up packet must not change aside from the Authentication Section unless MCI authentication is in use.</t> <sectionanchor="significant changes" title="Protectinganchor="significant_changes"> <name>Protecting BFD Significant Changes withMore Computationally Intensive Authentication">MCI Authentication</name> <t> This document proposes that BFD control packets that signal a state change, a change in demand mode (D bit), or a poll sequence (P or F bit change) be categorized as a "significant change". Control packets that do not require a poll sequence, such asbfd.DetectMultbfd.DetectMult, are also consideredasa significant change. </t> <t> Such significant changes are intended to be protected by more computationally intensive authentication. </t> </section> </section> <sectionanchor="optimized type" title="Using Less Computationally Intensiveanchor="optimized_type"> <name>Using LCI AuthTypes">Types</name> <t> The majority of packets exchanged in a BFD session in the Up state are not significant changes. This document proposes a new optimized authentication mode where packets that are not significant changes may usea less computationally intensivean LCI authentication mechanism. </t> <t> Once the session has reached the Up state, the session can usea less computationally intensivean LCI Auth Type derived from the format in <xref target="signaling"/>. Currently, this includes: </t> <ul> <li> Meticulous Keyed ISAACauthenticationAuthentication as described in <xreftarget="I-D.ietf-bfd-secure-sequence-numbers"/>.target="RFC9986"/>. This authentication type protects the BFD session when BFD Up packets do not change, because only the paired devices know the shared secret, key, and sequence number to select the ISAAC result. </li> </ul></t><t> Other mechanisms may be defined in the future. </t> </section><section title="Periodic More Computationally Intensive Reauthentication"><section> <name>Periodic MCI Reauthentication</name> <t> When using theless computationally intensiveLCI authentication mechanism, BFD should periodically test the session using the MCI authentication mechanism. MCI authentication is tested using a Poll sequence. To test MCI authentication, a Poll sequenceSHOULD<bcp14>SHOULD</bcp14> be initiated by the sender using the MCI authentication mode rather than the LCI mechanism. If a control packet with the Final (F) bit is not received using MCI authentication within twice the Detect Interval as would be calculated by the receiving system, the session has been compromised, andMUSTit <bcp14>MUST</bcp14> be brought down. </t> <t> The value "twice the Detect interval as would be calculated by the receiving system" is, roughly, twice the number of packets the local system would transmit to the receiving system within its own Detect Interval. This accommodates for possible packet loss from the sending system during the Poll sequence to the receiving system, plus time for the receiving system to transmit control packet with the Final (F) bit set to the local system. </t> <t> This"more computationally intensive"MCI reauthentication interval" for performing such periodic tests using themore computationally intensiveMCI authentication mechanism can be configured depending on the capability of the system. </t> <t> Most packets transmitted in a BFD session are BFD Up packets. MCI authenticating a limited subset of these packets with a Poll sequence as described above,for examplee.g., every one minute, significantly reduces the computational demand for the system while maintaining security of the session across the configured MCI reauthentication interval. </t> </section> <sectionanchor="optimized modes" title="Optimizedanchor="optimized_modes"> <name>Optimized AuthenticationModes">Modes</name> <t>The cryptographic authentication mechanisms specified in <xref target="RFC5880" section="6.7">BFD</xref> describe enabling and disabling of authentication as aone timeone-time operation."...The following is stated in <xref target="RFC5880" section="6.7.1"/>:</t> <blockquote>... implementations using thismechanism SHOULDmethod <bcp14>SHOULD</bcp14> only allow the authentication state to be changed at most once without some form of intervention (so that authentication cannot be turned on and off repeatedly simply based on the receipt of BFD Control packets from remotesystems)." (<xref target="RFC5880" section="6.7.1"/>) Oncesystems).</blockquote> <!-- [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"/>). In addition, it states that an implementationSHOULD NOT<bcp14>SHOULD NOT</bcp14> allow the authentication state to be changed based on the receipt of a BFD control packet.</t> <t> This document proposes that an "optimized" authentication mode that permits botha more computationally intensivean MCI authentication mode anda less computationally intensivean LCI modetobe used within the same BFD session. This pairing ofaan MCI andaan LCI mode of authentication is carried in new BFD authentication types representing a given optimized authentication type pairing. </t> <t> This document definesin <xref target="significant changes"/>which BFD control packets require MCIauthentication.authentication in <xref target="significant_changes"/>. A BFD control packet that failsauthentication is discarded,authentication, or a BFD control packet that was supposed to beMCI authenticated,MCI-authenticated but wasnot; e.g.not (e.g., a significant changepacket,packet), is discarded. However, there is no change to the state machine for BFD, as the decision of a significant change is still decided by how many valid consecutive packets were received. </t> <t> In this specification, the contents of an Up packetMUST NOT<bcp14>MUST NOT</bcp14> change aside from the Authentication Section without MCI authentication. The full procedure is documented in the following sections. </t> </section> <sectionanchor="signaling" title="Signalinganchor="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? 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 that 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: * OptimizedAuthentication">BFD procedures will be in use. * The pairing of the MCI and LCI authentication mechanisms will be used for that session. * There is a requirement to carry a Sequence Number. * The current MCI or LCI mode will be carried as described below. --> <t> When the Authentication Present (A) bit is set and the Auth Type (<xref target="RFC5880" section="4.1" sectionFormat="comma"/>) is a type supporting Optimized BFD Authentication, the Auth Type signals a pairing ofa more computationally intensivean MCI authentication type anda less computationally intensivean LCI authentication type. This pairing is advertised in a single Auth Type value in order to permit implementations to be aware that: </t> <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 describedbelow:</li>below.</li> </ul></t> <t> <figure align="center" title="Common<figure> <name>Common Optimized BFD AuthenticationSection"> <artwork><![CDATA[Section</name> <artwork align="center"><![CDATA[ 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Auth Type | Auth Len | Auth Key ID | Opt. Mode | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Sequence Number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Authentication Specific Data ~+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ]]></artwork>+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+]]></artwork> </figure></t><!-- <t> The Meticulous Keyed MD5 (<xref target="RFC5880" section="6.7.3"/>), Meticulous Keyed SHA-1 (<xref target="RFC5880" section="6.7.4"/>), and Meticulous Keyed ISAAC Authentication (<xref target="I-D.ietf-bfd-secure-sequence-numbers" section="5"/>) Sections define the fourth octet of their respective PDUs as "Reserved". When used as the more computationally intensive authentication mechanism for new optimized authentication Auth Codes, the "Reserved" field of the PDU is repurosed as the "Optimized Authentication Mode" field. </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> The values of Auth Type and Auth Len are defined in their respective optimized BFD authentication procedural documents. </t> <t> The values of the Optimized Authentication Mode field are: </t> <ol> <li> When using themore computationally intensiveMCI authentication type for optimized BFD Auth Types. </li> <li> When using theless computationally intensiveLCI authentication type for optimized BFD Auth Types. </li> </ol></t><t> Authentication Specific Data: When using the more computationally intensive authentication type, the remainder of the Authentication Section carries that type's data. </t><section title="Transmitting<section> <name>Transmitting and Receiving Using OptimizedAuthentication">Authentication</name> <t> The procedures for authenticating BFD Control packets using Optimized Authentication is similar to the existing procedures covered in <xref target="RFC5880" section="6.7"/>. Optimized Authentication modes have common procedural requirements for authentication regardless of which more or less computationally intensive authentication modes are used. </t> <t> The required value of the Auth Len field for a given Optimized Authentication mode is defined in the respective specifications for their respectivemoreMCI andless computationally intensiveLCI modes. </t> <t> The following common procedures apply to authenticating BFD Control 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> If the received BFD Control packet does not contain an Authentication Section (<xref target="RFC5880" sectionFormat="comma" section="4.1"/>), or the Auth Type is not a supported Optimized Authentication Auth Type, then the received packetMUST<bcp14>MUST</bcp14> be discarded. </t> <t> 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 packetMUST<bcp14>MUST</bcp14> be discarded. </t> <t> If bfd.SessionState is AdminDown, Down, or Init and the Optimized Authentication Mode field is not 1, then the received packetMUST<bcp14>MUST</bcp14> be discarded. </t> <t> If bfd.SessionState is Up and there is a significant change as defined in <xreftarget="significant changes"/>,target="significant_changes"/>, and the Optimized Authentication Mode field is not 1, then the received packetMUST<bcp14>MUST</bcp14> be discarded. </t> <t> If the Auth Len field is not equal to a value appropriate for the Optimized Authentication Mode field, the packetMUST<bcp14>MUST</bcp14> be discarded. </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 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 numberspace)space), the received packetMUST<bcp14>MUST</bcp14> be discarded. </t> <t> Otherwise (bfd.AuthSeqKnown is 0), bfd.AuthSeqKnownMUST<bcp14>MUST</bcp14> be set to 1, bfd.RcvAuthSeqMUST<bcp14>MUST</bcp14> be set to the value of the received Sequence Number field, and the received packetMUST<bcp14>MUST</bcp14> be accepted. </t> <t> For the specified Auth Type and Optimized Authentication Mode, perform the appropriate authentication procedures. If authentication succeeds, the received packetMUST<bcp14>MUST</bcp14> be accepted. Otherwise, the received packetMUST<bcp14>MUST</bcp14> be discarded. </t> </section> <sectionanchor="operations" title="Optimizedanchor="operations"> <name>Optimized AuthenticationOperations">Operations</name> <t> As noted in <xreftarget="significant changes"/>,target="significant_changes"/>, when using optimized BFD procedures,more computationally intensiveMCI 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 in the BFD Control packet when in the Up state. </t> <t> Once the BFD session has reached the Up state, the BFD Up stateMUST<bcp14>MUST</bcp14> 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 the LCI authentication mode. This is to permit mechanisms such as <xreftarget="I-D.ietf-bfd-secure-sequence-numbers">target="RFC9986"> Meticulous Keyed ISAAC for BFDAuthentication</xref>,Optimized Authentication</xref> or otherapprovedapproved, less intensive authenticationmechanisms,mechanisms to be bootstrapped before switching to the LCI mode. </t> <t> It isRECOMMENDED<bcp14>RECOMMENDED</bcp14> that when using optimized authentication that implementations switch from MCI authentication to LCI authentication mode after an interval that is at least the Detection Time. In the circumstances where a BFD session successfully reaches the Up state with MCI authentication, but there are problems with the LCI authentication, this will permit the remote system to tear down the session as quickly as possible. </t> <t> BFD sessions using optimized authentication that succeed in reaching the Up state using MCI authentication and fail using LCI authenticationSHOULD<bcp14>SHOULD</bcp14> bring the issue to the attention of the operator.Further,Furthermore, implementationsMAY<bcp14>MAY</bcp14> wish to throttle session restarts. </t> <t> It is furtherRECOMMENDED<bcp14>RECOMMENDED</bcp14> that BFD implementations using optimized authentication defer notifying their client that the session has reached the Up state until it has transitioned to using the LCI authentication mode. In the event where LCI authentication is failing in the protocol, this avoids propagating the failed transitions to the LCI mode to their clients. </t> </section> </section> <sectionanchor="opt-auth-yang-model" title="Optimizinganchor="opt-auth-yang-model"> <name>Optimizing Authentication YANG DataModel">Model</name> <sectionanchor="data-model-overview" title="Dataanchor="data-model-overview"> <name>Data ModelOverview">Overview</name> <t> The <xref target="RFC7950">YANG 1.1</xref> data model defined in this document augments the "ietf-bfd" module to add data nodes relevant to the management of the feature defined in this document. It adds an interval value that specifies how often the BFD session should bere-authenticatedreauthenticated using more computationally intensive authentication once it is in the Up state. </t> </section> <sectionanchor="tree-diagram" title="Tree Diagram">anchor="tree-diagram"> <name>Tree Diagram</name> <t> The tree diagram for the YANG modules defined in this document use annotations defined in <xref target="RFC8340">YANG TreeDiagrams.</xref>.Diagrams</xref>. </t><t> <figure> <artwork><![CDATA[<sourcecode type="yangtree"> module: ietf-bfd-opt-auth augment /rt:routing/rt:control-plane-protocols /rt:control-plane-protocol/bfd:bfd/bfd-ip-sh:ip-sh /bfd-ip-sh:sessions/bfd-ip-sh:session /bfd-ip-sh:authentication: +--rw reauth-interval? uint32 augment /rt:routing/rt:control-plane-protocols /rt:control-plane-protocol/bfd:bfd/bfd-ip-mh:ip-mh /bfd-ip-mh:session-groups/bfd-ip-mh:session-group /bfd-ip-mh:authentication: +--rw reauth-interval? uint32 augment /rt:routing/rt:control-plane-protocols /rt:control-plane-protocol/bfd:bfd/bfd-lag:lag /bfd-lag:sessions/bfd-lag:session/bfd-lag:authentication: +--rw reauth-interval? uint32 augment /rt:routing/rt:control-plane-protocols /rt:control-plane-protocol/bfd:bfd/bfd-mpls:mpls /bfd-mpls:session-groups/bfd-mpls:session-group /bfd-mpls:authentication: +--rw reauth-interval?uint32 ]]></artwork> </figure> </t>uint32</sourcecode> </section> <sectionanchor="the-yang-model" title="Theanchor="the-yang-model"> <name>The YANG DataModel"> <t>Model</name> <!-- [rfced] RFC 8177 doesn't appear to be referenced in the YANG Module. Please review and let us know if/how we should update the module or if this reference should be removed. Current: This YANG module imports modules defined in<xref target="RFC8177">YANGYANG Data Model for KeyChain </xref>, <xref target="RFC8349">AChains [RFC8177], A YANG Data Model for Routing Management (NMDAversion)</xref>,Version) [RFC8349], and<xref target="RFC9314">YANGYANG Data Model for Bidirectional Forwarding Detection(BFD)</xref>.(BFD) [RFC9314]. --> <t> This YANG module imports modules defined in "<xref format="title" target="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 this document enable optimization by using one of the newly defined key-chain crypto-algorithms defined in this YANG module. </t><t> <figure> <artwork><![CDATA[ <CODE BEGINS> file "ietf-bfd-opt-auth@2025-11-12.yang"<!--[rfced] The YANG module (Section 8.3) has been updated as shown below per the formatting option of pyang. Please let us know of 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 { yang-version 1.1; namespace "urn:ietf:params:xml:ns:yang:ietf-bfd-opt-auth"; prefix"bfd-oa";bfd-oa; import ietf-routing { prefix"rt";rt; reference "RFC 8349: A YANG Data Model for Routing Management (NMDAversion)";version)."; } import ietf-bfd { prefix bfd; reference "RFC 9314: YANG Data Model for Bidirectional Forwarding Detection (BFD)."; } import ietf-bfd-ip-sh { prefix bfd-ip-sh; reference "RFC 9314: YANG Data Model for Bidirectional Forwarding Detection (BFD)."; } import ietf-bfd-ip-mh { prefix bfd-ip-mh; reference "RFC 9314: YANG Data Model for Bidirectional Forwarding Detection (BFD)."; } import ietf-bfd-lag { prefix bfd-lag; reference "RFC 9314: YANG Data Model for Bidirectional Forwarding Detection (BFD)."; } import ietf-bfd-mpls { prefix bfd-mpls; reference "RFC 9314: YANG Data Model for Bidirectional Forwarding Detection (BFD)."; } organization "IETFBFDBidirectional Forwarding Detection (BFD) Working Group"; contact "WG Web: <http://tools.ietf.org/wg/bfd> WG List: <rtg-bfd@ietf.org> Authors: Mahesh Jethanandani (mjethanandani@gmail.com) Ashesh Mishra (ashesh@aalyria.com) Ankur Saxena (ankurpsaxena@gmail.com) Manav Bhatia (mnvbhatia@google.com) Jeffrey Haas (jhaas@juniper.net)."; description "This YANG module augments the base BFD YANGmodelmodule to add attributes related to the experimental BFD Optimized Authentication. 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)20252026 IETF Trust and the persons identified as authors of the code. All rights reserved. Redistribution and use in source and binary forms, with or without modification, is permitted pursuant to, and subject to the license terms contained in, the Revised BSD License set forth in Section 4.c of the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info). This version of this YANG module is part of RFCXXXX (https://www.rfc-editor.org/info/rfcXXXX);9985 (https://www.rfc-editor.org/info/rfc9985); see the RFC itself for full legalnotices. 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.";notices."; revision"2025-11-12""2026-05-19" { description "Initial Version."; reference "RFCXXXX:9985: Optimizing BFD Authentication."; } feature optimized-auth { description "Indicates that the implementation supports optimized authentication."; reference "RFCXXXX:9985: Optimizing BFD Authentication."; } grouping bfd-opt-auth-config { description "Grouping for BFD Optimized Authentication Parameters."; leaf reauth-interval { type uint32; units "seconds"; default "60"; description "Interval of time after which more computationally intensive authentication should be utilized to prevent an on-path-attacker attack. A value of zero means that we do not do periodic reauthentication using the more computationally intensive authentication method. This value SHOULD have jitter applied to it to avoid self-synchronization during expensive authentication operations."; } } augment "/rt:routing/rt:control-plane-protocols" + "/rt:control-plane-protocol/bfd:bfd/bfd-ip-sh:ip-sh" + "/bfd-ip-sh:sessions/bfd-ip-sh:session" + "/bfd-ip-sh:authentication" { uses bfd-opt-auth-config; description "Augment the 'authentication' container for single hop BFD module to add attributes related to BFD optimized authentication."; } augment"/rt:routing/rt:control-plane-protocols/""/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; description "Augment the 'authentication' container for multi-hop BFD module to add attributes related to BFD optimized authentication."; } augment"/rt:routing/rt:control-plane-protocols/""/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; description "Augment the 'authentication' container for BFD over LAG module to add attributes related to BFD optimized authentication."; } augment"/rt:routing/rt:control-plane-protocols/""/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; description "Augment the 'authentication' container for BFD over MPLS module to add attributes related to BFD optimized authentication."; }} <CODE ENDS> ]]></artwork> </figure> </t>}]]></sourcecode> </section> </section> <sectionanchor="IANA" title="IANA Considerations">anchor="IANA"> <name>IANA Considerations</name> <t>This documents requests the assignment ofIANA has assigned one URI and one YANGmodel.module as described in this section. </t> <sectionanchor="ietf-xml-registry" title="IETFanchor="ietf-xml-registry"> <name>IETF XMLRegistry">Registry</name> <t>This document registers one URIsIANA has registered the following URI in the "ns"subregistry of the "IETF XML"registry<xref target="RFC3688"/>. Followingwithin theformat in"IETF XML Registry" group <xreftarget="RFC3688"/>, the following registration is requested:target="RFC3688"/>: </t><t> <figure> <artwork> <![CDATA[ URI: urn:ietf:params:xml:ns:yang:ietf-bfd-opt-auth Registrant Contact: The IESG XML: N/A,<dl spacing="compact" newline="false"> <dt>URI:</dt><dd>urn:ietf:params:xml:ns:yang:ietf-bfd-opt-auth</dd> <dt>Registrant Contact:</dt><dd>The IESG</dd> <dt>XML:</dt><dd>N/A; the requested URI is an XMLnamespace. ]]> </artwork> </figure> </t>namespace.</dd> </dl> </section> <sectionanchor="yang-module-names" title="Theanchor="yang-module-names"> <name>The YANG Module NamesRegistry">Registry</name> <t>This document registers oneIANA has registered the following YANGmodulesmodule in the "YANG Module Names" registry <xreftarget="RFC6020"/>. Following the format in <xref target="RFC6020"/>,target="RFC6020"/> within thefollowing registrations are requested:"YANG Parameters" registry group: </t><t> <figure> <artwork> <![CDATA[ name: ietf-bfd-opt-auth namespace: urn:ietf:params:xml:ns:yang:ietf-bfd-opt-auth prefix: bfd-oa maintained<dl spacing="compact" newline="false"> <dt>Name:</dt><dd>ietf-bfd-opt-auth</dd> <dt>Maintained byIANA: No reference: RFC XXXX ]]> </artwork> </figure> </t>IANA:</dt><dd>No</dd> <dt>Namespace:</dt><dd>urn:ietf:params:xml:ns:yang:ietf-bfd-opt-auth</dd> <dt>Prefix:</dt><dd>bfd-oa</dd> <dt>Reference:</dt><dd>RFC 9985</dd> </dl> </section> </section> <sectionanchor="Security" title="Security Considerations">anchor="Security"> <name>Security Considerations</name> <sectionanchor="Protocol Security" title="Protocolanchor="Protocol_Security"> <name>Protocol SecurityConsiderations">Considerations</name> <t> Devices implementing BFD are oftenresource constrained,resource-constrained, whether in a singlesession,session or a multidimensional set of scaled sessions. Desired detection intervals for the BFD sessions, and their number, are common scaling considerations for BFD implementations. Security mechanisms also impact the performance of implementations, whether in software or hardware, due to the use of additional computational resources these mechanisms use. </t> <t> The optimized procedures in this document provide a different level of resistance to attack than methods using a single authentication mechanism: </t> <ul> <li> Themore computationally intensiveMCI authentication mechanisms used for optimized authentication are expected to have similar cryptographic strength acceptable for BFD for authenticating the entire session, as described in <xref target="RFC5880"/>. </li> <li> When the BFD state machine is attempting to move from the Down state to the Up state, themore computationally intensiveMCI authentication mechanism is intended to protect vs.attemptsattempt to inappropriately start BFD sessions. </li> <li> When the BFD state machine is in the Up state, themore computationally intensiveMCI authentication mechanism is intended to protect vs.attemptsattempt to change BFD session parameters or to reset the BFD session. </li> <li> <!-- [rfced] May we rephrase the following sentence to avoid repetition of "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, theless computationally intensiveLCI authentication mechanism is intended to provide resistance to keeping a BFD session in the Up state inappropriately. Since the procedures for changing BFD state require themore computationally intensiveMCI mechanism and theless computationally intensiveLCI 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. </li> <li> Theperiodic more computationally intensive re-authenticationperiodic, MCI reauthentication procedure provides protection against long-term successful spoofing of theless computationally intensiveLCI authentication mechanism. </li> </ul></t><t> In other words, the intention of optimized BFD procedures is to make it difficult to reset or inappropriately start BFD sessions. However, protecting against keeping the session Up is seen as a less interesting attack and can receive less protection. </t> <t>The recent escalating series of attacks on MD5 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 Search for SHA-1 </xref> raise concerns about their remaining useful lifetime as outlined in <xref target="RFC6151">Updated Security Considerations for the MD5 Message-Digest and the HMAC-MD5 Algorithm </xref> and <xref target="RFC6194">Security Considerations for the SHA-0 and SHA-1 Message-Digest Algorithm </xref>. If replaced by strongeralgorithmsalgorithms, the computational overhead will make the task of authenticating every packet even more difficult to achieve.</t> <t>The procedures described in this document provide a mechanismwhichthat could enable implementations to leverage stronger security to address the concerns above when strong authentication is required. However, this requires operators to evaluate thetradeoffstrade-offs of the less computationally intensive mechanisms to adequately address their desired security stance.</t> <t>Keys generated and distributed out of band for the purposes described in this specification are generally limited in the security they can provide. It is essential that these keys are selectedwell,well and protected when stored.</t> </section> <sectionanchor="YANG Security" title="YANGanchor="YANG_Security"> <name>YANG SecurityConsiderations">Considerations</name> <t> <!-- [rfced] FYI - We have updated the following text to point to Section 3.7.1 instead of Section 3.7 in order to match the 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 <xreftarget="I-D.ietf-netmod-rfc8407bis"/>.section="3.7.1" target="RFC9907"/>. </t> <t> The "ietf-bfd-opt-auth" YANG module defines a data model that is designed to be accessed via YANG-based management protocols, such as the Network Configuration Protocol (NETCONF) <xreftarget="RFC6241">NETCONF</xref> ortarget="RFC6241"/> and RESTCONF <xreftarget="RFC8040">RESTCONF</xref>.target="RFC8040"/>. These YANG-based management protocols (1) have to use a secure transport layer (e.g., Secure Shell (SSH) <xreftarget="RFC4252">SSH</xref>target="RFC4252"/>, TLS <xreftarget="RFC8446">TLS</xref>,target="RFC8446"/>, and QUIC <xreftarget="RFC9000">QUIC</xref>)target="RFC9000"/>) and (2) have to use mutual authentication. </t> <t> The Network Configuration Access Control Model (NACM) <xreftarget="RFC8341">(NACM)</xref>target="RFC8341"/> provides the means to restrict access for particular NETCONF or RESTCONF users to a preconfigured subset of all available NETCONF or RESTCONF protocol operations and content. </t> <t> There are a number of data nodes defined in this YANG module that are writable/creatable/deletable (i.e., "config true", which is the default). All writable data nodes are likely to be sensitive or vulnerable in some network environments. Write operations (e.g., edit-config) and delete operations to these data nodes without proper protection or authentication can have a negative effect on network operations. The following subtrees and data nodes have particular sensitivities/vulnerabilities: </t> <ul> <li> 'reauth-interval' specifies the interval in Up state, after whichmore computationally intensiveMCI authenticationSHOULD<bcp14>SHOULD</bcp14> be performed to prevent aPerson-In-The-MiddlePerson-in-the-Middle (PITM) attack. If this interval is set very low, the utility of these optimization procedures is lessened. If this interval is set very high, attacks detected by themore computationally intensiveMCI authentication mechanisms may happen overly late. </li> </ul> <t> There are no particularly sensitive readable data nodes. </t> <t> There are no RPC operations defined in this model. </t> </section> </section><section title="Contributors" anchor="contributors"> <t> The authors</middle> <back> <references> <name>References</name> <references> <name>Normative References</name> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.2119.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.3688.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5880.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.6020.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7950.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8174.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8177.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8349.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9314.xml"/> </references> <references> <name>Informative References</name> <!-- [rfced] References a) For [SHA-1-attack1]: We found an open access version of thisdocument would likepaper: https://link.springer.com/chapter/10.1007/11535218_2. May we update this reference toacknowledge Reshad Rahman as a contributorpoint to thisdocument. </t> </section> <section title="Acknowledgments"> <t>The authors would likeversion? Current: [SHA-1-attack1] Wang, X., Yin, Y., and H. Yu, "Finding Collisions in the Full SHA-1", 2005. 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>. b) For [SHA-1-attack2]: We were unable tothank Qiufang Ma, Stephen Farrell, and Acee Lindemfind a source that matched this reference's information. We did find a presentation forproviding directorate review ofthe NIST Cryptographic Hash Workshop from the authors listed in thisdocument.</t> </section> </middle> <back> <references title="Normative References"> <?rfc include="reference.RFC.2119.xml"?> <?rfc include='reference.RFC.3688.xml'?> <?rfc include='reference.RFC.5880.xml'?> <?rfc include='reference.RFC.6020.xml'?> <?rfc include='reference.RFC.7950.xml'?> <?rfc include='reference.RFC.8174.xml'?> <?rfc include='reference.RFC.8177.xml'?> <?rfc include='reference.RFC.8349.xml'?> <?rfc include='reference.RFC.9314.xml'?> </references> <references title="Informative References">reference: https://csrc.nist.gov/csrc/media/events/first-cryptographic-hash-workshop/documents/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/><address> <postal> <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> <!-- 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 Computer 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/><address> <postal> <street/> <city/> <region/> <code/> <country/> </postal> <phone/> <facsimile/> <email/> <uri/> </address></author> <author initials="F." surname="Yao"> <organization/><address> <postal> <street/> <city/> <region/> <code/> <country/> </postal> <phone/> <facsimile/> <email/> <uri/> </address></author> <date year="2005"/> </front> </reference><?rfc include='reference.RFC.1321.xml'?> <?rfc include='reference.RFC.2026.xml'?> <?rfc include='reference.RFC.3174.xml'?> <?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'?><xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.1321.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.2026.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.3174.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.6151.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.6194.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8340.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.4252.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.6241.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8040.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8341.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8446.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8792.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9000.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9907.xml"/> <!-- companion document 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 Authentication </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> <sectionanchor="examples" title="Examples">anchor="examples"> <name>Examples</name> <t> This section tries to show some examples in how the model can be configured. </t> <sectionanchor="example-a.1.1" title="Singleanchor="example-a.1.1"> <name>Single Hop BFDConfiguration">Configuration</name> <t> <!--[rfced] Appendix A a) FYI: We added the following sentence to Appendix A.1 with a corresponding reference entry for RFC 8792 in the Informative References section. Original: This example demonstrates how a Single Hop BFD session can be configured for optimized authentication. Current: This example demonstrates how a Single Hop BFD session can be configured for optimized authentication. Note that line wrapping is used per [RFC8792]. b) When running xmllint on the XML schema, we received the following error. Are any changes needed to the schema, or is it ok as is? Error: Extra content at the end of the document <interfaces ^ --> This example demonstrates how a Single Hop BFD session can be configured for optimized authentication. Note that line wrapping is used per <xref target="RFC8792"/>. </t><t> <figure> <artwork><![CDATA[<sourcecode type="xml"><![CDATA[ =============== NOTE: '\' line wrapping per RFC 8792 =============== <?xml version="1.0" encoding="UTF-8"?> <key-chains xmlns="urn:ietf:params:xml:ns:yang:ietf-key-chain" xmlns: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\ saac"> <key-chain> <name>bfd-auth-config</name> <description>"An example for BFD Optimized Auth configuration."\ </description> <key> <key-id>55</key-id> <lifetime> <send-lifetime> <start-date-time>2017-01-01T00:00:00Z</start-date-time> <end-date-time>2017-02-01T00:00:00Z</end-date-time> </send-lifetime> <accept-lifetime> <start-date-time>2016-12-31T23:59:55Z</start-date-time> <end-date-time>2017-02-01T00:00:05Z</end-date-time> </accept-lifetime> </lifetime> <crypto-algorithm>bfd-mki:optimized-sha1-meticulous-keyed-isa\ ac</crypto-algorithm> <key-string> <keystring>testvector</keystring> </key-string> </key> </key-chain> </key-chains> <interfaces xmlns="urn:ietf:params:xml:ns:yang:ietf-interfaces" xmlns:if-type="urn:ietf:params:xml:ns:yang:iana-if-type"> <interface> <name>eth0</name> <type>if-type:ethernetCsmacd</type> </interface> </interfaces> <routing xmlns="urn:ietf:params:xml:ns:yang:ietf-routing" xmlns:bfd-types="urn:ietf:params:xml:ns:yang:ietf-bfd-types" xmlns:iana-bfd-types="urn:ietf:params:xml:ns:yang:iana-bfd-type\ s" 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\ saac"> <control-plane-protocols> <control-plane-protocol> <type>bfd-types:bfdv1</type> <name>name:BFD</name> <bfd xmlns="urn:ietf:params:xml:ns:yang:ietf-bfd"> <ip-sh xmlns="urn:ietf:params:xml:ns:yang:ietf-bfd-ip-sh"> <sessions> <session> <interface>eth0</interface> <dest-addr>2001:db8:0:113::101</dest-addr> <desired-min-tx-interval>10000</desired-min-tx-interv\ al> <required-min-rx-interval> 10000 </required-min-rx-interval> <authentication> <key-chain>bfd-auth-config</key-chain> <opt-auth:reauth-interval>30</opt-auth:reauth-inter\ val> </authentication> </session> </sessions> </ip-sh> </bfd> </control-plane-protocol> </control-plane-protocols></routing> ]]> </artwork> </figure> </t></routing>]]></sourcecode> </section> </section> <sectionanchor="experiment" title="Experimental Status">anchor="experiment"> <name>Experimental Status</name> <t> This document describes an experiment that presents a candidate solution to update BFD Authentication that is currently specified in <xref target="RFC5880"/>. This experiment is intended to provide additional insights into what happens when the optimized authentication mechanism defined in this document is used. Here are the reasons why this document is on the Experimental track:<t><list style="symbols"></t> <ul spacing="normal"> <li> <t> In the initial stages of the document, there were significant participation and reviews from the working group. <!-- [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.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 of a single Auth Type to indicate use of optimized authentication, etc. These changes did not get significant review from the working group and thereforedoesdo not meet the bar set inSection 4.1.1 of<xreftarget="RFC2026"/>target="RFC2026" section="4.1.1"/>. </t> </li> <li> <t> There are no known implementations at this time. </t> </li> <li> <t> The work in this document could become very valuable in the future, especially if the need for deploying BFD authentication at scale becomes a reality. </t></list></t> </t></li> </ul> <t> This document is classified as Experimental and is not part of the IETF Standards Track. Implementations based on this document should not be considered as compliant with <xref target="RFC5880">BFD</xref>. </t> </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> </rfc>