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. >>> >>> >>> Section 5, para that starts 'If bfd.AuthSeqKnown is 0: The sentence is >>> incomplete. Maybe 'is set to 1, then bfd.Rcv.AuthSeq...'? >> Ok. How about what we have done in the other drafts? Move that statement to >> the end and say (effectively telling what initializes the ability to start >> detecting packet loss)? >> >> Otherwise (bfd.AuthSeqKnown is 0), bfd.AuthSeqKnown MUST be set to 1, >> bfd.RcvAuthSeq MUST be set to the value of the received Sequence Number >> field, and the received packet MUST be accepted. > > [DC] I'm literally saying that what is currently written [IF, without a > THEN] isn't a sentence. However you want to make it a real sentence is fine > by me. >>> >>> >>> Section 5, last para.: This sentence conflicts (received Sequence Number >>> MUST NOT be compared vs. bfd.Rcv.AuthSeq) with the previous paragraph >>> (bfd.RcvAuthSeq+1 is equal to the received Sequence Number). I'm not sure >>> what '.vs' means in this sentence, nor is it clear what 'discarding the BFD >>> packets' means. >> Packets can arrive out of sequence. Therefore, if there is a strict >> comparison done of the sequence numbers, one would detect packet loss, when >> the only thing that has happened is that packets have arrived out of >> sequence. The document does not dictate what an implementation should do to >> detect out of order sequence. It just says that a strict comparison should >> not be used to decide whether to accept or reject a packet. Section 6.2 has >> more to say about this. If it helps, we can refer to Section 6.2. > > [DC] 'compared vs.' is an odd phrase. Maybe, 'compared to' or 'strictly > compared'? or something similar. A ref to Section 6.2 would not be bad > either. [mj] Ok. Will make those edits. >>> 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. Thanks. >>> Section 9.2: While I didn't review this closely, I did notice that some >>> changes in the template affect the first paragraph (which outlines some of >>> the security required for these modules). Please update this. >> Ok. Will fix it. >> >> Thanks. >> >> >> Mahesh Jethanandani >> [email protected] <mailto:[email protected]> Mahesh Jethanandani [email protected]
