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

[Josh King]

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. 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.

> 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. 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.

> 
> 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.
> 
> 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.

> 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). 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.

> 
> 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.

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

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: OpenPGP digital signature
URL: <http://lists.chambana.net/pipermail/commotion-dev/attachments/20150623/e06e8ae6/attachment-0001.sig>