[OLSR-users] Some updated on 0.4.4

[John Gorkos]

I've been thinking about security plugins, too, and I'd like to throw my 
thoughts into the mix.
  In my opinion, the MANET is a means to an end, not the end itself.  Most 
users of the MANET aren't interested in using the MANET, they're interested 
in getting their email from hotmail.com, their news from CNN, and (for the 
geeks), their geek update from slashdot.  They would like for these 
transactions to be secured over the air, but they really aren't concerned 
with the methodology.
  To this ends, it seems that what the users really want is end-to-end 
encryption between their MANET node and the network gateway which is routing 
their traffic onto the Internet.  Encryption that works regardless of the 
path taken to get to that gateway (making IPSEC a non-starter).
  I see little need to encrypt or obfuscate the actual intra-MANET traffic.  
Almost all of that traffic is going to be nothing more than OLSR traffic, 
routing updates, and administrative traffic to maintain the MANET.  As long 
as a secure (TLS) connection is used to protect the configuration passwords 
and settings of the devices which make up the MANET (in the case of a MANET 
with fixed assets as well as mobile assets), who cares if you can sniff the 
traffic between two points.
  My solution has been to make sure that each gateway on the MANET is capable 
of terminating some form of encrypted P-t-P tunnel with nodes in the MANET.  
Currently, my MANET only has one gateway, so I make it easy by telling every 
node that it needs to establish a P-t-P VPN tunnel with a given gateway 
machine, using a static IP address.  What I envision, though, is a daemon 
that will tear down and reestablish the VPN connection whenever the default 
gateway changes through OLSR.
  An example of this would be a neighborhood MANET, with several members of 
the net providing broadband connections from their homes.  Some folks have 
DSL, some ISDN, and some cable.  Each gateway node, regardless of it internet 
connection type, has the same VPN server on it.  As a 
bicyclist/pedestrian/mobile node moves through the neighborhood, their 
default route will change to whichever gateway is closest.  In my world, the 
OLSR daemon would signal the VPN tunnel client that the default gw has 
changed, and the daemon would tear down the old VPN connection and start a 
new connection with the closer gateway.
  The real reason I'm doing this is to promote a subscriber model of MANET 
participation.  If you are a subscriber, you get a certificate signed by my 
root CA.  If you have the certificate, you can build a VPN tunnel to one of 
the gateways.  The gateways are configured such that ONLY traffic coming from 
a VPN tunnel is allowed through router onto the Internet.  It does require a 
root CA (something I realize Andreas is opposed to), but that could live 
anywhere on the Internet (or on whatever private backbone network that each 
of the gateways is hooked to:  imagine a series of gateways connected to a 
SONET ring in a metropolitan area...).  I suppose I could even establish more 
VPN tunnels between the gateways and the central CA to ensure my intra-net 
administration traffic is secure.  Anyone can become a member of the MANET 
without a certificate:  I'd always welcome more nodes to make the mesh more 
robust, but without a subscriber agreement and a certificate, you can't GO 
anywhere off the MANET.
  Thoughts?  I've got the first half of this system already implemented using 
a fixed VPN server address.  It would actually even work with multiple 
gateways, assuming all gateways could see the VPN server.  I could put the 
VPN server in a co-lo facility with an OC3 and VPN all MANET->internet 
traffic through my server there, and then on to the internet.  The only price 
of this is I'm paying twice for traffic into the co-lo site:  once as it 
comes in via the tunnel, once as it goes back out on to the internet.  return 
traffic has the same path:  it comes to the server at the co-lo, where it is 
encrypted and sent to the MANET back over the same wire.
  Programatically, all I really need now is a plugin that notices when the 
default gateway changes and triggers a restart of the vpn client, with the 
new gateway as the server.  A little more intelligence would be nice:  if the 
new gateway doesn't have a VPN server running, revert to the previous server.  
This would prevent the rogue-node problem where someone with a grudge and an 
OSLR daemon says "I've got your default route, baby" and then routes you to 
their /dev/null device. 

John Gorkos


On Thursday 06 May 2004 11:10, Andreas Tønnesen wrote:
> Hi Alex,
>
> Security is not my area of expertise - but here are my comments.
>
> First of all, I do agree that a certificate solution would probably be
> better in many ways. But the MANET is supposed to be without any kind of
> centrelaized services and IMO this kind of break with that
> philosophy(atleast of you demand the rootCA to always be reachable for
> revocation lists, initial signing etc.). There are many questions that
> must be answered for scenarioes with rootCAs. Who is to decide who
> should be the rootCA? Should one operate with backup/reelection of
> rootCAs if the rootCA node looses connection? What kind of process
> should lead to a revocation/issuing of a sertificate?
> If there is to be no dynamic in the scenario(eg. revocation/issuing)
> then why not just have a fixed database of public keys and go for a
> assymetric signing scenario?
>
> I can see scenarios where a shared key can be used. As an example a
> shared key could e.g. be saved into a SIM card that does the actual
> signing so that the key never leaves the card, which all users insert
> into their nodesand which could be replaced on a daily basis.
>
> But ofacuse - a shared key is probably no optimal solution and the
> secure OLSR solution is going to support(but not yet implement) all
> different kind of encryption/signing schemes due to a flexible message
> header. So in future versions a sertificate solution might be
> implemented - but there are just so much more work that has to be done
> in addition to the signing/timestamp exchange proccess for such a
> solution to work.
>
> regards,
> Andreas
>
> Alexander Morlang wrote:
> > Andreas Tønnesen wrote:
> >> Hi all,
> >>
> >> Just some words on what will be added on 0.4.4.
> >>
> >> I am currently working on a security plugin for olsrd that will be a
> >> part of olsrd 0.4.4. This functionality will ensure integrity in the
> >> MANET by the use of a shared key and freshness will be ensured by a
> >> timestamp exchange functionallity. The protocol itself will be
> >> described in my master thesis and in a paper later on. I can't say
> >> just how well documented or tested this plugin will be in the 0.4.4
> >> realease but I figure it will be interesting for some anyways.
> >
> > Isn't a certificate based signing with some kind of a rootCA instead of
> > a shared key more usable?
> > As soon as there are more user, it would be impossilble to keep the
> > sharedkey "secret", changing the key on a few hundred nodes would be not
> > that easy.
> >
> > Alex
> >
> >> Besides that I will update the gateway tunneling code used in this
> >> paper: http://www.olsr.org/docs/XA-OLSR-paper-for-ICC04.pdf
> >> so that it is usable without all the obscure pre-configuration needed
> >> as of now - but this will probably not happen in the 0.4.4 release.
> >>
> >> In my work at Thales Communications I have implemented a IP(v4)
> >> address autoconfiguration plugin(and daemon) that I hopefully can
> >> release into the public domain soon. However I cannot assure that this
> >> plugin will be GPL licensed. This work will be documented in a
> >> Internet draft and probably a paper in the near future.
> >>
> >> Minor issues that will be updated in 0.4.4 are some RFC compliance
> >> issues(HNA IPv6 messages and route calculation based on WILL_ALWAYS),
> >> some more options in the configuration file and some more work on the
> >> link-layer information(but this is far from beeing usable as of yet).
> >>
> >> And finally - as my master is soon finished I am looking for a
> >> _interesting_ job(Unix, C, network...) ;)
> >>
> >>
> >> - Andreas T