Gorry,
> 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. 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. > > ---------------------------------------------------------------------- > 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. > ### 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. > > ### 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> > > ### 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. > > ### 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 > > ### 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"/>) > > ### 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
