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]<mailto:[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]<mailto:[email protected]>> Date: Tuesday, 14 October 2025 at 07:54 To: Eric Vyncke (evyncke) <[email protected]<mailto:[email protected]>> Cc: Jeffrey Haas <[email protected]<mailto:[email protected]>>, The IESG <[email protected]<mailto:[email protected]>>, [email protected]<mailto:[email protected]> <[email protected]<mailto:[email protected]>>, [email protected]<mailto:[email protected]> <[email protected]<mailto:[email protected]>>, rtg-bfd@ietf. org <[email protected]<mailto:[email protected]>>, Reshad Rahman <[email protected]<mailto:[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]<mailto:[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]<mailto:[email protected]>> Date: Tuesday, 26 August 2025 at 16:28 To: Eric Vyncke (evyncke) <[email protected]<mailto:[email protected]>> Cc: The IESG <[email protected]<mailto:[email protected]>>, [email protected]<mailto:[email protected]> <[email protected]<mailto:[email protected]>>, [email protected]<mailto:[email protected]> <[email protected]<mailto:[email protected]>>, rtg-bfd@ietf. org <[email protected]<mailto:[email protected]>>, Reshad Rahman <[email protected]<mailto:[email protected]>>, Reshad Rahman <[email protected]<mailto:[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]<mailto:[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 > >
