Hi Jeffrey, Thanks for your quick reply. Just to be super clear, my comments were not questioning the specification but I felt the wording as defined was not clear to me and I was left with some guesswork which left me unsure if I understood correctly. So my comments are really just a request to clarify the text (with more words) and not change any of the defined procedures.
Please see further below (marked with [MK]). On 12.08.25, 03:04, "Jeffrey Haas" <[email protected] <mailto:[email protected]>> wrote: [Speaking roughly as chair...] Mirja, On 8/11/25 14:42, Mirja Kühlewind via Datatracker wrote: > - “meticulously increasing sequence number” -> I know the term “meticulous” is > used for BPF but I’m not sure the term is clear in the context of sequence > number….? If you mean that all values have to be used at the sender without > gaps, I think you should simply say that. Would you check the definition covered by: https://datatracker.ietf.org/doc/html/draft-ietf-bfd-secure-sequence-numbers-22 <https://datatracker.ietf.org/doc/html/draft-ietf-bfd-secure-sequence-numbers-22>, section 1.1 and see if that covers the question here? At the moment, this is referred to via section 2's Terminology "expected to be familiar with". [MK] Okay the definition in draft-ietf-bfd-secure-sequence-numbers-22 is good but I really would recommend to add a reference and not assume this is known. I didn't realize in the first place that this is part of the BFD terminogy as it just look like a word in the text. Also this part is quite essential and therefore it probably don't hurt to be super clear. I would even recommend to cite the definition to make it crystal clear, like this or something: "As specified in draft-ietf-bfd-secure-sequence-numbers-22, the term "meticulous" means that the Sequence number is incremented on every new packet which is sent." > -- “If bfd.AuthSeqKnown is 0, bfd.AuthSeqKnown is set to 1” -> not sure what > you want to say here…? Do you mean it will be set to 1 when a new packet is > received (and not discarded)? Also you don’t really say what bfd.AuthSeqKnown > is supposed to be at all? At minimum it would be good to say that it is > defined > in RFC5880 but even better would be to briefly recap what it is. Some text seems to be absent covering that this is part of received packet procedures. A reference to RFC 5880 section 6.8.1 seems appropriate. The text you elided also covers that the known received sequence number is immediately updated as well. See further below. [MK] Yes there seems to be something missing. Again spelling these things out to be more clear would be great! > - “If bfd.AuthSeqKnown is 1, and the received Sequence Number field is not > equal to bfd.RcvAuthSeq + 1 (in a circular number space), then the loss count > is incremented by one” -> This doesn’t seem correct. If more than one packet > is > lost, the loss count should not be increased by one but by the difference > between last seen and the current value, no? This seems generally correct. However, consider also the attack mentioned below and note how an attacker could arbitrarily inject random numbers that radically change the perceived loss count. I believe the current text reflects a compromise vs. such attacks. [MK] If this is really indented, you should explicitly say this. However, I personally don't think that seems like the best way to cover this attack. This attack only becomes an attack if you use the loss count in some way that can influence you procedures negatively. However, the result of having a wrong loss count doesn't seem an attack in itself. Therefore it seem more useful to me to keep the loss count accurate and rather make sure that people understand the attack vector when using this information. > - “when bfd.AuthSeqKnown is 1, the received Sequence Number MUST NOT be > compared” -> this doesn’t really fit to the previous text, I guess you mean if > bfd.AuthSeqKnown is already 1 when a new packet is received? The section you elided was: "the received Sequence Number MUST NOT be compared vs. bfd.RcvAuthSeq for purposes of discarding the BFD packets." This is intentional procedure. In the other mechanisms leveraging a sequence number that include stronger authentication, the sequence number check is used to ignore out of sequence number window packets. Compare, for instance, vs. RFC 5880 section 6.7.3. The motivation to exclude similar checks from the null authentication is since packets containing sequence numbers are immediately accepted on receipt, it's important to not protect against a class of sequence number attacks. That attack would involve the unauthenticated sequence number from an attacker pushing the last known sequence number ahead. The actual BFD neighbor would continue sending packets using its existing sequence number space. However, if the receiver considered the correct packets from its real neighbor to be out of the sequence number window and discarded the packets, the session would drop. This is not an issue for authenticated types. [MK] The current text seems to short and maybe even incomplete. I think this need to be elaborated in the draft. > Also in Section 6: > - “When using MD5 or SHA authentication, BFD MUST use an authentication type > (bfd.AuthType) that is of type meticulous” -> not fully sure what exactly you > mean here. There is no type “meticulous” in itself. You mean type MUST be > “Meticulous Keyed MD5” or “Meticulous Keyed SHA1”, respectively? I think it > important to be correct here in the language you are using. See the top comment about the definition of meticulous types. The goal is to not to limit the mode to specific existing types, but those which have the meticulous sequence number property. [MK] This is really about wording. The current text sounds like as if there should be a type "meliculious". When I looked at the types I assumed that all types that have the meticulous sequence number property are meant. But that is not what the text says. As I said I think it is important to be correct here in the language used and a minor word change as you phrase it would easily address this. OLD: “When using MD5 or SHA authentication, BFD MUST use an authentication type (bfd.AuthType) that is of type meticulous” NEW: “When using MD5 or SHA authentication, BFD MUST use an authentication type (bfd.AuthType) that has the meticulous sequence number property.” Mirja -- Jeff -- last-call mailing list -- [email protected] <mailto:[email protected]> To unsubscribe send an email to [email protected] <mailto:[email protected]>
