Hi, I do not think that "L3 VPN" appropriately qualifies the type of "VPN Leakages" described in this document. It seems to me that "split tunnel AF bug" describes it better. One definition of "L3VPN" is at https://tools.ietf.org/html/rfc4031#section-3.1
It would also be interesting to ask the L3VPN WG about it. Please find a couple more comments inline on the Abstract. On Apr 24, 2014, at 6:11 AM, [email protected] wrote: > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > This draft is a work item of the Operational Security Capabilities for IP > Network Infrastructure Working Group of the IETF. > > Title : Layer-3 Virtual Private Network (VPN) tunnel traffic > leakages in dual- stack hosts/networks > Author : Fernando Gont > Filename : draft-ietf-opsec-vpn-leakages-05.txt > Pages : 10 > Date : 2014-04-24 > > Abstract: > The subtle way in which the IPv6 and IPv4 protocols co-exist in > typical networks, together with the lack of proper IPv6 support in > popular Virtual Private Network (VPN) tunnel products, may I believe that "lack of proper IPv6 support in popular VPN tunnel products" needs to be either substantiated or dropped. Also, it's not clear to me what is "proper support" versus (perhaps) "improper support". > inadvertently result in VPN tunnel traffic leaks. That is, traffic > meant to be transferred over an encrypted and integrity protected VPN > tunnel The title says "L3VPN Tunnels", but in general L3VPN Tunnels do not imply encryption. IP-in-IP, GRE, and L2TPv3 can create L3VPN tunnels without encryption or integrity protection. > may leak out of such tunnel and be sent in the clear on the > local network towards the final destination. This document discusses > some scenarios in which such VPN tunnel traffic leakages may occur as > a result of employing IPv6-unaware VPN software. This paragraph seems closer to describing the actual problem: "IPv6 unaware tunnel encapsulation" -- it seems to me that this is not a "VPN" problem. Lastly, please note that there are instances where the demultiplexing of IPv6 from IPv4 before tunnel encapsulation is a deliberate action: http://www.cisco.com/c/en/us/td/docs/ios/12_0s/feature/guide/l2tpv29s.html#wp1276833 Thanks, Carlos. > Additionally, this > document offers possible mitigations for this issue. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-opsec-vpn-leakages/ > > There's also a htmlized version available at: > http://tools.ietf.org/html/draft-ietf-opsec-vpn-leakages-05 > > A diff from the previous version is available at: > http://www.ietf.org/rfcdiff?url2=draft-ietf-opsec-vpn-leakages-05 > > > Please note that it may take a couple of minutes from the time of submission > until the htmlized version and diff are available at tools.ietf.org. > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > _______________________________________________ > OPSEC mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/opsec _______________________________________________ OPSEC mailing list [email protected] https://www.ietf.org/mailman/listinfo/opsec
