Subject: [OPSEC] draft-ietf-opsec-vpn-leakages - clarifying questions from the IESG.

From: joel jaeggli <[email-masked]>
Date: Sun, 23 Mar 2014 07:57:11 -0700

Hi,

I hope that you folks are recovering well from IETF meeting related
excesses and accompanying travel.

Some questions came up in the IESG review of the document that are more
appropriately answered by the working group rather than by me attempting
to channel you folks.

https://datatracker.ietf.org/doc/draft-ietf-opsec-vpn-leakages/

1. Does the working-group view view disabling IPV6 in deployed equipment
due to operational necessity as a desirable outcome.

2. Does the working-group characterize the problem of vpn leakages
captured in this document as being distinct from the problems posed by
split-tunnels in general.

Your thoughts would be appreciated.
joel

---

From: "Carlos Pignataro (cpignata)" <[email-masked]>
Date: Sun, 23 Mar 2014 17:39:51 +0000

Joel, Warren (as shepherd),

In addition to some responses below, it appears that my review comments sent to opsec are yet to be addressed:
http://www.ietf.org/mail-archive/web/opsec/current/msg01477.html
	"The only remaining bit is the issue raised by Carlos which we'll
	hopefully address in the next rev."
http://www.ietf.org/mail-archive/web/opsec/current/msg01447.html

It seems the remaining bit is still remaining. Frankly, I am still concerned that this doc still refers to "VPN Leakages" while its applicability and scope is a small subset of "VPNs".

More inline.

> due to operational necessity as a desirable outcome.

My personal view is "No". That would be a step backwards in deploying IPv6.

> split-tunnels in general.

I do not think it is different. Rather, this is one instantiation of a more general problem.

Thanks,

-- Carlos.

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

---

From: "George, Wes" <[email-masked]>
Date: Mon, 24 Mar 2014 14:30:12 -0400

>due to operational necessity as a desirable outcome.

Well, I think the answer there is no. I know we added a good bit of text
to 7123 to make it clearer that we were writing this for completeness’
sake, not to advocate disabling IPv6 as an outcome.

Wes

This E-mail and any of its attachments may contain Time Warner Cable proprietary information, which is privileged, confidential, or subject to copyright belonging to Time Warner Cable. This E-mail is intended solely for the use of the individual or entity to which it is addressed. If you are not the intended recipient of this E-mail, you are hereby notified that any dissemination, distribution, copying, or action taken in relation to the contents of and attachments to this E-mail is strictly prohibited and may be unlawful. If you have received this E-mail in error, please notify the sender immediately and permanently delete the original and any copy of this E-mail and any printout.

---

From: Fernando Gont <[email-masked]>
Date: Tue, 25 Mar 2014 17:49:36 +0000

Hi, Joel,

On 03/23/2014 02:57 PM, joel jaeggli wrote:
> 1. Does the working-group view view disabling IPV6 in deployed
> equipment due to operational necessity as a desirable outcome.

This should not be characterized as a "desired outcome". The document
describes a problem, and discusses possible mitigations. It never says
or suggests that this is the desired outcome -- if anything, just a
possible "last resort" scenario.

For instance, this is what the document says:

   "While the desired mitigation for the issues discussed in this
   document is for VPN clients to be IPv6-aware, we note that in
   scenarios where this would be unfeasible, and administrator may want
   to disable IPv6 connectivity on all network interfaces of the node
   employing the IPv6-unaware VPN client."

As a guy that both normally employs IPv6 and that also employs an
IPv6-unaware client (OpenVPN), I face this problem very frequently.

What I usually do is that, whenever I really mean to employ my VPN
client, I resort to disabling IPv6. This is certainly not a desired
outcome... but a tradeoff between "having my taffic sent out in the
clear when I mean it to be encrypted" and "employing IPv6".

The desired outcome (albeit noted in the I-D) is that VPN clients
successfully support IPv6. But at times this not under the control of
the folk employing the VPN client.

> captured in this document as being distinct from the problems posed
> by split-tunnels in general.

The problem is different because this problem arises from a (usually
overseen) interaction between the two protocols (which are usually
assumed to be separate worlds).

FWIW, this wan not only discussed in opsec, but we also presented this
document in at the ipsecme wg.

Thanks!

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

---

From: Tina TSOU <[email-masked]>
Date: Sat, 29 Mar 2014 07:19:02 +0000

Dear Joel et al,

For question 1,

This document does not describe disabling IPv6 as a desired outcome, but rather notes that in some scenarios, it might be the only option left to mitigate VPN leakages.

Thank you,
Tina

-----Original Message-----
From: OPSEC [mailto:[email-masked]] On Behalf Of joel jaeggli
Sent: Sunday, March 23, 2014 10:57 PM
To: [email-masked]; [email-masked]; opsec chairs
Subject: [OPSEC] draft-ietf-opsec-vpn-leakages - clarifying questions from the IESG.

Hi,

I hope that you folks are recovering well from IETF meeting related excesses and accompanying travel.

Some questions came up in the IESG review of the document that are more appropriately answered by the working group rather than by me attempting to channel you folks.

1. Does the working-group view view disabling IPV6 in deployed equipment due to operational necessity as a desirable outcome.

2. Does the working-group characterize the problem of vpn leakages captured in this document as being distinct from the problems posed by split-tunnels in general.

---

From: joel jaeggli <[email-masked]>
Date: Sat, 29 Mar 2014 07:26:49 -0700

On 3/23/14, 10:39 AM, Carlos Pignataro (cpignata) wrote:
> In addition to some responses below, it appears that my review
> comments sent to opsec are yet to be addressed: 
> http://www.ietf.org/mail-archive/web/opsec/current/msg01477.html "The
> only remaining bit is the issue raised by Carlos which we'll 
> It seems the remaining bit is still remaining. Frankly, I am still
> concerned that this doc still refers to "VPN Leakages" while its
> applicability and scope is a small subset of "VPNs".

the problem I take it with respect to aplicability is that the draft
targets a narrow subset of vpns. The problem of exposure via split
tunnels  or in fact multi-interface issues is covers a whole range of
issues, some of which are deliberate, some accidental or in this case
inadvertent.

>> I hope that you folks are recovering well from IETF meeting
>> related excesses and accompanying travel.
>> 
>> Some questions came up in the IESG review of the document that are
>> more appropriately answered by the working group rather than by me
>> attempting to channel you folks.
>> 
>> Your thoughts would be appreciated. joel
>> 
>> 
>> _______________________________________________ OPSEC mailing list 
>> [email-masked] https://www.ietf.org/mailman/listinfo/opsec
>

---

From: Gert Doering <[email-masked]>
Date: Sat, 29 Mar 2014 17:19:07 +0100

Hi,

> issues, some of which are deliberate, some accidental or in this case

Well, one could argue that for the case of split tunnels, this is a
deliberate decision by the admin setting this up.  For v4/v6 "split",
it might not be a conscious decision, but a lack of proper software
support - and in any case, I find it useful to raise awareness about
this problem.

Actually, looking at this from a different angle, namely that of a 
developer of such VPN software, it's surprisingly difficult to make 
"full tunneling" work with IPv6 in a hostile network - if you do not 
want to go to "make a kernel module that overrides any routing decision 
at lowest level", but take the portable approach OpenVPN does ("install 
routes to a 'tun' interface, which hands the packet to userland for 
encryption and forwarding"), it is really really hard to ensure that 
*all* packets go into the tunnel, and nobody installs extra routes 
via RA+PIO or RIO behind your back, siphoning off traffic to those
destinations.

In a portable way across 7 unix platforms and 3 windows variants.

Gert Doering
        -- NetMaster
-- 
have you enabled IPv6 on something today...?

SpaceNet AG                        Vorstand: Sebastian v. Bomhard
Joseph-Dollinger-Bogen 14          Aufsichtsratsvors.: A. Grundner-Culemann
D-80807 Muenchen                   HRB: 136055 (AG Muenchen)
Tel: +49 (0)89/32356-444           USt-IdNr.: DE813185279

---

From: Fernando Gont <[email-masked]>
Date: Sat, 29 Mar 2014 20:43:41 -0300

Joel,

On 03/29/2014 11:26 AM, joel jaeggli wrote:
>> It seems the remaining bit is still remaining. Frankly, I am
>> still concerned that this doc still refers to "VPN Leakages"
>> while its applicability and scope is a small subset of "VPNs".
> 
> the problem I take it with respect to aplicability is that the
> draft targets a narrow subset of vpns. The problem of exposure via
> split tunnels  or in fact multi-interface issues is covers a whole
> range of issues, some of which are deliberate, some accidental or
> in this case inadvertent.

As noted by Gert and myself, this document raises awareness about a
specific (yet common) problem scenario where, as a result of the
interactions between IPv4 and IPv6, your traffic may (either
deliberately or inadvertently) leak out of your VPN software.

This problem has affected (and in some cases "is still affecting")
products from vendors (Cisco, Juniper, OpenVPN, etc.).

The solution, as noted by Gert, is non-trivial. Raising awareness of
this issue has led a number of folks (including vendors) from at least
paying attention and consider doing something about this. And, at the
same time, for folks employing the said VPN software to be aware of
these issues.

This kind of thing
<http://marc.info/?l=openbsd-cvs&m=135420170107687&w=2> should be an
indication of why the document is important.

Thanks!

Cheers,

---

From: joel jaeggli <[email-masked]>
Date: Sun, 30 Mar 2014 09:37:32 -0700

wrapping up.

> due to operational necessity as a desirable outcome.

Feedback I heard was.

Not desirable, sometimes necessary.

Dovetails with 7123 advice.

Tweak the applicability/language so it probably represents the subset of
 vpns to which this applies.

As a vpn developer it is in fact hard to prevent route inject even in
the v6 supporting case.

> split-tunnels in general.

With respect to the deliberate of the choice yes.  as a distinct class
of problem no, also applies to v6 supporting vpn applications used
deliberately.

> Your thoughts would be appreciated.

Thanks, this is information that I can use with the IESG.