Jeff and Ketan, Thanks for your prompt replies. See below for EV>
Regards -éric From: Jeffrey Haas <[email protected]> Date: Monday, 25 August 2025 at 16:07 To: Eric Vyncke (evyncke) <[email protected]> Cc: The IESG <[email protected]>, [email protected] <[email protected]>, [email protected] <[email protected]>, rtg-bfd@ietf. org <[email protected]>, Reshad Rahman <[email protected]>, Reshad Rahman <[email protected]> Subject: Re: Éric Vyncke's Discuss on draft-ietf-bfd-optimizing-authentication-29: (with DISCUSS and COMMENT) [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. :-) EV> while I welcome reusing code & procedure, I would err on the “update” side (even for an experimental draft updating a PS one). To be discussed at the IESG telechat next week. > > ### 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? EV> correct, the proposed text will clear this DISCUSS point once submitted. @@ -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:" EV> actually, after re-re-reading sections 7 & 7.1, I would suggest: s/ For example, for Auth Type "Optimized MD5 Meticulous Keyed ISAAC Authentication" (type TBD):/ For example, for Auth Type "Optimized MD5 Meticulous Keyed ISAAC Authentication" (section 7.1 of this document):/ EV> and consider this point as a non-blocking COMMENT > > ### 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. EV> we disagree 😊 EV> rather than using “TBD” you need to add a RFC Editor note to replace all “TBD” by the actual value once known EV> *AND* add a normative reference to the secure-seq-number I-D the first time this TBD is used. > > ## 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> EV> thanks > > 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. EV> I agree with you, let’s simply remove the sentence about future crypto algos 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. EV> after reading your comment above, I dig further and indeed ISAAC does not seem to be an acronym. It also makes me wonder about the choice of this algo. Curious to read the SEC ADs views. > > ### 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. EV> as I am not a SEC AD, I will let them comment when the review the draft. > > ### 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
