[Olsr-dev] "Secure" Mesh networks

Sven-Ola Tuecke (spam-protected)
Tue Feb 9 10:32:05 CET 2010


you still gave no good answer to the question "what do you want to secure?" 

* Prevent access to the radio/spectrum? That's impossbile. Everyone can use 
it. Simply use other BSSID.

* Prevent third party from evasdropping? I would think it's sufficient to grab 
a hardware node and reverse-engineer.

* Prevent untrusted node from inserting bogus routing data? Iptables will do 
the job - as an alternative the olsr-secure plugin can be used (but iptables 
is superior IMO)

* Protect your valuable resources (aka. Internet Gatway, couple of 
live-porn-webcams etc): use openvpn or similar. Sell keys to the customers.

* You don't what to be visible as "please join" type of net: simply do not 
send ESSID or do not answer DHCP requests.

There are enough techniques to secure data communication in unfriendly network 
environments. Ask you favorite chinese dissident on that. Any encryption 
technology will fail - besides really sophisticated stuff not possible with 
cheap retail hardware from next supermarket. Or at least has disadvantages / 
alternatives. On the other hand: beeing hospitable and invite other to extend 
you network has advantages.

Note: if you have installed a protected mesh in my neighourhood, and I want to 
join: I would simply install an analog Babycam with a strong directional 
antenna sending a picture "let me in, tel: 1234" and waiit a couple of weeks.

// Sven-Ola

Am Dienstag 09 Februar 2010 08:59:12 schrieb John Barrett:
> I'm not looking to add any more encryption than necessary, but I am
> looking for something more secure than a shared key.  WPA already gives
> us that much, and most likely, if the WPA key is compromised, then the
> shared key will also be compromised (someone steals a router and reads
> out the data with a jtag cable for instance). What I'm looking at with
> certificates and TLS is providing a means of blocking out a single
> compromised node if needed (by updating the certificate revocation
> list), with just a little more overhead than the current secure plugin,
> and that overhead mostly at "startup" when 2 nodes become aware of each
> other.

More information about the Olsr-dev mailing list