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

Henning Rogge (spam-protected)
Wed Jan 23 07:31:19 CET 2013


On 01/22/2013 04:02 PM, Daniel 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).
>
> 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.

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.

> 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. 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...

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.

Henning Rogge


-- 
Diplom-Informatiker Henning Rogge , Fraunhofer-Institut für
Kommunikation, Informationsverarbeitung und Ergonomie FKIE
Kommunikationssysteme (KOM)
Fraunhofer Straße 20, 53343 Wachtberg, Germany
Telefon +49 228 9435-961,   Fax +49 228 9435 685
mailto:(spam-protected) http://www.fkie.fraunhofer.de

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 6169 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://lists.olsr.org/pipermail/olsr-dev/attachments/20130123/aaa5bef2/attachment.bin>


More information about the Olsr-dev mailing list