[LAC-TF] Fwd: Re: [OPSEC] IPv6 implications on IPv4 nets: IPv6 RAs, IPv4's VPN "leakage"

[Fernando Gont]

Ultimo fwd -- el resto consultenlo de las listas correspondientes ;-)


-------- Original Message --------
Subject: Re: [OPSEC] IPv6 implications on IPv4 nets: IPv6 RAs,	IPv4's
VPN "leakage"
Date: Tue, 4 Sep 2012 12:28:25 -0400
From: Dave Dugal <dave at juniper.net>
Organization: Juniper Networks, Inc.
To: Fernando Gont <fgont at si6networks.com>
CC: 'opsec at ietf.org' <opsec at ietf.org>

I agree: interesting (read: dangerously unexpected).  This is precisely
why one of the SSL VPN gateways I'm intimately familiar with disables
IPv6 for the life of the [v4] VPN session.  It's a bit inconvenient for
me at home, but is the least worst option for the generally unaware user
(present company explicitly excluded).

- Dave

On 9/4/2012 12:18 PM, Fernando Gont <fgont at si6networks.com> proclaimed ...
> Folks,
> 
> I was thinking about discussing the following scenario, that I came up
> with a few days ago:
> 
> A dual-stacked user (v6 enabled by default) "visits" an IPv4-only
> network, and establish his VPN with his office (for "mitigating"
> sniffing attacks, etc.).
> 
> A local attacker sends forged ICMPv6 RAs, thus triggering IPv6
> configuration at the victim nodes.
> 
> If any of the remote nodes the victim is trying to "visit" is
> IPv6-enabled, then it's possible/likely that the IPv6 destination
> address will be used over the IPv4 one. in which case the victim will
> send his traffic on the local network, as opposed to "through the VPN".
> 
> 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.
> 
> Thoughts?
> 
> Thanks!
> 
> Best regards,
>