On Fri, Nov 23, 2012 at 12:44:32PM +0100, Henning Brauer wrote:
> * Fernando Gont <[email protected]> [2012-11-23 12:09]:
> > FYI. This is might affect OpenBSD users employing e.g. OpenVPN:
> > <http://tools.ietf.org/html/draft-gont-opsec-vpn-leakages>.
> 
> we're way less affected than other OSes, since we prefer inet over
> inet6 by default. targeted attacks could still work.
> 

Yes!

But this wouldn't help any non-OpenBSD hosts behind an OpenBSD VPN
gateway.  "block quick inet6" is more efficient in this case ;)

> I recommend "ifconfig $foo -inet6" in any case :)
> 

In the section "Mitigations to VPN traffic-leakage vulnerabilities" of
Fernando's paper it is suggested that a VPN client disables IPv6
globally if it is not going to send all IPv6 traffic over the tunnel
as well.  The problems with -inet6 in this context are that a) it
isn't a global IPv6 on/off switch and b) that it deletes all
configured addresses from the selected interface, so the VPN client
could not restore the previous configuration after the VPN connection
is terminated.

In iked(8)'s case, IPv6 is supported but nothing is forwarded unless
the related flows are configured.  And even in this case, IKEv2 would
use traffic selector negotiation, which is not yet implemented in
iked, and disable or narrow the configured IPv6 flows based on the
peer's configuration.  Maybe traffic selector negotiation is a risk by
itself (see RFC 5996, section 2.9).

The mitigation section of the paper is not very clear about the "IPv6
supported, but not used or negotiated" case.  Regarding iked(8), I
would think about at least one of the following options:

a) Just don't care about it and expect that admins configured pf and
the interfaces correctly.

b) Document it in the iked.conf(5) manpage near the packet filtering sections.

c) Make sure that the "any" keyword for flows in iked.conf will cause
iked to advertise both the IPv4 and IPv6 traffic selectors.  This
would at least mitigate some possible problems, for example with the
Windows IKEv2 client which already asks for any IPv4 and IPv6 by
default.

d) Implement an automatic IPv6 kill switch in iked that follows the
suggestion to disable all IPv6 traffic if we have an IPv4-only tunnel.
iked(8) could use a pf anchor to load a block rule, disable
net.inet6.ip6.forwarding, or we could add a knob net.inet6.enable=0
that doesn't alter the configured routes and addresses and simply
returns somewhere in the network stack (ugh).

e) Just switch everything to IPv6 today.  Oh wait, OpenBSD would have
a reversed problem in this case by looking up IPv4 on dual-stack
setups first *g*.  Haha, I'm wondering if we'll ever see any serious
security problems because of "legacy IPv4" in an IPv6-world...

Reyk

Reply via email to