Subject: [OPSEC] Last Call: <draft-ietf-opsec-vpn-leakages-02.txt> (Virtual Private Network (VPN) traffic leakages in dual-stack hosts/ networks) to Informational RFC

From: The IESG <[email-masked]>
Date: Mon, 02 Dec 2013 04:53:48 -0800

The IESG has received a request from the Operational Security
Capabilities for IP Network Infrastructure WG (opsec) to consider the
following document:
- 'Virtual Private Network (VPN) traffic leakages in dual-stack hosts/
   networks'
  <draft-ietf-opsec-vpn-leakages-02.txt> as Informational RFC

The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action. Please send substantive comments to the
[email-masked] mailing lists by 2013-12-16. Exceptionally, comments may be
sent to [email-masked] instead. In either case, please retain the
beginning of the Subject line to allow automated sorting.

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) products, may inadvertently
   result in VPN traffic leaks.  That is, traffic meant to be
   transferred over a VPN connection may leak out of such connection and
   be transferred in the clear from the local network to the final
   destination.  This document discusses some scenarios in which such
   VPN leakages may occur, either as a side effect of enabling IPv6 on a
   local network, or as a result of a deliberate attack from a local
   attacker.  Additionally, it discusses possible mitigations for the
   aforementioned issue.

The file can be obtained via
http://datatracker.ietf.org/doc/draft-ietf-opsec-vpn-leakages/

IESG discussion can be tracked via
http://datatracker.ietf.org/doc/draft-ietf-opsec-vpn-leakages/ballot/

No IPR declarations have been submitted directly on this I-D.

---

From: "Carlos Pignataro (cpignata)" <[email-masked]>
Date: Mon, 16 Dec 2013 20:20:37 +0000

Apologies for the lateness of these two small comments, and if it has been made before --

Looking only at the title and first sentence of the Abstract:

--->8---
  Virtual Private Network (VPN) traffic leakages in dual-stack hosts/networks

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) products, may inadvertently
   result in VPN traffic leaks.
--->8---

I have one concern and one small comment:

First, "VPN" is a pseudo-technical term, or a meta-term. If I understand, this document refers to a very narrow slice of "VPNs" (not to L1VPNs, not to L2VPNs, not to MP-BGP/MPLS IP VPNs, not to...). The document seems to be (only?) focusing on client/concentrator VPNs, and within these ones the IPsec ones. Can we make this very explicit in the 1. title, 2. abstract, and even 3. a formal definition of scope?

Second, are these "leakages" if the packets are not destined to go in the tunnel? I guess if the "traffic" (i.e., payload) is not sent on the IPsec tunnel, then it is leaked. But it is a bit borderline...

The second is not a big deal, the first one is, IMHO.

Thanks,

-- Carlos.

On Dec 2, 2013, at 7:53 AM, The IESG <[email-masked]> wrote:

> _______________________________________________
> OPSEC mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/opsec

---

From: Fernando Gont <[email-masked]>
Date: Sun, 22 Dec 2013 02:56:31 -0300

Hola, Carlos,

Thanks so much for your feedback! Please find my responses in-line...

On 12/16/2013 05:20 PM, Carlos Pignataro (cpignata) wrote:
> --->8--- Virtual Private Network (VPN) traffic leakages in
> dual-stack hosts/networks
> 
> Abstract
> 
>  result in VPN traffic leaks. --->8---
> 
> First, "VPN" is a pseudo-technical term, or a meta-term. If I 
> understand, this document refers to a very narrow slice of "VPNs" 
> (not to L1VPNs, not to L2VPNs, not to MP-BGP/MPLS IP VPNs, not 
> to...). The document seems to be (only?) focusing on 
> client/concentrator VPNs, and within these ones the IPsec ones.
> Can we make this very explicit in the 1. title, 2. abstract, and
> even 3. a formal definition of scope?

I'm currently working on a "Terminology" section which describes what
we mean by "VPN".

Regarding the title... I'm not sure it's easy to come up with
something simple that makes this clear (particularly when, as you
correctly state, "VPN" is kind of a meta-term)... Do you have any
suggestions for some alternative title?

wrt to the Abstract, how about changing it to:

---- cut here ----
   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 SSL-based or IPsec-based Virtual Private Network (VPN)
   products, may inadvertently result in VPN traffic leaks.
[...]
---- cut here ----

?

I realize that this might still be a bit unclear, though. If you have
any suggestions, please do let me know.

> Second, are these "leakages" if the packets are not destined to go
> in the tunnel? I guess if the "traffic" (i.e., payload) is not sent
> on the IPsec tunnel, then it is leaked. But it is a bit
> borderline...

We deem it as a "leakage" when traffic to some destination is expected
to go through the VPN, but doesn't. Trivial example: You employ e.g.
OpenVPN to send all your traffic through some VPN gateway (e.g., some
box at you office or home), but then connect to a dual-stacked
network. If the destination is IPv6-enabled, your traffic will leak
out of your VPN inadvertently.

Thoughts?

Thanks!

Best regards,
-- 
Fernando Gont
SI6 Networks
e-mail: [email-masked]
PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492

---

From: "Carlos Pignataro (cpignata)" <[email-masked]>
Date: Sun, 22 Dec 2013 19:21:14 +0000

Hola, Fernando!

>Thanks so much for your feedback! Please find my responses in-line...

AnytimeŠ please see inline.

>I'm currently working on a "Terminology" section which describes what

This is a good start.

>suggestions for some alternative title?

I think that, for the title, saying ³VPN traffic leakages² is too generic
to be accurate, and you need to qualify ³VPN².

The document seems to hint at the type of VPNs in scope. Although this
would be more clear after the terminology section, basically the document
covers VPNs that are:
1. Hub-and-Spoke (I.e., client-based in a client-gateway model) VPNs, as
opposed to Mesh VPNs (MPLS BGP VPNs).
2. Encryption-based VPNs (given the mentions of ³in the clear²), as
opposed to simply tunneling.

This is similar to the Cisco AnyConnect software client in my mac.

Based on this, ³Client-based encryption-based VPNs²?

Again, maybe it will be more clear after the terminology section.

>   products, may inadvertently result in VPN traffic leaks.

I think this covers one of the qualities (SSL-based or IPsec-based) but
not the other (client-based vs. full mesh).

>any suggestions, please do let me know.

I do think it¹s better, but not quite there yet.

>out of your VPN inadvertently.

I agree with your perspective. Although it can be argued both ways, I do
think it is totally fair to call it a leakage in this case.

Thanks,

‹ Carlos.

---

From: Fernando Gont <[email-masked]>
Date: Sun, 22 Dec 2013 16:51:07 -0300

>> I'm currently working on a "Terminology" section which describes what

FWIW, this is what we hae at the time of this writing (still subject to
comments and edits);

---- cut here ----
   When employing the term VPN (or its acronym, "VPN"), this document
   refers to IPsec-based or TLS-based tunnels, where traffic is
   encapsulated and sent from a client to a middle-box, to access
   multiple network services (potentially emplying different transport
   and/or application protocols).

   Our use of the term "Virtual Private Networks" excludes the so-called
   SSL/TLS VPN portals (a front-end provided by the middlebox to add
   security to a normally-unsecured site).  Further discussion of SSL-
   based VPNs can be found in [SSL-VPNs].

   We note that, in addition to the general case of "send all traffic
   through the VPN", this document additionally considers the so-called
   "split-tunnel" case, where some subset of the traffic is sent through
   the VPN, while other traffic is send to its intended destination with
   a direct routing path (i.e., without employing the VPN tunnel).  We
   note that many organizations will prevent split-tunneling in their
   VPN configurations if they would like to make sure the users data
   goes through a gateway with protections (malware detection, URL
   filtering, etc.), but others are more interested in performance of
   the user's access or the ability for researchers to have options to
   access sites they may not be able to through the gateway.
---- cut here ----

Where:

   [SSL-VPNs]
              Hoffman, P., "SSL VPNs: An IETF Perspective",  IETF 72,
              SAAG Meeting., 2008,
              <http://www.ietf.org/proceedings/72/slides/saag-4.pdf>.

> to be accurate, and you need to qualify ³VPN².

Is that possible in a one-liner?

> opposed to simply tunneling.

Please see if the above text clarifies this point.

> Based on this, ³Client-based encryption-based VPNs²?

Client-based would seem to still lead to ambiguity. Also, some parts of
the I-D notes that some VPNs may not employ encryption 8even when for
the most part we focus on VPNs that do encryption).

My take is that one way or another we'll ahve to live with a generic
title which makes sense when one defines the terminology... thoughts?

> not the other (client-based vs. full mesh).

How about "...popular client-based (whether SSL or IPsec) Virtual
Private Network..."?  -- Although I'd like to check with Paul Hoffman et
al before applying...

Further suggestions welcome ;-)

Thanks!

Best regards,

---

From: "Carlos Pignataro (cpignata)" <[email-masked]>
Date: Sun, 22 Dec 2013 20:54:21 +0000

Thanks Fernando. Please see inline.

>   and/or application protocols).

I do not think this is the best approach. Here you are saying: “when we
say VPN we actually mean this, so we will make statements about VPNs”.
Instead, I’d suggest the more precise approach is to say “in this document
we consider Foobar VPNs, so we will make statements about Foobar VPNs”
(where Foobar is a modifier/qualifier of VPN, defined in the document).

>   based VPNs can be found in [SSL-VPNs].

Additionally, this talks about a specific view from the user (it is not a
provider provisioned VPN for example). So I’d define what it is and not
what it is not.

>Is that possible in a one-liner?

It is necessary, in a one- or two-liner.

>Please see if the above text clarifies this point.

I think it doesn’t.

The IETF has defined terminology and taxonomy for VPNs. For example:
http://tools.ietf.org/html/rfc2764
http://tools.ietf.org/html/rfc3809
http://tools.ietf.org/html/rfc4026 for PP-VPNs, esp. S. 3, 3.10, 4
http://tools.ietf.org/html/rfc4110#section-1.5

And as you acknowledge it is a meta term (and an overused one); I’d talk
about Foobar-VPNs, with narrow definitions.

>the most part we focus on VPNs that do encryption).

I agree client-based is not ideal ― esp. when there’s clientless SSL VPNs
that might fit your scope.

>title which makes sense when one defines the terminology... thoughts?

My experience is that the use of qualifiers helps and is a best practice.
L3VPNs, L2VPNs, PPVPNs, IPsec-VPNs, etc. I’d prefer following the same
model here, even when you might have to define a new term.

>Private Network..."?  -- Although I'd like to check with Paul Hoffman et

In my opinion, that is better than saying “popular VPNs”. That does
exclude L2TP, PPTP, etc., although those are potentially subject to the
same vulnerabilities described in the doc.

Thanks,

― Carlos.

---

From: Fernando Gont <[email-masked]>
Date: Sun, 22 Dec 2013 18:06:30 -0300

Hi, Carlos,

> (where Foobar is a modifier/qualifier of VPN, defined in the document).

If you know of such modifier/qualifier, I'd like to know -- particularly
if it's a one/two word thing that will not result in cumbersome text
throughout the document.

Besides, at the end of the day, foobar VPN would still be one definition
of ours, so... I'm not sure that would make the text any more precise
(as long as the terminoogy is clarified up frnt, as with a "Terminology"
section).

> provider provisioned VPN for example). So I’d define what it is and not

Not sure what you mean.

> It is necessary, in a one- or two-liner.

So far we have tried to do that with the terminology Section -- and I
doubt that can be clearly one with a one liner. But if you have any
suggestions, I'm all ears.

> about Foobar-VPNs, with narrow definitions.

I'll check the references, and will also let others weigh in.

Thanks,

---

From: "Carlos Pignataro (cpignata)" <[email-masked]>
Date: Sun, 22 Dec 2013 23:06:08 +0000

Fernando,

> (as long as the terminoogy is clarified up frnt, as with a "Terminology"

I proposed a couple, I think they are better than nothing but certainly not great. Perhaps a potentially good one is hub-and-spoke (like in the softwires terminology, as I understand you are talking always about cases with a VPN Concentrator (hub), and the vulnerability in the (software) clients (spokes)).

In any case, my main point is that saying "VPN leakages in dual-stack networks" is not correct, as it overgeneralizes.

And I think that "foobar VPN" is much better than "VPN", provided that "foobar" is defined in the document. It's OK to create a new term if it is needed and none exists.

> suggestions, I'm all ears.

See above (although you'd need to be "all eyes" or use a text-to-speach interface :-)

Net-net -- given the number of different types of VPNs, if the leakage does not apply to all (or even most) of them, I still think that technically the title/abstract/doc needs to narrow scope.

> I'll check the references, and will also let others weigh in.

Sounds good -- thanks.

Carlos Pignataro.

---

From: Paul Hoffman <[email-masked]>
Date: Sun, 22 Dec 2013 19:11:14 -0800

The VPN Consortium (www.vpnc.org) differentiates between the two large
categories as "secure VPNs" and "trusted VPNs". So, if the WG thinks it is
important to make this change in the title, adding "secure" might be it.
However, the new terminology section is certainly needed as well.

--Paul Hoffman