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) <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 4th 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 > > > > > > > >
