inline w/ [DC] Thanks for the quick review. Apologies for the slow response.
I've fixed where I was too quick reading RFC 5880. For everything else, I've suggested options and clarifications. Deb On Mon, Sep 15, 2025 at 3:10 PM Jeffrey Haas <[email protected]> wrote: > [Note for IESG, other authors, and WG: I will be unavailable Wednesday > through early next week and thus replies will be delayed. I'd encourage my > other co-authors to take any negotiated points and consider submitting > appropriate edits for review.] > > > Deb, > > Thanks for your considered feedback. > > > On Sep 15, 2025, at 8:27 AM, Deb Cooley via Datatracker < > [email protected]> wrote: > > ---------------------------------------------------------------------- > > DISCUSS: > > ---------------------------------------------------------------------- > > > > A discuss is merely the start of a conversation. > > > > This specification is misleading as it stands today: > > 1. 'strong authentication': none of the mechanisms mentioned are > > 'strong'. Please find another word/phrase to describe. > > We're aware of the irony of the choice of terminology. For purposes of > the document it's solely intended to be "the strong one of the pair". > Similarly "less computationally intensive" is overly long although somewhat > more precise. Our hope was we'd reach this portion of the process and > receive the suggested "this is what you should call it instead". > [DC]: a few options: 'more computationally intensive', 'keyed hash authentication', 'hash based authentication'. These are all long, but this system has so many authentication options, it is hard to choose a single word descriptor. > > > > 2. operating > > situation: Fast networks speeds combined with inadequate CPU > > capability will drive the solution which is practical. Please > explain > > this. > > Line card CPUs are not super powerful. They're also busy doing important > things like installing your routes and firewalls from the control plane, or > emitting telemetry or answering management queries. Especially when not > helped by hardware assist, performing cryptographic operations on ~40 byte > packets every few milliseconds is resources that are considered poorly > spent. > > Thus, while security mechanisms are defined for BFD, they're often not > deployed because they're too burdensome. Frankly, they degrade the > experience so much that the best answer is often to turn them off. > > The mechanism explored here serves two motivations: > 1. Decrease the cost to run authentication mechanisms as an attempt to > encourage their deployment. > 2. Permit cryptographic mechanisms that are stronger to be deployed. > > Because, frankly, without something like this, people will ask for sha-2/3 > and line card engineers will simply laugh at the IETF. > > 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. > > > > 3. key management: According to RFC 5880, these are distributed > > in the clear as fields in the packets (local/remote > discriminators), > > clearly available to an attacker. This does not appear to be > address > > in this draft or in RFC 5880. > > Sorry, I'm confused. Perhaps you've misread RFC 5880. > > For RFC 5880, §4.2 password auth, it's old-school plain-text visible > authentication. And yes, with exactly the usual problems. > > For both §4.3/§4.4 MD5/SHA-1, the MAC/digest is stored in the auth value > field. For example, the MD5 procedure is covered in §6.7.3, you see that > this is the typical PDU signing operation for IETF protocols: The PDU is > generated with the desired fixed outputs, the authentication key is placed > in the appropriate portion of the PDU, and then the MD5 is calculated over > the entire packet and then that is stored in the authentication value field > during transmission. > > Discriminators are not "keys" in the sense to be managed. They are > protocol elements for session demultiplexing. They are required to have > appropriate randomness properties to help serve as nonces for the > authentication to prevent attacks based on predictable contents. After > all, the BFD packets are very small. > [DC] yeah, I was wrong (not the first, nor the last time). RFC 5880 is virtually silent on keys for the keyed hashes and how they are distributed. It still isn't great, but that ship sailed 15 years ago. > > > > > My comments below mostly all point back to this discuss. > > > > > > ---------------------------------------------------------------------- > > COMMENT: > > ---------------------------------------------------------------------- > > > > Thanks to Stephen Farrell for their secdir review. His comments are > relevant. > > > > General: Please change 'strong authentication' to 'authentication' > throughout > > the specification. One can hardly call MD5 and SHA1 keyed hashes > 'strong'. > > We took some care to ensure the term "strong authentication" was used > throughout the document to permit appropriate substitution for the security > reviews' chosen terminology. However, simply truncating this to > authentication begs the question: Is the assertion here that the "less > computationally intensive" mechanism is not "authentication"? > > I think once we know what goes into that slot for "less..." we can make > the changes fast enough. > [DC] see above. > > > [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). > > > > Intro: Please add a little bit more explanation to remind the reader > why these > > normally fast hashes are too slow/hard. Please address both speed of the > > transmission and capability of the device performing the hashes. > > We can try to do so. My expectation is, yet again, we'll get challenged > by security practitioners that aren't the engineers deciding time slices in > the RTOS for the line card. > [DC] more repetition on my part. > > > > > 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. > > > > > 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. > > > > > 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. > > > > > 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.] > > [Note for other readers, this was partially addressed in a call with Deb > previously] > > As we discussed, "no authentication" was previously considered as a design > candidate. However, we can't do that since this mechanism for choosing > optimization modes requires the minimal header in section 7. In an earlier > version of this proposal, the BFD Auth Type field was populated by > different values for the strong vs. the less computationally intensive > modes. However, this lead to state machine issues for BFD for our > intentions: > - If we move from, e.g., md5 to no-authentication and that's not an > acceptable combination to the remote BFD speaker, the session unexpectedly > drops. The fix here was to have the Auth Type contain a valid pairing of > the strong/less... so that such a drop wasn't likely. > - BFD authentication types that needed sequence numbers had procedures > that required continuity, and no authentication would desynchronize things. > > The simple password type similarly couldn't serve due to the lack of a > sequence number field and the lack of the gap of a "reserved" field that we > had leveraged in the other mechanisms. Certainly if we want to add such a > thing, replicating the simple password authentication procedures in an > optimized PDU format are possible... but it's effectively no security when > MITM is possible. > > Similarly, the NULL authentication mechanism from bfd-stability was > considered and stayed in the proposal for quite some time. However, since > part of the procedures we tend to want out of mechanisms when a sequence > number is present is an "acceptable window" mechanism (e.g. > secure-sequence-numbers, §6, " sequence number lies outside of..."), that > eventually proved problematic when there was no cryptographic operation > over the contents of the PDU. In particular, it opened the mechanism to > injection attacks where accepted PDUs outside of the range that were > injected by a partially informed attacker could push the next expected > sequence number out of the range of the legitimate speaker. The session is > thus able to be reset by such an attacker with a very small number of > packets. > > The likely response to the above is, "Why isn't this in the draft?" > > - Section 7 provides the generalized format for such optimized features. > If a mechanism doesn't fit here, it's not a candidate. > - The procedures for whether to accept a sequence number as in/out of > range are particular to a given proposal, and perhaps guidance will change > from the single instance of the attack we determined vs. NULL auth. > [DC] if you take my suggestions on Section 3, para 1, this comment goes away. > > > > > > 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. > > > > > 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... > > > > > 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)'. > > > Perhaps in the Opt. Mode? If so, it would be easier to see > > if the same words were used in Para 1 as in the numbered list for Opt. > > Mode/Optimized Authentication Mode. > > > > 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. > > > > > 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. > > > > > Section 10: Designating any of these mechanisms as 'strong' is > disingenuous at > > best. Please remove the word 'strong' from this specification. Para 2 > points > > out why this is true. > > Answered above. > [DC] yeah, I'm pedantic. apologies. > > > > > 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. > > If a given profile can support using nothing but stronger authentication > modes, great! This profile is just another item in the matrix for > scenarios where that doesn't scale for some reason. > > > > > Section 10: Normally I would expect to see how the provision of > symmetric keys > > (for keyed hashes, etc.) is accomplished. According to RFC 5880, keys are > > shipped across the network in the clear via the local/remote > discriminator > > field. This helps the attacker. Please address this issue here, or > point back > > to the relevant section in RFC 5880 where the mitigation is outlined. > > You're very confused here. If you believe this is true, please cite the > bit of RFC 5880 that leads you to that conclusion. Hopefully the > commentary above helped reduce this confusion. > [DC] yeah, I'm wrong. > > -- Jeff
