Hi, On Sat, Oct 27, 2012 at 4:28 PM, Fernando Gont <[email protected]> wrote: > Hi, Cameron, > > Thanks so much for your feedback! Please find my comments in-line.... > > > On 10/27/2012 06:10 PM, Cameron Byrne wrote: >> The attack that i am most concerned about is that many folks assume >> the VPN will "lock the stack". And, the VPN software may in fact lock >> the IPv4 stack (on the WAN, only traffic to and from the VPN endpoints >> is allowed). But, in the case of dual stack, the VPN locks the IPv4 >> stack and the IPv6 stack is left wide open to a public WLAN. So, the >> attacker at a coffee shop can own the VPN users system via IPv6 and >> therefore access the secure corporate network over IPv4. This is not >> a case of protocol translation or traffic leaking, but a case of using >> a "jump host" to illicitly move from a public WLAN to a secure >> corporate network. > > Agreed. > > It looks like I should probably change the title of the I-D to something > along the lines of > > "Security Implications of dual-stack hosts/networks on Virtual Private > Networks (VPN)" > > or > > "Security Issues of Virtual Private Networks (VPN) in dual-stack hosts/ > networks" > ? >
Yes, i think that make sense. The major issue is that when VPN clients on hosts do not have feature parity between IPv4 and IPv6, there will be problems. Either way is fine with me. > (please do let me know if you have any preference of title over the > other, or feel free to suggest an alternative title) > > Then the I-D could mention possible/common security implications such: > > * Lost of confidentiality in the resulting traffic (i.e., you thought > your traffic was protected from eavesdroppers, when in fact it wasn't) > > * The possibility of an attacker stealing credentials (e.g. if an > insecure protocol was sending user/pass in the clear) > > * And the attack scenario you describing (an attacker using the VPN as a > pivot to attack some system in the VPN). > > > >> I think there is also some additional ipv6 nuance that can be explored >> in this case of a dual-stack VPN. For example, how is LLA treated on >> the coffee shop WLAN? > > In what sense? > Well, even feature parity between IPv4 and IPv6 is not enough. A dual-stack VPN should also account for LLA connectivity. IPv4 only had to account for 1 address scope. If the VPN is not supposed to be a "split tunnel", then is LLA on the WLAN interface is also supposed to be statefully firewalled on the host? Should the VPN host allow NDP from LLA and nothing else? If this is a guide to implementers, then pointing out the LLA area may be a good idea. > >> Also, the name server issue can be explored, >> if RA or DHCPv6 provides a DNS server, the VPN client should be sure >> to not use those since a rogue DNS server can create a situation where >> VPN traffic is leaked.... http://intranet is spoofed by the local >> attacker DNS server and skims login creds > > Agreed. I will try to test common implementations (Windows, *BSD, > Solaris, and Linux) with respect to this issue, and provide a summary. > > Thanks so much for your feedback! > Your welcome, i hope this draft can improve the area of VPN implementations. Thanks for taking the time to write it up. CB > Best regards, > -- > Fernando Gont > SI6 Networks > e-mail: [email protected] > PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 > > > _______________________________________________ OPSEC mailing list [email protected] https://www.ietf.org/mailman/listinfo/opsec
