Hi Gorry, I would like to follow up on your DISCUSS and comments on this document. The authors have posted v35 of the document that clarifies what is meant by "optimizing". Can you check if that is now clarified and ok with you?
If not, then I would like to offer some suggestions (to you and the authors) to consider: Lightweight BFD Authentication CSPRNG Based BFD Authentication Alternating BFD Authentication Alternating Between Regular and Lightweight BFD Authentication Thanks, Ketan On Mon, Aug 25, 2025 at 9:34 PM Gorry Fairhurst <[email protected]> wrote: > On 25/08/2025 16:51, Jeffrey Haas wrote: > > Gorry, > Thank you for the very quick response. > >> On Aug 25, 2025, at 10:33 AM, Gorry Fairhurst via Datatracker < > [email protected]> wrote: > >> ---------------------------------------------------------------------- > >> DISCUSS: > >> ---------------------------------------------------------------------- > >> > >> Thank you for the work put into this document. I have one topic that > I'd like > >> to discuss: > >> > >> ### 1. In the title and throughout the document, I a became little > unsure about > >> the words > >> optimized BFD authentication - The title worries me. I > >> think the words "optimised" could suggest stronger authentication, > which > >> seems to me to not be the case, and hence this could be potentially > >> confusing because this is not really optimised for better > authentication, > >> but a more lightweight implementation of authentication, which I > understand > >> from the I-D is expected could also make authentication more easy to > deploy, > >> which could have merit. > > The term optimized is used in the dictionary sense as "improved" and not > to imply "to make stronger". > > > > If there is text in the document that implies that this is otherwise, > let's discuss that. > > GF: OK, I've stepped-up to have this discussion. I have no predetermined > outcome that I wish to see happen at this time, except to discuss if we > can find a "representative" title, and I agree that before we have that > discussion, we ought to gather more IESG reviews. > > > During the lifetime of the optimized authentication and secure sequence > number documents, there was an understood tension that some of the > terminology would likely be in need of refinement when we reached IESG > discussion. As an example, we avoid using "strong authentication" because > this will immediately give people reason for objection when MD5 and SHA-1 > are used in that context; they are merely "stronger". Similarly, we avoid > using "weak/weaker", "less strong", and instead have focused on "less > computationally intensive" even though it is clumsy. > > > > It is hopefully contextually clear when reviewing both the optimized > authentication draft and the secure sequence numbers drafts together that > the optimization is to use stronger authentication for state changes, and > for the vast majority of BFD Up packets (the real work of the protocol) > that we're providing a mode that permits those packets to use the less > computationally intensive method to do their protocol work while at the > same time not break the CPU budget. > > > > The IESG is welcome to recommend a cluster of terms that covers all of > the related properties, especially if citably covered by appropriate terms > of art. > GF: Sounds good, and Ketan is currently the responsible AD. > > > >> ---------------------------------------------------------------------- > >> COMMENT: > >> ---------------------------------------------------------------------- > >> > >> Thanks for preparing this I-D, I have the following comments which I > hope will > >> help revise this I-D. > >> > >> ### 1. Thank you to Marcus Ihlar for his TSV-ART review, see: > >> > https://datatracker.ietf.org/doc/review-ietf-bfd-optimizing-authentication-28-tsvart-lc-ihlar-2025-08-18/ > >> > >> As noted in the reviwe, could the editors please add a short discussion > on loss > >> and reauthentication in Section 5, or in an Operational Considerations > section? > >> > > See paragraph 2 of section 5 from version -29. This "twice' section was > added to address his comments. > GF: Aha, that new text is helpful indeed. > > > >> ### 2. The I-D text ought to say why the document is experimental, > please could > >> you add to > >> the Introduction by citing the Appendix that explains this. > > As noted elsewhere, the IESG as a whole should decide what they want > here. We've been through this dance multiple times with the routing-ADs > and Ketan likely has the token at the moment. > > > > The short form of this is that the documents represent the consensus of > a small number of individuals finishing this work in BFD with a desire to > publish work that is likely valuable for future use, but has not yet been > implemented. > > > > Once the IESG makes its determination about what boilerplate will > satisfy it for this document cluster, we likely will just add it to all > three documents. > GF: All this is fine, but my particular request here was to add a > cross-reference the appendix so a reader finds the appendix when they > read the introduction. You could of course do more. > > > >> ### 3. The I-D currently states: "All BFD Control Packets with the > states > >> AdminDown, Down, and Init > >> require strong authentication." - could this be a RFC-2119 > requirement? > >> Please consider making this a nomative case for this I-D , i.e. make > this > >> "REQUIRES", or the REQUIRES in the following: "In addition to these > >> requirements, BFD "significant changes" require strong > authentication." > > [Note - these changes will be staged and pushed once review is complete] > > <t>All BFD Control Packets with the states AdminDown, Down, and > Init > > - require strong authentication.</t> > > + MUST use strong authentication.</t> > > > GF: Thanks this would address that. > >> ### 5. The I-D currently states: > >> "When using the less computationally intensive authentication > >> mechanism, BFD should periodically test the session using the strong > >> authentication mechanism." > >> - I'd agree, but I do think the text needs to explain why this is > >> desirable, i.e. to justify why people SHOULD think seriously about > >> enabling this test. > > The other authors may have thoughts about appropriate text here. I > don't. > > > > The short form of this is that ISAAC, in the only specified optimized > authentication mode we have at this point, is expected to be strong enough > that we believe it's secure. The only motivation to periodically do strong > authentication is "just in case". Normative text for "just in case" isn't > exactly compelling. > GF: To be clear, I only ask to say briefly how the test helps (which it > should), so a reader knows that they ought to follow the should. > >> ### 6. The I-D currently states: > >> "Once > >> enabled, every packet must have Authentication Bit set and the > >> associated Authentication Type appended." > >> - Please cit the section here, I could not be sure what was cited? > > - associated Authentication Type appended. In addition, it states > that an > > + associated Authentication Type appended (<xref target="RFC5880" > section="4.1"/>). > > + In addition, it states that an > GF: Thanks. > >> ### 7. The I-D currently states: > >> "As a security precaution, it mentions that > >> authentication state be allowed to change at most once" > >> Whereas, RFC 5880 use RFC-2119 text: > >> "In order to avoid security risks, implementations using this method > >> SHOULD only allow the authentication state to be changed at most once > >> without some form of intervention." > >> - Could this RFC 5880 text be quoted as-is, in the current I-D (with > a > >> reference?) > > - authentication as a one time operation. As a security precaution, > it > > - mentions that authentication state be allowed to change at most > once. > > + authentication as a one time operation. > > + "... implementations using this method SHOULD 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 remote > > + systems)." (<xref target="RFC5880" section="6.7.1"/>) > GF: Looks good to me. > >> ### NiTs > >> ==== > >> > >> /It provides procedure where BFD state/It provides a procedure where > BFD state/ > >> /describes enabling and disabling/describe enabling and disabling/ > >> /authentication state be allowed to change at most once/the > authentication > >> state be allowed to change at most once/ > >> > > Accepted. > > > > -- Jeff > > Best wishes, > > Gorry > >
