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,
_______________________________________________
OPSEC mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/opsec
