[secdir] Secdir telechat review of draft-ietf-v6ops-transition-ipv4aas-12

Christian Huitema <huitema@huitema.net> Mon, 07 January 2019 06:27 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 55F71130DE5; Sun, 6 Jan 2019 22:27:23 -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.2
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <154684244329.17044.2866311660755291596@ietfa.amsl.com>
Date: Sun, 06 Jan 2019 22:27:23 -0800
Archived-At: <https://mailarchive.ietf.org/arch/msg/secdir/Ivdt7uiZbUfDRG_tVuhcEQYc-p8>
Subject: [secdir] Secdir telechat review of draft-ietf-v6ops-transition-ipv4aas-12
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: Mon, 07 Jan 2019 06:27:23 -0000

Reviewer: Christian Huitema
Review result: Ready

I already reviewed the version 11 of this draft. From a security point of view,
the main change between the two versions is the addition of a paragraph
acknowledging the potential risks of relying on DHCP for configuration. To
quote: "As described in [RFC8026] and [RFC8026] Security Consideration
sections, there are generic DHCP security issues, which in the case of this
document means that malicious nodes may alter the priority of the transition
mechanisms."

Well, on the one hand, this does directly address the point I raised in the
previous review. On the other hand, it is a bit sad to have a dry
acknowledgement like that, without any hint at mitigations. If I was writing an
April's fool RFC, I would qualify that as one of those security sections that
seem written primarily for appeasing the security reviewer. But then, do we
want to give some advice to implementers? For example, do we want to tell them
that it is OK to deploy compliant devices in a basic home network? Probably. In
the branch office of a financial institution? Most probably not. Do we have a
way to convey that in simple terms? I would add something like:

"As stated in the introduction, this document addresses deployment of IPv4 as a
service in a residential or small-office network. Deployment in more
challenging environments would require additional security analysis."