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" ? (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? > 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! 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
