Hi Reshad/Authors, I saw an update posted and I believe there were offline discussions.
Please let me know if the document is ready for IETF LC initiation? Mahesh, please do post the editorial nits and other such fixes on the next update so they don't catch further directorate and IESG reviews. Thanks, Ketan On Tue, Jul 22, 2025 at 3:49 PM Reshad Rahman <reshad= [email protected]> wrote: > 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. > >
