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. -- Jeff > On May 15, 2025, at 8:24 AM, Ketan Talaulikar <[email protected]> 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. > > 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. > > 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. :-) > > 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". > > 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. > > 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. "Weak" would have simply been shot down for the other mode. "Light" will certainly have complaint about lack of crispness about the relevant property. 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. > 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. > > 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. > > 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. > > 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. > 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. > > 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. > 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. > > 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. > > 515 Authors: Mahesh Jethanandani ([email protected]) > 516 Ashesh Mishra ([email protected]) > 517 Ankur Saxena ([email protected]) > 518 Manav Bhatia ([email protected])."; > > <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> >
