[Olsr-dev] "Secure" Mesh networks

[John Barrett]

Sven-Ola Tuecke wrote:
> Hey,
>
> you still gave no good answer to the question "what do you want to secure?" 
> IMO. 
>
> * Prevent access to the radio/spectrum? That's impossbile. Everyone can use 
> it. Simply use other BSSID.
>   
or use off-frequency routers, a method that I disagree with due to 
certain trends in the amateur radio community.
> * Prevent third party from evasdropping? I would think it's sufficient to grab 
> a hardware node and reverse-engineer.
>   
thats always a problem, and wpa is as good as it gets to stop that, even 
though not 100% at this time.
> * 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)
>   
I'd be interested in better understanding that comment a LOT better, I 
dont see how IPT gets involved at all except for blocking/allowing 
traffic in general from a specific node. My current plan is to block 
everything except what is needed for the handshake, and have olsrd open 
up holes when nodes complete the handshake.
> * Protect your valuable resources (aka. Internet Gatway, couple of 
> live-porn-webcams etc): use openvpn or similar. Sell keys to the customers.
>   
openvpn keys or node certificates -- is there a real difference ?? Only 
that node certs block them out before they get any access to the mesh at 
all.
> * You don't what to be visible as "please join" type of net: simply do not 
> send ESSID or do not answer DHCP requests.
>   
ad-hoc meshes dont answer DHCP in the first place. How does not 
identifying the mesh help ?? there may be another mesh or AP the same 
channel -- don't want to bump with them !!
> 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.
>   
All of which take time and expertise to set up and configure, while I'm 
trying to make the infrastructure as plug-and-play as possible while 
still maintaining a degree of security.

I plan on publishing both the firmware and the website that will support 
this system. If someone wants to use it to make a public network, then 
more power to them !! I'll even allow them to use my website to manage 
their certificates if they want !! I'm taking into account that not all 
amateur organizations may want to be part of the nation wide mesh that I 
would like to create. I wouldn't make much sense for a network in DE or 
UK to compete with each other or the US for a limited pool of IP 
addresses (16 million per mesh using the current addressing scheme), so 
the website is going to support creating multiple logical mesh clouds.
> 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.
>   
It would be an interesting test case -- you might shut down PART of the 
mesh, but I think your effective radiated power would be breaking the 
FCC rules for unlicensed transmitters, so what you might get in a few 
weeks is a notice of apparent liability for deliberate and malicious 
interference :) Remind me to add on a 2.4ghz setup for my mobile Doppler 
direction finder !!
> // 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.
>>     
>
>   
I'm looking to secure a mesh to be used by amateur radio operators 
(though the setup applies equally well to an ISP selling access to a mesh).

The mesh in question will generally be used for accessing the internet, 
and accessing a few servers on the mesh (mail, web, voip).

But when the crunch comes, the mesh will be used for emergency 
communications.

I am unhappy with other solutions for securing the mesh that have been 
proposed by amateur operators, the foremost being to shift the base 
frequency of the router so that it is no longer lined up on the standard 
channel frequencies. Most new operators do not have the electronics 
skills to make these modifications, so my preference is to stick to 
unmodified hardware.

As demonstrated by events such as Katrina, when a disaster occurs that 
results in a call up of em comm resources, they are drawn from all over 
the country. If there is to be a mesh network run by amateurs, then 
there has to be a standard in place in advance that will allow operators 
connect to the mesh without any (and I mean ANY) need to configure their 
nodes upon arrival on scene. They should drive up, power up, and given 
the needed peer links, be able to immediately provide access to the 
services needed.

1. I want the over-the-air traffic reasonably secure from sniffing (WPA 
is as good as it gets right now)
2. I only want authorized nodes on the mesh (certificates and TLS 
handshake + key exchange is workable)
3. I want to be able to block out rogue nodes with stolen certs 
(certificate revocation list handles this one, and should be a rare 
occurance -- amateur operators protect their gear)