[Babel-users] A happy babel user: re6st

[Dave Taht]

On Wed, Jan 23, 2013 at 5:18 PM, <jp at nexedi.com> wrote:

> Hi,
>
> > > a- How can we prevent one babel participant to act against other
> > > participants by providing wrong information to other participants ?
> > > Imagine for example that a bad organization joins re6st + babel
> > > network and starts capturing all routes in order to analyze traffic
> > > or even block it.
> >
> > Since you're already encrypting and authentifying all your traffic,
>
> We authenticate each node mesh but we do not want to encrypt traffic (it
> is a configuration error).
>
> > Denis' work won't help you.  The best I can think of is to do some
>
> What is Denis work ?
>


Denis added authentication to the quagga version of babel.

See the code in quagga-RE and in the RFC draft, currently under revision:

http://tools.ietf.org/html/draft-ovsienko-babel-hmac-authentication-01


> > filtering to drop any routes that don't make sense, but I'm not sure
> > it will help you much.
> >
> > BGP has the same problem, and SBGP, while promising, hasn't seen much
> > deployment yet.
>

It would be nice to find something that scaled to small region networks
both from authentication and to collapsing prefix matches.

And to not make the same mistakes as in BGP. Tall order.



> >
> > > b- How can we create a hierarchical addressing system ? The idea
> > > here is to group participants dynamically and assign them a "big"
> > > IPv6 address range.
> >
> > Yep.  I've thought about it, and I don't see a good way to make
> > automatic aggregation work in Babel -- the longest-prefix rule will
> > cause Babel to ignore the aggregated routes.
>
>
Well your edge gateway could only offer it's /48 out on one interface but I
haven't looked over your meshyness yet.



> Ulysse B. found some approaches based on IPv6 NATs and automated discovery
> of connected neighbours
>
>
reference?


> >
> > > c- How can we implement more policies (ex. latency) ?
> >
> > We're working on it (Matthieu and I).  Current babeld head has some
> > stability improvements which should in principle make it possible to
> > have a stable network even when using latency as a cost measure.  As
> > I told you last summer, I've come up with a cool way to measure
> > latency without increasing the amount of traffic much, so now it's
> > a simple matter of programming.
>

awesome. in time for ietf? :puppy dog eyes:

I note that my (side?) of the work has been on reducing per-hop latency
under load (aka bufferbloat and "fq_codel"). I keep hoping to have a
version that can throw dropped packets to userspace in the hope that
congestion notifications also, will lead to better meshy routing networks.

fq_codel and derivatives like nfq_codel and cake do a good job of reducing
latency under load, so I would hope that the remaining problem for a
smoothing a babel + fq_codel network would be wifi power save (CAP can
induce 200ms of delay or more)

Having a measurement of router-2-router latency would be a good way to
distinguish between wifi, 10, 100, gigE, and tunneled networks.

Similarly I keep hoping that someone will look hard at the metrics that the
minstrel algorithm can provide on a per connected host basis.

https://www.bufferbloat.net/projects/cerowrt/wiki/Minstrel_Wireless_Rate_Selection

it is a much more direct way of determining available bandwidth and
connectivity (passive, too) and (actual in use bandwidth is something that
cake throws to userspace too.)

regrettably I'm mostly working on polishing up the fq_codel work and sims
for the next quarter.


>
> Great.
>
> Regards,
>
> JPS.
>
> >
> > -- Juliusz
> >
> _______________________________________________
> Babel-users mailing list
> Babel-users at lists.alioth.debian.org
> http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/babel-users
>



-- 
Dave Täht

Fixing bufferbloat with cerowrt:
http://www.teklibre.com/cerowrt/subscribe.html
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.alioth.debian.org/pipermail/babel-users/attachments/20130123/9690065a/attachment.html>