Re: [mif] Subject: Comments on draft-ietf-mif-mpvd-dhcp-support-01

Steven Barth <cyrus@openwrt.org> Wed, 22 July 2015 07:21 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 A929B1ACDF0 for <mif@ietfa.amsl.com>; Wed, 22 Jul 2015 00:21: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, HTML_MESSAGE=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 yTCASnMOTWNL for <mif@ietfa.amsl.com>; Wed, 22 Jul 2015 00:21: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 272681B2AAE for <mif@ietf.org>; Wed, 22 Jul 2015 00:21:16 -0700 (PDT)
Received: from localhost ([127.0.0.1]) by mail.core-networks.de id 1ZHoL4-0000mo-Bv with ESMTPSA (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) for ; Wed, 22 Jul 2015 09:21:14 +0200
To: Hui Deng <denghui02@hotmail.com>, "mif@ietf.org" <mif@ietf.org>
References: <COL125-W436833B2B6FAD013C45D6DB1830@phx.gbl>
From: Steven Barth <cyrus@openwrt.org>
Message-ID: <55AF4469.50308@openwrt.org>
Date: Wed, 22 Jul 2015 09:21:13 +0200
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.1.0
MIME-Version: 1.0
In-Reply-To: <COL125-W436833B2B6FAD013C45D6DB1830@phx.gbl>
Content-Type: multipart/alternative; boundary="------------070707070207090606030506"
Archived-At: <http://mailarchive.ietf.org/arch/msg/mif/TdPndwyN2DsjgjBngluEw8g_DNs>
Subject: Re: [mif] Subject: Comments on draft-ietf-mif-mpvd-dhcp-support-01
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 07:21:18 -0000

I resent it and it went through. See https://mailarchive.ietf.org/arch/msg/mif/bcfrumt2vd-YU2lUL-IKSWSqt0c
It seems my subscription wasn't 100% through the first time I sent, sorry about that.


Am 22.07.2015 um 09:13 schrieb Hui Deng:
> Hello all,
>  
> Steven sent this, by some chance, it was not shown up in our list, so I cc here
>  
> From: Steven Barth <cyrus@openwrt.org>
> To: mif@ietf.org
> Cc: 
> Date: Tue, 21 Jul 2015 21:55:49 +0200
> Subject: Comments on draft-ietf-mif-mpvd-dhcp-support-01
> Hi everyone,
>
> as promised few comments on the DHCPv6 support draft. This is based on roughly
> reading it 1-2 times and not meant to be conclusive in any way. Also I'm not a
> dhc expert, though I have implemented a DHCPv6 client, server and relay myself.
>
> 3 SHOULD contain exactly one still allows more than one PVD_AUTH vs.
> "MUST be the last option inside PVD" in 5
>
> 5 refers to RFC3791 in key-hash and digital-signature options but 3791 is
> not part of references.
>
> 6 specifies that ANY options may be encapsulated. This is awkward, e.g., what
> would be the meaning of e.g. a Status or a Reconfigure-Accept option within
> that container, more general what happens to options explicitly defined to be
> on some level and / or having a specific meaning there?
>
> Also where may your container option be present? Only on the top-level?
> Also inside IA_NA/IA_PD? Inside IAAddr / IAPrefix?
>
> Also in which DHCPv6 messages may your container appear?
>
> 7.1 merely specifies to send ORO etc. in SOLICIT, but not in REQUEST, RENEW etc.
> whereas 7.3 says OPTION_PVD must not be sent if ORO is absent in request
>
> 8 mentions the use of timestamps to avoid replay attacks, though DHCPv6 is usually
> used to bootstrap network connectivity and thus at this point devices (especially
> embedded ones) may not have an accurate wallclock yet. This is especially interesting
> since DHCPv6 itself may carry NTP server addresses to use.
>
> Some additional stuff related to routers forwarding this kind of information from
> to clients (e.g. your coffee shop example in 8). In general this should applies to CPEs,
> as specified in RFC 7084, especially if they themselves got the information using
> DHCPv6 from an ISP, but not necessarily. Again disclaimer: this list is not conclusive:
>
> Since you don't restrict options inside your container, it may originally contain options
> e.g. FQDN which may only be directed at the specific receiving router but not hosts behind
> it (e.g. the hotspot got the PVD TLVs via DHCPV6 itself). Furthermore the container may
> contain options which are specified to not be sent to clients unless explicitly asked for
> in an ORO. In both instances the "coffee shop router" would need to dynamically remove
> options from the container which will inevitably invalidate the signature of the container.
>
> Also given the "coffee shop router" is supposed to hand out addresses from different PVDs
> and "tag" them appropriately: How is it supposed to do that with just a container which
> SHOULD contain a signature?
> It certainly cannot place IAAddrs or IAPrefixes inside containers since it doesn't have
> the key (there are more and even more severe issues with trying to use containers for IA_Xs
> or IAAdress / IAPrefix but I will skip them for the sake of simplicity for now).
>
> Also, if a hotspot / CER / etc. asks (e.g. an ISP) for PVD information that does
> not necessarily mean that all the hosts behind said router will understand PVD information
> so that router requires that it also gets "legacy" information for "legacy" hosts being
> not PVD-aware OR it needs some guidance to construct that information from data within
> the PVD containers it got.
>
> Cheers,
>
> Steven