> > > > 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. >
+1 This is my understanding of how things should work. Cheers, Manav P.S. I am also copying my official email ID which needs to be updated in the next version of the draft. > > 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] > > > > > > >
