Subject: [RTG-DIR] RtgDir review: draft-ietf-opsec-vpn-leakages-02

From: Martin Vigoureux <[email-masked]>
Date: Thu, 5 Dec 2013 17:09:23 +0100

Hello,

I have been selected as the Routing Directorate reviewer for this draft. 
The Routing Directorate seeks to review all routing or routing-related 
drafts as they pass through IETF Last Call and IESG review, and 
sometimes on special request. The purpose of the review is to provide 
assistance to the Routing ADs. For more information about the Routing 
Directorate, please see http://www.ietf.org/iesg/directorate/routing.html

Although these comments are primarily for the use of the Routing ADs, it 
would be helpful if you could consider them along with any other IETF 
Last Call comments that you receive, and strive to resolve them through 
discussion or by updating the draft.

Document: draft-ietf-opsec-vpn-leakages-02
Reviewer: Martin Vigoureux
Review Date: 2013-12-05
IETF LC End Date: 2013-12-16
Intended Status: Informational

Summary:
This document is basically ready for publication, but has nits that 
should be considered prior to publication.

Comments:
This document is short, focussed, and well written.
However it is unclear, beyond that fact that users do not know that 
traffic is leaking from (rather not mapped onto) their VPN, what the 
real issue is. Yes, a man in the middle, might intercept the leaked 
traffic but this traffic is a priori intended to resources only 
accessible through the VPN. So, knowing that the leaked traffic will not 
reach the targeted destination, it is not clear which critical 
information it may carry. I believe that it would be worth giving an 
example.
Note that this relates to/extends a comment raised against 
draft-gont-opsec-vpn-leakages-00 but which was apparently not addressed.
http://www.ietf.org/mail-archive/web/opsec/current/msg01135.html

Minor Issues:
Abstract:
    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.
I believe this sentence does not exactly reflect the content of the 
document. For the first part, I think it is not only because of enabling 
IPv6 but because a site has both IPv4 and IPv6 support *and* a VPN 
client has poor capabilities in handling securely (i.e., mapping on the 
VPN) packets which use one of the two address families.
By the way this is said in section 4:
    the resulting VPN traffic leakage is a side-effect of employing
    IPv6-unaware VPN software in a dual-stacked host/network.

Thanks
-m

---

From: Warren Kumari <[email-masked]>
Date: Thu, 5 Dec 2013 14:49:09 -0500

> I have been selected as the Routing Directorate reviewer for this draft.

Just a quick note to say think you for the helpful review…

W

> The Routing Directorate seeks to review all routing or routing-related drafts as they pass through IETF Last Call and IESG review, and sometimes on special request. The purpose of the review is to provide assistance to the Routing ADs. For more information about the Routing Directorate, please see http://www.ietf.org/iesg/directorate/routing.html
> 
> Although these comments are primarily for the use of the Routing ADs, it would be helpful if you could consider them along with any other IETF Last Call comments that you receive, and strive to resolve them through discussion or by updating the draft.
> 
> This document is basically ready for publication, but has nits that should be considered prior to publication.
> 
> Comments:
> However it is unclear, beyond that fact that users do not know that traffic is leaking from (rather not mapped onto) their VPN, what the real issue is. Yes, a man in the middle, might intercept the leaked traffic but this traffic is a priori intended to resources only accessible through the VPN. So, knowing that the leaked traffic will not reach the targeted destination, it is not clear which critical information it may carry. I believe that it would be worth giving an example.
> Note that this relates to/extends a comment raised against draft-gont-opsec-vpn-leakages-00 but which was apparently not addressed.
> I believe this sentence does not exactly reflect the content of the document. For the first part, I think it is not only because of enabling IPv6 but because a site has both IPv4 and IPv6 support *and* a VPN client has poor capabilities in handling securely (i.e., mapping on the VPN) packets which use one of the two address families.

-- 
"Does Emacs have the Buddha nature? Why not? It has bloody well everything else..."

---

From: Fernando Gont <[email-masked]>
Date: Fri, 06 Dec 2013 14:02:10 -0300

Hi, Martin!

Thanks so much for your review! -- Please find my comments inline...

On 12/05/2013 01:09 PM, Martin Vigoureux wrote:
> accessible through the VPN.

The most basic scenario, as described in the I-D is this:
You attend a conference and tunnel everything through the VPN (for
security/privacy reasons). But then all your traffic goes in the clear...

The implications are that the user can now be monitored wrt which istes
he visits, etc., his location is leaked out, plaintext passwords come up
in the clear, MITM attacks become possible, etc.

> So, knowing that the leaked traffic will not

This is what we currently have in the I-D, as an example, in the intro:

---- cut here ----
   It is a very common practice for employees working at remote
   locations to establish a VPN connection with their office or home
   office.  This is typically done to gain access to some resources only
   available within the company's network, but also to secure the host's
   traffic against attackers that might be connected to the same remote
   location.  The same is true for mobile nodes that establish VPN
   connections to secure their traffic while they roam from one network
   to another.  In some scenarios, it is even assumed that employing a
   VPN connection makes the use of insecure protocols (e.g. that
   transfer sensitive information in the clear) acceptable, as the VPN
   provides security services (such as data integrity and/or
   confidentiality) for all communications made over the VPN.
---- cut here ----

Please let me know if you think this should be modified/augmented...
and, if possible, provide advice regarding "how" that should be done. :-)

> VPN) packets which use one of the two address families.

Would this modification address your comment?:

---- cut here ----
   This document discusses some scenarios in which such VPN leakages
   may occur as a result of employing IPv6-unaware software in networks
   that support IPv6 (either legitimately, or as a result of a
   deliberate attack from a local attacker).
---- cut here ----

Thanks!

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

---

From: Martin Vigoureux <[email-masked]>
Date: Mon, 9 Dec 2013 17:10:16 +0100

Fernando,

thanks for following up.

Your explanations clarify a lot, so I think these clarifications need to 
be brought to the draft. You are free not to take the suggested text as 
is, but I think you need to keep the objective.

I would start by clarifying the Abstract:
OLD:
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.
NEW:
That is, traffic meant to be transferred over a VPN connection may leak 
out of such connection and be sent in the clear on the local network 
towards the final destination.

OLD:
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.

NEW:
This document discusses some scenarios in which such VPN leakages may
occur as a result of employing IPv6-unaware VPN software.

Then I believe you need to rework the first paragraph of the 
Introduction to clearly and rapidly state your problem space rather than 
loosing the reader in the VPN-to-corporate-resources sink. This echoes 
the comment you also received from Lee and the original one from KK.

OLD:
    It is a very common practice for employees working at remote
    locations to establish a VPN connection with their office or home
    office.  This is typically done to gain access to some resources only
    available within the company's network, but also to secure the host's
    traffic against attackers that might be connected to the same remote
    location.  The same is true for mobile nodes that establish VPN
    connections to secure their traffic while they roam from one network
    to another.  In some scenarios, it is even assumed that employing a
    VPN connection makes the use of insecure protocols (e.g. that
    transfer sensitive information in the clear) acceptable, as the VPN
    provides security services (such as data integrity and/or
    confidentiality) for all communications made over the VPN.
NEW:
    It is a very common practice for users of a VPN software to
    establish a VPN connection towards a targeted endpoint when their
    terminal, which hosts the VPN software, is itself connected to a
    local network (e.g., a conference network). This is typically done
    to gain access to some resources which are otherwise not accessible,
    but also to secure the terminal's traffic through the local network
    (e.g., against attackers that might be connected to the same local
    network). The latter case constitute the problem space of this
    document. Indeed, it is sometimes assumed that employing a VPN
    connection makes the use of insecure protocols (e.g., that transfer
    sensitive information in the clear) acceptable, as a VPN provides
    security services (such as data integrity and/or confidentiality)
    for all communications made over that VPN. However, this document
    illustrates that under certain circumstances, some traffic might not
    be mapped onto the VPN and thus be sent in the clear on the local
    network.

-m