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

[Daniel]

Hi Henning!

On 01/23/2013 08:31 AM, Henning Rogge wrote:
>> 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).
>>
>> 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.
> 
> Building a secure tunnel for Smartgateway would be possible, but it comes at a
> cost. At the moment Smartgateway use an "asymmetric tunnel", which means that
> one traffic TOWARDS the gateway is using the tunnel. This also means that the
> receiver doesn't need to be aware which node is sending traffic towards the
> gateway.

If only a single shared key is used on the gateway for all clients, a wild-card
policy is possible, I guess by using tunnel mode with static parameters and a
bit twisted NAT setup.
In all other cases => either manually configure at least some static
(ipsec,tunnel,adressing,routing) parameters and/or have some IKE RPC animal to
deal with some of it.

And also, olsrd could negotiate the tunnel setup or something else (netifd,
zebra, you-name-it) could do it, monitoring available gateways via olsr-jsoninfo.

Setting up a tunnel could mean anything between generating IPSec and/or L2TP
configuration and directly setting up endpoints and ipsec parameters using
netlink, plus setting up the inside-tunnel addresses and routing, ...
Or just feeding zebra to do the job?

> With a bi-directional (and secured) tunnel, you need a mechanism on the gateway
> to send traffic towards a node into this side of the tunnel.

Sounds like some NAT/routing hack to me... But I see the advantage of not
carrying the protocol overhead of additional L2TP-header, Ethernet-frame and
inside tunnel IP...
To be secure from be point of view of the gateway owner, it would also be enough
to AH sign only the packages from the client to the gateway and route the
downstream through the mesh in plain.


>> Obviously it's worth trying not to re-invent IKE but making something way more
>> simple...
> 
> I would suggest NOT to invent your own key-exchange protocol. Just use IKE with
> a long caching time for the keys, so you only have to do it once.

What's really at stake here are the ~200kb+ of flash needed to store the
binaries for racoon2 or openswan or ipsec-tools' IKE plus dependencies.
(strongswan doesn't claim AH transport is working, in terms of size it's about
the same)
Using only iproute2 or even hardcoding such a setup and having olsrd do the
netlink setup could safe a lot of space... (Obviously, without key-exchange and
re-keying, this is also at the cost of security)

Are you aware of a FOSS IKE implementation which could fit into the ~60kb left
on a 4MB-flash node? I'd happily use it! (and it should be possible to solve a
micro-version of IKE in even less binary size)

One reason for using L2TP is that ISPs over here already use it so we use xl2tpd
for WAN dialup and only need few additional kernel modules and iproute2
userspace for static l2tpv3 and ipsec support.


Cheers


Daniel