[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". > 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. > 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. > > 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. > [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. > > 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. > > 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. > > Section 3, para 4: 'as defined later in this document', which section is > that? A forward reference to section 6 seems appropriate, perhaps? > > 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? > > 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. > > 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? > > 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. > > 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. > 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. > > 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* > > 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. > > 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. 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. -- Jeff
