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

Juliusz Chroboczek <jch@pps.univ-paris-diderot.fr> Wed, 09 July 2014 01:39 UTC

Return-Path: <jch@pps.univ-paris-diderot.fr>
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 E3FE51A0203 for <homenet@ietfa.amsl.com>; Tue, 8 Jul 2014 18:39:59 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.549
X-Spam-Level:
X-Spam-Status: No, score=-1.549 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_FR=0.35, UNPARSEABLE_RELAY=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 IJf9AdGr8hGK for <homenet@ietfa.amsl.com>; Tue, 8 Jul 2014 18:39:58 -0700 (PDT)
Received: from korolev.univ-paris7.fr (korolev.univ-paris7.fr [IPv6:2001:660:3301:8000::1:2]) (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 EBA531A0202 for <homenet@ietf.org>; Tue, 8 Jul 2014 18:39:57 -0700 (PDT)
Received: from mailhub.math.univ-paris-diderot.fr (mailhub.math.univ-paris-diderot.fr [81.194.30.253]) by korolev.univ-paris7.fr (8.14.4/8.14.4/relay1/46573) with ESMTP id s691dtLL018526 for <homenet@ietf.org>; Wed, 9 Jul 2014 03:39:55 +0200
Received: from mailhub.math.univ-paris-diderot.fr (localhost [127.0.0.1]) by mailhub.math.univ-paris-diderot.fr (Postfix) with ESMTP id C6A832C212E for <homenet@ietf.org>; Wed, 9 Jul 2014 03:39:55 +0200 (CEST)
X-Virus-Scanned: amavisd-new at math.univ-paris-diderot.fr
Received: from mailhub.math.univ-paris-diderot.fr ([127.0.0.1]) by mailhub.math.univ-paris-diderot.fr (mailhub.math.univ-paris-diderot.fr [127.0.0.1]) (amavisd-new, port 10023) with ESMTP id 4vdP0vb0_tS5 for <homenet@ietf.org>; Wed, 9 Jul 2014 03:39:54 +0200 (CEST)
Received: from ijon.pps.univ-paris-diderot.fr (unknown [78.194.40.74]) (Authenticated sender: jch) by mailhub.math.univ-paris-diderot.fr (Postfix) with ESMTPSA id B7BC22C2136 for <homenet@ietf.org>; Wed, 9 Jul 2014 03:39:53 +0200 (CEST)
Received: from jch (uid 1000) (envelope-from jch@pps.univ-paris-diderot.fr) id c00301 by ijon.pps.univ-paris-diderot.fr (DragonFly Mail Agent v0.9); Wed, 09 Jul 2014 03:39:59 +0200
Date: Wed, 09 Jul 2014 03:39:59 +0200
Message-ID: <87d2dfb98w.wl-jch@pps.univ-paris-diderot.fr>
From: Juliusz Chroboczek <jch@pps.univ-paris-diderot.fr>
To: Daniel Migault <mglt.ietf@gmail.com>
In-Reply-To: <CADZyTkmZ+rC99qeC7gFEwc4JBoX9sHBUpo7p89+VC6zY7Z8drQ@mail.gmail.com>
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> <CADZyTk=YgD=JtyDpEz8TXOQmHxKzBoiEZbbW0LhZQy2GaKLqZQ@mail.gmail.com> <87vbrcydr9.wl.jch@pps.univ-paris-diderot.fr> <CADZyTk=kST4zPaPzz4DsAcCOtmYbQo-s2du+nEvJv0MSrneEMg@mail.gmail.com> <CADZyTkmZ+rC99qeC7gFEwc4JBoX9sHBUpo7p89+VC6zY7Z8drQ@mail.gmail.com>
User-Agent: Wanderlust/2.15.9
MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue")
Content-Type: text/plain; charset=US-ASCII
X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.7 (korolev.univ-paris7.fr [194.254.61.138]); Wed, 09 Jul 2014 03:39:55 +0200 (CEST)
X-Miltered: at korolev with ID 53BC9D6B.001 by Joe's j-chkmail (http : // j-chkmail dot ensmp dot fr)!
X-j-chkmail-Enveloppe: 53BC9D6B.001 from mailhub.math.univ-paris-diderot.fr/mailhub.math.univ-paris-diderot.fr/null/mailhub.math.univ-paris-diderot.fr/<jch@pps.univ-paris-diderot.fr>
X-j-chkmail-Score: MSGID : 53BC9D6B.001 on korolev.univ-paris7.fr : j-chkmail score : . : R=. U=. O=. B=0.000 -> S=0.000
X-j-chkmail-Status: Ham
Archived-At: http://mailarchive.ietf.org/arch/msg/homenet/1peX9tp2CHMGo1H_tNOSuIb7zLs
Cc: "homenet@ietf.org" <homenet@ietf.org>
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: Wed, 09 Jul 2014 01:40:00 -0000

Thanks for your patience, Daniel.  I feel I'm understanding a little more
now.  My main misunderstanding was the following:

 - you're not populating DNS with mDNS data, you're populating it with the
   DHCP hostname data; I now understand that mDNS is mostly orthogonal.

What I still don't understand is how your protocol can work when the
hidden master is not the CPE.

> In the architecture document we mention that the CPE is the most likely
> to host the DNS zone for the home network.

I'd really like to encourage you to revise the drafts so that it makes it
clear that the hidden master is not necessarily the CPE.  I'd be
particularly keen to understand how the hidden master can sign the zone
when it is not the CPE, given that you expect signing keys to be obtained
over DHCP.

> I do not think our architecture is bound to the CPE [...] If you could
> point specific sections, that would help to clarify the next versions.

    This document describes a homenet naming architecture where the CPEs
    manage the DNS zone associates to its home network,

    [...]

    the DNS(SEC) Homenet Zone built by the CPE is outsourced to Public
    Authoritative Servers.

    [...]

    The zone signing and secure delegation can be performed either by the
    CPE or by the Public Authoritative Servers.

    [...]

    outsourcing the authoritative naming service from the CPE

...and so forth, and so on.  I'm sure you can see where my confusion stems
from ;-)

> Similarly, I do not recall using the term proxy in one or the other
> draft, and I do not see what could be considered as a proxy.

I fear I wasn't very clear:

1. the homenet nodes populate the master zone at the hidden master (which
   is not at all the CPE, as we've established above) using DHCP;

2. the hidden master (which is not at all the CPE) performs a zone
   transfer to its secondaries (which are not at all the ones hardwired by
   the ISP into the CPE) using normal DNS(SEC) procedures.

So in effect the hostname data is flowing (1) from the node to the hidden
master which (2) forwards it to the authoritative secondaries.  In effect,
it's being proxied from the node to the secondaries by the hidden master.

> In the architecture we propose, things may be as follows: the NAS only
> needs a hostname: myserver for example. You plug the NAS in your home
> network, it announces its name via DHCP. The DHCP transmit the
> information to the entity that manages the DNS zone, which then
> outsource the zone to the registrar. You NAS does not need to be
> configured to update the zone at the registrar.

Ah.  I think that's the crucial point -- it's easier to provide
credentials to a single node rather than to every node that needs to
register in the global DNS.  That makes sense.

So how does the hidden master get the credentials?  You say:

    The DHCP Server makes the Public Key available to the DNS servers, so
    the CPE can secure its DNS transactions.  Note that the Public Key
    alone is not sufficient to perform the authentication [...] How the
    binding is performed is out of scope of the document.  It can be
    a centralized database or various bindings may be sent to the
    different servers.

That speaks about the ISP's DHCP server, right?  But now that we've
established that the hidden master is not the CPE -- it's not necessarily
on the same link as the DHCP server.  Are you assuming a DHCP proxy at the
CPE?

I also don't understand what you mean by "various bindings" in the last
sentence quoted above.  I'd appreciate a clarification.  Perhaps you can
tell us how the private keys are distributed in your implementation?

>>> Suppose your ISP has a connectivity issue, even a node in your home
>>> network will not be able to contact your web server as the DNS(SEC)
>>> resolution is not possible.

>> But my nodes are still running mDNS/zeroconf, right?

> By the way, I am not deprecating the use of mDNS at all it is simply
> orthogonal.

What I meant by that is that you're still running mDNS, so losing
connectivity to the master won't prevent you from resolving using mDNS.
However, I now see that you're not deriving the DNS zone from mDNS, so the
name you're interested in might very well not be advertised over mDNS.

Thanks for your patience,

-- Juliusz