Done. > On Jul 4, 2024, at 1:34 PM, Reshad Rahman <res...@yahoo.com> wrote: > > Hi Mahesh, > > Thanks, the changes are good with me. So you will be submitting -16 soon? > > Regards, > Reshad. > > On Tuesday, July 2, 2024 at 04:52:17 PM EDT, Mahesh Jethanandani > <mjethanand...@gmail.com> wrote: > > > Hi Reshad, > >> On Jun 13, 2024, at 8:04 AM, Reshad Rahman <res...@yahoo.com >> <mailto: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 >> <mailto: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 <mailto:mjethanand...@gmail.com> > > > > > >
Mahesh Jethanandani mjethanand...@gmail.com
