Hi Jeff, > On Jan 19, 2024, at 4:19 AM, Jeffrey Haas <[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. > > 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”? > >>> >>> 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]
