Hi Jeff, Mahesh,
I have just gone through the response below and the changes in -17, thank you
for addressing my comments.
Regards.Reshad.
On Wednesday, June 19, 2024 at 02:54:51 PM EDT, Jeffrey Haas
<jh...@pfrc.org> wrote:
Reshad,
The pending changes covered in addressing your comments are currently in this
github pull request:https://github.com/bfd-wg/optimized-auth/pull/46
Details below.
On Jun 12, 2024, at 11:19 PM, Reshad Rahman <reshad=40yahoo....@dmarc.ietf.org>
wrote:
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..."
Changed.
- 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?
There's nothing else. The intent here is to summarize the key point succinctly.
- 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.
This is a lingering issue from when null auth was part of this procedure.
My proposed change is to remove the text about "to detect an on-path attacker",
to use the following text instead:
"When using optimized methods of authentication, BFD sessions should
periodically test the session using strong authentication. Strong
authentication is tested using a Poll sequence. To test strong authentication,
a Poll sequence SHOULD be initiated by the sender using the strong
authentication Auth Type rather than the chosen optimized Auth Type. If a
control packet with the Final (F) bit is not received within the Detect
Interval, the session has been compromised, and should be brought down. The
interval for initiating a Poll sequence can be configured depending on the
capability of the system."
- "If a Fin is not received" should be "If a control packet with the Final (F)
but is not received".
In the diff.
- 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.
I'm proposing this become "configured strong reauthentication interval" to
clarify the situation.
Section 1.3-----------
- Add "Auth Type" to terminology section?
Done.
Section 2---------
- Typo: authentiation
Fixed.
- 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?
Oi, that's been in there for a while. Auth now only in Up/Up states.
The other authors will have to remind me if there was reason we had it in the
other states.
Section 3---------
- Section 3, first sentence "type supporting Optimized BFD authentication", add
a reference to section 6.1.
Done.
- "Optimized:", mention those are the values of the field with "Values are:" as
is typically done.
Now reads:
The values of the Optimized field are:
Section 4---------
- Typo in 3rd paragraph "there is problems"
Fixed.
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.
I've added:"Implementations supporting the optimization procedures defined in
this document enable optimization by using one of the newly defined key-chain
crypto-algorithms defined in this YANG module."
- Define a grouping for reauth-interval
Done.
- 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?
Removed.
Fundamentally the thing we're juggling with the reorgs is to make sure we don't
have conflicting updates in the yang modules. So, we'll be checking this vs.
the bfd stability document as well.
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?
This was addressed as part of the secdir review. See if the new text addresses
your concerns.
- 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?
I don't think so, but might be convinced otherwise. The current procedures are
"one-stop enable this auth type and you get all of the appropriate things".
Before, it was the weird conflict between which mode was configured and whether
there was an optimized flag to turn things on.
Did we consider putting a session admin-down before enabling/disabling
optimized auth?
In the current procedure, it's a single setting to use a pairing of
strong/optimized auth in a single type. This wouldn't be necessary.
More broadly, this also avoids the mid-flight auth changes that RFC 5880
handwaves the complexity for.
Section 8---------
Rehman -> Rahman
Fixed.
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...
Fixed example, and to be audited by Mahesh.
At least one motivation to not make it mandatory is a lack of clear procedure
of "auth is enabled, and that auth is 'off'". :-P
Attached, find the output from iddiff.
-- Jeff
