Re: [homenet] New version draft-mglt-homenet-naming-architecture-dhc-options-02.txt

Michael Richardson <mcr+ietf@sandelman.ca> Thu, 03 July 2014 14:20 UTC

Return-Path: <mcr@sandelman.ca>
X-Original-To: homenet@ietfa.amsl.com
Delivered-To: homenet@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8D9311B2A0E for <homenet@ietfa.amsl.com>; Thu, 3 Jul 2014 07:20:55 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.343
X-Spam-Level:
X-Spam-Status: No, score=0.343 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FH_RELAY_NODNS=1.451, RDNS_NONE=0.793, SPF_PASS=-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 Ds6c1io2bQFC for <homenet@ietfa.amsl.com>; Thu, 3 Jul 2014 07:20:53 -0700 (PDT)
Received: from tuna.sandelman.ca (unknown [209.87.249.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 982521B2A46 for <homenet@ietf.org>; Thu, 3 Jul 2014 07:20:53 -0700 (PDT)
Received: from sandelman.ca (obiwan.sandelman.ca [209.87.249.21]) by tuna.sandelman.ca (Postfix) with ESMTP id 6DAE420028; Thu, 3 Jul 2014 10:21:24 -0400 (EDT)
Received: by sandelman.ca (Postfix, from userid 179) id 2C45763B0E; Thu, 3 Jul 2014 10:20:50 -0400 (EDT)
Received: from sandelman.ca (localhost [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id 0FD4D63B0A; Thu, 3 Jul 2014 10:20:50 -0400 (EDT)
From: Michael Richardson <mcr+ietf@sandelman.ca>
To: Juliusz Chroboczek <jch@pps.univ-paris-diderot.fr>
In-Reply-To: <87k37uy703.wl.jch@pps.univ-paris-diderot.fr>
References: <CADZyTkk6rUuFJ5Wds2hioBBQa9-kXDJxyg_gBGQ1R6u5CHF2Ww@mail.gmail.com> <87fvij5wdw.wl.jch@pps.univ-paris-diderot.fr> <CADZyTkk2bv7T-Bs_ckG4i2MpXVDRqLA2R1dQgrMVrPSckOy-GQ@mail.gmail.com> <87k37uy703.wl.jch@pps.univ-paris-diderot.fr>
X-Mailer: MH-E 8.2; nmh 1.3-dev; GNU Emacs 23.4.1
X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m<nPbLgmtKK-5dC@#:k
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="=-=-="; micalg="pgp-sha1"; protocol="application/pgp-signature"
Date: Thu, 03 Jul 2014 10:20:50 -0400
Message-ID: <5895.1404397250@sandelman.ca>
Sender: mcr@sandelman.ca
Archived-At: http://mailarchive.ietf.org/arch/msg/homenet/rv_aBBBogrw_GJV50jH9k8Tvoq8
Cc: "homenet@ietf.org" <homenet@ietf.org>, Daniel Migault <mglt.ietf@gmail.com>
Subject: Re: [homenet] New version draft-mglt-homenet-naming-architecture-dhc-options-02.txt
X-BeenThere: homenet@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: <homenet.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/homenet>, <mailto:homenet-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/homenet/>
List-Post: <mailto:homenet@ietf.org>
List-Help: <mailto:homenet-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/homenet>, <mailto:homenet-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 03 Jul 2014 14:20:55 -0000


Juliusz Chroboczek <jch@pps.univ-paris-diderot.fr> wrote:
    > I've got a device that wants to be advertised in the global DNS (a web

Let's call this device "FredBaby" (with allusions to Breakfast at Tiffanys,
which I was reading on the weekend)

    > server is the obvious example, but it doesn't matter).  Your draft
    > suggests (I think) that the device should speak to the CPE which will
    > take care of the interaction with the public DNS (arrow 6 in Figure 1 is
    > missing, by the way).  I'd like to understand why the device needs to go
    > through the middleman rather than speaking directly to the authoritative
    > DNS server.

The reason why FredBaby device MAY speak to the CPE as the middleman is
because:
    1) in the homenet we can automate the discovery of CPE / FredBaby,
       and probably bootstrap a secure relationship between them.
    2) the CPE may be managing multiple zones in multiple different ways.
       For instance, dyndns update to the ISP, dyndns to the DNS provider,
       stealth primary for the zone, public primary for the zone.
    3) we may be able to bootstrap the secure relationship between the
       CPE device some of the forward zones with the ISP, and definitely
       will do that for the reverse zone with the ISP.  FredBaby will have
       no relationship with the ISP(s).
    4) the CPE will know about all the other devices that want their name
       managed, such as Rusty, Yunioshi, Sally.  In particular the CPE
       will also know about brother-FredBaby, the device which you are
       replacing, but haven't yet turned off.  You'll therefore be able
       to see all the various attempts to publish in one place and
       decide who gets priority, and which devices ("Sally" the Tomato),
       you weren't supposed to publish your relationship with.


    > My family was poor but honest, Daniel, and NATed addresses were all we
    > could afford.  Notwithstanding our difficult conditions, my parents took
    > a lot of care to bring me up to believe that end-to-end is always better

LUXURY! <Queue Monty Python sketch>

    >>     - CPE presents a centralized point for end user interactions

    > I'm not convinced about that, the authoritative DNS master seems like the
    > natural place for end-user interactions.  (Note that this does not
    > prevent
    > the CPE's web interface from implementing some sort of proxy to the DNS
    > master's interface.)

I'm not sure I understand where the authoritative DNS master is.
I don't think that Daniel is demanding the CPE be the only possible answer,
and perhaps within HNCP we should be passing around the address of the
homenet authoritative DNS master, as if there are multiple CPE they might
need to argue about it too.

    >>     - CPE can integrate multiple protocols to publish a zone. Suppose
    >> mDNS is
    >> used by a node, than registration of its IP address and name cannot be
    >> perfomed on a public authoritative server cannot be performed using mDNS.

    > I strongly disagree.  I don't want mDNS->DNS proxying.  Registering in
    > the
    > global DNS is something that should be under user control, while mDNS
    > is something that happens automatically (for better or worse).

I think that this is the reason why we want it proxied; so that we have a
filter.   That's why FredBaby shouldn't talk to some out-of-home DNS master
directly.  I think that populating DNS from mDNS could well be turned off
by default, and enabled in a UI on a per name basis.

--
Michael Richardson <mcr+IETF@sandelman.ca>, Sandelman Software Works
 -= IPv6 IoT consulting =-