To me, that seems like an attractive nuisance, where it's likely something that's really easy to implement and operate, and then build things that rely on it that are more valuable to where the idea it's strung together with something as lightweight as Babel becomes insanely irresponsible. Kind of like its predecessor RIPv1.
The idea of publishing or implementing a new routing protocol that doesn't have cryptographic verification designed into it as a feature seems like sabotage.
My day to day is dealing with the consequences of devops teams launching low-security infrastructure and then clients wanting to migrate their high-sensitivity data to it, and this Babel spec is precisely the kind of thing that causes that conflict.
Sure, build something untrusted that forces people to implement their own security that is at a level sufficient for themselves. I understand that as a reasonable design principle, but perhaps I have been out of the game too long, as seeing how these things play out, it's not clear how a routing protocol without at least signed updates is a good idea.
Re:The Babel Routing Protocol
by _nhynes on Monday December 21, 2020 @03:01PM
(#25498861)
The intro suggests that it’s for “unstable networks.” The protocol is required by the HomeNet project [0, 1], so residential networking (possibly including IoT) seems to be one application.
Re:The Babel Routing Protocol
by nisa on Monday December 21, 2020 @05:23PM
(#25500347)
it's used for mesh networks (but can also be used for other applications) - some freifunk communities in germany use it and there is ongoing development to port the most popular mesh firmware called gluon to use babel as it's a layer3 mesh and gluon is using a layer2 mesh (using B.A.T.M.A.N) - layer3 scales better because with more nodes you have a noisy switch on layer2.
https://tools.ietf.org/html/draft-ietf-babel-rfc6126bis-20#s...
To me, that seems like an attractive nuisance, where it's likely something that's really easy to implement and operate, and then build things that rely on it that are more valuable to where the idea it's strung together with something as lightweight as Babel becomes insanely irresponsible. Kind of like its predecessor RIPv1. The idea of publishing or implementing a new routing protocol that doesn't have cryptographic verification designed into it as a feature seems like sabotage.
My day to day is dealing with the consequences of devops teams launching low-security infrastructure and then clients wanting to migrate their high-sensitivity data to it, and this Babel spec is precisely the kind of thing that causes that conflict.
Sure, build something untrusted that forces people to implement their own security that is at a level sufficient for themselves. I understand that as a reasonable design principle, but perhaps I have been out of the game too long, as seeing how these things play out, it's not clear how a routing protocol without at least signed updates is a good idea.
[0]: https://datatracker.ietf.org/wg/homenet/about/
[1]: https://datatracker.ietf.org/doc/draft-ietf-homenet-babel-pr...
Fascinating stuff - if you want to learn more about babel here is a technical talk from the developer: https://www.battlemesh.org/BattleMeshV8/Agenda?action=Attach...