Christian, On Mon, Jun 10, 2024 at 05:11:17PM -0700, Christian Huitema wrote: > On 6/10/2024 9:22 AM, Jeffrey Haas wrote: > >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'm not arguing with that. I'm verifying that we had discussed leveraging the sequence windowing mechanism utilized by the cryptographically authenticated mechanisms and had disconsidered it. > 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. Glad you agree with that conclusion. > 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. Presuming you're talking about the cryptographically authenticated mechanisms for meticulous md5/sha1, no. The only way to push the sequence number ahead in such circumstances is to send a valid BFD PDU that has the relevant authentication data. If that is possible, the attacker already can subvert the authentication. And again, sequence rollover for replay has the presumption that you're using exactly the same contents for the BFD PDU. The procedures for randomizing the Discriminators provide an appropriate nonce to prevent replay since the authentication data is computed over the entire BFD PDU. If we get a sequence number rollover for a BFD session under those circumstances, the implementors and network engineers should be proud that the session was able to stay up for that long and the network that stable. > >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. I'm sure you would. Your concerns are understood and previously discussed. And, as noted, networks choose performance in some circumstances over security for scaling purposes. > >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. Your third point is one that had some level of discussion among working group members (not necessarily on-list) over the time the draft has been around. It's part of the reason for this text: : Implementations MAY provide mechanisms wherein all expected packets : received across an expected interval but delivered out of order are not : considered lost packets. Why not MUST? Because BFD is often implemnted in resource constrained devices and there's a strong motivation to keep the implementation simple. To pick a simple possible case that had some discussion, the Detection Multiplier in BFD encodes the number of packets that, when lost, are the reason why the session moves to Down. One could say that an implementation should keep around state for some number of packets and report when there is loss observed within a given rolling window of Detection Multiplier packets. This isn't a lot of code. But it was enough to concern some implementors. Rather than mandate such an implementation, it becomes an option. And, since this is YANG, if it becomes a popular implementation it can be standardized. > 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. Your opinion on NULL is registered and the concerns acknowledged. Your observation on sequence number rollover for existing authentication mechanisms remains incorrect. Hopefully the explanation supplied above helps your understanding. -- Jeff
