[Gen-art] Gen-ART Review of draft-ietf-dime-4over6-provisioning-03
Russ Housley <housley@vigilsec.com> Sun, 12 July 2015 21:28 UTC
Return-Path: <housley@vigilsec.com>
X-Original-To: gen-art@ietfa.amsl.com
Delivered-To: gen-art@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 03D361A1AA2; Sun, 12 Jul 2015 14:28:19 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -99.2
X-Spam-Level:
X-Spam-Status: No, score=-99.2 tagged_above=-999 required=5 tests=[BAYES_50=0.8, USER_IN_WHITELIST=-100] autolearn=ham
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 qNIbZx9pXzXu; Sun, 12 Jul 2015 14:28:17 -0700 (PDT)
Received: from odin.smetech.net (x-bolt-wan.smeinc.net [209.135.219.146]) by ietfa.amsl.com (Postfix) with ESMTP id 3FC9D1A19E3; Sun, 12 Jul 2015 14:28:17 -0700 (PDT)
Received: from localhost (unknown [209.135.209.5]) by odin.smetech.net (Postfix) with ESMTP id 769259A4017; Sun, 12 Jul 2015 17:28:06 -0400 (EDT)
X-Virus-Scanned: amavisd-new at smetech.net
Received: from odin.smetech.net ([209.135.209.4]) by localhost (ronin.smeinc.net [209.135.209.5]) (amavisd-new, port 10024) with ESMTP id 2g35PPLhsSuq; Sun, 12 Jul 2015 17:26:47 -0400 (EDT)
Received: from [192.168.2.100] (pool-108-51-128-219.washdc.fios.verizon.net [108.51.128.219]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by odin.smetech.net (Postfix) with ESMTP id A04809A4021; Sun, 12 Jul 2015 17:27:45 -0400 (EDT)
From: Russ Housley <housley@vigilsec.com>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Date: Sun, 12 Jul 2015 17:27:34 -0400
Message-Id: <50C9C295-15B4-463F-908B-A05C71DF7DFF@vigilsec.com>
To: draft-ietf-dime-4over6-provisioning.all@ietf.org
Mime-Version: 1.0 (Apple Message framework v1085)
X-Mailer: Apple Mail (2.1085)
Archived-At: <http://mailarchive.ietf.org/arch/msg/gen-art/mV6Y_wAU4nLfPuiu-5L3vT7D0j8>
Cc: IETF Gen-ART <gen-art@ietf.org>, IETF <ietf@ietf.org>
Subject: [Gen-art] Gen-ART Review of draft-ietf-dime-4over6-provisioning-03
X-BeenThere: gen-art@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "GEN-ART: General Area Review Team" <gen-art.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/gen-art>, <mailto:gen-art-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/gen-art/>
List-Post: <mailto:gen-art@ietf.org>
List-Help: <mailto:gen-art-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/gen-art>, <mailto:gen-art-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sun, 12 Jul 2015 21:28:19 -0000
I am the assigned Gen-ART reviewer for this draft. For background on Gen-ART, please see the FAQ at <http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>. This review is in response to a request for early Gen-ART review. Document: draft-ietf-dime-4over6-provisioning-03 Reviewer: Russ Housley Review Date: 2015-07-12 IETF LC End Date: 2015-07-20 IESG Telechat date: unknown Summary: Almost Ready Major Concerns: None Minor Concerns: In section 2.4, please replace "the MAP-E document" with a reference to [I-D.ietf-softwire-map]. The Security Considerations section talks about two concerns: (1) man-in-the-middle modification of the AVP contents leading to misconfiguration, and (2) disclosure of subscriber addresses allowing the attacker to track subscriber activity. If I have understood these properly, the second one is more of a privacy consideration. Please consider moving this to a separate section on privacy considerations. Returning to the first part of the security considerations, please say more about the possible consequences of a man-in-the-middle making modifications to the AVP contents. Is there anything that the implementer can do to make the attack more difficult to accomplish or raise the likelihood of detection? Other Comments: Section 2.6 begins this way: "It appears that two items are common to the different transition methods and the corresponding AVPs to carry them can be reused...". By the time this document achieves consensus and it is ready to be published as an RFC, there is no longer a need for such a soft touch. I suggest: "There are two items that are common to the different transition methods, and the corresponding AVPs to carry them can be reused..." Section 3.3 says: 64-Multicast-Attributes AVP MUST include at least the ASM-mPrefix64 AVP or the SSM-mPrefix64 AVP. Both the ASM-mPrefix64 AVP and the SSM-mPrefix64 AVP MAY be present. Would it be more clear to say it this way? 64-Multicast-Attributes AVP MUST include the ASM-mPrefix64 AVP or the SSM-mPrefix64 AVP, and it MAY include both. Please provide labels for Figures 5, 6, and 7. Based on the other figures, they should probably be: - Figure 5: LW4over6-Binding AVP - Figure 6: MAP-E-Attributes AVP - Figure 7: MAP-Mapping-Rule AVP
- [Gen-art] Gen-ART Review of draft-ietf-dime-4over… Russ Housley
- Re: [Gen-art] Gen-ART Review of draft-ietf-dime-4… mohamed.boucadair
- Re: [Gen-art] Gen-ART Review of draft-ietf-dime-4… Jari Arkko