> 1) A mandatory-to-implement security mechanism. That's not what our userbase want. People are running Babel over VPNs (the RTT-based variant). People are running Babel over secure link layers. These users would not be served by putting encryption into the base protocol.
RFC 7298 (HMAC-based authentication for Babel) is a feature that I've been under pressure to implement in the reference implementation, and I'm open to that, time permitting, but I don't want to bloat the base protocol document with it. > The current draft says that security can be accomplished by using > a lower-layer security solution, No. The current RFC (not draft) says that Babel as defined in this document is a completely insecure protocol. Either you roll your own security, or you use RFC 7298. > 2) Congestion avoidance. I am not sure how Babel would behave in the > presence of congestion, Very well. It has seen a lot of testing in congested meshes. > I have looked through the spec, and I don't see any mechanism > to rate-limit Babel messages, The metric doesn't change more often than once per hello interval, so there's no way to get more than one triggered update per hello interval. Updates are delayed and aggregated, so unless you have massive metric instability, you get much, much less than that. And route flapping doesn't cause triggered updates in Babel. > Are there mechanisms in the implementation to avoid these problems? The implementation has a token bucket that logs a huge warning whenever it triggers. It hasn't triggered in years, but has been useful to detect bugs in earlier versions. Margaret, this is a loop-avoiding distance vector protocol that employs delayed and aggregated updates. The amount of traffic generated is microscopic. Please don't take my word for it -- see Fig. 4.7 on page 43 of Roger Baig Viñas' M.Sc. (Note that Roger is part of the BMX6 community, so if he's biased, he's biased against Babel -- but I've met him personally, and I believe he's an honest and conscienscious researcher.) http://bmx6.net/attachments/download/129/master_thesis__evaluation.pdf > If Juliusz would be willing to surrender change control of the protocol > to an IETF WG, I'm willing to go to Prague. I'm willing to have the number of coffees, teas, beers, heck, even Cokes if you insist, that will be necessary for both of us to feel that trust and understanding have been established. You cannot reasonably expect me to "surrender" the fruit of seven years of my life before that has happened. -- Juliusz _______________________________________________ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
