On Fri, Nov 23, 2012 at 12:01:07PM -0300, Fernando Gont wrote: > On 11/23/2012 11:12 AM, Reyk Floeter wrote: > > 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 problem is that even if you tried to send all IPv6 traffic over the > VPN, the mechanism to achieve that might be non-trivial. e.g., some VPN > implementations install "more specific routes" that override (i.e > "longest matching prefix" thing) the existing default route. -- but > there are a plethora of vectors that might be leveraged to install even > more specific routes than those (Route Information Options, ICMPv6 > Redirects, etc.). > > That is, "getting all the v6 traffic on the VPN tunnel" might be tricky. >
Well, it is less tricky with our IPsec stack because we have these crazy flows (aka. SPD) that always "magically" bypass the routing table. And I think the risk that someone sneaks in conflicting flows is very small. > > a) Just don't care about it and expect that admins configured pf and > > the interfaces correctly. > > This one doesn't seem to obey the principle of "least surprise". Many > people are not aware about the implications of v6 on their "v4-only" > networks. > So how big is the risk with the link local addresses only? Otherwise the risk in an IPv4-only network is relatively low, and it would be a "surprising surprise", because we don't accept RAs by default and the attacks in sections 4 + 5 of your paper would not work (net.inet6.ip6.accept_rtadv=0 and net.inet6.icmp6.rediraccept=0). Unless you can somehow send a user to a host in the local network using the link local connectivity. > > > > 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). > > This seems a sensible thing to do. > Actually, in the iked(8)/IPsec case we could even block all v6 traffic without using PF by simply inserting a single "deny" flow. For example: # ping6 -w ff02::1%em0 # ipsecctl -vf /etc/ipsec-block.conf flow esp out from ::/0 to ::/0 type deny # ping6 -w ff02::1%em0 Most IPsec VPN clients could use their existing PFKEYv2 interface to dynamically add a similar rule to their Security Policy Database. But unfortunately, the SPD is the least portable part of PFKEYv2. This would obviously not help with OpenVPN or PPP. Some IPsec implementations even use tun/tap-like userspace interfaces instead of the IPsec stack (I think "vpnc" is such a case). Reyk
