Hi Jeff, Please check inline below for responses/clarifications with KT.
On Sat, May 17, 2025 at 6:14 AM Jeffrey Haas <jh...@pfrc.org> wrote: > Ketan, > > In the interest of trying to move review through faster, I've partially > addressed some of your comments. You can track the requested change > integration here: > https://github.com/bfd-wg/optimized-auth/tree/jhaas/v25-edits > > Meanwhile, as I note below a major bug regarding "significant changes" has > crept in, and recovering that from commit history will happen later. The > answers to your comments will hopefully let subsets of this AD review move > forward. > KT> OK. Please let me know once the full set is ready/updated - either in github or posted - so I can review and get back. > > -- Jeff > > > On May 15, 2025, at 8:24 AM, Ketan Talaulikar <ketant.i...@gmail.com> > wrote: > > General Comment/Suggestion: > > This is about the contents of this document and its relationship with > draft-ietf-bfd-stability and draft-ietf-bfd-secure-sequence-numbers. I > believe this document does not depend on those other two, at least not > normatively as indicated today. This proposal is self sufficient in that it > defines the optimized authentication framework without defining any of the > optimized auth types - this is perfectly OK. As such, for smooth > progression of this work, I would strongly recommend moving all text > related to the ISAAC-based auth types from this document into > draft-ietf-bfd-secure-sequence-numbers. I am sure there is a solution to > avoid reference to the draft-ietf-bfd-stability which is currently used > only for the updated YANG model. This way, this document becomes > independent of the other two for its further processing. > > We expected a portion of this commentary when we sent the documents along. > The non-obvious thing is the impacts of YANG module versioning and > maintenance rules on these documents. > > Tersely, while we're largely in agreement about the separation of > technology, the need to update the BFD IANA module can't be done severably > between each of the documents at this time. You have the ops AD on the > document who previously chaired one of the main YANG related working > groups. I suspect you might be willing to believe us on the matter, but > this intricacy and its impacts on how IETF maintains its modules is worth > broader IESG discussion. > > Spend some time digesting this detail and come back with what you think > the better options are. At the moment, you have the collective authors' > results of how we think this was best to do at this time. > KT> Is my understanding correct that the jumbling and interdependencies between these 3 documents are only on account of the YANG module(s)? > > > > > 17 Abstract > > > > 19 This document describes an optimization to BFD Authentication as > > 20 described in Section 6.7 of BFD RFC 5880. It provides procedure > > > > <minor> For clarity, I would suggest simplifying the first sentence as > follows: > > > > This document describes an optimization to BFD Authentication. > > Accepted. > > > > > > 88 1. Introduction > > > > <major-editorial> There is a lot of normative text and details in this > section > > that may be better moved to Section 4 where they are missing. > > I'm unclear on exactly what things you expect to be moved where given teh > remainder of the document beginning in section 2, nor what is "missing". > > The introduction is overly monolithic, but evolved there based on prior > WGLC discussion. Structurally, we have: > - Motivation for stronger authentication and the fact that this is > expensive in BFD. (More below.) > - The experimental section. This ballooned based on back and forth with > prior reviews. It certainly can be split out, but please offer an opinion > on where you believe it goes in the document. > - The procedural summary: Defining a "significant change", differentiating > between "strong" and "less computationally intensive" mechanisms, > reauthentication. If you think this procedural summary belongs split out > of the introduction section (perhaps the opinion changes if the experiment > monolith moves), then suggest where you think it otherwise belongs. One > would presume at the head of the document. > > As noted below, it appears some of the normative procedures for > "significant change" got eaten in a recent diff and will need to be > restored. More on that below. > KT> Let me wait for those changes. In the meantime, please see below a snippet of text that is there in the Introduction section but not in Section 4 where I would have expected it to be: When using the less computationally intensive authentication mechanism, BFD should periodically test the session using the strong authentication mechanism. Strong authentication is tested using a Poll sequence. To test strong authentication, a Poll sequence SHOULD be initiated by the sender using the strong authentication mode rather than the less computationally intensive mechanism. If a control packet with the Final (F) bit is not received within the Detect Interval, the session has been compromised, and MUST be brought down. > > > > > > > 90 Authenticating every BFD [RFC5880] control packet with MD5 > > 91 Message-Digest Algorithm [RFC1321], or Secure Hash Algorithm (SHA-1) > > 92 is a computationally intensive process. This makes it difficult, if > > 93 not impossible, to authenticate every packet - particularly at > faster > > > > <minor> I am not sure about the use of "impossible" here. Is that > assertion > > necessary? If so, I suggest providing additional context such as hardware > > offload and such to project it perhaps as "challenging"? > > Here, we've entered the BFD WG's traditional dance with the IESG about the > cost of authentication. > > A single sha1/md5 HMAC over a BFD PDU is "cheap", and may even have > support for hardware acceleration. > Now do it every 30ms without disrupting line rate forwarding. > Now do it for a large number of session on the same line card. > Now do it on your line card when you want that CPU to do other useful > things other than send BFD packets really fast - like program the FIB. > > And now, as the document tries to explain the motivation for, decide that > SHA-1 is "weak" and think you need to use something stronger like SHA-2 in > a strong mode. You've now reduced your scalability even further. > > Impossible is possibly not the best word. "Challenging" leads the > uneducated reviewer to say "of course you can do it". (No, you can't. At a > specific scale, which may be target platform specific, it can't be > supported.) > > I suggest you let this iteration of the security ADs pick their current > weasel word of choice for this. It changes each time. :-) > KT> Simply changing "impossible" to "challenging" or removing the " if not impossible" would be sufficient for me - this text is subjective. If the authors/WG want to retain "impossible" then that is a really strong objective claim which would then need to be substantiated. > > > > > > 100 SHA-0 and SHA-1 Message-Digest Algorithm [RFC6194]. If replaced by > > 101 stronger algorithms the computational overhead will make the task > of > > 102 authenticating every packet even more difficult to achieve. > > > > <minor> s/every packet/every BFD packet > > Accepted. > > > > > 104 This document describes an experimental update to BFD [RFC5880]. > > > > <major> Since an experimental track document cannot update an standards > track > > document, this needs to be rephrased. Perhaps "describes an experiment > that > > presents a candidate solution to update BFD Authentication that is > currently > > specified in RFC5880" ... or something along those lines? > > Accepted. > > > > > 110 * In the initial stages of the document, there were significant > > 111 participation and reviews from the working group. Since then, > > 112 there has been considerable changes to the document, e.g. the > use > > 113 of ISAAC, allowing for ISAAC bootstrapping when a BFD session > > 114 comes up and use of a single Auth Type to indicate use of > > 115 optimized authentication etc. These changes did not get > > 116 significant review from the working group and therefore does not > > 117 meet the bar set in Section 4.1.1 of [RFC2026] > > > > <major> The above bullet needs rephrasing for this document. Isn't the > point > > that the mechanism for alternating between strong and light modes of > auth that > > is described in this document does not meet the bar? The reference to > ISAAC does > > not seem appropriate here. > > Not my text, but the point is that the original proposal didn't survive > protocol attack analysis. Two aspects occurred throughout the evolution of > the document: > > - NULL auth with sequence number procedures actually made security weaker. > - The original proposal was to store the ISAAC result in the sequence > number. However, analysis of what it would take to successfully bootstrap > ISAAC meant that we moved back to more traditional BFD encoding and kept a > consistent sequence number between modes. > > If your point is "the history isn't helpful, delete it", perhaps we should > go with that. However, the point we were pushed to over the evolution of > this document and reclassification of it to experimental was "justify why > it's experimental and document it". > KT> Yes, that history isn't helpful. Let each document give its specific reason with minor wordsmithing. > > > > > 154 Once the session has reached the Up state, the session can choose a > > 155 less computationally intensive Auth Type. Currently, this > includes: > > > > 157 * Meticulous Keyed ISAAC authentication as described in > > 158 [I-D.ietf-bfd-secure-sequence-numbers]. This authentication > type > > 159 protects the BFD session when BFD Up packets do not change, > > 160 because only the paired devices know the shared secret, key, and > > 161 sequence number to select the ISAAC result. > > > > <major> Is it not possible to make this document about the mechanism of > > switching between strong and light auth modes and that alone? Is it not > > possible to leave the actual auth types to a separate document (i.e. > sequence > > numbers draft) ? > > Not fully. In its current state, it can be made somewhat generic. Had we > started with that, the mechanism would have failed because the > practicalities of "entraining ISAAC" in the face of possible lost packets > couldn't have been appropriately addressed. > > It is likely, but not guaranteed, that other mechanisms that could > supplant ISAAC might have considerations that are the same. We won't know > until someone suggests another one. > KT> Sure, we can cross that bridge when we come to it. Either way, no one is asking to change the proposal currently. The change is mainly editorial to move from one document into another to fix the unnecessary dependencies that are problematic for a reader/reviewer. The authors have likely been deep into this thing and with a lot of historical twists/turns along the way. Now that it is time to publish this work, please consider from a reader's perspective who is going to take a first fresh look at this set of documents. > > > > > > 226 > +------------------+----------------------------------------------+ > > 227 | configured | Interval at which BFD control packets are > | > > 228 | strong | retried with strong authentication. > | > > 229 | reauthentication | > | > > 230 | interval | > | > > 231 > +------------------+----------------------------------------------+ > > > > <question> Can the terms for the two modes of authentication be > introduced? > > Say "strong mode" and "light mode" - where the light mode is what is > being > > referred to as "less computationally intensive" mode in multiple places > > throughout this document? I believe doing so would help simply the text. > > As discussed among the authors, the names are largely obstacles. Whatever > was chosen was going to be nitpicked to death by security reviewers for > differing reasons. > > "Strong" is silly when discussing MD5 and SHA-1. It's simply stronger > than the other mode. > KT> There you go ... right now "strong" is sprayed all over this document and that is why there is a need for a proper terminology. > "Weak" would have simply been shot down for the other mode. > "Light" will certainly have complaint about lack of crispness about the > relevant property. > KT> How about "full" and "light"? There is no issue of crispness or clarity since those terms are going to be defined in the terminology section of this document and will be also available for use as a derivative in the sequence numbers document. > > My suggestion, likely supported by the other authors, is to forward this > for SEC AD review. Once they pick a set of ">" and "<" names for the > property that satisfies their review criteria, we can do the search and > replace. It could be "Alice" and "Bob" to be traditional for security > names. > > Meanwhile, the actual property is captured by the overly long name. > > > > > 265 3. Signaling Optimized Authentication > > > > 267 When the Authentication Present (A) bit is set and the Auth Type > is a > > 268 type supporting Optimized BFD Authentication (Section 6.1), the > Auth > > > > <minor> The reference to section 6.1 is confusing here. Is it necessary? > > It's a forward reference to a named section that will render as a link. > What is confusing? It clearly distinguishes it as a subset of types (which > you don't want in this document) that are capable of executing these > procedures. Previously existing types cannot support these procedures. > > > > > > 279 * The requirement to carry a Sequence Number. > > > > <major> Why does this document expect that there can never be an > optimized > > authentication type that would not use/require the use of Sequence > Numbers? > > Because the mode is built upon the "meticulous" property. > > We previously considered NULL auth as a way to keep things up. The > trouble we have with security reviewers whenever we have these discussions > is that they immediately start discussing replay attacks. In the absence > of a property that lets you limit the attack space, a third party attack, > potentially blind, could "succeed". > > What has always been perverse for this use case with stronger > authentication for packets that aren't just "I'm up" is that the "attack" > is to keep the session running when it's otherwise dead. > > The other motivation is that sequence numbers are generally required to > "entrain" a secondary mechanism in the face of packet loss. > > If you're aware of mechanisms that don't require such entraining and are > resilient vs. arbitrary packet loss within a window of N packets, let's > talk. Otherwise, you're picking on a property that we have found to be > required. > KT> Again, this is an editorial change. Moving the Sequence Number field into the sequence number draft where it is specific to the two defined ISAAC modes does not change the functionality. It is the "modular" lego brick building approach that is what we have generally favored at the IETF. Specifying it in this document binds all future optimized auth mechanisms to use sequence numbers that does not seem like a good approach to me. > > > > IOW why does this document not leave the Sequence Number field to the > specific > > Auth Type? i.e., in the sequence number draft. RFC5880 has the > precedence to > > include the sequence number field as something specific to the auth type. > > You are making a VERY thin reading of RFC 5880. The only thing that > ignores sequence numbers is "password" authentication. > > In any case, as above the property becomes far more critical when you have > two security mechanisms where one is required to bootstrap the other. > > > > > > > > 296 The Meticulous Keyed MD5, Meticulous Keyed SHA-1, and Meticulous > > 297 Keyed ISAAC Authentication Sections define the fourth octet as > > > > <major> Where are these sections? > > RFC 5880, §s 6.7.3/6.7.4, secure sequence number §5. I'm presuming what > you mean here is "cite the sections". Done. > KT> Yes, I meant citation. > > > > > 298 "Reserved". This document repurposes the "Reserved" field as the > > 299 "Optimized Authentication Mode" field when used for authentication > > 300 types for optimized BFD procedures. > > > > <major> Ref sec 4.1 of RFC5880, everything after Auth type and length > > is specific to the auth type. > > Correct. Which is why the cited items were the section 6.7* related items. > > > Ref sec 4.2, there is no reserved field. > > Ref sec 4.3 and 4.4 which introduces the reserved field but only for > > those specific types - this document does not affect those types. > > So, why does this document need to talk about the Auth Type > > specific formats? Why not just say there needs to be an Opt Mode field > > in the header of the new Auth Types that support this framework and > > leave the Auth specific format definition to those Auth Types (i.e., in > the > > sequence numbers draft)? > > If this is the conclusion you're drawing, you're down the wrong path. > This mechanism does NOT redefine the generic authentication section covered > in section 4.1, it leverages the specific examples cited. > KT> What it does is mandate this format for all optimizing auth types - current ISAAC and whatever may come in the future. That seems overly constraining to me when this can be just as well done for the two specific types in the sequence number draft. > > > > > 302 The values of the Optimized Authentication Mode field are: > > > > 304 1. When using the strong authentication type for optimized BFD > Auth > > 305 Types. > > > > 307 2. When using the less computationally intensive authentication > type > > 308 for optimized BFD Auth Types. > > > > <major> Can the two statements be rephrased for clarity? e.g., the field > is > > set to 1 when the strong type is in use and set to 2 when the light type > is in use? > > Once the current security ADs have agreed on what wording they're going to > fight over this week, sure. > > For the moment, the use is clear in the context of the terms chosen in the > current document. > > > > > <major> Do we foresee any other values such that we need IANA to > maintain a > > registry for this? > > Not without a deeper rewrite needed for the feature. In that case, we'd > choose a "yet another optimized method for optimizing bfd authentication" > or the convention chosen for such +1 names in the future. And, in such > cases, the pattern established in this document - and one of the late > changes to procedure - would be to use a single Auth Type to specify a full > set of procedures, while state machine internals like this optimized auth > type would be internal to the new implementation. > > Loosely, we're including the procedures for meticulous keyed md5/sha-1 by > reference as being the optimized mode's "strong" option. In the absence of > such loose inclusion, we'd end up copying and pasting the entirety of those > sections from RFC 5880 and update the reserved field for the magic number. > It's my experience that developers would prefer to see "this is the same, > but for this one thing" rather than have to figure that out by comparing > both documents. > KT> So, your answer is "no, we don't need an IANA registry" ? > > > > > > 375 Once the BFD session has reached the Up state, the BFD Up state > MUST > > 376 be signaled to the remote BFD system using the strong > authentication > > 377 mode for an interval that is at least the Detection Time before > > 378 switching to the less computationally intensive authentication > mode. > > 379 This is to permit mechanisms such as Meticulous Keyed ISAAC for BFD > > 380 Authentication [I-D.ietf-bfd-secure-sequence-numbers] to be > > 381 bootstrapped before switching to the less computationally intensive > > 382 mode. > > > > 384 It is RECOMMENDED that when using optimized authentication that > > 385 implementations switch from strong authentication to the less > > 386 computationally intensive authentication mode after an interval > that > > 387 is at least the Detection Time. In the circumstances where a BFD > > > > <major> Why is this RECOMMENDED required when the previous paragraph > makes > > this a MUST? Am I missing something? > > A pedantic reading of the wording is required. > > Once we transition to Up (BFD FSM), it is necessary to signal that Up > state for a time equivalent to the maximum permitted time before a session > would drop to permit the remote side to see the sequence numbers. This is > required to entrain the remote side in the face of packet loss. The > detection time is the period after which an absence of packets being > received would cause the remote BFD session to reset to Down. > > The recommendation is that once entrainment has been able to happen that > we switch from the strong auth type, which may use one set of keys, to the > optimized form which may use a different set of keys. It is not required > to use the same key for both mechanisms. The consequence of this is that > the BFD state machine can transition to Up and that if it doesn't move > quickly to the optimized mode that a client could be notified about the Up > session only to have it drop out of Up once the optimized mode kicks in and > has a key mismatch. > KT> Sure, why not make them both MUST? That was my question. > > > Also importantly, the document does not > > specific the behavior or the action that needs to be taken if these are > not followed by > > the other side? e.g., should the BFD session be brought down (say as a > result of > > those packets being dropped)? > > It's part of the core BFD FSM and would be inappropriate to normatively > restate here. > > The short form: If you don't pass authentication, the packet is dropped. > Drop enough packets, the FSM moves to Down. > KT> The short form will do just fine without any normative text/language. > > > > > 388 session successfully reaches the Up state with strong > authentication, > > 389 but there are problems with the optimized authentication, this will > > 390 permit the remote system to tear down the session as quickly as > > 391 possible. > > > > <major> What about the need for using strong mode when doing DOWN > notification > > or any other state change (e.g. AdminDown)? What about when doing any > > parameter change? What happens if there were to be a parameter change > > detected when using the light mode? > > You are highlighting a bug that's crept into the document. It'll take > some history spelunking to determine when the "significant change" text was > removed from the normative procedures. Likely, it was part of some of the > text in the Introduction that you've flagged above as being normative. > > I'll have to recover the diff from history. > KT> Thanks. It did seem oddly missing. > > > How about mandating that strong mode be used > > for the Initial period? Please consider beefing up this most important > section by > > moving some of the text from the introduction here and then specifying > > normatively the behavior for all these scenarios and conditions. > > > > 399 It is further RECOMMENDED that BFD implementations using optimized > > 400 authentication defer notifying their client that the session has > > 401 reached the Up state until it has transitioned to using the > optimized > > > > <major> Can this be specified in a more formal manner? I would assume > that one > > needs to wait for a long enough period in the light mode to cover the BFD > > interval and multiplier values in use? Why not make it a MUST? > > Two reasons: > 1. Some clients may want to go Up as soon as they know they have > bidirectional connectivity. In circumstances where the authentication > credentials are the same for both modes, this is likely to be good enough. > 2. The BFD specifications don't normatively discuss how client > applications are notified. So, we're not normatively specifying those > behaviors for this one mode. > KT> Thanks. That is enough for me, but do consider adding something to one of these two for the IESG review cycle. > > > > > > 406 5. Optimizing Authentication YANG Model > > 407 5.1. Data Model Overview > > > > <question> Is there a precedent to augment standards based YANG models > with > > experimental augments? > > You should ask your ops ADs, including the one who's an author here. :-) > > My suspicion is that it's ok. > > What your point raises as an interesting headache is the fact that the > edit to add these two code points to the main IANA module still needs to be > done to permit YANG to do the work. See original top point about how YANG > versioning considerations is forcing some of these choices. > KT> I'll park this for now. I need to understand the use of IANA for YANG modules. My initial sense was it was for things like enums and identifies that IANA can automatically update from their registries. But, I may be wrong ... so I need to study more ... Thanks, Ketan > > > > > 515 Authors: Mahesh Jethanandani (mjethanand...@gmail.com) > > 516 Ashesh Mishra (mishra.ash...@gmail.com) > > 517 Ankur Saxena (ankurpsax...@gmail.com) > > 518 Manav Bhatia (mnvbha...@google.com)."; > > > > <minor> Author list here is not aligned with the document > > Fixed. It'd be lovely if the tooling dealt with this. > > > > > 654 6.1. Auth Type > > > > 656 This document requests an update to the registry titled "BFD > > 657 Authentication Types". IANA is requested to assign two new BFD > > 658 AuthType: > > > > 660 * Optimized MD5 Meticulous Keyed ISAAC Authentication > > 661 [I-D.ietf-bfd-secure-sequence-numbers] (Part > > 662 meticulous-keyed-isaac-authentication), with a suggested value > of > > 663 7. > > > > 665 * Optimized SHA-1 Meticulous Keyed ISAAC Authentication > > 666 [I-D.ietf-bfd-secure-sequence-numbers] (Part > > 667 meticulous-keyed-isaac-authentication), with a suggested value > of > > 668 8. > > > > <major> I don't understand why this document is doing IANA allocations > for > > something that is specified in the sequence numbers document? > > See prior commentary about YANG impacts. If you find a better answer that > addresses the circular references, we can consider that. > > > > > 696 7. Security Considerations > > > > <major> Please cover the security considerations for the base protocol > feature > > first before getting into the considerations for the YANG model. Better > still, > > carve them into separate sub-sections for clarity. > > I've done so. > > > 737 The approach described in this document enhances the ability to > > > > <minor> I would not call it enhancement. > > The enhancement is to BFD security infrastructure. > > > However, some of the text from the > > introduction section can be moved here - the one that talks about the > > vulnerabilities for existing auth types > > Addressing cipher strength is appropriate here. I'll copy that section in > later as part of reorg. > > > and the need to find a balance for > > supporting hardware offload, etc. > > Those are scaling considerations and I believe they're inappropriate for > this section. > > > > > > <EoRv24> > > > >
