Éric,
> On Aug 26, 2025, at 9:28 AM, Éric Vyncke via Datatracker <[email protected]>
> wrote:
> ## DISCUSS (blocking)
>
>
> ### Update to RFC 5880
>
> As the section 2 contains `this document describes an experimental update to
> BFD [RFC5880].`, then I think that there is a need for an "Update" tag.
This one is a trivial change once the IESG has come to consensus about the
detail. Do experiments update standards track documents? Prior discussion
with the routing-ADs suggested not. My personal opinion is "not".
We don't care. Once the IESG has consensus, this will be updated to reflect it.
> ----------------------------------------------------------------------
> COMMENT:
> ----------------------------------------------------------------------
>
>
> ## COMMENTS (non-blocking)
>
> ### No implementation plans ?
>
> Per shepherd's write-up: `No implementations and no known plans to implement.`
> ... This is rather sad for a set of 3 I-Ds.
The regular dance the BFD working group has had with security folk over the
life of the working group (shortest-lived, according to Alex Zinin who gave me
this job years ago) is that "security is important and encryption is the tool
we need for it!".
As I've had to note over that same lifetime, the majority of operators DO NOT
use the encryption technologies we have for authentication. A significant
portion of the reason for this is that for single-hop BFD, the attacks against
the BFD protocol are silly vs. what an on-path attacker is capable of doing.
Why spend the energy spoofing and injecting a few cryptographically signed
packets when a DoS attack or ARP/ND attack will have more efficacy? For
multi-hop BFD, the security mechanisms make more sense. Security is about
defense in depth, after all.
That said, the line cards that are implementing BFD have better things to do
than to only generate small PDUs that are cryptographically signed at a high
rate at high scale. Operators want those line cards to do useful things like
program FIBs, firewalls, etc. So, providing a level of security for BFD has
always been a balancing act.
The WG participants and operators both are well aware that the cryptographic
mechanisms we're using in BFD are weak. However, anything stronger becomes an
attack on the line cards. Stronger cipher support, such as SHA-2, becomes
practical only when the line card CPUs start offering it as a "no-cost"
feature. We've set the stage for that work, but it's lived in the datatracker
graveyard until it's ready to be used.
Meanwhile, the mechanisms covered by optimized BFD and the use of the ISAAC
mechanism as a way to change the landscape has some promise to get us out of
this problem. I, in particular, have had customer conversations covering the
fact that we're in an increasingly scary world and that we will want to use our
defense in depth mechanisms, including strong ciphers. Thus, while the
motivation to deploy these things immediately is not present, it made sense to
complete this work for the time where it's needed. And, similarly, publication
as an RFC gives operators a stronger thing to use in their requests to vendors.
So, consider this a bit of public service.
>
> ### Use of optimized
>
> Like Gorry, I would prefer "lightweight" rather than "optimized" (the latter
> being a little unclear about which part is optimized).
In the context of this document, the optimization refers to the mode and not to
ISAAC itself. I.e., mode 1 vs. mode 2.
> ### Abstract
>
> s/This document describes a *new* BFD/This document describes a BFD/
Accepted.
>
> ### Section 1
>
> Even if obvious, s/it is possible for an attacker/it is possible for an
> *on-path* attacker/
This change is not correct. Blind injection attacks are possible, although
mitigated by the BFD discriminator selection procedures. Attacks may involve
off-path attackers that have had their attack seeded by an on-path inspection
of the discriminator, or discovery of the discriminator other ways. This may
include, for example, management mechanisms.
> ### Sectin 2
>
> Please consider rewriting `existing document` as this I-D will be a RFC once
> published and this sentence will flip sense.
s/the existing document/this document/.
>
> ### Section 3
>
> The SEC ADs will have a better view of course, but why `Auth Keys` as they are
> more suitable terms such as "nonces" or "cookies" (like TCP cookies)?
The analogy to tcp cookie isn't right since this is something that varies per
PDU rather than is attached to session setup.
The primary motivation to call them Auth Keys is this is what they're generally
called in RFC 5880 in other contexts such as MD5/SHA-1 to reflect the output of
the security mechanism.
>
> ### Section 3.1
>
> Who is the "we" in `so we explain why ISAAC was chosen` ? The authors ? The WG
> ? The IETF community ? Please rephrase to avoid using "we".
Voicing choice for the author. Instead:
- There are many CSPRNGs available, so we explain why ISAAC was chosen.
+ There are many CSPRNGs available. This section explains why ISAAC was
chosen.
</t>
<t>
@@ -470,7 +470,7 @@
administrator is not directly usable as a seed for the
generator. Instead, any secret key (including any
per-session data) would have to be hashed before being used
- to see the generator. Again, we choose ISAAC as the answer here. It
+ to see the generator. For these reasons, ISAAC was chosen. It
>
> Possible typo in `the internal state un an irreversible fashion`
Fixed
>
> s/secret key/shared key/ ?
I'm going to leave this one for Alan and the security folk to answer. The
document mostly uses "secret key" throughout the text.
>
> The page size of 256 sequence number is not really justified, I would naively
> have expected a much larger "page". Rate of 100's of pps is rather low level.
ISAAC wasn't crafted to solve BFD's problems, we're just conveniently using it.
:-)
> ### Section 4
>
> Unsure how to address my comment, but I had to read twice the subsection to
> understand the role of "opt mode". A leading text would make the reading task
> easier.
The explanatory text is covered in the other document.
> Also, why using a full octet for just 1 bit of information?
Being stingy with the bit assignment wasn't going to be helpful here. Any
change to how the field is processed would have to involve an update to the
entire procedure which would motivate a new code point.
From the other side of the observation, the current mode of optimization of a
strong mode vs. the less cpu intensive one was crafted as a way to leverage
ISAAC. If, in the future, we find that we need a further sub-state in the
authentication state machinery for optimization, we're not constrained to
justify bits. As an example, the "entrainment" procedure due to the lossy
nature of the protocol didn't end up requiring an additional sub-state to
synchronize the machinery, but such mechanisms were considered.
>
> ### Section 4.3
>
> The figure 3 should be clearer that the "auth key" is 20 octets long.
>
> Also, the text is about "Auth Key/Digest" and not about "Hash"
Both of these are lifted directly from RFC 5880. Were you wanting to file an
errata?
>
> ### Section 6
>
> It is unclear whether the procedure applies to all BFD packets or only to the
> non-Up ones.
The core of the procedures are in the optimizing document. Citing that
document's section 7/7.* might add clarity. Any specific text you'd care to
suggest?
-- Jeff
>
>
