On 14/10/2025 06:47, Ketan Talaulikar wrote:
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
Thanks Ketan, I see the improved abstract, and I do think this is helpful.
I am still unsure the present title is appropiate. I would still ask if
a change of title us possible. From my understanding, which is limited
to what I saw in the final document, I think any of these would be good.
I'd suggest either: Lightweight BFD Authentication or Alternating BFD
Authentication
... but, I think others may understand better any sensititivies
surrounding the title, so I will take advice from you, let's discuss
briefly. I am now eager to close this DISCUSS and see the document
published!
Gorry
(WIT AD)
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
