I've gone back to look at the draft again. My comments were never blocking, so I'm fine with you all saying it is fine as it stands.
It certainly does not meet the bar of having a discussion IRL on meeting week. See inline (I only have one remaining comment) Deb On Wed, Oct 29, 2025 at 10:47 AM Jeffrey Haas <[email protected]> wrote: > 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]> 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]> 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? > [DC] I went back and read the Introduction (v20) again. It does state a reason why one might want sequence numbers on the packets. I'm happy to call this resolved. > > 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 > [DC] I really have no idea what the point of the second para is in Section 6 (the rest of the subsections are fine, and the first sentence/para in the section is fine too). Why does this even need to be mentioned? There is literally no mention of any of these techniques anywhere else in the specification. It appears here, out of the blue. Personally, I'd delete it. But these aren't blocking comments, so if you all think it is clear, then I'm good. > > -- Jeff > >
