[Adding Ashesh and Manav’s explicitly till we update their e-mail address in the draft]
Hi Jeff, Thanks for picking this up. > On Jan 17, 2024, at 5:05 PM, Jeffrey Haas <[email protected]> wrote: > > Authors, > > Since secure sequence numbers is heading toward WGLC, it's time to refresh > this document and review it vs. secure sequence numbers, and bfd stability. > > ----- > > From Introduction and some confusion about configuration and operational > state: > > "This document also proposes that all BFD control packets which signal a > significant change MUST be authenticated if the session's bfd.AuthType is > non-zero. Other BFD control packets MAY be transmitted and received without > the A bit set." > > There's a bit of semantic confusion here. bfd.AuthType is what we use as our > state and what we put in our packet. And similarly, we're trying to say here > that "authentication may not be required for some packets". > > Part of where this is potentially confusing is that these mechanisms are > documenting changes from one auth type to the other. > > This means we have, leveraging management framework terminology, > configuration state that represents "start with authentication X, which will > use method 1 that goes into bfd.AuthType and user method 2 which also goes > into bfd.AuthType". This also has implications when we have this bit of > composite configuration with regards to authentication that isn't expected > (i.e. NULL when secure seq is configured) needs to be addressed. > > For operational state, reflecting the active type may be fine, but reflecting > the hybrid configuration state is also necessary. 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. > > > > One way to work through how to adjust the text is consider what the updates > to the YANG module might look like. ;-) > > 1.2: > s/a demand model/a demand mode/ Fixed. > > "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” > > 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. > > The text for secure sequence numbers also is now incorrect since the > mechanism has evolved. > > 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. Thanks > > -- Jeff > > > Mahesh Jethanandani [email protected]
