Subject: [homenet] Delegating Naming Architectures

From: Daniel Migault <[email-masked]>
Date: Tue, 3 Jul 2012 12:11:54 +0200

Hi,

Please find two Naming Architectures we would like to discuss at Vancouver:
    - "IPv6 Home Network Naming Delegation Architecture"
http://www.ietf.org/internet-drafts/draft-mglt-naming-delegation-00.txt
    - "Home Network Front End Naming Delegation"
http://www.ietf.org/internet-drafts/draft-mglt-front-end-naming-delegation-00.txt

Comments and suggestions are welcome.

Best Regards

Daniel

Abstract: "IPv6 Home Network Naming Delegation Architecture"

   This document describes the Naming Delegation Architecture that makes
   IPv6 Home Network globally reachable with Names or Fully Qualified
   Domain Names (FQDN).  In this architecture, the Customer Premise
   Equipment (CPE) acts as the DNS Authoritative Server of the Home
   Network also called the Delegated DNS Server.  The Naming Delegation
   is configured between the Delegated DNS Server and the Delegating DNS
   Server managed by the ISP.

   The use case considered in this document is an End User that
   subscribes its ISP a specific Delegated Domain for its Home Network.
   This document describes how the CPE automatically sets the Naming
   Delegation between the Delegating and Delegated DNS Server.

   The Naming Delegation is requested by the CPE.  The CPE DHCP Client
   and the ISP DHCP Server exchange DHCP Options to properly set the
   Naming Delegation.  More specifically, the CPE DHCP Client (resp. the
   ISP DHCP Server) configures the DNS(SEC) Zones of the Delegated DNS
   Server (resp. Delegating DNS Server).  For the Delegating DNS Server,
   the necessary pieces of information required to set the Naming
   Delegation are the IP address of the Delegated DNS Server, and if
   DNSSEC is used, the Delegation of Signing Information.  For the
   Delegated DNS Server, the necessary information is the Delegated
   Domain associated to the Home Network.

Abstract: "Home Network Front End Naming Delegation"

   This document proposes a Naming Delegation Architecture that makes
   possible End Users to reach the hosts or services of their Home
   Network using Names instead of IP addresses.

   This document shows how the Naming Delegation between the CPE and the
   ISP can be set so the CPE is not exposed on the Internet.  This
   document describes an Naming Architecture where ISPs provide Front
   End Delegating DNS Servers whereas the CPEs constitute a Back End
   Network of Delegated DNS Servers.  All DNS queries for any Home
   Network are addressed to the Delegating Front End Server.  The
   response is expected to be stored on a CPE, and the Front End
   Delegating DNS Server sends a DNS Query to that CPE before answering
   to the initial DNS query.

   The negotiation between the CPE and the ISP is using DHCP Options.
   This document provides options so Front End Delegating and the
   Delegated DNS Servers configure their respective Zone files and so
   that CPEs restrict access and protect themselves from unauthorized
   DNS Queries.

-- 
Daniel Migault
Orange Labs -- Security
+33 6 70 72 69 58

---

From: Mark Townsley <[email-masked]>
Date: Fri, 6 Jul 2012 17:33:45 +0200

Daniel, 

Just a bit of housekeeping... If you intend for these drafts to be considered by homenet, it's much easier for everyone if "homenet" is somewhere in the filename of the draft. Please consider resubmitting, if that is your intention. 

Thank you,

- Mark

On Jul 3, 2012, at 12:11 PM, Daniel Migault wrote:

>     - "IPv6 Home Network Naming Delegation Architecture"  http://www.ietf.org/internet-drafts/draft-mglt-naming-delegation-00.txt
> 
>     - "Home Network Front End Naming Delegation" http://www.ietf.org/internet-drafts/draft-mglt-front-end-naming-delegation-00.txt
> 
> 
> _______________________________________________
> homenet mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/homenet

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Mon, 16 Jul 2012 16:09:39 +0200

On Tue, Jul 03, 2012 at 12:11:54PM +0200,
 Daniel Migault <[email-masked]> wrote 

> Please find two Naming Architectures we would like to discuss at Vancouver:

I won't be in sunny British Columbia but I've read the drafts and I
have a philosophical question. You did not say clearly if the
delegated domain must be under an ISP's domain. If yes, it ties the
user to the ISP ("I've switched ISPs, use
<http://fridge.migault.free.fr/> and no longer
<http://fridge.migault.orange.fr/>"). If no, the ISP won't be able to
update the DNS delegation. IMHO, it would be a good idea to have a
high-level discussion of the service provided to the user, before
getting into protocol details.

A technical remark: since the DS record is sent by the client, one can
assume that it may suddenly be a new one (key rollover). Then, DNSSEC
validation will break for validators which have the old DS in the
caches. Two possible solutions: have a very low TTL, or just say that
it is the client's job to do rollovers properly (having two DS in
parallel, etc). The second solution implies that the CPE includes
rollover logic (like OpenDNSSEC does). DNSSEC in practice is hard and
you may want to have two drafts, one without DNSSEC and one for DNSSEC
gory details.

Also, a security remark. When you say:

> First delegation preserves the Home Network privacy, by avoiding ISP
> to know the Home Network hosts.

It certainly deserves a mention in Security Considerations saying that
it is a limited protection. Many names will be predictible ("printer",
"fridge", "nas", "iPad") and also the first DNS request to the parent
domain (which is probably controlled by the ISP) will include the
FQDN, thus revealing a name. (And I did not even mention the ability
of the ISP to sniff the network.)

---

From: Michael Richardson <[email-masked]>
Date: Mon, 16 Jul 2012 10:31:13 -0400

>>>>> "Stephane" == Stephane Bortzmeyer <[email-masked]> writes:
    Stephane> I won't be in sunny British Columbia but I've read the drafts and I
    Stephane> have a philosophical question. You did not say clearly if the
    Stephane> delegated domain must be under an ISP's domain. If yes, it ties the
    Stephane> user to the ISP ("I've switched ISPs, use
    Stephane> <http://fridge.migault.free.fr/> and no longer
    Stephane> <http://fridge.migault.orange.fr/>"). If no, the ISP won't be able to
    Stephane> update the DNS delegation. IMHO, it would be a good idea to have a
    Stephane> high-level discussion of the service provided to the user, before
    Stephane> getting into protocol details.

This is an important concern, but given that 90% of residential
customers already have this problem with their email addresses, I do not
think it's a new issue.  More clueful users have moved away from ISP
domains, and they will also do the same thing for their home networks.

So, we need to mandate those controls, and we need to think about
transition from one ISP to another, but the immense value of having
names automatically delegated from the ISP exceeds the pain of an
eventual switch.

    Stephane> caches. Two possible solutions: have a very low TTL, or
    Stephane> just say that 
    Stephane> it is the client's job to do rollovers properly (having two DS in
    Stephane> parallel, etc). The second solution implies that the CPE includes
    Stephane> rollover logic (like OpenDNSSEC does). DNSSEC in practice
    Stephane> is hard and 
    Stephane> you may want to have two drafts, one without DNSSEC and
    Stephane> one for DNSSEC 
    Stephane> gory details.

That's an interesting solution to the problem... "basic" and "secure" :-)

-- 
Michael Richardson <[email-masked]>, Sandelman Software Works

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Mon, 16 Jul 2012 16:36:38 +0200

On Mon, Jul 16, 2012 at 10:31:13AM -0400,
 Michael Richardson <[email-masked]> wrote 
 a message of 80 lines which said:

> customers already have this problem with their email addresses, I do
> not think it's a new issue.  More clueful users have moved away from
> ISP domains, and they will also do the same thing for their home
> networks.

My point was not "this technique is broken" but "the exact service
must be clearly stated". For instance, a high-level discussion at the
beginning of the draft explaining that these names are tied to the ISP
and the consequences (switching pain).

---

From: Zhen Cao <[email-masked]>
Date: Wed, 18 Jul 2012 20:10:10 +0800

Hi Daniel ,

I have read the drafts, and found the problem you would like to solve
very interesting. Thanks for the work.

Before going to the details of the solution part, I have some
questions about the necessity of home network naming delegation.
There are already technologies that make the home devices accessible
from the outside, e.g., RFC6281, the back-to-my-mac solution, and DDNS
solution RFC2136.

I tried to get the answer by myself, e.g., the integration of this
functionality into CPE makes the homenet devices more configurable,
etc... But I would very like to hear your opinion about the answer.
And I suggest the document to include a section of comparison with
existing tech.

Best regards,
-----------
Zhen/CMCC Labs

---

From: Daniel Migault <[email-masked]>
Date: Mon, 30 Jul 2012 07:06:37 +0200

Hi Mark,

Thanks for the comment. I am re-submitting the drafts tonight, with the
homenet in the file name.

BR,

Daniel

On Fri, Jul 6, 2012 at 5:33 PM, Mark Townsley <[email-masked]> wrote:

>
> Daniel,
>
> Just a bit of housekeeping... If you intend for these drafts to be
> considered by homenet, it's much easier for everyone if "homenet" is
> somewhere in the filename of the draft. Please consider resubmitting, if
> that is your intention.
>
> Thank you,
>
> - Mark
>

-- 
Daniel Migault
Orange Labs -- Security
+33 6 70 72 69 58

---

From: Daniel Migault <[email-masked]>
Date: Mon, 30 Jul 2012 07:54:33 +0200

Hi Stéphane,

Thank you for reading the drafts. My responses are added in the text.

On Mon, Jul 16, 2012 at 4:09 PM, Stephane Bortzmeyer <[email-masked]>wrote:

> The delegated domain name is under the ISP domain. If that is not clear,
we will clarify it in the next version.
In the current document, when the end user changes ISP, it has to change
its domain name too. Actually the service the ISP provide name
connectivity. Like IP addresses, phone numbers, email addresses, they are
resources provided by the ISP and people understand that changing ISP, in
most cases requires these resources to be changed. As Michael mentioned it
is an important concern but not a new issue.
The service ISP provides is different from providing a FQDN as registrars
do. In order to benefit from this latest service, the end user can use
CNAME/DNAME. CNAME / DNAME would need to be updated only when the end user
changes ISP, rather than any time the Homenetwork is being assigned a new
prefix.

However, we will clarify this in the next version.

> Good points. First we have to mention these two alternatives in the next
version, even though, I think we will consider it is the client's job to
perform the key rollover.  Secondly, the current document does not make
possible to send multiple DS, so we have to add this in the next version.

I am not sure we need to split the draft for DNS and DNSSEC, but we will
ask the WG.

> of the ISP to sniff the network.)

You are right it is a limited protection. ISPs have means to determine the
mostly used FQDN of a zone. However, this requires much processing, than if
the end user provides the list of its fqdn's hosts. We will mention this in
the next version too.

Thank you for reading the documents!

Daniel

-- 
Daniel Migault
Orange Labs -- Security
+33 6 70 72 69 58

---

From: Michael Thomas <[email-masked]>
Date: Mon, 30 Jul 2012 12:08:54 -0700

On 07/29/2012 10:54 PM, Daniel Migault wrote:
> On Mon, Jul 16, 2012 at 4:09 PM, Stephane Bortzmeyer <[email-masked] <mailto:[email-masked]>> wrote:
>
>      Daniel Migault <[email-masked] <mailto:[email-masked]>> wrote
> The delegated domain name is under the ISP domain. If that is not clear, we will clarify it in the next version.

Shouldn't we consider the case of over the top providers too? That is, suppose
that, oh say, google wanted to get into the DNS naming business. There's nothing
really stopping them or anybody else, nor do I think we should limit them.

I'm a little confused by the section of why DHCP is needed here between ISP
and CPE. With bind, for example, it's very easy to set up an authoritative server
to be a slave for zone transfers. That is, you can set up CPE to be the master of
zone information and do zone transfers to an authoritative server with lots of
bandwidth, etc. This has the property that it decouples the locality requirement
with DHCP, so yahoo-names works too in addition to $ISP.  And of course, it need
not involve CPE at all because naming could all be done as a web UI to their
DNS servers.

Mike