On Wed, Nov 28, 2018 at 10:28:50PM -0800, Dave Taht wrote:
Dave Taht <[email protected]> writes: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?
As it is we are having trouble to achieve that figure even without hashing. Doesn't this mean this should be priority?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.I've been meaning to poke into this a while: https://code.fb.com/connectivity/open-r-open-routing-for-modern-networks/ But I do take your point. It would be good to know that on a given 10,000 route 200 router babel network that hashing overhead accounted for .0X% of the 100% of cpu in use.
viele Grüße Christof
You are reasonable to assume that sha256 would be low overhead relative to other factors, I think. Still, would like to go measure. Aside: Where does the 300ms figure for re-attempting a challenge and response come from? _______________________________________________ Babel-users mailing list [email protected] https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/babel-users
-- () ascii ribbon campaign - against html e-mail /\ against proprietary attachments
signature.asc
Description: PGP signature
_______________________________________________ Babel-users mailing list [email protected] https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/babel-users
