> On Jan 18, 2024, at 7:26 PM, Mahesh Jethanandani <mjethanand...@gmail.com> > wrote: >> On Jan 17, 2024, at 5:05 PM, Jeffrey Haas <jh...@pfrc.org >> <mailto:jh...@pfrc.org>> 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? 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. >> "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. >> >> 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. >> 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
