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

[Juliusz Chroboczek <[e-mail]>]

> Ah, I see! Okay, that makes sense. Also, it occurred to me that the
> window-based approach likely isn't enough when there are multiple
> neighbours and you do unicast updates, as then another neighbour can eat
> up a whole chunk of PC number space that you never see.

Exactly.  The sender maintains just one (index, PC) state per interface,
not one state per destination.  (In constrained environments, you could in
principle have just one state for all interfaces, although that's not
allowed by the RFC as it is currently written.)

> However, what about other sources of reordering? Should we still do
> window-based verification to deal with this?

We might add it as an option to the document you suggest.  I'm not
currently planning to add it to babeld, but I might change my mind if new
evidence that it is needed surfaces.  Ok?

> Also, I guess this could all be described in a "relaxed PC verification
> to deal with reordering" document that could be optional to implement
> (i.e., you could still be compliant with RFC 8967 if you don't implement
> it)?

I tend to agree, but I'd rather we did the implementation first, to see
how it goes.

>> Expect on the order of 60 routes per packet. 64 packets gives you on
>> the order of 3800 routes.

> Right. Which is a lot for a local mesh network, but not a lot for the
> internet.

OTOH, you should be spreading the updates over the whole length of the
update interval to avoid sending bursts of packets.  It's been on my todo
list for babeld for a long time, but I never got around to implementing it.

> Do you have any insights into typical sizes of real-world babel
> deployments in terms of the number of routes?

Nexedi have around 1000 routers.  I don't know how many routes they're
advertising in total.

-- Juliusz