Re: [mif-arch-dt] Strawman solution proposals for DHCPv6 and RA support for multiple provisioning domains

Ted Lemon <ted.lemon@nominum.com> Fri, 22 November 2013 20:34 UTC

Return-Path: <Ted.Lemon@nominum.com>
X-Original-To: mif-arch-dt@ietfa.amsl.com
Delivered-To: mif-arch-dt@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 65F961ADFEF for <mif-arch-dt@ietfa.amsl.com>; Fri, 22 Nov 2013 12:34:11 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.2
X-Spam-Level:
X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3] autolearn=ham
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 JfpVAvWSQnHB for <mif-arch-dt@ietfa.amsl.com>; Fri, 22 Nov 2013 12:34:10 -0800 (PST)
Received: from exprod7og122.obsmtp.com (exprod7og122.obsmtp.com [64.18.2.22]) by ietfa.amsl.com (Postfix) with ESMTP id 13DD81ACCEA for <mif-arch-dt@ietf.org>; Fri, 22 Nov 2013 12:34:10 -0800 (PST)
Received: from shell-too.nominum.com ([64.89.228.229]) (using TLSv1) by exprod7ob122.postini.com ([64.18.6.12]) with SMTP ID DSNKUo+/u3WBIZOdrlDQbrd1YAWkkT7ZyFTZ@postini.com; Fri, 22 Nov 2013 12:34:03 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 Certification Authority" (verified OK)) by shell-too.nominum.com (Postfix) with ESMTP id E8DAE1B82B6 for <mif-arch-dt@ietf.org>; Fri, 22 Nov 2013 12:34:02 -0800 (PST)
Received: from webmail.nominum.com (cas-01.win.nominum.com [64.89.228.131]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (Client CN "mail.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by archivist.nominum.com (Postfix) with ESMTPS id CDC0D190043; Fri, 22 Nov 2013 12:34:02 -0800 (PST) (envelope-from Ted.Lemon@nominum.com)
Received: from [192.168.1.5] (192.168.1.10) by CAS-01.WIN.NOMINUM.COM (192.168.1.100) with Microsoft SMTP Server (TLS) id 14.3.158.1; Fri, 22 Nov 2013 12:34:02 -0800
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0 (Mac OS X Mail 7.0 \(1822\))
From: Ted Lemon <ted.lemon@nominum.com>
In-Reply-To: <E07F8EDD-6BA5-4B7D-B307-C819B6AC2053@gmail.com>
Date: Fri, 22 Nov 2013 15:33:57 -0500
Content-Transfer-Encoding: quoted-printable
Message-ID: <6AC3097B-C63D-4DC6-80BE-29FEFE355D40@nominum.com>
References: <5267F29C.3010304@ericsson.com> <0010ca0ba1f44fe2a1b8fa5f110a00c0@SN2PR03MB077.namprd03.prod.outlook.com>, <41845B5F-8694-4368-B2F6-BA3BA0CFDD91@gmail.com> <ee10ff9826854918aebf0565c93ce5a9@SN2PR03MB077.namprd03.prod.outlook.com> <E07F8EDD-6BA5-4B7D-B307-C819B6AC2053@gmail.com>
To: Jouni Korhonen <jouni.nospam@gmail.com>
X-Mailer: Apple Mail (2.1822)
X-Originating-IP: [192.168.1.10]
Cc: "mif-arch-dt@ietf.org" <mif-arch-dt@ietf.org>, Suresh Krishnan <suresh.krishnan@ericsson.com>, Dmitry Anipko <Dmitry.Anipko@microsoft.com>
Subject: Re: [mif-arch-dt] Strawman solution proposals for DHCPv6 and RA support for multiple provisioning domains
X-BeenThere: mif-arch-dt@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: MIF Architecture Design Team mailing list <mif-arch-dt.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/mif-arch-dt>, <mailto:mif-arch-dt-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/mif-arch-dt/>
List-Post: <mailto:mif-arch-dt@ietf.org>
List-Help: <mailto:mif-arch-dt-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/mif-arch-dt>, <mailto:mif-arch-dt-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 22 Nov 2013 20:34:11 -0000

On Nov 22, 2013, at 12:11 PM, Jouni Korhonen <jouni.nospam@gmail.com> wrote:
> Domain names and alike possible PVD-IDs are ok since they already are "human readable". However, I would put zero energy trying to add something readable data into PVDs if the used PVD-ID itself is e.g. a binary blob. I just see no value of that if it increases the data size of the PVD container or ID.

If the PVD ID is a blob, you need a mechanism for assigning a name to it and validating it.

Think about the possible flow here.   We want to be able to present this information to the user in a chooser, right?   So that means that if what's contained in the ID is a binary blob, we need a way to translate it.   Also, if the blob is something we've already seen and can cryptographically authenticate based on a previous leap of faith, then we need the signature to authenticate.  And if we don't have the name at this point, we need a process for finding the name associated with the blob after we've decided to try it.

It might be better to have a name that we can do all that too that's human-readable.   Then we can do cryptographic validation if we have already seen the name, and avoid connecting to a fraudulent version of the PVD (which we could also do with the blob).   But if we haven't seen the name before, and haven't yet accepted it, we want something to present to the user, don't we?

This bears thinking about.   I'm not saying you're wrong, but don't be too quick to leap to conclusions about this!