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

Ted Lemon <Ted.Lemon@nominum.com> Tue, 03 February 2015 12:47 UTC

Return-Path: <Ted.Lemon@nominum.com>
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 8079E1A8A0B; Tue, 3 Feb 2015 04:47:13 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.41
X-Spam-Level:
X-Spam-Status: No, score=-1.41 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, GB_ABOUTYOU=0.5, T_RP_MATCHES_RCVD=-0.01] 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 4e_W2E-zd48I; Tue, 3 Feb 2015 04:47:10 -0800 (PST)
Received: from sjc1-mx02-inside.nominum.com (sjc1-mx02-inside.nominum.com [64.89.234.25]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D1A5C1A871B; Tue, 3 Feb 2015 04:47:10 -0800 (PST)
Received: from archivist.nominum.com (archivist.nominum.com [64.89.228.108]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "*.nominum.com", Issuer "Go Daddy Secure Certificate Authority - G2" (verified OK)) by sjc1-mx02-inside.nominum.com (Postfix) with ESMTPS id 7F84ADA00D5; Tue, 3 Feb 2015 12:47:10 +0000 (UTC)
Received: from webmail.nominum.com (cas-03.win.nominum.com [64.89.235.66]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (Client CN "mail.nominum.com", Issuer "Go Daddy Secure Certificate Authority - G2" (verified OK)) by archivist.nominum.com (Postfix) with ESMTP id 4BB9E53E082; Tue, 3 Feb 2015 04:47:10 -0800 (PST)
Received: from [172.19.131.133] (12.130.116.26) by CAS-03.WIN.NOMINUM.COM (64.89.235.66) with Microsoft SMTP Server (TLS) id 14.3.224.2; Tue, 3 Feb 2015 04:47:09 -0800
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\))
From: Ted Lemon <Ted.Lemon@nominum.com>
In-Reply-To: <A48A040C-F8C3-4E97-AF97-CD80DD19C3CD@iki.fi>
Date: Tue, 3 Feb 2015 07:47:04 -0500
Content-Transfer-Encoding: quoted-printable
Message-ID: <ECA36B14-039B-4842-B492-632E8FC5F0C5@nominum.com>
References: <20150123153536.10431.23196.idtracker@ietfa.amsl.com> <A48A040C-F8C3-4E97-AF97-CD80DD19C3CD@iki.fi>
To: Markus Stenberg <markus.stenberg@iki.fi>
X-Mailer: Apple Mail (2.1878.6)
X-Originating-IP: [12.130.116.26]
Archived-At: <http://mailarchive.ietf.org/arch/msg/mif/nrHVXPllWkkX0OAgyCVsUREhgmE>
Cc: "mif@ietf.org List" <mif@ietf.org>, IETF Discussion Mailing List <ietf@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 12:47:13 -0000

On Feb 3, 2015, at 3:44 AM, Markus Stenberg <markus.stenberg@iki.fi> wrote:
> 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.)

I think this is future work.   The MIF working group did consider whether to separate IPv4 and IPv6 PVDs; my belief was that we should, but the consensus was that they should be able to be kept together.   I think it's true that the capability to authenticate an explicit provisioning domain's container across a home gateway that is doing NAT for IPv4 is unlikely to work without some care.   However, it's not clear to me that this is even a use case that we care about.   If it is, then it can be addressed by treating the NATted provisioning domain as a different provisioning domain than the external IPv4 provisioning domain.   It's actually not usual however for HGs to even pass the external PVD information into the home network on IPv4 NATs.   Instead, it sets up a DNS proxy and advertises that, and passes nothing else through at all.

> - 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)

This is another alternative, but it would only be necessary in the case where you wanted to advertise a translated prefix internally and have that be treated as the same PVD as the externally advertised prefix.   Since the current architecture document doesn't make specific recommendations about this, I don't think that we need to add anything, but if you think it's worthwhile we could add text that just explains the issue you've raised and talks about your proposed solution and possibly the one I've suggested.

I don't really want to add text about this, because I don't think it's been thought through carefully, and there are some holes in it that I can see.   For example, there's no way to prove that an advertised NAT prefix actually reaches the PVD that it is claimed to reach.   So you are pretty much at the mercy of the HG anyway.

> 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.

Me too, but I think that ship has already sailed.   And if you think about it, your point about RA and DHCPv6 is clearly an implementation issue: the implementation for explicit PVDs has to make it possible to connect them, because in practice they are related.   So there's no technical reason why this can't also work for DHCPv4 and explicit PVDs.

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

How about "PKI" instead of "TLS"?  I know PKI generally means X.509, but it isn't restricted to X.509.

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

Sorry about that.   Thanks for the thorough review!