[ipv6hackers] IPv6 implications on IPv4 nets: IPv6 RAs, IPv4, and VPN "evasion"

[Fernando Gont]

On 09/09/2012 04:09 PM, Bjoern A. Zeeb wrote:
>> -- the question is whether there are products that suffer from this
>> problem... and, as noted by others, there are.
> 
> Right but unimplemented code doesn't need an RFC, it needs fixing by
> vendors, as it's not about a fundamental underlying problem.

I personally think it *is* a fundamental underlying problem: the fact
that so far many VPNs only support IPv4, and due to the way IPv6 and
IPv4 interact/co-exist, traffic may leak out of the VPN.

That aside, please note that I'm not talking about writing an RFC about
this, but rather about including some words about this topic in an
existing I-D (draft-ietf-opsec-ipv6-implications-on-ipv4-nets).



>> Well, this is, to a large extent, irrelevant. Now, if you ask the
>> question, yes, it is a bit worse than the ipv6-only case: in order to
>> trigger the v4 connectivity, the attacker would have to be present on
>> the network when a "nomadic" host attaches to the network (in order to
>> be able to forge the dhcp-response packet). OTOH, an attacker can
>> trigger v6 connectivity at anytime by sending forged RAs (even if he
>> connects to such network after the victim node).
> 
> which mobile device doesn't do DHCP by default these days? 

I'm just saying that if the device has already done DHCP (and has eg
failed), you cannot just send DHCP-server packets to trigger v4
connectivity. -- although in many cases this is only a small difference,
since the attacker "will be there" when the nomadic node connects to the
"v6-only" network.


> You do not
> need to be malicious to see the traffic going the wrong way.

Agreed.

Cheers,
-- 
Fernando Gont
SI6 Networks
e-mail: fgont at si6networks.com
PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492