[Babel-users] [babel] rather than ripemd160...

[Dave Taht]

Juliusz Chroboczek <jch at irif.fr> writes:

>> Why not? If it's not MTI you risk the case where you get to pick between
>> "good performance on weak devices" and "interoperability with RFC-only
>> implementations".
>
> Is there any evidence that there are devices that can reasonably run Babel
> and that are too weak to use SHA256 for protecting control traffic?
>
> I don't have an ARM device handy right now, but a 450MHz MIPS 24Kc is able
> to SHA256 on the order of 16MB/s.  That's 10000 full-size frames per second,
> or on the order of 600000 Babel updates per second.

Sigh. Benchmarks. In particular I loathe benchmarks that do just one
small thing repeatedly, fully in i and dcache and claim "that's how fast
it is". No, you go and measure the impact on the total system, under a
real workload, changing whether you have hmac on or off, to draw a conclusion.

In the crypto case especially, people are really fond of 
large block sizes, and not fond of showing lots of very small
ones. startup overhead can be significant. It takes a really long time
to sha1 one byte.

Hardware crypto offloads for packets, from userspace, as another
example, are generally a lose, due to the kernel/userspace transition
required.

Lastly...

Routers *are* doing other things besides exchanging routes, like moving
packets around and dns, dhcp, and so on. Complex systems have emergent
properties that don't show up without "all up testing", which often
results in "RUD" - rapid unscheduled dissassembly. 

I already showed with the rtod experiments that a sufficient number of
routes can disable the dns and dhcp daemons, on a low end router.

Your typical low end router forwards packets until it runs out of cpu,
which is usually well below line rate. Processing packets locally eats
even more cpu.

We also tried in the last battlemesh we went at, to coax those trying to
measure convergence times to also measure them under heavy load. I don't
know if toke's preso on the second+ long delays that network experienced
fully registered (but we went off and fixed wifi regardless). I would
rather like to make battlemesh this year... with working hmac, unicast,
kick-arse wifi, and other whizbang new features and bugfixes.

...

I'm trying to redteam these ideas. If a given attacker hits me with
10,000 babel packets a second, unauthed, do I die? If I try valiantly to
verify these packets and fail, do I die sooner? If I figure out I'm
under attack from this particular box, can I blackhole all/most its packets
and move on, and not die at all? (RRL in bind is an example)

And honestly, all I'm pushing for at the moment is a way to do key
rotation, and it would be good to be able to have two algorithms to
evaluate. 

>
> My suggestion is to implement whatever the list recommends (Blake2B or 2S)
> in both BIRD and babeld, but to keep the status quo (SHA256 is MTI) in the spec.

I can live with that, but would prefer to have running code to deploy at
some scale, and measure.

> -- Juliusz
>
> _______________________________________________
> Babel-users mailing list
> Babel-users at alioth-lists.debian.net
> https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/babel-users