Hi Reshad, > On Jun 13, 2024, at 8:04 AM, Reshad Rahman <res...@yahoo.com> wrote: > > Here are my comments on draft-ietf-bfd-secure-sequence-numbers. I'm not a > security expert, so my comments are BFD specific, relying on SecDir for the > security aspects. > > Section 1 > > - Nit "parties securely signal" -> "parties to securely signal"
Fixed. > > Section 3 (updating RFC5880) > > - 3rd paragraph says "SHOULD include a Sequence Number field". RFC5880 > already has sequence number for all types except simple Password, is this > SHOULD targeted at future auth types? > > - "Packets which indicate a state transition SHOULD use a secure AuthType." > Replace with a MUST or explain the SHOULD. Based on the last paragraph of > section 4, I believe MUST should be used. Not using a secure AuthType seems > to be a security risk? Also the term "secure AuthType" implies that there are > non-secure AuthTypes, use the term "strong authentication" as in the > optimizing-authentication document and as in section 12 of this document? Replaced SHOULD with a MUST, and changed “secure AuthType” with “strong authentication”. > > > Section 4 > > - Last sentence "this Auth Type must only be used when > bfd.SessionState=Up". s/must/MUST/? Also, Figure 1 of > optimizing-authentication allows OPT in Init and Down states (I've commented > on that already). Done. > > Section 5 (ISAAC Authentication Format) > > - Reserved: "This field MUST be set to zero on transmit". That field is > used for the "Optimized" field in optimizing-authentication, so there seems > to be a conflict here. > > Section 6 > > - "The Auth Type field MUST be set to TBD1 (Meticulous Keyed ISAAC)". There > is no IANA registration for just ISAAC anymore, so it will be one of the 2 > auth types from optimizing-authentication? Changed it to refer to the two auth types. > > - Nit "process will irreversible" -> "process will be irreversible" Fixed. > > > Section 8 > > - Nit "infeasable" -> "unfeasible" Done. > > Section 10 > > - Nit "The following figure give" -> "The following figure gives" Done. > > > Section 10.2 > > - Nit in last paragraph on P13 "reciever" > > - Nit "then the the difference" > > - Nit "The receive then has to" -> "The receiver then has to" > > > References > > - optimizing-authentication is an informative reference. I think that's ok, > but felt it'd be good to point out. Made it normative. > > > Regards, > Reshad. > > > On Monday, June 3, 2024, 09:30:18 PM EDT, Reshad Rahman > <reshad=40yahoo....@dmarc.ietf.org> wrote: > > > BFD WG, > > This email starts a 2 week Working Group Last Call for the following 3 > documents, please review and provide comments by end of day on June 17th. > Feedback such as "I believe the document is ready to advance" is also welcome. > > https://datatracker.ietf.org/doc/draft-ietf-bfd-secure-sequence-numbers/ > <https://datatracker.ietf.org/doc/draft-ietf-bfd-secure-sequence-numbers/> > > https://datatracker.ietf.org/doc/draft-ietf-bfd-optimizing-authentication/ > <https://datatracker.ietf.org/doc/draft-ietf-bfd-optimizing-authentication/> > > https://datatracker.ietf.org/doc/draft-ietf-bfd-stability/ > <https://datatracker.ietf.org/doc/draft-ietf-bfd-stability/> > > > Those documents were discussed extensively a few years ago but there have > been a few changes since (e.g. use of ISAAC). > > IPR check was done a few years ago but it's been a while and there has been > significant changes in the documents since then: > 1- Authors, please respond whether you are aware of any undisclosed IPR. > 2- Mahesh, Ankur and Ashesh, is this IPR > <https://datatracker.ietf.org/ipr/3328/> still relevant/applicable to > draft-ietf-bfd-optimizing-authentication? > > > Regards, > Reshad. > > > > Mahesh Jethanandani mjethanand...@gmail.com
