Re: [homenet] securing zone transfer

Michael Richardson <mcr+ietf@sandelman.ca> Thu, 13 June 2019 01:25 UTC

Return-Path: <mcr+ietf@sandelman.ca>
X-Original-To: homenet@ietfa.amsl.com
Delivered-To: homenet@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D26FC120088 for <homenet@ietfa.amsl.com>; Wed, 12 Jun 2019 18:25:36 -0700 (PDT)
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, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 U8dlhPUMOduC for <homenet@ietfa.amsl.com>; Wed, 12 Jun 2019 18:25:34 -0700 (PDT)
Received: from tuna.sandelman.ca (tuna.sandelman.ca [IPv6:2607:f0b0:f:3:216:3eff:fe7c:d1f3]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BD1551201C6 for <homenet@ietf.org>; Wed, 12 Jun 2019 18:25:34 -0700 (PDT)
Received: from sandelman.ca (unknown [IPv6:2607:f0b0:f:2:56b2:3ff:fe0b:d84]) by tuna.sandelman.ca (Postfix) with ESMTP id 077AE380BE; Wed, 12 Jun 2019 21:24:08 -0400 (EDT)
Received: by sandelman.ca (Postfix, from userid 179) id 2E7661301; Wed, 12 Jun 2019 21:25:32 -0400 (EDT)
Received: from sandelman.ca (localhost [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id 2D12691F; Wed, 12 Jun 2019 21:25:32 -0400 (EDT)
From: Michael Richardson <mcr+ietf@sandelman.ca>
To: Juliusz Chroboczek <jch@irif.fr>
cc: homenet <homenet@ietf.org>
In-Reply-To: <87ftoecq5g.wl-jch@irif.fr>
References: <CADZyTkkgd8f49V+yoZvPZXx3b-_YRzpgUY1-obroq9QMLnFWNw@mail.gmail.com> <878su8fj24.wl-jch@irif.fr> <2348.1560261275@localhost> <87ftofwqut.wl-jch@irif.fr> <27503.1560302791@localhost> <87ef3zwoew.wl-jch@irif.fr> <4109.1560349340@localhost> <87ftoecq5g.wl-jch@irif.fr>
X-Mailer: MH-E 8.6; nmh 1.7+dev; GNU Emacs 24.5.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-sha256"; protocol="application/pgp-signature"
Date: Wed, 12 Jun 2019 21:25:32 -0400
Message-ID: <21639.1560389132@localhost>
Archived-At: <https://mailarchive.ietf.org/arch/msg/homenet/LOQWwAchZ7VGYfg2FheFuVeCyHg>
Subject: Re: [homenet] securing zone transfer
X-BeenThere: homenet@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: IETF Homenet WG mailing list <homenet.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/homenet>, <mailto:homenet-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/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, 13 Jun 2019 01:25:37 -0000

Juliusz Chroboczek <jch@irif.fr> wrote:
    > Are you assuming here there's a central Homenet controller that presents
    > a web interface where the "house owner" can choose which names get
    > published?

No, we are assuming that there are one or more homenet routers that either
come with a delegated domain from the manufacturer (probably a very ugly
one), or which that CPE's ISP will delegate via DHCPv6. (or both)

Whether we should or have to do some negotiation over HNCP if there are
multiple CPEs is a problem we can deal with later.

We have, however, been thinking about the problem of having partial
connectivity for the home, and how do published names get resolved.

    > I'm probably missing something, Michael, so please explain if you agree
    > with the analysis above, whether you're assuming a central controller,
    > and, if so, where is the central controller located in a network that has
    > multiple edge routers.

If an end user wants a non-ugly domain, and they buy it, then they need to
introduce one or more of their CPEs to the upstream provider of the
domain.  It could be it is at this point that it makes sense to do some HNCP,
but in essence, this is an internal problem, and the front-end-naming
document is not about internal issues.

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