[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 [127.0.0.1]) 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-Level:
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 ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (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 [198.74.231.69]) 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 [198.74.231.63]) 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 [127.0.0.1]) 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 [127.0.0.1]); 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 detail: 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 DS-Lite? 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 antecedents: 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.
- [secdir] secdir review of draft-ietf-softwire-lw4… Samuel Weiler
- Re: [secdir] secdir review of draft-ietf-softwire… mohamed.boucadair
- Re: [secdir] secdir review of draft-ietf-softwire… ian.farrer
- Re: [secdir] secdir review of draft-ietf-softwire… Ted Lemon