Hi Ketan
Your suggestions to the authors about section 2 will probably help a
lot in clearing my DISCUSS.
Regards
-éric
*From: *Ketan Talaulikar <[email protected]>
*Date: *Tuesday, 14 October 2025 at 10:24
*To: *Eric Vyncke (evyncke) <[email protected]>
*Cc: *Eric Vyncke (evyncke) <[email protected]>,
Jeffrey Haas <[email protected]>, The IESG <[email protected]>,
[email protected]
<[email protected]>, [email protected]
<[email protected]>, rtg-bfd@ietf. org <[email protected]>, Reshad
Rahman <[email protected]>
*Subject: *Re: Éric Vyncke's Discuss on
draft-ietf-bfd-secure-sequence-numbers-23: (with DISCUSS and COMMENT)
Hi Eric,
Thanks for your response. At this point, I am focussing on your
DISCUSS. I will request the authors to respond to the comments that
were not addressed - either right away or after the resolution of the
DISCUSS has been worked out.
I don't think this document updates RFC5880 since it does not change
anything in that RFC. These documents are about BFD authentication
extensions - i.e., introducing new types of authentication as
permitted by RFC5880.
Now, there may be some text that I think could be giving a different
impression and I believe all of such text is limited to Section 2.
Please confirm if I am missing something else.
I have some suggestions for the authors to consider for Section 2.
First, this document is not specifying "updates" but "extensions" to
RFC 5880. Second, that the changes to some of the state definitions
from RFC 5880 are not "updates" but changes to those states
specifically when the new authentication types introduced by this
document are being used (i.e., there is no change to those variables
for the auth types of RFC 5880 which only covered the keyed MD5 and
SHA1 types that were specified in that RFC).
I hope this helps in progressing the discussion on this document.
Thanks,
Ketan
On Tue, Oct 14, 2025 at 12:46 PM Eric Vyncke (evyncke)
<[email protected]> wrote:
Hi Ketan
When I note and appreciate that some of my ballot comments were
addressed (and I wonder why some were not...). My major and only
blocking DISCUSS still stands, i.e., section 2 title is
`Experimental updates to RFC 5880`, so IMHO this draft should
formally update RFC 5880.
Regards
-éric
*From: *Ketan Talaulikar <[email protected]>
*Date: *Tuesday, 14 October 2025 at 07:54
*To: *Eric Vyncke (evyncke) <[email protected]>
*Cc: *Jeffrey Haas <[email protected]>, The IESG <[email protected]>,
[email protected]
<[email protected]>,
[email protected] <[email protected]>, rtg-bfd@ietf. org
<[email protected]>, Reshad Rahman <[email protected]>
*Subject: *Re: Éric Vyncke's Discuss on
draft-ietf-bfd-secure-sequence-numbers-23: (with DISCUSS and COMMENT)
Hi Eric,
This document has also been updated by the authors and could you
please check the v26? Looking forward to progressing this discussion.
Thanks,
Ketan
On Wed, Aug 27, 2025 at 12:16 PM Eric Vyncke (evyncke)
<[email protected]> wrote:
[Replying on this email after reading further emails by Jeff &
Alan]
For the DISCUSS-level request for adding an “Update” tag,
let’s indeed discuss (hence the name) during the 4^th of Sep
telechat.
About the “no implementation” discussion, while I agree with
all Jeff’s points, having a set of experimental drafts that
won’t be experimented before years is strange... (i.e., it
does not really fit the section 4.2.1 of RFC 2026 – but I do
not mind too much).
Thanks for all other proposed changes in the text
Regards
-éric
*From: *Jeffrey Haas <[email protected]>
*Date: *Tuesday, 26 August 2025 at 16:28
*To: *Eric Vyncke (evyncke) <[email protected]>
*Cc: *The IESG <[email protected]>,
[email protected]
<[email protected]>,
[email protected] <[email protected]>, rtg-bfd@ietf. org
<[email protected]>, Reshad Rahman <[email protected]>, Reshad
Rahman <[email protected]>
*Subject: *Re: Éric Vyncke's Discuss on
draft-ietf-bfd-secure-sequence-numbers-23: (with DISCUSS and
COMMENT)
É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
>
>
