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
<[email protected]> 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.
