Re: [mif] Last Call: <draft-ietf-mif-mpvd-arch-09.txt> (Multiple Provisioning Domain Architecture) to Informational RFC

Markus Stenberg <markus.stenberg@iki.fi> Tue, 03 February 2015 08:45 UTC

Return-Path: <markus.stenberg@iki.fi>
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 280F21A1A92; Tue, 3 Feb 2015 00:45:03 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.778
X-Spam-Level:
X-Spam-Status: No, score=0.778 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_NEUTRAL=0.779] 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 eDK6TJ6-yuXO; Tue, 3 Feb 2015 00:45:01 -0800 (PST)
Received: from kirsi1.inet.fi (mta-out1.inet.fi [62.71.2.203]) by ietfa.amsl.com (Postfix) with ESMTP id 285731A8728; Tue, 3 Feb 2015 00:44:58 -0800 (PST)
Received: from poro.lan (80.220.64.126) by kirsi1.inet.fi (8.5.142.08) (authenticated as stenma-47) id 54C8A39200B014B6; Tue, 3 Feb 2015 10:44:56 +0200
Content-Type: text/plain; charset="us-ascii"
Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2070.6\))
From: Markus Stenberg <markus.stenberg@iki.fi>
In-Reply-To: <20150123153536.10431.23196.idtracker@ietfa.amsl.com>
Date: Tue, 03 Feb 2015 10:44:56 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: <A48A040C-F8C3-4E97-AF97-CD80DD19C3CD@iki.fi>
References: <20150123153536.10431.23196.idtracker@ietfa.amsl.com>
To: ietf@ietf.org
X-Mailer: Apple Mail (2.2070.6)
Archived-At: <http://mailarchive.ietf.org/arch/msg/mif/cKJgd1syXOmYcLet22Cmbp3Mhw0>
Cc: Markus Stenberg <markus.stenberg@iki.fi>, mif@ietf.org, IETF-Announce <ietf-announce@ietf.org>
Subject: Re: [mif] Last Call: <draft-ietf-mif-mpvd-arch-09.txt> (Multiple Provisioning Domain Architecture) to Informational RFC
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: <http://www.ietf.org/mail-archive/web/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: Tue, 03 Feb 2015 08:45:03 -0000

I am not sure if this document has been really thought through in terms of IPv4, or the dual-stack case. 

Notably, in section 2:
* Source address prefixes for use by connections within the provisioning domain

If we have a home router, which does NAT (and I dare you to find one that does not), the e.g. potential authentication mentioned in Section 2.3 becomes invalid in case of IPv4 as the source address prefix information has to change (or be omitted) for it to be useful. Section 2.5 further advocates combining both IPv4 and IPv6 PVDs, and as a result, whole authentication scheme becomes more or less invalid if not directly connected to the network PVD lives in. (And IPv4 source address prefix information has to change.)

My proposal:

- make use of source address specific optional with IPv4? (or note somewhere that prefix should be 0.0.0.0/0 if any use of NAT is ever thought reasonable using the PVD)

On not so serious note, as PvD has (more or less) binding to the protocol it was used to acquire the configuration information (e.g. DHCPv4, DHCPv6, or RA), I would much rather advocate single-AF PvDs so their lifetime would map to the lifetime of the other network information received/updated via that particular protocol.

My proposal (but I can live without too, this is mostly just elegance-of-design criteria for me):

- unbundle dual-stack case so that IPv4 PVD comes from DHCPv4, and IPv6 PVD from DHCPv6/RA. Or at least make bundling optional; in case of e.g. IKEv2, having both from same source makes still sense.

Nit: In section 7.2.1, where does TLS come from? Does DHCPv6 or RA have TLS transport? (X.509 certificate would fit better.)

Nit: In section 9, I am Markus, not Marcus ;)

Cheers,

-Markus