[secdir] Secdir last call review of draft-ietf-v6ops-transition-ipv4aas-11

Christian Huitema <huitema@huitema.net> Thu, 13 December 2018 20:49 UTC

Return-Path: <huitema@huitema.net>
X-Original-To: secdir@ietf.org
Delivered-To: secdir@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 901AC130E9B; Thu, 13 Dec 2018 12:49:36 -0800 (PST)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: Christian Huitema <huitema@huitema.net>
To: <secdir@ietf.org>
Cc: v6ops@ietf.org, ietf@ietf.org, draft-ietf-v6ops-transition-ipv4aas.all@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 6.89.1
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <154473417654.32125.9104927217788947044@ietfa.amsl.com>
Date: Thu, 13 Dec 2018 12:49:36 -0800
Archived-At: <https://mailarchive.ietf.org/arch/msg/secdir/J2bLpST_stvvAOBz5u6U3gJJifs>
Subject: [secdir] Secdir last call review of draft-ietf-v6ops-transition-ipv4aas-11
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.29
List-Id: Security Area Directorate <secdir.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/secdir>, <mailto:secdir-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/secdir/>
List-Post: <mailto:secdir@ietf.org>
List-Help: <mailto:secdir-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/secdir>, <mailto:secdir-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 13 Dec 2018 20:49:37 -0000

Reviewer: Christian Huitema
Review result: Has Issues

I have reviewed draft-ietf-v6ops-transition-ipv4aas-11 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 summary of the review is "ready with issue".

The document describes solution for providing "IPv4 as a service", i.e.
provision of IPv4 as a service over an IPv6 only network.
It calls this support "transition as a service".

For various reasons, IETF working groups have standardized not just one but
five different mechanisms for providing this transition: 464XLAT [RFC6877],
Dual-Stack Lite [RFC6333], Lightweight 4over6 (lw4o6) [RFC7596],
MAP-E [RFC7597], and MAP-T [RFC7599]. (I am sure that Monty Python could have
produced a nice sketch about that.) The purpose of the draft is to
state how home routers (a.k.a. customer premise equipment, CPE) should
inform local devices about which of the mechanisms are available, which
should be preferred, and what parameters should be used when deploying
the chosen services. This is done using the DHCPv6 "S46" option
specified in RFC 8026.

The draft also makes specific recommendation regarding the use of the UPnP and
PCP services, by requiring specific error codes when a requested port mapping 
is not available through the specified transition technology.

The security section briefly points to the "Basic Requirements for IPv6
Customer Edge Routers" specified in RFC 7084, and to the security
section of each of the RFC describing the security technologies, and implicitly
argues that there are no other security issues. I think that is insufficient.

The draft introduces a reliance on the DHCPv6 "S46" option for assessing the
relative priority of different transition technologies. An attacker could spoof
the DHCPv6 response, and direct client traffic to a different technology than
selected by the service provider. This could be used, for example, to capture
IPv4 traffic in an IPv6 network and send it to a route chosen by the attacker.
The attack might also be used in a dual stack network that does not support
any transition technology. I don't understand how this attack is mitigated.


The introduction uses the acronym WAN without spelling out "Wide Area Network". 
Also, WAN is used as substitute for local Internet Service Provider network. We could
debate whether such networks are always "wide area", by opposition to say
"metropolitan" or "regional". This is the same convention used in RFC 7084 that
this document updates. It is arguably defined by reference, but spelling it out
would be nice.

The comparison with RFC7084 section includes a mangled sentence: 

   This document doesn't include support for 6rd ([RFC5969]), because as
   in an IPv6-in-IPv4 tunneling.

Please rephrase. Please also rephrase the next sentence, for similar reasons:

   Regarding DS-LITE [RFC6333], this document includes slightly
   different requirements, because the PCP ([RFC6887]) support and the
   prioritization of the transition mechanisms, including dual-stack.