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