On 6/10/2024 9:22 AM, Jeffrey Haas wrote:
...
In RFC 5880, the specification of Meticulous Keyed MD5 addresses both number
rollover and out of order delivery. The same text is repeated for meticulous
MD5 and meticulous SHA1:
... if the
sequence number lies outside of the range of bfd.RcvAuthSeq+1 to
bfd.RcvAuthSeq+(3*Detect Mult) inclusive (when treated as an
unsigned 32-bit circular number space) the received packet MUST be
discarded.
That means that if a the packet 1-2-3-4 are delivered out of order as 1-4-2-3,
then packets 2 and 3 are going to be ignored and 1 loss will be detected.
That's probably not right.
For our authentication purposes, without the presence of some sort of
computed digest across the packet, NULL authentication means that an active
attacker can knock the session over simply by injecting packets that push
the sequence numbers ahead. Without the sequence number windowing check,
it's trivial. With the sequence numbering window, it still becomes possible
by simply hitting the right window and increases the window out of the range
of the real client too fast.
That's not what NULL authentication specifies. The spec says "the loss
count is incremented by one and bfd.RcvAuthSeq is set to the received
Sequence Number". I am not happy about that, but it is actually robust.
If the endpoint expects packet 5 and suddenly receives spoofed packet
5555, one loss is detected and bfd.RcvAuthSeq is set to 5556. When
packet 5 is received as expected, another loss is detected, but
bfd.RcvAuthSeq is set to 6 and operation is back to normal.
The "meticulous" variants use a different spec, one that relies on a
window of acceptable numbers. A spoof packet can push bfd.RcvAuthSeq to
the end of that window. The next spoofed packet can push it further,
etc. If it is possible, that attack can push the window far ahead and
really mess up loss detection. But the attack is only possible if the
counter rolls over, and the attacker has retained copies and copies the
old packets.
Trying to further mitigate that using a pacing check becomes problematic in
most implementations and isn't natural for current BFD implementations.
The conclusion was thus we can't use NULL for authentication. We're only
interested in it for the stability check.
However, as you note, in the event of regular packet reordering, we start
bumping the counters too hard.
The loss counter increments by 2 for each spoofed NULL packet. This can
be done at will by the attacker. I think everybody would sleep better at
night if the NULL option was removed on implementations used one of the
"meticulous" option instead. And if rollover was officially not supported.
What can you do about this?
Nothing.
We*could* mitigate active attempts to bump the counters, and perhaps that's
reasonable to restore the check on the sequence windowing to try to remove
some noise from the system. However, outside of that work... if you're
having this issue occur with ANY authentication mechanism regularly, it
means you have a problem.
The best this mechanism can do is help provide you notice of issues.
Outright dropped packets tells you there is loss. Regular out of order
delivery is a notice of out of order. Past this, you can notify the client
of issues and that's the entire value proposition here.
There is another possibility: expose more counters. I recently had to
design something similar for a QUIC transport API, and I ended up with
three counters:
* number of packets received,
* number of packets deemed lost (i.e., number of holes)
* number of packets that were deemed lost but where later received.
Such an API would provide more information to the management application
that uses the Yang module.
But this kind of advice is way outside a security review. From the
security point of view, there are just two obvious recommendations:
don't use NULL authentication, and don't allow rollover of sequence numbers.
-- Christian Huitema
