draft-ietf-bfd-optimizing-authentication-17 has been published with the comments to date addressed.
-- Jeff > On Jun 19, 2024, at 2:51 PM, 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 > <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 >> <mailto: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 > > <16-17.html> >
