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. > > > 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. > 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'? > 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] > > > > > > >
