Hi Jeff,
Looks good, thanks for addressing the comments.
Comments/questions/nits:- There are still 2 instances of "stronger
authentication" in the doc, see my previous comment on -21 on the use of
"stronger authentication". Should this instead be "strong authentication". e.g.
Section 1.3 has "with a stronger authentication", should that be "with strong
authentication"?- Section 3 "an less computationally intensive" -> "a less
computationally intensive"- Section 4 2nd paragraph: in "using the strong
authentication for an interval", are we missing "mode" or "method" after
"strong authentication"?- Please add Qiufang and Stephen who did the YD and
SECDIR reviews respectively. AFAIK there's no requirement to do so, but I
believe it's good form.
I'm good to ship -22 to the AD as-is.
Regards,Reshad.
On Monday, February 24, 2025 at 08:02:51 PM GMT+4, Jeffrey Haas
<[email protected]> wrote:
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/
There is also an HTMLized version available at:
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
Internet-Drafts are also available by rsync at:
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
