Last Call Review of draft-ietf-opsec-vpn-leakages-02
review-ietf-opsec-vpn-leakages-02-secdir-lc-moriarty-2013-12-12-00

Request Review of draft-ietf-opsec-vpn-leakages
Requested rev. no specific revision (document currently at 06)
Type Last Call Review
Team Security Area Directorate (secdir)
Deadline 2013-12-16
Requested 2013-12-05
Draft 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
Review review-ietf-opsec-vpn-leakages-02-secdir-lc-moriarty-2013-12-12
Reviewed rev. 02 (document currently at 06)
Review result Has Issues
Review completed: 2013-12-12

Review
review-ietf-opsec-vpn-leakages-02-secdir-lc-moriarty-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,
Kathleen