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

From: Martin Vigoureux <[email-masked]>
Date: Mon, 27 Jan 2014 14:40:56 +0100

Fernando,

I see you have published a new version of your draft.

I would have appreciated a reply to my e-mail below, at least stating 
why you believe the text you suggested me to provide you with was, in 
the end, not satisfactory.

-m

Le 09/12/2013 17:10, Martin Vigoureux a écrit :
> 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
>
> Le 06/12/2013 18:02, Fernando Gont a écrit :
>> Hi, Martin!
>>
>> Thanks so much for your review! -- Please find my comments inline...
>>
>> On 12/05/2013 01:09 PM, Martin Vigoureux wrote:
>>> 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.
>>
>> 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
>>> reach the targeted destination, it is not clear which critical
>>> information it may carry. I believe that it would be worth giving an
>>> example.
>>
>> 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. :-)
>>
>>
>>
>>> 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.
>>
>> 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,
>>
>
>