Thanks Mahesh. Please see inline.
On Tuesday, July 22, 2025 at 09:14:46 AM EDT, Mahesh Jethanandani
<[email protected]> wrote:
Hi Reshad,
See comments inline:
On Jul 14, 2025, at 10:53 PM, Reshad Rahman <[email protected]> wrote:
BFD Auth authors, BFD WG, Ketan,
Thanks to the authors for addressing the comments which came from AD-review. I
have gone through all 3 documents, concentrating on the changes made since WGLC
completed, and the documents are all aligned with each other.
Here are some comments/questions (and a few small nits I noticed).
draft-ietf-bfd-optimizing-authentication
Comments/questions:- Intro: "whereby only important BFD state transitions
require strong authentication" (this seems to be new text). I thought all state
transitions required strong authentication?
There are certain state transitions that like DOWN to INIT and INIT to DOWN
that do not need strong authentication. Maybe we can use the term “significant
change” that we have defined in the document that lists the state transitions
that need stronger authentication.
Looking at the current definition of "significant change" in section 2, it says
"State change, a demand mode change...". Are you suggesting to change that
definition to "important state changes"?
JTBC my recollection is that all state changes require strong auth. This is the
table present in older revs of this doc. Read : On state change from
<column> to <row>
Auth : Authenticate BFD control packet
NULL : No Authentication. Use NULL AUTH Type.
n/a : Invalid state transition.
Select : Most packets NULL AUTH. Selective (periodic)
packets authenticated.
+--------+--------+--------+--------+
| | DOWN | INIT | UP |
+--------+--------+--------+--------+
| DOWN | NULL | Auth | Auth |
+--------+--------+--------+--------+
| INIT | Auth | NULL | n/a |
+--------+--------+--------+--------+
| UP | Auth | Auth | Select |
+--------+--------+--------+--------+
BTW I missed the fact that the abstract also says "important BFD state
transitions", that was added in rev-24. My recommendation, as shepherd, is to
do "strong auth" for all state transitions which is what IIRC the document had
until recently. If the authors have justification to do "strong auth" for
important state transitions only, you need to define what are the important
state transitions (I'm assuming it'd be from/to Up state). And change the
following in section 3 to say "important BFD state changes": The intention of
these optimized procedures is to permit strong
authentication for BFD state changes
Regards,Reshad.
