[Babel-users] Babel MAC auth fails due to packet reordering

[Toke Høiland-Jørgensen]

Juliusz Chroboczek <jch at irif.fr> writes:

> CC-ing babel at ietf.  List, Daniel has reported that multicast packets are
> delayed in his network by up to 200ms, which breaks Babel-MAC's PC check.
> Toke has determined that the issue is with WiFi powersave, which is
> unfortunately not something we can control.  Toke has proposed a patch
> against his implementation of Babel that implements window-based PC
> validation, in the style of RFC 4303 Section 3.4.3.
>
>> I took a shot at implementing window-based PC verification in Bird,
>> patch below (compile-tested only);
>
> That should work, although I fear that a window size of 64 is not enough,
> especially since RFC 8967 Section 4.2 allows increasing the PC by more
> than one.  So we'd either need to remove that latitude from the spec, or
> require the use of a more complicated data structure.

My PoC uses a window size of 32, actually, but could be trivially
extended to 64 (just by switching from a u32 to a u64 for storing the
bitmap), and a bit less trivially to a larger window by using a bitmap
spanning several u64s (or some other data structure).

> But I've been thinking the issue is that we require a single strictly
> monotonic sequence of PCs that mixes up unicast and multicast packet.
> What about relaxing the requirement so that the sequence of unicast
> packets is monotonic, the sequence of multicast packets is monotonic, but
> the two sequences can grow independently?  This will still prevent replay:
> a unicast packet won't be possibly replayed as unicast, due to the
> monotonicity condition, and it cannot be replayed as multicast, since the
> MAC covers the pseudo-header
>
> More precisely, I propose that we maintain two distinct "last PC" fields
> in the neighbour table, called PCu and PCm.  These behave as follows:
>
>   - when we receive a challenge reply, we set both PCu and PCm to the
>     value received in the challenge reply;
>   - when we receive a normal packet, we compare its PC against *either*
>     PCu or PCm, depending on whether it's unicast or multicast;
>   - if the packet is accepted, we update *either* PCu or PCm, leaving the
>     other value unchanged.
>
> (We could generalise that to having one PC value per destination address,
> but I'm not sure it's useful.)

Hmm, I certainly see where you're coming from; having separate sequence
numbers for unicast/multicast would neatly sidestep this particular
problem. However, one problem with this is that it's not straight-forwardly
backward compatible. I.e., if a sender starts using separate sequence
number spaces for unicast and multicast, they would become incompatible
with receivers implementing RFC8967 as it is written today, even on
networks that exhibit no reordering. Whereas simply having a reorder
window is more of a "be lenient in what you accept" thing on top of the
existing spec (i.e., a babel speaker implementing a replay window can
interoperate fine with one that doesn't, except for reordering). Also,
packets could get reordered for other reasons, not necessarily related
to whether they are unicast or multicast; a window-based approach would
deal with that as well.

As for the size of the window (setting aside the case where an
implementation increases the PC by more than one for every packet), I
guess we'd need it to be large enough to contain a full routing table
dump. A window of 64 packets can fit several thousand routes even in the
worst case with no compression; so I'm wondering if this isn't enough
for most deployments?

-Toke