[Speaking largely as one of the contributing authors.] Éric,
Thanks for your comments. > On Aug 25, 2025, at 7:04 AM, Éric Vyncke via Datatracker <[email protected]> > wrote: > > ## DISCUSS (blocking) > > > ### Sections 6 & 7 > > Should this document formally update RFC 5880 ? Especially based on section 7 > `This document repurposes the "Reserved" field as the "Optimized > Authentication > Mode" field when used for authentication types for optimized BFD procedures.` Taking a different but related point of view from Ketan's response, BFD authentication is generically defined in §4.1 of RFC 5880. You'll note, that it defines only a type, and a length. As Ketan points out, each subsequent section defines individual types. From this point of view, the new optimized types discussed in this document and refined in the secure sequence numbers document (which really must be evaluated together), these are "new". They happen to conveniently be largely based on the types defined in RFC 5880, and so is the procedure. This permits implementations to heavily leverage significant portions of code and procedure. :-) > > ### Section 7 > > s/excepting that Auth Type is *still* TBD and that *Reserved* is set to > 1/excepting that Auth Type is TBD and that *"Optimized Authentication Mode"* > is > set to 1/ > > As 'Reserved' has just been reused, then the new field name must be used. [Note that these diffs are staged in the document github and will be pushed into the next revision upon conclusion of review.] I believe the diff you wish to see is this? @@ -398,13 +398,13 @@ <t> When Optimized Authentication Mode is 1, the format of the authentication section is the same as <xref target="RFC5880" section="4.3"/>, - excepting that Auth Type is still TBD and that Reserved is set to 1. + excepting that Auth Type is TBD and that the Optimized Authentication Mode field is set to 1. </t> <t> When Optimized Authentication Mode is 2, the format of the authentication section is the same as <xref target="I-D.ietf-bfd-secure-sequence-numbers" section="5"/>, - excepting that Auth Type is still TBD and that Reserved is set to 2. + excepting that Auth Type is TBD and that the Optimized Authentication Mode field is set to 2. </t> > > ### Section 7.1 > > The text is about OptMode being 1 or 2 while the previous section introduced > these values with "For example" and restricting it to MD-5-related > authentication. It is either an example (like section 7) or normative (like > section 7.1). Was this sentence unclear in the procedure? "The following common procedures apply to authenticating BFD Control packets utilizing Optimized Authentication:" > > ### Section 9 > > Even more critical, there is no request to the IANA to allocate the `TBD` > authentication type in > https://www.iana.org/assignments/bfd-parameters/bfd-parameters.xhtml#bfd-parameters-2 As Ketan notes, the request is in the secure sequence numbers document. The need here is for the RFC Editor to keep the two document synchronized. > > ## COMMENTS (non-blocking) > > ### Section 3 > > In `If optimized authentication mechanisms are in use` the 'optimized > authentication mechanisms' have not been formally specified as 'the mechanisms > described in this document'. Suggest adding it either here '(i.e., this > specication)' or in the terminology section. Updated: <t>Once the BFD state machine has reached the Up state, it will continue to send BFD Control Packets in the Up state for a period as discussed in <xref target="operations"/>. If optimized authentication mechanisms are - in use, the session MAY switch to the less computationally intensive + in use, as defined later in this document, the session MAY switch to the less computationally intensive mode.</t> > > Unsure whether this draft is the right place to say "SHA-2 is left for future > study" (if BFD does not support it). BFD doesn't support it at the moment. It has, however, been specified and left in the document graveyard: https://datatracker.ietf.org/doc/html/draft-ietf-bfd-hmac-sha-05 The motivation for the optimized authentication and secure sequence number documents was that the computational overhead for BFD using stronger ciphers proved infeasible. As we inevitably have to walk the new security AD through each time we do a BFD document, line cards have better things to do with their CPU than generate cryptographic signatures over tiny packets ever few milliseconds. These overheads already push operators to avoid bothering with encryption. The goal here is to reduce the general overheads for the protocol while at the same time leverage better cryptography when it's important. For your COMMENT, my recommendation is that we skip talking about other ciphers, especially in this document. What little we discuss is intended to be exemplary in terms of how optimized behavior can operate and defer specific procedure for a given cipher to other documents. As an example, if we wanted to dig SHA-2 out of the draft graveyard, the appropriate thing to do would be to define it as a paired optimized draft similar to how MD5 and SHA-1 are treated in the secure sequence numbers draft. > > ### Section 3.1 > > s/do not require a poll sequence, such as a bfd.DetectMult are/do not require > a > poll sequence, such as a bfd.DetectMult*,* are/ ? - such as a bfd.DetectMult are also considered as a + such as bfd.DetectMult are also considered as a > > ### Section 4 > > Readers (including me) will welcome an expansion of ISAAC. Note that this isn't very well expanded even in the defining documents. I recommend leaving this comment hanging until the IESG has reviewed the secure sequence numbers document and deciding what to do about the term in that document. > > ### Section 5 > > Is it about "reauthentication" or "authentication refresh" ? I'm unclear as to how the two of these are distinct. If there's a citable preferred term of art that we should be using, we can certainly move to it. Note that this will have impact on the YANG module. > > ### Section 8 > > s/Optimizing Authentication YANG Model/Optimizing Authentication YANG Data > Model/ ? - <section anchor="opt-auth-yang-model" title="Optimizing Authentication YANG Model"> + <section anchor="opt-auth-yang-model" title="Optimizing Authentication YANG Data Model"> <section anchor="data-model-overview" title="Data Model Overview"> <t> The <xref target="RFC7950">YANG 1.1</xref> model defined in @@ -549,7 +549,7 @@ </figure> </t> </section> - <section anchor="the-yang-model" title="The YANG Model"> + <section anchor="the-yang-model" title="The YANG Data Model"> <t> This YANG module imports <xref target="RFC8177">YANG Key Chain </xref>, <xref target="RFC8349">A YANG Data Model for
