Christian, Reshad,
> On Jun 13, 2024, at 12:41 PM, Christian Huitema <huit...@huitema.net> wrote: > On 6/13/2024 8:46 AM, Reshad Rahman wrote: >> <RR> Was there any consideration to change the procedure to increment the >> loss count so that if we get 1-3-2-4, we increment loss count when we >> receive 3 (2 is deemed lost) but not when we receive 2 (2 < 3 so that means >> out of order). Also when we receive 2, since 2 < 3 (OOO) if we don't update >> bfd.RcvAuthSeq, then when we receive 4 we won't increment loss count. So >> it'd be counted as 1 loss. > > Or, you could use the same "windowed" process as used with the authenticated > modes. But the security issue is obvious. > > The current specification for loss detection with NULL auth is almost > stateless. A spoofed packet does increase the loss counter, but the next > packet restores the state to what it needed to be. Adopting your proposed > rule or the windowed rule will make it stateful. A spoofed packet would > increment bfd.RcvAuthSeq, and could cause lots of "good" packets to be > ignored. Exactly this. The minimal state kept would cause the highest number in the rolling sequence number space to cause the lost packets to "latch" vs. the highest seen sequence number. Under attack or bug conditions, this would be problematic due to the lack of authentication. > > This brings back my argument against using NULL authentication. I would > prefer to not see it used at all, but barring that you could at a minimum > have a warning in the security section. RFC 5880 says that "BFD can provide > failure detection on any kind of path between systems, including direct > physical links, virtual circuits, tunnels, MPLS Label Switched Paths (LSPs), > multihop routed paths, and unidirectional links (so long as there is some > return path, of course)." We're not changing that behavior for BFD. The lack of security in the NULL auth is exactly why we removed it from being an acceptable mechanism for the optimized authentication procedures. In that circumstance, it harmed security rather than helped it. Thus, it remains only as a mechanism to provide a non-cryptographic mechanism for sequence loss. > I understand that the risk of using NULL auth appears limited if the > endpoints are connected by direct physical links, and maybe also if tunnels > are protected by IPSEC. But the risks are obvious for multihop routed paths, > tunnels without authentication, and probably virtual circuits or MPLS Label > Switched Paths as well. So, if you cannot swallow a blanket ban on NULL auth, > at a minimum you should have some MUST NOT specifications for any path in > which packets can be injected by third parties. This is true for plain BFD, and authentication is available and operationally recommended under such situations. That said, this revisits and attempts to relitigate long-shipped RFCs rather than discuss this specific mechanism. > > With a precaution like that in place, you could use the same windowed > procedure for all authentication types, including NULL. That would probably > simplify implementations. Sadly, the windowing procedures are harmful for NULL or anything else without a signature over the payload. Thus, we didn't recommend them. -- Jeff
