[Babel-users] Adding a monetary factor to routing cost

[justin kilpatrick]

On Wed, Sep 13, 2017 at 10:23 AM, Juliusz Chroboczek <jch at 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