[Olsr-dev] "Secure" Mesh networks
Tue Feb 9 18:58:43 CET 2010
Sven-Ola Tuecke wrote:
> 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.
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
> * 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
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
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
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
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)
More information about the Olsr-dev