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