Hi Jeff, Coming back to this point in the thread ...
> On Jan 19, 2024, at 4:14 PM, Mahesh Jethanandani <[email protected]> > wrote: > > Hi Jeff, > >> On Jan 19, 2024, at 4:19 AM, Jeffrey Haas <[email protected] >> <mailto:[email protected]>> wrote: >> >> >> >>> On Jan 18, 2024, at 7:26 PM, Mahesh Jethanandani <[email protected] >>> <mailto:[email protected]>> wrote: >>>> On Jan 17, 2024, at 5:05 PM, Jeffrey Haas <[email protected] >>>> <mailto:[email protected]>> wrote: >>> That is a good point. However, and thinking of this from a management >>> perspective, the operator can signal a they want optimized auth. It will up >>> to the implementation to update the bfd.AuthType field as it toggles >>> through the different authentication types. For example, if optimized-auth >>> is set to true, the session could start with no auth, transition to >>> bfd.AuthType=5 as the session is coming up, and then transition to >>> bfd.AuthType=0 after it has reached UP state. >>> >>> Orthogonally, the operator can indicate whether they want to secure the >>> sequence numbers that are included in the BFD packet. It will be up to >>> implementation to decide whether they want to use it when bfd.AuthType is >>> set to a non-zero value, or only use it when bfd.AuthType is set to 0. >>> >>> In summary, two new leafs in the YANG model, one boolean leaf for >>> “optimized-auth” and one boolean leaf for “secure-seq-num”. >>> >>> If this sounds kosher, I will add text to that effect in the draft. >> >> At the moment, the keychain model is being used for BFD authentication. It >> has provision for one key set. >> >> Adding new leaves (in a container?) for optimized-auth is one way to do it. >> Having a mode for the optimized auth in a choice for NULL-auth or >> secure-seq-number would do the trick. There's probably a must condition for >> setting this mode vs. authentication otherwise being set? > > I think I see where the confusion could be. > > In my mind, and my co-authors can correct me if my understanding is > incorrect, I do not see "optimized auth" as a choice between "NULL-auth" and > "secure-sequence" numbers. When the A-bit is set, the choice is between doing > authentication as described in RFC 5880 (bfd.AuthType=[1..5]), or doing > "optimized auth". If "optimized auth" is chosen, bfd.AuthType can toggle from > one of the non-zero values to NULL-auth (whatever non-zero value is assigned > to it) and back. > > At the same time, if 'secure-seq-num' is configured as ’true’, the sequence > number is generated as defined by I-D.ietf-bfd-secure-sequence-numbers, and > inserted into the packet. The only question I ask is, if “optimized auth” is > enabled, and when there is a state transition, the packet is “fully” > authenticated by selecting bfd.AuthType as one of the non-zero values (but > not NULL-auth). Do we need to generate a secure sequence number at that time? > Or is it easier/simpler to let it continue generating the secure sequence > number, and not deal with “lost” packets as the session transitions from > bfd.AuthType with a non-zero value and NULL-auth. Want to make sure that this is clear enough (here), and if you think text to that effect should be added to the draft. > >> >> Interesting edge choice question: Alan's recent changes permits even "simple >> password" to be a valid mode, but it's probably not something we want to >> operationally support. In particular, because it does NOT include sequence >> numbers and thus provides zero protection vs. reply during the non-optimized >> path. > > Agree. Where do we call this out? In this or in the secure-sequence-number > draft? > >> >>>> "configured interval" probably needs to be more specific to this >>>> mechanism. In particular, this is the interval for how long before we >>>> retry strong authentication. >>> >>> There is no “strong” vs “weak” authentication, unless I am missing >>> something. >>> >>> I have rephrased it to: >>> >>> “ Interval at which BFD control packets are retried for authentication” >> >> The tone of language I'm suggesting we find wording for is the non-optimized >> authentication vs. the optimized. Optimized will currently consist of NULL >> and secure-seq-number. >> >> Both of those new types are authentication. See below. > > Ahh! I see. How about > > “Interval at which BFD control packets are retried with strong > authentication” or > “interval at which BFD control packets are retried with non-optimized > authentication”? And this … Thanks. > >> >>>> >>>> 2. Authentication Mode: >>>> >>>> The text in this section indicates that there are circumstances where no >>>> authentication (a-bit is off) is permissible. However, the text then >>>> moves to discuss NULL authentication, which is authentication that still >>>> carries an a-bit, and has contents. This is likely from earlier work prior >>>> to realizing we want some form of anti-replay attack. >>>> >>>> I suspect the correct thing to do here is move all text toward discussing >>>> the "non-authenticated" mode as the less encumbered authentication, of >>>> which this document defines the NULL method. >>> >>> Ok. I have changed the text to talk about the value of bfd.AuthType as >>> either a non-zero value or using a zero (NULL) value, even as A-bit is set. >> >> Note that the "NULL" auth type is likely to be not-zero. :-) Zero is >> reserved. > > Thanks for correcting that perception. I did think it would be zero, but I > can see that it would be NBC change. So a non-zero NULL value 😉. > > Thanks. > >> >>>> 3. NULL Auth Type. >>>> >>>> The main text here in need of updating is the sequence numbers. As we've >>>> worked through in the discussions for secure sequence numbers, we want the >>>> sequence numbers to be preserved across authentication mechanisms. >>>> >>>> Is the answer to take the text we have in secure sequence numbers covering >>>> this detail and move them to this document? >>> >>> Most the text in this document defers to the >>> I-D.ietf-bfd-secure-sequence-numbers draft, and I would not duplicate any >>> text from there in this document. >> >> Ok, we'll review the documents versus each other once edits are in. >> >> Thanks! >> >> -- Jeff >> > > > Mahesh Jethanandani > [email protected] <mailto:[email protected]> Mahesh Jethanandani [email protected]
