[Olsr-dev] "Secure" Mesh networks

[John Barrett]

Sven-Ola Tuecke wrote:
> John,
>
> interesting plan. Sorry to be harsh - I taxed you as the average 
> encryption-does-it-all bloke. Those normally tend to think that their 
> knowlege about some crypto give them an advantage over others.
>
> That baby-cam approach works. Yes - limited area only. We have seen that in 
> practise by a community member calling the RegTp (sort of FCC in Germany). 
> They have impressive equipment, but the rule says: shared medium, no need to 
> put up cooperative radios (such as all-wifi, sharing a channel). So they 
> solved by convincing (!forcing) the baby-cam owner. Obvioulsy a cooperative 
> approach too...
>
> The iptables approach should work, because you already have a trusted 
> environment: you - and only you - can login to that routers probably with 
> ssh-pubkey. For a typical mesh meant to share some service this is sufficient 
> to keep out the bad boys.
>
> For a mesh with a critical resource such as your emergency thing, you may want 
> more. Those military boys are also interested in that topic for their meshed 
> battlefield robotos I presume. Maybe it helps to google some patent databases 
> on that topic...
>
> // Sven-Ola
>
>   

I've actually got very little experience coding for crypto, except for 
one recent project involving SRP6, but we trust TLS/SSL for moving our 
credit card info over the net, so its gotta be fairly tight so long as 
the certificates are reasonably secure. And the requirement that each 
node have a cert, and each node initiate a connection with its peer to 
collect the peer's validation key should pretty well stop anyone from 
getting the validation keys short of stealing a router with a currently 
valid cert.

I really dont expect much trouble from baby cams or other APs causing us 
much trouble. Even though the frequency is shared, as licensed amateurs, 
we have the right to run a LOT more power than any off the shelf 
baby-cam :)

The mesh managers cannot afford to be logging into and reconfiguring 
iptables on routers. The system has to be able to handle all that on its 
own because we do not know from moment to moment what peers any given 
node might be trying to communicate with -- I've got a mobile node, 
others will have nodes in a "go-box" that they will deploy on site as 
needed, others will be fixed locations -- so any iptables changes need 
to happen automatically. This shouldnt be all THAT much of a problem as 
a node will NOT announce a one-hop peer to the rest of the mesh until 
validation is completed, then all the nodes can open up traffic for that 
IP address as the notification propagates across the mesh. (That 
actually seems a little klunky on second thought -- I'll have to put 
some additional thought into it once I understand whats going on a 
little better)

I dont think I need military grade crypto !! I'm trying to pull this off 
with minimal code over and above what is current state of the art :) 
This is just the first part of the architecture I'm working on, and I 
want to get to work on the rest of the features !! Next will be a 
revamped DNS system extending the UPnP concept to named servers that may 
be connected to any mesh node, followed by some changes in how the 
routers acting as internet gateways work to facilitate inter-island 
routing (Joe from New York drives to Boston, but can still access the 
servers on the NY mesh, or any other mesh island participating in the 
"cloud" to which he is subscribed)