[secdir] secdir review of draft-ietf-softwire-lw4over6-11

Samuel Weiler <weiler@watson.org> Thu, 23 October 2014 21:11 UTC

Return-Path: <weiler@watson.org>
X-Original-To: secdir@ietfa.amsl.com
Delivered-To: secdir@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com []) by ietfa.amsl.com (Postfix) with ESMTP id CE7B81A1ACF; Thu, 23 Oct 2014 14:11:57 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.589
X-Spam-Status: No, score=0.589 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, J_CHICKENPOX_31=0.6, T_RP_MATCHES_RCVD=-0.01] autolearn=no
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id rEzf8fYsNGd5; Thu, 23 Oct 2014 14:11:56 -0700 (PDT)
Received: from cyrus.watson.org (cyrus.watson.org []) by ietfa.amsl.com (Postfix) with ESMTP id 4BCAA1A1A22; Thu, 23 Oct 2014 14:11:55 -0700 (PDT)
Received: from fledge.watson.org (fledge.watson.org []) by cyrus.watson.org (Postfix) with ESMTPS id 5137B46B4C; Thu, 23 Oct 2014 17:11:54 -0400 (EDT)
Received: from fledge.watson.org (weiler@localhost.watson.org []) by fledge.watson.org (8.14.9/8.14.9) with ESMTP id s9NLBrbe061602; Thu, 23 Oct 2014 17:11:54 -0400 (EDT) (envelope-from weiler@watson.org)
Received: from localhost (weiler@localhost) by fledge.watson.org (8.14.9/8.14.9/Submit) with ESMTP id s9NLBrxb061599; Thu, 23 Oct 2014 17:11:53 -0400 (EDT) (envelope-from weiler@watson.org)
X-Authentication-Warning: fledge.watson.org: weiler owned process doing -bs
Date: Thu, 23 Oct 2014 17:11:53 -0400
From: Samuel Weiler <weiler@watson.org>
To: draft-ietf-softwire-lw4over6.all@tools.ietf.org
Message-ID: <alpine.BSF.2.11.1410231708570.60907@fledge.watson.org>
User-Agent: Alpine 2.11 (BSF 23 2013-08-11)
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; format="flowed"; charset="US-ASCII"
X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.4.3 (fledge.watson.org []); Thu, 23 Oct 2014 17:11:54 -0400 (EDT)
Archived-At: http://mailarchive.ietf.org/arch/msg/secdir/O1QT55SCRPbbVl7ogRPeOsrPrdA
Cc: iesg@ietf.org, secdir@ietf.org
Subject: [secdir] secdir review of draft-ietf-softwire-lw4over6-11
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
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: <http://www.ietf.org/mail-archive/web/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, 23 Oct 2014 21:11:58 -0000

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.

Does this mechanism introduce new points for a DoS attack,
e.g. forging the ICMPv6 error message (type 1, code 5) mentioned in
Section 5.1?  I would like to see a list and discussion of these or,
if appropriate, an analysis showing that none exist.

It's probably worth explaining this 2119 RECOMMENDation in more 

    Unless an lwB4 is being allocated a full IPv4 address, it is
    RECOMMENDED that PSIDs containing the well-known ports (0-1023) are
    not allocated to lwB4s.

I would like to see a discussion of provisioning mechanism security.
Are there security-related factors that should drive the choice of
provisioning mechanism (the doc mentions several options...)?  Are
there configuration choices that should or must be made when using one
of thsoe for this purpose?

Non-security stuff:

I'm not seeing any explicit discussion of whether (and how) a lwB4 can 
request additional port space after the initial assignment.  If that 
feature does not exist, I would like to see it explicitly acknowledged 
as a limitation with a discussion of why it is not being provided.

Again, assuming that there is not such a mechanism: since this is the 
architecture document, I would like to see a few words on expected 
port assignment/utilization ratios.  Assuming a typical case of a 
residential subscriber, it seems that lw4o6 would need to assign 
enough ports to each user to accommodate expected peak usage.  This 
pretty clearly results in fewer users accommodated on a public v4 
address than if they were sharing the port space on demand.  How much 
much v4 space does lw4o6 consume in this environment compared to 

Editorial stuff:

The next-to-last paragraph of section 1 doesn't seem to flow well with
the text around it, perhaps for lack of clarity in pronoun

    This document is an extended case, which covers address sharing for
    [RFC7040].  It is also a variant of A+P called Binding Table Mode
    (see Section 4.4 of [RFC6346]).

And I think something is broken in the below sentence:

    The solution specified in this document allows the assignment of
    either a full or a shared IPv4 address requesting CPEs.