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

[Teco Boot]

Interesting idea.

When finished extending smartgw for multiple tunnels, and time permits, I would love a tunnelless smartgw. With IPv6, this is doable, with routing based in source address (to gw that "owns" the prefix) in case destination is outside the manet. Something IETF Homenet is looking for.

A not so secure method is (dynamically) set up a filter on the gw for a (range of) address(es). 

How would the transport-AH-HMAC work for attached nodes? Just sign the packets and strip at gw? How can gw know which packets should be stripped?

Teco


Op 22 jan. 2013, om 16:02 heeft Daniel het volgende geschreven:

> 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.
> 
> 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...
> 
> <tunnelclient.txt>-- 
> Olsr-dev mailing list
> (spam-protected)
> https://lists.olsr.org/mailman/listinfo/olsr-dev