<br><br><div class="gmail_quote">On Wed, Jan 23, 2013 at 5:18 PM, <span dir="ltr"><<a href="mailto:jp@nexedi.com" target="_blank">jp@nexedi.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Hi,<br>
<div class="im"><br>
> > a- How can we prevent one babel participant to act against other<br>
> > participants by providing wrong information to other participants ?<br>
> > Imagine for example that a bad organization joins re6st + babel<br>
> > network and starts capturing all routes in order to analyze traffic<br>
> > or even block it.<br>
><br>
</div>> Since you're already encrypting and authentifying all your traffic,<br>
<br>
We authenticate each node mesh but we do not want to encrypt traffic (it is a configuration error).<br>
<br>
> Denis' work won't help you. The best I can think of is to do some<br>
<br>
What is Denis work ?<br></blockquote><div><br><br>Denis added authentication to the quagga version of babel.<br><br>See the code in quagga-RE and in the RFC draft, currently under revision:<br><br><a href="http://tools.ietf.org/html/draft-ovsienko-babel-hmac-authentication-01">http://tools.ietf.org/html/draft-ovsienko-babel-hmac-authentication-01</a><br>
<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
> filtering to drop any routes that don't make sense, but I'm not sure<br>
> it will help you much.<br>
><br>
> BGP has the same problem, and SBGP, while promising, hasn't seen much<br>
> deployment yet.<br>
<div class="im"></div></blockquote><div><br>It would be nice to find something that scaled to small region networks both from authentication and to collapsing prefix matches.<br><br>And to not make the same mistakes as in BGP. Tall order.<br>
<br> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="im">><br>
> > b- How can we create a hierarchical addressing system ? The idea<br>
> > here is to group participants dynamically and assign them a "big"<br>
> > IPv6 address range.<br>
><br>
</div>> Yep. I've thought about it, and I don't see a good way to make<br>
> automatic aggregation work in Babel -- the longest-prefix rule will<br>
> cause Babel to ignore the aggregated routes.<br>
<br></blockquote><div><br>Well your edge gateway could only offer it's /48 out on one interface but I haven't looked over your meshyness yet.<br><br> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Ulysse B. found some approaches based on IPv6 NATs and automated discovery of connected neighbours<br>
<div class="im"><br></div></blockquote><div><br>reference?<br> <br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="im">
><br>
> > c- How can we implement more policies (ex. latency) ?<br>
><br>
</div>> We're working on it (Matthieu and I). Current babeld head has some<br>
> stability improvements which should in principle make it possible to<br>
> have a stable network even when using latency as a cost measure. As<br>
> I told you last summer, I've come up with a cool way to measure<br>
> latency without increasing the amount of traffic much, so now it's<br>
> a simple matter of programming.<br></blockquote><div><br>awesome. in time for ietf? :puppy dog eyes:<br><br>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. <br>
<br>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) <br>
<br>Having a measurement of router-2-router latency would be a good way to distinguish between wifi, 10, 100, gigE, and tunneled networks.<br><br>Similarly I keep hoping that someone will look hard at the metrics that the minstrel algorithm can provide on a per connected host basis.<br>
<br><a href="https://www.bufferbloat.net/projects/cerowrt/wiki/Minstrel_Wireless_Rate_Selection">https://www.bufferbloat.net/projects/cerowrt/wiki/Minstrel_Wireless_Rate_Selection</a><br><br>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.)<br>
<br>regrettably I'm mostly working on polishing up the fq_codel work and sims for the next quarter.<br> <br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
Great.<br>
<br>
Regards,<br>
<br>
JPS.<br>
<br>
><br>
> -- Juliusz<br>
> <br>_______________________________________________<br>
Babel-users mailing list<br>
<a href="mailto:Babel-users@lists.alioth.debian.org">Babel-users@lists.alioth.debian.org</a><br>
<a href="http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/babel-users" target="_blank">http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/babel-users</a><br></blockquote></div><br><br clear="all"><br>-- <br>Dave Täht<br>
<br>Fixing bufferbloat with cerowrt: <a href="http://www.teklibre.com/cerowrt/subscribe.html" target="_blank">http://www.teklibre.com/cerowrt/subscribe.html</a>