[Commotion-dev] Adding a cmake option for Babel in Commotion 1.2?

[Dave Taht]

On Tue, Jun 23, 2015 at 10:27 AM, Josh King <jking at opentechinstitute.org> wrote:
> Hi Dave,
>
> Trimmed and added responses inline below
>
> On 06/23/2015 12:48 PM, Dave Taht wrote:
>>
>> Did you fit sqm-scripts in there?
>>
>
> It's definitely in the repo (though I'm not sure I pushed up that
> addition yet). I'm definitely not concerned about the space with it,
> since it's pretty tiny even with the LuCI module. I was a little
> concerned about turning it on by default, since I hadn't had much time
> to test it and I'm somewhat concerned about any potential additional
> load on the gateways (especially when I'm trying to track down a crash
> bug). If you have any thoughts on its resource utilization, I'd
> appreciate your feedback.

Do ship it. :)

Don´t turn it on by default. DO encourage those maintaining exit nodes
to properly configure and enable it on their ISP uplinks - it makes a
world of difference, particularly for short flows, voice and crypto
traffic.

http://wiki.openwrt.org/doc/howto/sqm

To give you an idea how bad the buffering is on the ISP links, see the
up and down results here.

http://www.dslreports.com/speedtest/results/bufferbloat?up=1

sqm-scripts moves stuff way up past the green line on uploads, and
usually does OK on downloads.

They are a standard openwrt package at this point and among other
things work correctly with ipv6 where wondershaper and the default
qos-scripts do not.

There is more advanced work going on in ceropackages - the new "cake",
and support for it are in kmod-sched-cake, and tc-adv, but while I
encourage testing it, it aint fully baked yet. Of note in cake is that
it does GRO peeling - modern routers like the linksys 1900ac are very
agressive about GRO/TSO/GSO offloading and this really messes up
things. So far as I know you are using routers that do not do any
offloads of this sort, so you are fine with what we have there.

http://www.bufferbloat.net/projects/codel/wiki/Cake

If you are fortunate enough to have an uplink that does hardware flow
control then you do not need to shape the egress portion of the link.

> But I'll tell you what, when I stomp that bug
> and roll images for final-round testing, I'll enable it for those images
> and we can make sure there are no issues with having it on.

TIA!

I would kind of prefer you do it sooner rather than later. About the
main difficulty I would expect is how and where it hooks into your
firewall rules, which I assume are different than openwrt´s.

>> I note that I am a little scared by everyone converging on a single  "best"
>> crypto algorithm. I would much rather there be diversity and at least two rather
>> different forms of crypto throughout the network - the vpn layer and a ssh
>> or mosh like layer below it should be very, very different....
>>
> Yeah, I hear you there. Unfortunately, this is also a tradeoff with the
> processing and entropy constraints of embedded routers. I think we have
> a decent compromise though in Commotion. We have two forms of encryption
> that are relatively constantly in use. One, IBSS-RSN for the links, is
> AES-based and hardware accelerated by the wifi chipset, so it has almost
> no overhead. The other, Serval's nacl-based encryption (essentially the
> VPN layer in your model), is fast and has relatively tiny keys, so it
> has the least overhead we can reasonably manage.

nacl is quite impressive. I hope to use it elsewhere.

Are you fiddling with dnsmasq and dnssec? With dnssec-timestamp, 2.73 almost
feels generally deployable.

> Then other things like
> the web interface, SSH, and in the future the dashboard agent, use more
> heavyweight things like TLS with RSA keys but are not in use all the
> time. It might be better from a security standpoint to use more than one
> of these, but we already have a good number of crypto libraries taking
> up space and processing resources.

Just so you have two entirely different layers of encryption...

>
>>
>> hmm. I will have to think about this. Was giving HIP a revisit recently.
>>
>
> One thing I like about this model is that if we tie this in with how
> Serval announces routes and keys, we can probably come up with a fairly
> zero-collision addressing mechanism. Since you'd always get an address
> announcement in a packet signed by the keypair the address was derived
> from, you should always be able to tell if the address is valid and not
> spoofed. It won't be quite as low-collision as SHA-2 itself given the
> limited number of bits available in the address, but still pretty good.

It does look encouraging.

>> No, I agree. In the case of ipv6, it is a real pita to number every interface
>> and only sort of necessary when you want to distribute a prefix. I *am*
>> loving source specific routing, and could forsee a day where a device
>> had a 1000 local ipv6 addresses to chose from, each going out a different
>> gateway somewhere else on the network....
>>
> I'll have to look into source-specific routing more. It seems like it
> could be a good solution for certain kinds of problems.

My own primary use case is in "simply" preventing any ulas or
random ipv6 addresses not from my isp(s) from even
attempting to escape the network at that egress point. It is bcp38
on steroids, with far less complexity (for a change).

I happen to like what I have seen of olsrv2, I hope that ss enters
it as well.

>
>> I am more than a little down on hnetd presently. It needs more
>> dogfooding and, well, I was not expecting the god-like perspective it
>> wants over the whole network. In supporting a DV protocol for homenet
>> (babel), I was aiming for the most minimal amount of shared state
>> there - only to be blind sided by the new, proposed address
>> distribution protocol wanting to know ALL....
> Ha, I actually wrote and the deleted "despite its relative complexity"
> at the end of that sentence (not wanting to bash a protocol that I am
> not fully versed in).

go right ahead. I'm in awe at how the kitchen sink entered that protocol
and daemon when I was not looking.

> Generally in Commotion my first design principle
> has been to make use of centralized or stateful resources where it makes
> sense, but not be dependent on them. I also want to adhere to standards
> where possible, but the amount of complexity and shared state on display
> with what I've read so far about HOMENET would seem to fly in the face
> of the first design principle. However, I'm going to do some more
> reading to make sure I fully understand it before following my first
> impression and discounting it.

More eyeballs and dogfooding - and alternative ideas such what we have
just discussed - are needed.

>>
>> serval looks very interesting, I had not been tracking the work at
>> all. And I didnt know SEND was ressurected to any extent. Thx for the
>> update, I am liking what I see here.
>
> No problem!
>>
>> In tossing out hnetd from my network, I started down another, simpler,
>> prototypical path, and I dont know where I'll end up....
>>
>> https://github.com/dtaht/ipv6_selfassign
>>
> Looks cool! I'll check it out and let you know if I have any questions.

That was forced by me wanting a "normal" 4 port debian based rangeley box
to have dual uplinks, sanely. It works...

> --
> Josh King
> Lead Technologist
> The Open Technology Institute
> http://opentechinstitute.org
> PGP Fingerprint: 8269 ED6F EA3B 7D78 F074 1E99 2FDA 4DA1 69AE 4999
>



-- 
Dave Täht
worldwide bufferbloat report:
http://www.dslreports.com/speedtest/results/bufferbloat
And:
What will it take to vastly improve wifi for everyone?
https://plus.google.com/u/0/explore/makewififast