Last Call Review of draft-ietf-opsec-vpn-leakages-02
review-ietf-opsec-vpn-leakages-02-opsdir-lc-romascanu-2014-02-16-00

Hi,

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
          network?

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
          considered?

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.

Regards,

Dan