On Wed, Sep 13, 2017 at 10:23 AM, Juliusz Chroboczek <j...@irif.fr> wrote: >> I've got a working commit that adds price as an unsigned integer in >> between the metric and prefix fields in route updates. > > You're modifying the base protocol rather than doing an extension, so > please change the header so that unmodified Babel routers don't try to > associate with your routers. (Just change the "Magic" value in the packet > header to some other arbitrary value.)
Will do, I should change the header on the local socket interface too since I've added new functionality. I'd like to make a proper spec for this and have it work as an extension in the long term. > Another possible optimisation is to put the sub-TLV in the Router-ID TLV, > which will allow you to carry a single price for multiple routes > advertised by the same router. I've considered this as well, in small networks where nodes typically set a similar price (for example a default value) this works really well but I'm not sure how much aggregation would be useful in a 'real' usecase where prices are probably being auto adjusted. That's part of the reason I didn't dive right into a TLV based implementation I wanted something to play around with and gain intuition. >> The easiest way I found to do it was to use a wireguard tunnel as >> a neighbor and then have an external program monitor the rtt, > > Babeld can monitor RTT out of the box. Please check the manual page, and also I should clarify, I'm using Babel for the RTT computation, but an external program monitors the values and is actually responsible for interpreting the values and closing off wireguard tunnels in order to isolate Babel from lying or malicious nodes. There's no real reason you can't do all of this in Babel but then we get into pulling crypto and key exchange into Babel to replace wireguard, adding another socket without a link local address so that messages can be sent directly to other babel instances for verification, advertising a verification endpoint, and then some sort of database to log previously hostile nodes so that the attack/block process doesn't start again on restart. If it turns out there's a lot of interest in a standalone version of Babel that can do route verification I'm not opposed to integrating all of that directly into Babel, but right now I still want some hard numbers on exactly how effective this method is before such a large development investment is made. I'll bring some hard data about effectiveness when I post to the mailing list about this. Thanks! - Justin _______________________________________________ Babel-users mailing list Babel-users@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/babel-users
