The Babel Routing Protocol

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.