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