Can the authors also consider s/updates/extensions in the following: 2. <https://www.ietf.org/archive/id/draft-ietf-bfd-secure-sequence-numbers-26.html#section-2>Experimental updates to RFC 5880 <https://www.ietf.org/archive/id/draft-ietf-bfd-secure-sequence-numbers-26.html#name-experimental-updates-to-rfc>
This document describes an experimental update to BFD <https://www.ietf.org/archive/id/draft-ietf-bfd-secure-sequence-numbers-26.html#RFC5880> [RFC5880 <https://www.ietf.org/archive/id/draft-ietf-bfd-secure-sequence-numbers-26.html#RFC5880> ]. This experiment is intended to provide additional insights into what happens when the authentication method defined in this document is used. Thanks, Ketan On Tue, Oct 14, 2025 at 11:54 PM Jeffrey Haas <[email protected]> wrote: > https://github.com/mjethanandani/bfd-secure-sequence-numbers/pull/57 > > The above pull request, if approved by the coauthors, will likely address > this discuss. This is done by deleting most of the text and just saying > "these variables are relaxed to permit the isaac mechanism". It also gets > rid of the text discussing the strength of the auth type since that is > covered in better detail in the optimizing authentication document. > > -- Jeff > > > On 10/14/25 04:52, Eric Vyncke (evyncke) wrote: > > 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]> <[email protected]> > *Date: *Tuesday, 14 October 2025 at 10:24 > *To: *Eric Vyncke (evyncke) <[email protected]> <[email protected]> > *Cc: *Eric Vyncke (evyncke) <[email protected]> > <[email protected]>, Jeffrey Haas <[email protected]> > <[email protected]>, The IESG <[email protected]> <[email protected]>, > [email protected] > <[email protected]> > <[email protected]>, [email protected] > <[email protected]> <[email protected]>, rtg-bfd@ietf. org > <[email protected]> <[email protected]>, Reshad Rahman <[email protected]> > <[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) <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 > > > > > > > > >
