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

Request Review of draft-ietf-opsec-vpn-leakages
Requested rev. no specific revision (document currently at 06)
Type Last Call Review
Team Ops Directorate (opsdir)
Deadline 2014-02-18
Requested 2013-12-02
Authors Fernando Gont
Draft last updated 2014-02-16
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 Dan Romascanu 
State Completed
Review review-ietf-opsec-vpn-leakages-02-opsdir-lc-romascanu-2014-02-16
Reviewed rev. 02 (document currently at 06)
Review result Has Nits
Review completed: 2014-02-16



I am the assigned OPS-DIR reviewer for draft-ietf-opsec-vpn-leakages-02. The OPS-DIR review have as principal goal helping the OPS ADs in their evaluation and balloting of documents at IESG reviews. Please consider these comments together with the other IETF Last Call comments. 

This document is ready but it can be improved with some extra test and editorial clarifications as mentioned below. 

This document is very useful from an operational point of view as it draws the attention of operators about the consequences of the interaction at deployment between dual-stacked hosts and non-IPv6-aware VPNs which have as consequences leakages of non-secured IPv6 traffic. It explains clearly the source of the problem, as well as one (radical) way of mitigation. 

The following questions from Annex A.1 of RFC 5706 apply: 

5.  Has the impact on network operation been discussed?  See
       Section 2.5.

       *  How will the new protocol impact the behavior of other
          protocols in the network?  Will it impact performance (e.g.,
          jitter) of certain types of applications running in the same

The document practically proposes only one solution of mitigation - disabling IPv6 functionality of dual-stacked hosts which connect to VPN servers using a non-IPv6-aware (IPv4-only) VPN. This is actually a very radical impact on the behavior of other protocols in the network which slows the deployment and usage of IPv6. I believe that at least one more recommendation needs to be added - try to look for another VPN solution with IPv6 functionality. Maybe the IPv4-only functionality results from the usage of an older version of the VPN software - ask if a new version with IPv6 support is available, and in case it is not press the vendor to provide one as soon as possible. 

   9.  Is configuration discussed?  See Section 3.4.

       *  Are configuration defaults and default modes of operation

Are dual-stacked hosts deployed with both IPv4 and IPv6 stacks enabled? Is there room taking into account the security threat described in this document and the current status of IPv6 deployment to issue a recommendation that IPv6 functionality should be disabled by default? Just asking. 

A couple of editorial comments: 

1. The last paragraph of the Introduction stops at Section 5 with the description of the relevant sections in the document, leaving out exactly Section 6 which is the most important for the operators because it contains the recommendations for mitigation. 

2. Section 2, Section 5, Section 6 have paragraphs with internal indentation. I *think* that the intention is to point to the fact that the information in these paragraphs is kind of supplementary, bringing clarification to the core text. This is not clear however as this is not a commonly accepted convention in RFCs and readers may just ignore it, or consider this an editorial bug. If my guess is correct I suggest to explain the convention in the Introduction.