[mif] Comments on draft-ietf-mif-mpvd-ndp-support
Steven Barth <cyrus@openwrt.org> Wed, 22 July 2015 08:23 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 358571A036C for <mif@ietfa.amsl.com>; Wed, 22 Jul 2015 01:23:19 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.55
X-Spam-Level:
X-Spam-Status: No, score=-1.55 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35] 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 CdkvU-eTaEdl for <mif@ietfa.amsl.com>; Wed, 22 Jul 2015 01:23:17 -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 BEF7A1A0267 for <mif@ietf.org>; Wed, 22 Jul 2015 01:23:17 -0700 (PDT)
Received: from localhost ([127.0.0.1]) by mail.core-networks.de id 1ZHpJ5-0002xh-RA with ESMTPSA (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) for mif@ietf.org; Wed, 22 Jul 2015 10:23:16 +0200
To: "mif@ietf.org" <mif@ietf.org>
From: Steven Barth <cyrus@openwrt.org>
Message-ID: <55AF52F1.2040802@openwrt.org>
Date: Wed, 22 Jul 2015 10:23:13 +0200
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.1.0
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
Archived-At: <http://mailarchive.ietf.org/arch/msg/mif/evOxSWmRsHxo8cul9FEagL3aW7Q>
Subject: [mif] Comments on draft-ietf-mif-mpvd-ndp-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: Wed, 22 Jul 2015 08:23:19 -0000
Hello everyone, some probably non-conclusive comments on the NDP-support draft. 3 "However, including a PVD container or identity options inside a Router Solicitation (RS) NDP messages is also possible (actually, in this way a host can solicit for information from a specific provisioning domain)." This is awkward. Foremost, hosts only send RSs when they change links and also replies to RS may be multicasted to all hosts on the links (and often in practice still are). In any case I don't see the point of adding the container to the RS and / or maybe the Identity. This is just plain ambiguous. 3 "The PVD container MUST NOT be fragmented i.e., should the IPv6 packet be fragmented, the PVD container and the accompanying PVD identity MUST both be inside the same fragment." The i.e. makes it ambiguous. Now MUST the whole container NOT be fragmented or MUST every fragment have a PVD Identity or only the first one? 3 S-bit: Could this not just be encoded as "Name Type" = 0? 3 "Name Type": I find it peculiar that the name type is selectable but not the signature algorithm (at least to my understanding). 3 "Key Hash": Since this doesn't have a length field a client not understanding the name type cannot interpret anything in the container even if it does not want to check the signature. I'm not sure if this is intended. 3 "This MAY imply adding padding zero octets to the tail of the PVD container option until the alignment requirement has been met" A MAY padding seems awkward and actually ambiguous. (This also applies to 4 to a lesser degree) 4 Is it useful that PVD ID is a separate TLV if a container MUST have exactly 1 in it and the stand-alone use (e.g. in RS) is probably questionable? 6 Again as for dhcpv6, timestamps may not be ready for checking at the point where RAs are evaluated since these are essentially bootstrap protocol and not all devices do have RTCs or unauthenticated NTP server options may be used to tamper with wallclock settings. 9 RFC 3971 is in informative references but since you use it as source for your signature algorithm should it not be normative? Cheers, Steven
- [mif] Comments on draft-ietf-mif-mpvd-ndp-support Steven Barth
- Re: [mif] Comments on draft-ietf-mif-mpvd-ndp-sup… Jouni Korhonen
- Re: [mif] Comments on draft-ietf-mif-mpvd-ndp-sup… Steven Barth
- Re: [mif] Comments on draft-ietf-mif-mpvd-ndp-sup… Jouni Korhonen
- Re: [mif] Comments on draft-ietf-mif-mpvd-ndp-sup… Steven Barth
- Re: [mif] Comments on draft-ietf-mif-mpvd-ndp-sup… Jouni Korhonen
- Re: [mif] Comments on draft-ietf-mif-mpvd-ndp-sup… Steven Barth
- Re: [mif] Comments on draft-ietf-mif-mpvd-ndp-sup… Jouni Korhonen