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
