[Commotion-dev] Serval security summary

Wed Apr 4 20:41:20 UTC 2012

(Excuse me if I am missing something, I'm working off of the paper attached in this thread, some blog posts of Pauls and the discussion on this list).

Before diving into the Serval Overlay Mesh specifically, I'm curious about what the core motivations are for building a network with verifiable addresses.  If the client software can verify the identity over any network, like OpenPGP or OTR does, then it doesn't matter how the packets get there as long as they are properly encrypted and verified.  The internet is built upon those easily spoofed IP addresses, and it has proven a reliable medium for secure communications (given the right software on the endpoints).

I can understand wanting verified routing to prevent poisoning, but I guess this should be possible by adding crypto verification into the mesh daemons.  Something like: when olsrd receives a message to register a new route, that message includes a public key to tie to that route/address.  It seems feasible that this could happen purely within olsrd, batmand, etc.

Specifically about the Serval Overlay Mesh, sounds like a good plan if such a thing is needed. The huge problem with this approach is that is requires all of the software to be re-written to support it.  Another thing I wonder about is the architecture being built on a single cryptographic technique like Cryptobox.  It makes sense for the prototype to use only one type of key, but I think that the grand plan should allow for other types of keys, like OpenPGP does.

For the example of verified, encrypted voice calls, there is already ZRTP+SRTP+SIP.  We have a public alpha of a ZRTP-oriented voice service: https://ostel.me.  The ZRTP+SRTP+SIP combo is also fully compatible with a serverless, p2p setup.  You can use it with such clients as Jitsi (cross-platform), Twinkle (GNU/Linux), Groundwire (iOS), CSIPSimple (Android), and more.  More from us on that topic here:
https://guardianproject.info/tag/zrtp/
https://guardianproject.info/wiki/OSTN

.hc

On Apr 3, 2012, at 7:08 PM, Jeremy Lakeman wrote:

> We (Serval) have some ideas for routing, but we haven't started
> implementing anything yet. I have been doing some R&D on some new
> ideas for link quality measurements, but we haven't really started
> looking at the higher level routing problem yet.
> 
> An initial version might work in parallel to some other routing
> daemon, eg olsr. The overlay layer would translate from public key to
> current IP address, then consult the routing table to work out which
> peer is the next hop. In this mode it should be possible for packets
> to traverse an existing network without replacing the routing daemon
> on every device.
> 
> There are some reasons why I don't like olsr / batman layer 3 routing.
> The need to sense topology via broadcast packets, since the routing
> table would prevent you sending test unicast packets to 2 hop
> neighbours, this makes sensing link failures and new links take way
> too long IMHO. You have much more flexibility operating at layer 2 or
> 4.
> 
> Eventually we intend to route across different networking protocols
> and between networks that might be sharing the same IP addresses. eg
> small networks of android phones in hotspot mode all with 192.168.43.X
> addresses, with additional bluetooth links between them.
> 
> In my own research, with the android phones we have in reasonable
> quantities, I've noticed that wifi burst mode consumes waaaaay too
> much air time when a link suddenly fails. Though I haven't established
> if this is systemic to wifi, or limited to this specific chipset. The
> 802.11 spec leaves dealing with burst failures up to the implementer.
> 
> Linux buffer bloat is also really annoying, it's far too easy to be
> reacting to stale topology information.
> 
> Combine these two issues and building a map of a highly mobile network
> is almost impossible with any reasonable traffic volume. Using BATMAN
> for example, with mobile nodes, poor slightly directional antennas,
> and obstructions, gives a voice channel that is almost continuously
> dropping out.
> 
> On Wed, Apr 4, 2012 at 6:40 AM, Josh King <joshking at newamerica.net> wrote:
>> Hi all,
>> 
>> I just wanted to share out a document for discussion that I got a while
>> back and have been meaning to send out, namely a summary of some of the
>> security architecture that the Serval Project is working on for
>> Commotion. It's just a general summary at this point, but there will be
>> more forthcoming.
>> 
>> One question that I wanted to pose is: the document doesn't talk much
>> about routing. Is there a sense of how routing is going to work in the
>> secure overlay network, or am I missing that in the document?
>> 
>> Thanks to the Serval folks for providing this!
>> --
>> Josh King
>> Technical Lead
>> Open Technology Initiative
>> New America Foundation
>> 
>> _______________________________________________
>> Commotion-dev mailing list
>> Commotion-dev at lists.chambana.net
>> http://lists.chambana.net/mailman/listinfo/commotion-dev
>> 
> 
> _______________________________________________
> Commotion-dev mailing list
> Commotion-dev at lists.chambana.net
> http://lists.chambana.net/mailman/listinfo/commotion-dev
> 