[mif] Second Review: draft-ietf-mif-mpvd-dhcp-support
Steven Barth <cyrus@openwrt.org> Thu, 29 October 2015 09:56 UTC
Return-Path: <cyrus@openwrt.org>
X-Original-To: mif@ietfa.amsl.com
Delivered-To: mif@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A63751B2C5C for <mif@ietfa.amsl.com>; Thu, 29 Oct 2015 02:56:18 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.549
X-Spam-Level:
X-Spam-Status: No, score=-1.549 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, SPF_FAIL=0.001] 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 Rx60jBLCoZMq for <mif@ietfa.amsl.com>; Thu, 29 Oct 2015 02:56:16 -0700 (PDT)
Received: from mail.core-networks.de (mail.core-networks.de [IPv6:2001:1bc0:d::4:9]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 37D991B2C58 for <mif@ietf.org>; Thu, 29 Oct 2015 02:56:16 -0700 (PDT)
Received: from localhost ([127.0.0.1]) by mail.core-networks.de id 1ZrjwL-0002ah-MH with ESMTPSA (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) for mif@ietf.org; Thu, 29 Oct 2015 10:56:13 +0100
References: <20151019222659.32205.49209.idtracker@ietfa.amsl.com>
From: Steven Barth <cyrus@openwrt.org>
To: mif@ietf.org
Message-ID: <5631ED3D.3080408@openwrt.org>
Date: Thu, 29 Oct 2015 10:56:13 +0100
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:40.0) Gecko/20100101 Icedove/40.0
MIME-Version: 1.0
In-Reply-To: <20151019222659.32205.49209.idtracker@ietfa.amsl.com>
Content-Type: text/plain; charset="windows-1252"
Content-Transfer-Encoding: 7bit
Archived-At: <http://mailarchive.ietf.org/arch/msg/mif/65wBwohJ-s7WXHJVY1UXF4r5Do4>
Subject: [mif] Second Review: draft-ietf-mif-mpvd-dhcp-support
X-BeenThere: mif@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Multiple Interface Discussion List <mif.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/mif>, <mailto:mif-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/mif/>
List-Post: <mailto:mif@ietf.org>
List-Help: <mailto:mif-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/mif>, <mailto:mif-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 29 Oct 2015 09:56:18 -0000
As for the NDP-support draft: Thanks for the updated version, here is a second review of the draft. I intentionally did not look at my first review notes so there might be duplicates. Feel free to ignore them if they are invalid. 1. It is unclear what to do with enclosed TLVs The reasoning is similar to the NDP TLVs in the other draft: The draft defines what TLVs can be enclosed but not how the enclosing affects the meaning of the TLVs, e.g. is an enclosed RDNSS-TLV or an IAAddr still generally applicable for all purposes and if not how is the meaning changed specifically? This is especially problematic since the draft does not disallow any TLVs from being inside the container, see also 2. 2. It is unclear how this draft interacts with the Identity Association state machines defined in RFC3315 i.e. how are IAs and addresses and prefixes actually enclosed here. The draft needs to specify clearly what happens to identity associations / address assignments and how they are associated to PVDs especially taking into account the possibility of having multiple IAs (e.g. IA_NA and IA_PD) or addresses from different PVDs in the same IA. See also 3. 3. It is unclear where the PVD container option can occur. Is it restricted to only occur on the top-level or can it occur also inside other containers (e.g. Identity Associations), if the latter is true, how does it affect what options can be enclosed in it. 4. Signature calculation is unclear. The signature generation defined in RFC 3971 includes several other components (e.g. a CGA message type tag, a kind of pseudoheader, etc.) besides the actual NDP message being signed. It is unclear if your signature mechanism uses the same header fields or if the intention was just to use a plain RSASSA-PKCS1-v1_5 over the PVD container. 5. Mandatory to implement security seems outdated. The use of SHA-1 as only mandatory hash for key identification and as only defined hash for signatures seems a bit outdated these days especially in the light of recent advancements in its cryptanalysis. This seems especially problematic since there does not seem to be a way to signal the use of a different signature algorithm. 6. Replay Protection seems not adequately addressed. No specific mechanism is defined. It is suggested to use either timestamps or a nonce of an undefined format. Also the suggested use of DHCPv6 AUTH would not provide replay protection for the PVD container but for the whole DHCPv6 message being secured.
- [mif] I-D Action: draft-ietf-mif-mpvd-dhcp-suppor… internet-drafts
- [mif] Second Review: draft-ietf-mif-mpvd-dhcp-sup… Steven Barth