Hi Mirja, Sorry for taking the time to follow up on this. The changes suggested to address this review are being tracked at:
For the remaining comments, see inline. > On Aug 12, 2025, at 2:54 AM, Mirja Kuehlewind <[email protected]> > wrote: > > 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." Ok. Will add the text to the Terminology section. > > >> -- “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! This has been reworded to match the text in the other two drafts (draft-ietf-bfd-optimizing-authentiation, draft-ietf-bfd-secure-sequence-numbers). Essentially, we are moving this sentence one paragraph below and replacing it with. 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. It implies that if all other conditions fail, you are in INIT state, and therefore the implementation should (locally) set bfd.AuthSeqKnown to 1, and (again locally) set bfd.RcvAuthSeq to the received Sequence Number, thus setting it up to start watching for lost packets. > > >> - “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. Yes, and no. My experience with counters jumping suddenly only causes people in NOC to go into alarm mode, because no one has bothered to read the documentation or understand what its true implication is. My suggestion is to limit the loss count to packets lost within a detect multiplier window. Therefore, if the detect multiplier is 3, the loss packet count should be incremented if the lost packet’s sequence number is within that window. Anything outside of it, should be considered an attack. > >> - “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. How about this? Per RFC 5880, Section 6.7.3 a receiver MUST discard a received packet that lies outside the range of bfd.RcvAuth and bfd.RcvAuthSeq+(3*Detect Multi). In case of NULL authentication where packets containing sequence numbers are accepted on receipt, an attacker with unauthenticated sequence number could move the Sequence Number forward. Meanwhile, the actual BFD neighbor’s packets will be discarded and the session would drop. To prevent such an attack, the receiver Sequence Number MUST NOT be compared vs. bfd.RcvAuthSeq for purposes of discarding the BFD packets. > > >> 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.” Ok. We will update the text to say something similar. Cheers. > > Mirja > > > > -- Jeff > > > -- > last-call mailing list -- [email protected] <mailto:[email protected]> > To unsubscribe send an email to [email protected] > <mailto:[email protected]> > > > Mahesh Jethanandani [email protected]
