Reshad,
With the exception of the nits boilerplate error, which I'm unclear how it
wants to be resolved, the following should address the comments below. I
believe everything is otherwise addressed and the document should be able to be
advanced with its cluster.
-- Jeff
Internet-Draft draft-ietf-bfd-optimizing-authentication-22.txt is now
available. It is a work item of the Bidirectional Forwarding Detection (BFD)
WG of the IETF.
Title: Optimizing BFD Authentication
Authors: Mahesh Jethanandani
Ashesh Mishra
Ankur Saxena
Manav Bhatia
Jeffrey Haas
Name: draft-ietf-bfd-optimizing-authentication-22.txt
Pages: 25
Dates: 2025-02-24
Abstract:
This document describes an optimization to BFD Authentication as
described in Section 6.7 of BFD RFC 5880.
The IETF datatracker status page for this Internet-Draft is:
https://datatracker.ietf.org/doc/draft-ietf-bfd-optimizing-authentication/
<https://datatracker.ietf.org/doc/draft-ietf-bfd-optimizing-authentication/>
There is also an HTMLized version available at:
https://datatracker.ietf.org/doc/html/draft-ietf-bfd-optimizing-authentication-22
<https://datatracker.ietf.org/doc/html/draft-ietf-bfd-optimizing-authentication-22>
A diff from the previous version is available at:
https://author-tools.ietf.org/iddiff?url2=draft-ietf-bfd-optimizing-authentication-22
<https://author-tools.ietf.org/iddiff?url2=draft-ietf-bfd-optimizing-authentication-22>
Internet-Drafts are also available by rsync at:
rsync.ietf.org <http://rsync.ietf.org/>::internet-drafts
> On Dec 31, 2024, at 2:53 PM, Reshad Rahman <[email protected]> wrote:
>
> Hi,
> I'm in the process of (re)doing the shepherd writeup for
> draft-ietf-bfd-optimizing-authentication and took a look at -21, comments
> below.
>
> Regards,Reshad.
>
>
>
> 1. Introduction
>
>
>
>
> “This document describes an experimental updates to BFD” should be “describes
> experimental updates” or “describes an experimental update”.
>
>
>
>
> 3rd paragraph, what is “the existing document”, is it RFC5880?
>
>
>
>
> a demand mode change (to D bit) -> a demand mode change (D bit change)?
>
>
>
>
> “ In other words, the contents of
>
> an Up packet MUST NOT change aside from the authentication section
>
> without stronger authentication to take advantage of the method
> described in this document.”:
> - For “authentication section”, please add a reference to section 6.7 of
> RFC5880.
> - What is meant by “stronger authentication” here (and elsewhere in the
> document), is it stronger algorithms or do you mean authenticating every
> packet? Whichever it is, it should be spelled out.
> - “of the method” -> “of the optimized authentication method”
>
>
>
>
> “Limiting authentication to
>
> packets that affect a BFD session's state allows more sessions to be
> supported with this optimized method of authentication.”
>
> - Should that be “Limiting strong authentication to packets”?
>
>
>
>
> “ * Meticulous Keyed ISAAC authentication as described in
>
> [I-D.ietf-bfd-secure-sequence-numbers]. This authentication type
>
> prevents the attack when the Up packets do not change, because
>
> only the paired devices know the shared secret, key, and sequence
> number to select the ISAAC result.”
>
> - Instead of “This authentication type prevents the attack when …”, should
> this paragraph say “This authentication type protects the BFD session when ….”
>
>
>
>
>
>
>
> “ When using optimized methods of authentication, BFD sessions should
>
> periodically test the session using strong authentication. Strong
>
> authentication is tested using a Poll sequence. To test strong
>
> authentication, a Poll sequence SHOULD be initiated by the sender
>
> using the strong authentication Auth Type rather than the chosen
> optimized Auth Type. ”
> - Wrt “Optimized methods” (should be singular or plural?), it may not be 100%
> clear what they are comprised of and IMO needs to be spelled out. My
> understanding is that the optimized method(s) consists of not (strongly?)
> authenticating every BFD control packet and instead using a less
> computationally intensive algorithm.
> - What is meant by “strong authentication” here? IIRC it means
> “non-optimized”, anyway “strong authentication” should be clearly defined.
> - The first sentence mentions “test the session using strong authentication”,
> the 2nd sentence mentions “strong authentication is tested”, that paragraph
> needs some tweaking.
>
>
>
>
> “If a control packet with the Final (F) bit is
>
> not received within the Detect Interval, the session has been
> compromised, and should be brought down. “
>
> - “should be brought down” -> “SHOULD/MUST be brought down”?
>
>
>
>
>
>
>
> 1.3 Terminology
>
>
>
>
> “Control packets that do not require a poll
>
> sequence, such as bfd.RequiredMinRxInterval
>
> bfd.RequiredMinTxInterval, or bfd.DetectMult
>
> are also considered as a significant change.”
>
>
>
>
> - Should that instead say “Changes to control packets….”?
>
>
>
>
> 2. Authentication mode
>
>
>
>
> The cryptographic authentication mechanisms specified in BFD
>
> [RFC5880] describes enabling and disabling of authentication as a one
> time operation.
>
> - Add reference specifically to Section 6.7 of RFC5880.
>
>
>
>
>
>
>
>
>
>
> 3. Signaling Optimized Authentication
>
>
>
>
> - The new field Optimized has values 1 (for strong) and 2 (for optimized). It
> is a bit odd to have a field named Optimized contain a value indicating
> Optimized. Suggest renaming the field e.g. to “mode” or “strength” or …
>
>
>
>
> 4. Optimized Authentication Operations
>
>
>
>
>
>
>
> “It is RECOMMENDED that when using optimized authentication that
>
> implementations switch from strong authentication to optimized
> authentication after sending at least Detect Mult packets. “
> - Instead of “when using optimized authentication”, should it say “when using
> an optimized authentication Auth type”? Same comment applies to the following
> paragraph (and maybe in other laces in the doc), This makes me wonder if the
> term “optimized authentication” is a bit overloaded in that it seems to have
> multiple meanings
