Juliusz Chroboczek <[email protected]> writes: > 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.
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 _______________________________________________ Babel-users mailing list [email protected] https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/babel-users
