Gorry Fairhurst has entered the following ballot position for draft-ietf-bfd-optimizing-authentication-29: Discuss
When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/about/groups/iesg/statements/handling-ballot-positions/ for more information about how to handle DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-bfd-optimizing-authentication/ ---------------------------------------------------------------------- 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. As noted in https://datatracker.ietf.org/doc/statement-iesg-handling-ballot-positions-20220121/, a DISCUSS ballot is a request to have a discussion to consider the topic above. ---------------------------------------------------------------------- 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? ### 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. ### 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." ### 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. ### 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? ### 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?) ### 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/
