Authors, BFD WG,
Here are my comments on draft-ietf-bfd-optimizing-authentication (hence subject 
change). I have strived to go back to previous discussions to make sure I'm not 
reopening any closed issues, but I could have missed some.
Section 1---------
- 2nd paragraph "Control packets that do not require a poll sequence, such as 
bfd.RequiredMinRxInterval...". I think the last part should be "such as a 
change in bfd.RequiredMinRxInterval..." - 2nd paragraph, last sentence starting 
with "In other words": I have a hard time groking the part "...aside from the 
authentication section without stronger authentication...". I think this is 
reiterating that if an Up packet changes we need to use stronger 
authentication, but is there anything else?
- Part which starts with "Once the session has reached the Up state". There is 
1 less computationally intensive auth type which is using ISSAC. Then it says 
that "To detect an on-path attacker" we have 2 options: strong auth or ISAAC. 
If we were already using ISAAC and we switch to ISAAC, hoes does that help? I 
am probably missing something. 
- "If a Fin is not received" should be "If a control packet with the Final (F) 
but is not received".
- Last paragraph, the term "configured interval" here and in 1.3 refers to the 
"reauth-interval"? Mention that in section 1 and also "configured interval" if 
used alone is misleading since there are many configured intervals in BFD? Also 
I don't see the need to have "configured interval" in the terminology section 
since it's only used once afaik in the document.
Section 1.3-----------
- Add "Auth Type" to terminology section?
Section 2---------
- Typo: authentiation
- Figure 1: so we can use OPT if there's no state change even when in INIT or 
DOWN state? Per section 1, it should only be in UP state?
Section 3---------
- Section 3, first sentence "type supporting Optimized BFD authentication", add 
a reference to section 6.1.
- "Optimized:", mention those are the values of the field with "Values are:" as 
is typically done.
Section 4---------
- Typo in 3rd paragraph "there is problems"
Section 5.3 (YANG)------------------
- It needs to be mentioned explicitly that optimizing authentication is enabled 
by using 1 of the 2 new crypto-algorithm, it's implied but not clearly spelled 
out.
- Define a grouping for reauth-interval
- There's an identity for null-auth but IIRC use of null-auth has been removed 
from the optimization mechanism a few months ago. can we remove null-auth from 
this document?
Section 7---------
- If reauth-interval is set very low, I understand how the optimization is 
worthless. But why is that the case if reauth-interval is very high, I mean 
optimization would be great? Do you mean that we'd be insecure if it's too high?
- Some time ago we discussed the impact of enabling optimized authentication 
and how it could make a session go down. IIRC the mixed (strong + opt) 
crypto-algorithm was added to mitigate that. Do we need some text in this 
section or elsewhere to describe that procedure? Did we consider putting a 
session admin-down before enabling/disabling optimized auth?
Section 8---------
Rehman -> Rahman
Section B.1-----------
- key-chain "bfd-auth-config' is defined but not used in the BFD session 
authentication section. Sigh, why didn't we put key-chain as mandatory...
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-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.



  

Reply via email to