Subject: [OPSEC] draft-ietf-opsec-vpn-leakages proposed IESG note text.

From: joel jaeggli <[email-masked]>
Date: Sat, 21 Jun 2014 20:36:39 -0700

Folks,

After some roundabout attempts at clearing the discuss on
draft-ietf-opsec-vpn-leakages the following text has been proposed by
the IESG as a note on the document. It could proceed to the rfc editor
queue with this text in place.  We could also adjust the document
accordingly, however at this point, the current position is farily hard won.

Thoughts would be appreciated.

joel
---

This document describes a problem of information leakage in VPN software
and attributes that problem to the software's inability to deal with
IPv6. We do not think this is an appropriate characterization of the
problem. It is true that when a device supports more than one address
family, the inability to apply policy to more than one address family on
that device is a defect. Despite that, inadvertent or
maliciously-induced information leakage may also occur due to the
existence of any unencrypted interface allowed on the system, including
the configuration of split tunnels in the VPN software itself.  While
there are some attacks that are unique to an IPv6 interface, the sort of
information leakage described by this document is a general problem that
is not unique to the situation of IPv6-unaware VPN software. We do not
think this document sufficiently describes the general issue.

---

---

From: "Fred Baker (fred)" <[email-masked]>
Date: Sun, 22 Jun 2014 04:29:00 +0000

> think this document sufficiently describes the general issue.

I might suggest that this text say who “we” is. Clearly, those who wrote the draft, who might otherwise be described in the first person plural, must disagree with that assessment.

Personally, if the final sentence is the considered opinion of the IESG, I would rather not publish as an RFC - a permanent archival document - a description that the same RFC says is inadequate. I would rather that the IESG return the document to the working group and request a replacement that “sufficiently describes the general issue”.

---

From: Fernando Gont <[email-masked]>
Date: Sun, 22 Jun 2014 18:29:33 -0300

Hi, Joel,

Thanks so much for your efforts in this area.

Short version of my answer: "This is fine. Please go ahead and push
the document forward".

Long version of my answer:
This note is meant to reflect an IESG opinion, so I respect it as
such. I'd note that I don't know of any other case where the VPN
supports more than one address family that is not "IPv4 and IPv6"
("IPv4 and OSI"?). Additionally, if the "leak" occurs because of a
split tunnel, then that's not a leak, but rather the result of an
explicit decision (the split policy established by the administrator).
But I'm fine with having different views on the topic.

Thanks,
Fernando

On 06/22/2014 12:36 AM, joel jaeggli wrote:
> joel ---
> This document describes a problem of information leakage in VPN
> software and attributes that problem to the software's inability to
> deal with IPv6. We do not think this is an appropriate
> characterization of the problem. It is true that when a device
> supports more than one address family, the inability to apply
> policy to more than one address family on that device is a defect.
> Despite that, inadvertent or maliciously-induced information
> leakage may also occur due to the existence of any unencrypted
> interface allowed on the system, including the configuration of
> split tunnels in the VPN software itself.

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

---

From: joel jaeggli <[email-masked]>
Date: Mon, 30 Jun 2014 09:31:54 -0700

> Personally, if the final sentence is the considered opinion of the IESG, I would rather not publish as an RFC - a permanent archival document - a description that the same RFC says is inadequate. I…
I would hold that option out to the w.g. and the authors, Though I don't
personally think the effort to produce a document for the purpose
satisfying the IESG as a particularly worthy goal. So if the sentiment
(which as I interpret it as being the case) is that the document in
present form adresses a real problem and that it should be dealt with in
a discrete fashion rather than rolled up with the generic problem of
split tunneling then I can live with myself.

---

From: Fernando Gont <[email-masked]>
Date: Mon, 30 Jun 2014 17:44:16 -0300

On 06/30/2014 01:31 PM, joel jaeggli wrote:
>> 
>> Personally, if the final sentence is the considered opinion of
>> the IESG, I would rather not publish as an RFC - a permanent
>> archival document - a description that the same RFC says is
>> inadequate. I would rather that the IESG return the document to
>> the working group and request a replacement that “sufficiently
>> describes the general issue”.
> I would hold that option out to the w.g. and the authors, Though I 
> don't personally think the effort to produce a document for the 
> purpose satisfying the IESG as a particularly worthy goal. So if
> the sentiment (which as I interpret it as being the case) is that
> the document in present form adresses a real problem and that it
> should be dealt with in a discrete fashion rather than rolled up
> with the generic problem of split tunneling then I can live with
> myself.

Agreed. This point has been made a number of times already on the
mailing-list (and off-list too).

That aside, the argument of "this being a specific case of split
tunelling" has been argued against both on and off-list. This post
summarizes the issue pretty well, I think:
<http://www.ietf.org/mail-archive/web/opsec/current/msg01565.html>
(and comes with the "extra" of someone working on VPN code).

But at this point in time I can live with the IESG note, if that's
what it takes.

Thanks,