[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,
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".
-- “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.
- “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.
- “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.
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.
-- Jeff
--
last-call mailing list -- last-call@xxxxxxxx
To unsubscribe send an email to last-call-leave@xxxxxxxx
