Re: draft-ietf-bfd-secure-sequence-numbers (WGLC for the 3 BFD auth documents and IPR check)

[Reshad Rahman <[e-mail]>]

 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 <[e-mail]> wrote:  
 
 Hi Reshad,


On Jun 13, 2024, at 8:04 AM, Reshad Rahman <[e-mail]> 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=[e-mail]> 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-optimizing-authentication/

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 still relevant/applicable to draft-ietf-bfd-optimizing-authentication?

Regards,Reshad.



  


Mahesh [e-mail]