Hi, Cameron, Please let me know your thoughts about my comments below, such that I can rev the I-D accordingly.
Thanks! Best regards, Fernando On 10/27/2012 08:28 PM, Fernando Gont 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" > ? > > (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
