As Mahesh notes, in-person discussion at IETF 124 on the lingering security review can certainly happen. With his publish for version -20, here's perhaps a few other inputs that might shorten that discussion:
> On Oct 18, 2025, at 6:26 PM, Mahesh Jethanandani <[email protected]> > wrote: > > Hi Deb, > > Let me make another attempt to explain the why. See inline with [mj] > >> On Oct 13, 2025, at 8:02 AM, Deb Cooley <[email protected]> wrote: >> >> My replies with [DC].... >> >> On Sat, Oct 11, 2025 at 12:49 PM Mahesh Jethanandani >> <[email protected] <mailto:[email protected]>> wrote: >> Hi Deb, >> >> Sorry for taking the time to get back on this. >> >>> On Sep 23, 2025, at 4:20 AM, Deb Cooley <[email protected] >>> <mailto:[email protected]>> wrote: >>> >>> For reasons unknown to me, my ballot was not sent to the authors (or to the >>> list). I'm including it below: >>> >>> Deb Cooley >>> Sec AD >>> >>> Many thanks to Christian Huitema for the extensive review and discussion. >>> >>> Section 1 or 3: I don't think it would hurt to add a sentence or two to >>> remind the reader about both the high speed of the links (I think RFC 5880 >>> <https://datatracker.ietf.org/doc/rfc5880/> points to SONET) and the >>> computation limits on the line cards. >> In the case of optimized authentication, a more/less compute mode needs to >> be enabled. In that case, I can see the reason to mention high speed links >> and computation load, i.e. as the link speed goes up it puts more >> computational load on the line card to authenticate every packet). However, >> in this draft, we are advocating for NULL auth to avoid that computation >> load, and still be able to measure the loss of packets. Therefore, I am >> struggling to articulate a sentence on possible impact of loss measurement >> because of speed/compute. Did you have a suggestion? >> >> [DC] RFC 5880 already covers this situation, and the Simple Password option >> should be fast (and just as insecure). Why is the NULL Authentication >> method necessary? As for text, I would look to what Jeff Haas is proposing >> for the Optimized draft as an option. > > [mj] I think the term “NULL Authentication” has tripped up quite a few folks. > > Today, as BFD is defined, when a session is established without > authentication, it does NOT carry a sequence number. The only time BFD packet > is required to carry a sequence nubmer is when authentication is enabled. In > other words, the receiver will aceept a packet that is larger when > authentication is enabled than when it authentication is disabled. For the > purposes of loss detection, which is what this draft is all about, what is > required is for the sequence number to be inserted in the BFD packet, and > that larger packet be received by the receiver. To avail of this capability > (of inserting a sequence number), this draft is proposing that authentication > mode be enabled, so the sequence number is inserted in the packet, but not do > any authentication. Thus the name “NULL Authentication”. Turn on > authentication mode, but do not do any authentication. > > That is why adding a sentence on speeds and CPU capability, beyond what RFC > 5880 already says in its Operational Considerations, does not make sense in > this draft, while making complete sense for the other two drafts. I agree that the current draft covers the desired scenario appropriately. Unlike the optimized/secure-sequence-number drafts, the goal of the proposed NULL mechanism has nothing to do with speed in terms of "making authentication faster". Instead, it simply provides a mechanism for BFD sessions that would otherwise be happy with NO authentication to have a place to put the meticulously increasing sequence number. Perhaps some of the discomfort is that section 4 discusses "a bfd meticulous authentication type is configured" while the split to section 5 discussing null as a mechanism for the "doesn't need authentication" use case is a bit too separate for the reviewers' comfort? >>> Section 6: Titled 'Theory of Operation'. It is unclear what the purpose >>> of this section is. This draft is about Null Authentication, I'm not sure >>> why MD5, SHA1, and ISAAC are mentioned here. It is literally the only >>> mention of MD5, SHA1 and ISAAC in the specification. (Possibly some of this >>> information could be put in Security Considerations?) >>> >> I agree that the section if read in isolation does sound incomplete. Will >> rewrite it. However, for implementations that are not comforable running BFD >> without some form of authentication, including where the mode does not do a >> full digest, the section is suggesting what other meticulous auth types they >> could use. >> >> [DC] The only suggestion I have is that this section is meant to be some >> sort of rationale section. To answer the question about 'Why does BFD need >> this feature'? > > [mj] See above. In addition, the idea in this draft is to do loss detection, > where the losses are such that they do not bring down the BFD session, but > happen frequently enough to indicate that there might be a problem at the > link level. Is the discomfort here that section 6 talks about how to do the measurements while the motivations are covered in section 3? If so, what rewrite would address that discomfort? -- Jeff
