[Olsr-dev] RFC: secure access control for SmartGW tunnels

[L. Aaron Kaplan]

On Jan 22, 2013, at 4:02 PM, Daniel <(spam-protected)> wrote:

> Hi everyone!
> 
> Looking for a way to add secure access control to SmartGW, I played around with
> an olsrd IPv6 mesh and managed to establish an
> Ethernet-over-L2TPv3-IPSec-transport-AH-HMAC(SHA1) tunnel using iproute2 3.7.0.
> This provides a tunnel authenticated by pre-shared keys at the cost of only
> little CPU, ROM and RAM resources (tested => impressive even on small MIPS
> cores, whole image incl. olsrd, kmod-ipsec*, iproute2 and luci web-interface
> also still easily fits on 4M devices).

Out of interest: 
Did you measure or can you estimate the overhead that the authentication creates?

> 
> SmartGW currently uses plain IP-over-IP tunnels. While this might be suitable
> for the simple case, it would be nice to also have the option to choose other
> gateway/tunnel setups, like the one above (and illustrated by the attached script).
> 
Agreed. 
On a related note - this reminds me of another cool tunnel solution which was developed by Christian from Funkfeuer Graz: anytun.
 
Overview: http://www.anytun.org/index.php?option=com_content&view=article&id=15&Itemid=30
Details: http://svn.anytun.org/anytun-common/trunk/papers/draft-gsenger-pointner-secure-anycast-tunneling-protocol-01.txt

In brief: in OLSR you can easily announce "anycast" IP addresses (just announce the same HNA on multiple nodes).
These can be tunnel endpoints. The network will always chose the closest one. 

Question: would your solution also lend itself to an anytun type of setup?

> Other possible setups are IPv6-over-IPSec-tunnel-AH-HMAC(SHA1) or even just
> plain IPSec-transport-AH-HMAC(SHA1) between a gateway and a gateway-client.
> 
> This could be accomplished (on Linux) by either implementing the communication
> with the IPSec stack via netlink or by allowing to call an external script to
> setup the tunnel e.g. using iproute2.
> 
> Gateway tunnels would have to either store and use a static key for the whole
> gateway or use per-user keys.
... which could come from some authentication system (LDAP, ...)

> Both parties would also need to exchange session
> parameters and/or store (at least some) static per-tunnel parameters permanently.
> 
> Obviously it's worth trying not to re-invent IKE but making something way more
> simple...
> 
> <tunnelclient.txt>

I must say that I *really* like the idea. 
My fingers are itching to try it out in a test setup ;-)
We have a hackathon on the weekend...


Aaron.