Skip to main content

Last Call Review of draft-ietf-opsec-vpn-leakages-02

Request Review of draft-ietf-opsec-vpn-leakages
Requested revision No specific revision (document currently at 06)
Type Last Call Review
Team Security Area Directorate (secdir)
Deadline 2013-12-16
Requested 2013-12-05
Authors Fernando Gont
I-D last updated 2013-12-12
Completed reviews Genart Last Call review of -02 by Russ Housley (diff)
Genart Telechat review of -03 by Russ Housley (diff)
Genart Telechat review of -04 by Russ Housley (diff)
Secdir Last Call review of -02 by Kathleen Moriarty (diff)
Opsdir Last Call review of -02 by Dan Romascanu (diff)
Assignment Reviewer Kathleen Moriarty
State Completed
Request Last Call review on draft-ietf-opsec-vpn-leakages by Security Area Directorate Assigned
Reviewed revision 02 (document currently at 06)
Result Has issues
Completed 2013-12-12
I have reviewed this document as part of the security directorate's
ongoing effort to review all IETF documents being processed by the
IESG.  These comments were written primarily for the benefit of the
security area directors.  Document editors and WG chairs should treat
these comments just like any other last call comments.

The document is almost ready for publication, but could benefit from proving
better descriptions in the introduction of the work.  The Security
Considerations probably has the most crisp statement of the draft purpose.

The reference to VPN, never distinguishes if the document is referring to an
IPSec or TLS VPN.  I suspect IPSec from the document, but making this clear
would be helpful to the reader.  TLS has become popular when providing
restricted access and may be just an encrypted session to a particular service
as opposed to a full VPN with routed traffic using IPSec.  Unfortunately,
language has blurred here, mostly because of marketing, so clarity would be
helpful to avoid possible confusion for the reader.

I would recommend introducing the comparison of slit-tunneling earlier in the
document as this is a similar issue (IPv6 getting routed separately from the
VPN traffic), although split-tunneling is an intentional configuration option.

Is the draft intended for developers/implementers or operational teams/VPN
users -- or both?  The proposed fixes could be done by the VPN software or
operators could disable interfaces, the former would obviously be preferred and
the abstract mentions products, so you may want to repeat that preference later
in the document.

Thank you,