Subject: [homenet] draft-mglt-homenet-front-end-naming-delegation-01

From: Andrew Sullivan <[email-masked]>
Date: Wed, 7 Nov 2012 11:31:20 -0500

Dear colleagues,

While I was delighted to notice that
draft-mglt-homenet-front-end-naming-delegation-01 had been modified in
response to previous suggestions, such that it removed some of the
more controversial parts of its predecessor, the core remark I made
about the -00 is still true: I think it is way, way too complicated.
I also think it's a nearly solved problem in shipping product to-day.

Best,

A

-- 
Andrew Sullivan
[email-masked]

---

From: "Griffiths, Chris" <[email-masked]>
Date: Wed, 7 Nov 2012 17:46:20 +0000

> I also think it's a nearly solved problem in shipping product to-day.

Andrew,

As one of the newer co-authors on this draft, I am happy to see that the changes we made to the draft have resolved some of the more contentious issues previously brought up.  I would like to understand further if you or other folks in the WG have any suggestions on how we could make this less complex and address naming both in and out of the home.  As an operator who is deploying home network platforms to millions of customers today, I politely disagree that this problem is nearly solved today in shipping products, but could be solved with existing platforms and protocols which desperately needs documentation..  Given the proposed architecture for Homenet, and the ability to have multiple layers of networks, there is going to be a need for a scaled approach to deal with internal and external naming which will need to include service discovery and publishing naming to outside the home.

Thanks

Chris

---

From: Andrew Sullivan <[email-masked]>
Date: Wed, 7 Nov 2012 15:51:34 -0500

Out of order:

On Wed, Nov 07, 2012 at 05:46:20PM +0000, Griffiths, Chris wrote:

> As an operator who is deploying
> home network platforms to millions of customers today, I politely
> disagree that this problem is nearly solved today in shipping
> products, but could be solved with existing platforms and protocols
> which desperately needs documentation.

Yeah, that's probably a fairer description of what I was trying to
say, and I appreciate the correction.

> which desperately needs documentation..  Given the proposed
> architecture for Homenet, and the ability to have multiple layers of
> networks, there is going to be a need for a scaled approach to deal
> with internal and external naming which will need to include service
> discovery and publishing naming to outside the home.

This I strongly agree with.

Mostly, I am worried that this proposal is a cure worse than the
disease.  I've read the draft several times, and I just don't get why
it isn't better to put all this DNS data out in a public DNS server
somewhere, and have everything (including the nodes inside the homenet
boundary) query that.  If you want to reduce traffic, put a DNS
cacheing resolver on the CPE.  Use a simple-minded http-based
injection protocol for DNS data that the CPE can use (we have several
of those deployed, although none is an IETF protocol).

The proposal as it stands includes support for different views; for
mixed-mode authoritative and recursive services in the same resolver,
something we regularly say is a bad thing; and three options for
securing zone transfers, one of which we heard in mdnsext is the
barrier to adoption of unicast DNS DNS-SD.  Many of these tricks --
views in particular -- work only most of the time when careful
administrators set the whole thing up, and so I'm worried that we're
not going to be able to build automatic tools that allow this all to
work completely reliably, _especially_ when inside the homenet most of
the time people will actually get mDNS answers anyway and so there'll
be a mismatch between the name spaces.  It's mostly the complexity of
all of this that troubles me.

How much of it is necessary?  

Best,

A

-- 
Andrew Sullivan
[email-masked]

---

From: Daniel Migault <[email-masked]>
Date: Wed, 7 Nov 2012 17:33:45 -0500

Hi Andrew,

Thank you for your comments, we are considering them for the next version.
I am answering in the text.

> boundary) query that.

The architecture document recommends not to outsource everything in a
server outside the homenet.

3.7.3 <http://tools.ietf.org/html/draft-ietf-homenet-arch-06#section-3.7.3>.
 Name spaces

   It is desirable that only one name space is in use in the homenet,
   and that this name space is served authoritatively by a server in the
   homenet, most likely resident on the CER.

This is actually the only way to provide the Service Naming resolution in
case the connectivity of the homenet to the Internet is down.

3.7.5 <http://tools.ietf.org/html/draft-ietf-homenet-arch-06#section-3.7.5>.
 Independent operation

   Name resolution and service discovery for reachable devices must
   continue to function if the local network is disconnected from the
   global Internet, e.g. a local media server should still be available
   even if the Internet link is down for an extended period.

> If you want to reduce traffic, put a DNS
> cacheing resolver on the CPE.

The goal is not to reduce the traffic but to avoid exposing the CPE to
resource exhaustion by hosting a DNS service on the CPE. However caching
the Resolver may be in some case be a way to replace the what we designated
as the Homenet Authoritative Server. Of course the diagram should be
considered as a functional diagram. We will clarify this in the next
version thanks for the remark.

>  Use a simple-minded http-based

If I understand correctly, you use an http-base protocol to fill the CPE
with the appropriated DNS data. In fact we are doing the reverse. The CPE
has the data and injects the DNS Data to the Public Server, so that it can
properly perform the DNS authoritative service.

Then filling may not be appropriated, since we need to properly manage the
Public Server with appropriated data (updating information  checking
versions...). These requirements are addressed by IETF defined protocols,
benefit from multiple implementations and a lot of experience. We do not
see any reasons to do something different. On the other hand, we may also
provide some alternatives, for specific use cases. We will do that in the
next version, feel free to send these use cases on the Mailing list.

> something we regularly say is a bad thing;

In the most common case, the DNS zone hosted by the CPE is only requested
by the Resolver. The diagram should be considered as a functional diagram.
In most common cases, the Authoritative Server will be more like a file or
cached in the resolving server. Thanks for the remark, we will clarify this
in the next version.

However you are right that in some case the Authoritative Server will be
hosted by the CPE. We still believe it is more realistic to host the
Resolving Server and the Authoritative Server on a same device, than to ask
the End User to have an additional box for their Authoritative Server. Port
binding, firewall rules on that boxe probably match the BCP. The main
advantage of having this configured in the box is that most of the
misconfiguration issues may be avoided.

and three options for
> all of this that troubles me.

Views are optional. Can you provide specific scenarios we need to address?

> _______________________________________________
> homenet mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/homenet
>

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

---

From: Andrew Sullivan <[email-masked]>
Date: Wed, 7 Nov 2012 18:11:26 -0500

> server outside the homenet.

Well, yes, but note also that it says that you want only one name
space.  This requirement is _certainly_ going to be violated in the
medium term, because everyone is using mDNS and there's no evidence
that anyone is ready to back off their plans (the zigbee guys are
cleaving to it).  

The draft as it stands seems to imagine that what people will use is
one namespace, and it'll be DNS.  Ten years ago, I might have said,
"Could happen."  Today, it's impossible.  We are going to have two
namespaces here.  (Yes, a complete review of -arch- is on my TODO.
After today's meeting, at least I've moved it higher in the list.)

> case the connectivity of the homenet to the Internet is down.

That is a good point.  It might be emphasised more strongly in the
draft, unless I'm just missing it (which is possible).

> as the Homenet Authoritative Server. 

Yeah, that's pretty much what I had in mind.  But such a cache
wouldn't solve your "disconnected operation" problem.

> properly perform the DNS authoritative service.

Actually, Dyn (for instance -- full disclosure, they paid for my trip
here) takes updates from many end points via an http-based API.  This
is for information that goes into global DNS servers.  Yes, we could
do this with Dynamic Update, but that involves a more complicated
security model that is poorly understood by the sort of developers who
often work on the end point code.  Telling them, "use TLS and HTTP"
allows them to pick up libraries that we are reasonably confident are
well-developed as opposed to writing code to do TSIG.

> cached in the resolving server. Thanks for the remark, we will clarify this

Well, it's like a file that is interpreted by a server that can send
DNS responses.  I agree the uses aren't manifold, but it's still a
mixed authoritative/recursive server as far as the client is
concerned.  Maybe we've decided that for this case, that's good
enough, but since it's at odds with some experience we've had with the
DNS more generally, it's worth noting it.

> Views are optional. Can you provide specific scenarios we need to address?

My personal view is that views are hateful, but many people seem to think
it's important to hide names when one isn't authorized to use them.
In any case, you're undoubtedly going to need views wherever there's a
NAT and v4.

A

-- 
Andrew Sullivan
[email-masked]

---

From: "Griffiths, Chris" <[email-masked]>
Date: Wed, 7 Nov 2012 23:29:57 +0000

On Nov 7, 2012, at 5:33 PM, Daniel Migault <[email-masked]<mailto:[email-masked]>> wrote:

If I understand correctly, you use an http-base protocol to fill the CPE with the appropriated DNS data. In fact we are doing the reverse. The CPE has the data and injects the DNS Data to the Public Server, so that it can properly perform the DNS authoritative service.

Then filling may not be appropriated, since we need to properly manage the Public Server with appropriated data (updating information  checking versions...). These requirements are addressed by IETF defined protocols, benefit from multiple implementations and a lot of experience. We do not see any reasons to do something different. On the other hand, we may also provide some alternatives, for specific use cases. We will do that in the next version, feel free to send these use cases on the Mailing list.

The way I read this was to use something similar to the several free / commercial ASP services to publish to northbound public DNS platforms via HTTP (I assume Dyn and others fall into this bucket).  I don't disagree with this approach currently, but am curious why we wouldn't simply leverage the DNS protocol to perform these actions.  Either of these components could be primed to the Homenet gateway via configuration and/or automated.  That being said, would providing both options (DNS or HTTP) meet your thoughts here?  Certainly something we could add to the next version of the draft and I don't have a preference either way.

In the most common case, the DNS zone hosted by the CPE is only requested by the Resolver. The diagram should be considered as a functional diagram. In most common cases, the Authoritative Server will be more like a file or cached in the resolving server. Thanks for the remark, we will clarify this in the next version.

However you are right that in some case the Authoritative Server will be hosted by the CPE. We still believe it is more realistic to host the Resolving Server and the Authoritative Server on a same device, than to ask the End User to have an additional box for their Authoritative Server. Port binding, firewall rules on that boxe probably match the BCP. The main advantage of having this configured in the box is that most of the misconfiguration issues may be avoided.

I think something like mDNS and DNS-SD are an alternative to this approach.  I know Stuart Cheshire and team have wide area bonjour working quite nicely and could certainly fill this role and remove some complexity for design. I am curious if the proposed work in MDNSEXT might help with this.

and three options for

Agreed on multiple views, and curious how we can leverage mDNS and other service discovery mechanisms to generate and publish northbound.  Something we certainly want to update the next draft with.