Subject: [OPSEC] I-D Action: draft-ietf-opsec-vpn-leakages-05.txt

From: [email-masked]
Date: Thu, 24 Apr 2014 03:11:16 -0700

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
   inadvertently result in VPN tunnel traffic leaks.  That is, traffic
   meant to be transferred over an encrypted and integrity protected VPN
   tunnel 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.  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/

---

From: "Carlos Pignataro (cpignata)" <[email-masked]>
Date: Sat, 26 Apr 2014 16:44:33 +0000

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.

>   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".

>   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
>   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
> _______________________________________________
> OPSEC mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/opsec

---

From: joel jaeggli <[email-masked]>
Date: Sat, 26 Apr 2014 09:51:15 -0700

> 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) "improp…

I disagree and i think the comments from present and past implementers
(myself included) corroborate this assertion. naming specific products
doesn't actually serve a useful purpose.

---

From: "Carlos Pignataro (cpignata)" <[email-masked]>
Date: Sat, 26 Apr 2014 16:59:32 +0000

> doesn't actually serve a useful purpose.

My point is that the comments on broken implementations relate to a subset of the universe of "VPN Products". My understanding is that these relate to software-based "VPN client endpoints" (happy to be corrected otherwise) but *not* to the many other types of "VPN products".

I agree that naming specific products is not helpful at all. That was not my suggestion. But, implying that this problem exists generally in "VPN products" does not help either. Are you aware of this bug present in *any* RFC 4364 L3VPN?

I still think that the title and abstract are overly-scoped, and more precision in definition will help the document.

Thanks,

Carlos.