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

[Mahesh Jethanandani <[e-mail]>]

Done.

> On Jul 4, 2024, at 1:34 PM, Reshad Rahman <[e-mail]> 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 <[e-mail]> wrote:
> 
> 
> Hi Reshad,
> 
>> On Jun 13, 2024, at 8:04 AM, Reshad Rahman <[e-mail] <mailto:[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] <mailto: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-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
> [e-mail] <mailto:[e-mail]>
> 
> 
> 
> 
> 
> 


Mahesh Jethanandani
[e-mail]