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

Bjoern A. Zeeb bzeeb-lists at lists.zabbadoz.net
Sun Sep 9 21:09:11 CEST 2012


On Thu, 6 Sep 2012, Fernando Gont wrote:

> On 09/04/2012 05:52 PM, Bjoern A. Zeeb wrote:
>>> Assuming the VPN product does not disable local v6 support, and that the
>>> VPN does not provide IPv6 connectivity (*), this attack vector could
>>> prove to be an interesting one ("unexpected", to some extent).
>>>
>>> (*) even then, this attack might still work.
>>
>> I haven't read the draft (yet) but you
>>
>> 1) get what you pay for, and
>> 2) we have the technology to prevent all of this
>>
>> so it's not science or research anymore but a problem of monkeys.
>
> -- 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.


>> And to finish my thoughts, is this any worse than an ipv6-only VPN
>> on a say dual stack network (or any other combination)?
>
> 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?  You do not
need to be malicious to see the traffic going the wrong way.

/me codes back to being a monkey

-- 
Bjoern A. Zeeb                                 You have to have visions!
          Stop bit received. Insert coin for new address family.



More information about the Ipv6hackers mailing list