[OLSR-users] Some updated on 0.4.4

[Andreas Tønnesen]

Hi John,

I only read trough you mail briefly - as I'm about to call it the day :)

We are talking about different isses here. The reason for signing OLSR
traffic to gain data integrity is so noone can mess up you MANET.

Imagine a node declaring 1 hop routes to all IP addresses? It could
have nearly ALL data traffic routed to itself - and do with it whatever
it pleases. Imagine a node DoSing the entire MANET by flooding messages
at a high rate. Imagine a node declaring itself as a Internet gateway
only to pass itself off as hotmail.com or younetbank.com.
So - what if you want to be able to control what nodes should
participate in your MANET...
These are some of the reasons for securing OLSR traffic. In a typical
military scenario confidentiallity might be an issue as well - mening
one must encrypt the data traffic. After all - one can get a pretty good
idea of the topology by listening in for a few seconds.

How users ensure security in their TCP sessions is not of my concern :)
I don't work at that level. But even if they are totally ignorant to how
their traffic is relayed they do care that it actually IS routed to
the intended host.


Regarding the gateway issues you mention I have implemented IP-in-IP
tunneling to gateways so that nodes can be in control of what gateways
they use. the implementation is not very much of use to anybody else
as of yet - but I'll rewrite it soon. Check out the paper:
http://www.olsr.org/docs/XA-OLSR-paper-for-ICC04.pdf
for which the implementation was done.
The problem is that a node in OLSR cannot control what gateway it uses
as all routing is done hop-by-hop. So to be able to control this
nodes can tunnel IP in IP to the gateways.
This is something you should consider for your solution.

My master thesis(to be ready by 1. aug) contains a secion on this :)

regards,
Andreas

John Gorkos wrote:
> 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

-- 
Andreas Tønnesen((spam-protected))
UniK University Graduation Center
University of Oslo
http://www.olsr.org