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

[Juliusz Chroboczek <[e-mail]>]

CC-ing babel@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.

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.)

-- Juliusz