Deb, This followup will occur in multiple parts and will partially track the github diffs I'm queueing.
Note that these comments, and prior ones responded today, are covered in this github pull request: https://github.com/bfd-wg/optimized-auth/pull/76 > On Sep 23, 2025, at 8:41 AM, Deb Cooley <[email protected]> wrote: > > > 2. operating > > situation: Fast networks speeds combined with inadequate CPU > > capability will drive the solution which is practical. Please > > explain > > this. > > [...] > If your comment is specifically covering "fast network speeds", the intent > here is to cover the high pps rate of the BFD protocol. > [DC] the intent is to motivate why these systems can't do SHA2 type > authentication. Some shorter version of what you have above. Maybe > something like: The network speeds are x-fast, x packets per second, and the > CPUs performing authentication are typically the line cards which are both > very busy and very constrained. You all will obviously come up with > something more suitable and accurate. Please see if the comment below updating the security considerations addresses your point here. > > [Note: while SHA-1 keyed hashes might not be currently deprecated, they > are > > definitely on NIST's list to deprecate.] > > Thus the motivation for this feature. Operators already avoid even sha-1. > If we want to leave implementors with no practicable solution to deploy, this > will force the industry solely into either very weak mechanisms or no > authentication at all. > > > > > Intro: There is a link to MD5, but not to SHA-1? I suggest: > > https://nvlpubs.nist.gov/nistpubs/FIPS/NIST.FIPS.180-4.pdf. > > We'll add this to the next revision. > > [DC] I double checked a bunch of sources (mostly because Paul recommended > RFC 3174 which doesn't cover keyed hashes). I came up with two: the FIPS > listed in my original comments, and RFC2104 which defines keyed hashes. I > think you need them both. (RFC 2104 will be a downref, but that is fine). Upon review, I'm suggesting we keep Paul's recommendation for RFC 3174 for reference to the SHA-1 algorithm. It parallels the simple reference to MD5 already present. More particularly, BFD doesn't currently leverage HMAC. See RFC 5880, section 9. > > > Section 3, para 1: Would one characterize 'Simple Password Authentication' > > as > > 'strong'? or even 'adequate'? Is there a reason it was left off the list > > of > > examples? [Given there are only three options, it seems strange to use > > examples here.] > > It was elided intentionally. We could add some text suggesting that it's not > a candidate for the stronger mode. > > [DC] just delete the concept of 'for example'. Specify this option to be > used with the keyed hash authentication mechanisms. I have a doubt on this point which will be discussed in more detail in the reply covering renaming "strong authentication". BFD's authentication mechanisms currently consist of: - No authentication - "NULL" authentication from the under IESG review bfd stability document - Plaintext password - Keyed hash authentication (md5/sha-1) Currently, the optimized BFD mechanism is best fit using KHA mechanisms - ESPECIALLY if the less computationally intensive mechanism uses the same key. However, as part of the security feedback, there may be pressure to fork the stronger mechanism key from the less strong mechanism key. If so, we open the possibility to using other security mechanisms from the stronger mechanism that might not be KHA. However, we've reached the end of my knowledge of such things. So, my question to you is: Are we likely to want to leave the option open for non-KHA mechanisms here? If so, the "for example" remains appropriate. If not, it can be trimmed to something covered by wording we use to discuss the stronger mechanism. > > Section 3, para 4: 'as defined later in this document', which section is > > that? > > A forward reference to section 6 seems appropriate, perhaps? > > [DC] I agree. This will be in next rev. > > > Section 3, last para: please ref which section in the specification this > > will > > be described. > > The 3.1 immediately following. Is a forward reference to the next sentence > really necessary? > > [DC] no, I'd either delete it or move it to Section 3.1. I've chosen to delete this. The coauthors should review the flow of section 3/3.1 to see if meaning was lost. > > > Section 4, bullet list: Why not list 'Simple Password Authentication', or > > 'NULL Auth'? Are these not also less computationally intensive? [assuming > > 'Simple Password Auth' was not listed because it isn't even 'adequate'. > > And if > > NULL Authentication is ONLY suitable when the CPUs aren't capable of any > > processing, then that needs to be stated much more clearly in the stability > > draft.] > [DC] if you take my suggestions on Section 3, para 1, this comment goes away. > I think some of the concern might remain. However, I'm proposing the following change: "Once the session has reached the Up state, the session can use a less computationally intensive Auth Type derived from the format in Section 7." > > > > > > Section 4: Please add a sentence about how other mechanisms might be added. > > [since this specification is not meant to be prescriptive with respect to > > the > > use of ISAAC.] > > Would "other mechanisms may be defined in the future" be acceptable? > > [DC] perfect. Done. > > Section 5: Do both sides (sender/receiver) calculate the timing of the Poll > > sequence? [to prevent the ability of the adversary to corrupt/block the Poll > > sequence messages] > > They're independent. > > Either side may initiate a poll for any reason at any time. Doing so, it > must use the strong mechanism. The opposite side must respond to the poll > sequence with the final bit, and thus must also use the strong mechanism. > > An active attacker that tries to "prevent" this would simply knock the > session over. It doesn't take an active attack during a poll to do this, > such interference would likely be capable for the optimized mode. > > [DC] so none of these mechanisms are actually useful for keeping a session > from being disrupted... I wouldn't frame it that way. The optimized procedures have been tailored toward "once the session is Up, you can't change the contents of the packets aside from the authentication data". The stronger authentication requirement thus prevents the less strong mechanism from being used to knock the session over. The only thing you can do with spoofed Up packets is keep the session up. Each side of the session MUST be able to process poll sequences. It's required for protocol parameter changes in most cases even without the optimization mechanism. A poll sequence that is initiated with stronger authentication that isn't responded to by either side is enough for that side to unilaterally determine that it should drop the session. > > > > > Section 7: Is the 'authentication present (A)' bit transmitted? > > RFC 5880, ยง4.1, defines the core PDU. > > > If so, where > > in Figure 1 is it? > > It isn't, because these procedures document only authentication modes > covering the optional authentication section. > > [DC] can you add an itty bitty parenthetical to say something like '(in the > core PDU)'. I've done: When the Authentication Present (A) bit is set and the Auth Type ([RFC5880], Section 4.1) is a type supporting Optimized BFD Authentication, Is that sufficient? > > Section 7.2, para 2, Section 10.1, para 1: If the goal is to allow other > > mechanisms, then the links to the ISAAC specification can be removed. > > [Note: > > there may be other places in the specification where this needs to be done.] > > We could certainly strike the example reference. This usually turns into > "what kind of example mechanisms?" My preference would be to leave it. > > [DC] how about adding "or other approved less intensive authentication > mechanisms"? I don't mind the example, just make it clear it is only that. Done. > > > > > Section 7.2, para 3: Do I understand this correctly? If there is an issue > > switching from the original authentication mode to a 'computationally less > > intensive' mode, then the session is torn down? That seems unfortunate. If > > that isn't what this means, then perhaps revise. > > That's exactly what it means. > > In prior versions of this proposal when separate Auth Types were being used, > the pairing of the strong/less... methods were only via configuration. This > meant that it was possible for a mismatch of authentication configuration and > credentials to only be found when you had advanced the internal FSM state to > "switch to optimized mode". Moving to a single Auth Type with the Opt. Mode > means this shouldn't happen. > > However, if there *ARE* problems, perhaps with a future mechanism, you want > to discover that it's a problem ASAP rather than a "long" time afterwards. > Long could be a second. It could be a minute. *shrug* > > [DC] huh... ok. Note: The above is intended to deal with situations that become more likely if the key for the two modes is split. > > Section 10: Please add a sentence here which explains (justifies?) the > > level > > of authentication that is possible/practical for these systems. Please > > address > > both speed of transmission and CPU capabilities. > > Define the Universe. Give three examples. > > No thanks. > > Devices implementing BFD are often resource constrained, whether in a single > session, or a multidimensional set of scaled sessions that vary depending on > desired detection intervals. Product managers usually end up commissioning > scaling matrices under specific profiles. It scales as well as it does and > depends on configuration. > > [DC] this ^. I'm just trying to make it incredibly obvious that there are no > other choices in this situation and for this use case. Humor me. I've added this paragraph to the start of the protocol security considerations. See if it addresses your point. Devices implementing BFD are often resource constrained, whether in a single session, or a multidimensional set of scaled sessions. Desired detection intervals for the BFD sessions, and their number, are common scaling considerations for BFD implementations. Security mechanisms also impact the performance of implementations, whether in software or hardware, due to the use of additional computational resources these mechanisms use. -- Jeff
