Subject: Re: [homenet] I-D Action: draft-ietf-homenet-front-end-naming-delegation-00.txt

From: Andrew Sullivan <[email-masked]>
Date: Wed, 12 Nov 2014 13:10:03 -0500

Dear colleagues,

On Fri, Sep 19, 2014 at 12:16:30AM -0700, [email-masked] wrote:
> 
> A New Internet-Draft is available from the on-line Internet-Drafts directories.
>  This draft is a work item of the Home Networking Working Group of the IETF.
> 
>         Title           : Outsourcing Home Network Authoritative Naming Service
>         Authors         : Daniel Migault
>                           Wouter Cloetens
>                           Chris Griffiths
>                           Ralf Weber
> 	Filename        : draft-ietf-homenet-front-end-naming-delegation-00.txt

I have read this draft.  I have a few comments.

First, it's worth noting that the current specification means that DNS
queries inside the homenet apparently rely on the availability of the
Public Authoritative Servers.  This is contrary to widely deployed
practice, where gateways often answer for things inside the network.
I'm not opposed to this in principle, but it does mean additional
latency inside the homenet for certain kinds of operations, and it
makes the resolution of names inside the homenet dependent on a
service not subject to the homenet's administration -- one that will
doubtless come under DoS, if experience in the rest of the DNS is any
guide.

Of course, it _has_ to be this way, because the document continues to
recommend that signing happen outside the CPE, and therefore the CPE
can't respond with signed records.  Even if signing did happen on the
CPE, there'd be a problem in that the CPE zone and the public zone
will inevitably be different in the case of any NAT.  (I know, we're
all going to use v6 for this.  And I agree, but we can't actually
specify something guaranteed to break in the case of a v4 NAT.)

But now I wonder how this is going to work in practice, because there
are probably going to be some homenet nodes that one does not want to
have published on the global Internet.  Presumably those names one
will want to access inside the homenet anyway.  I suppose we could say
"use only link-local resolution for those cases", though that of
course restricts us to a single local link and I thought part of what
was driving us was a desire not to have that restriction.  Otherwise,
the CPE has to be a DNS server for some but not all names inside the
homenet, and a forwarder for the rest of them.  That seems a little
complicated.

Since there are not different views, and since the CPE is not listed
in the NS set for the zone, the CPE will never get queried unless it
answers authoritatively without listing itself in the NS set; I
suppose that's another way to do this, but if that's the plan then the
document needs to be clear about it somewhere (if it's there, I'm
sorry to have missed it.  Perhaps it needs to be stated more plainly
in that case).  The recommendation not to use split-brain is clear in
section 7, but the reasoning is opaque.

If the CPE is never going to be queried, then the reasoning in 6.1 # 1
"pro-cpe-signing" doesn't make sense.  The CPE doesn't actually
respond to queries, so who cares if it has an equivalent zone?
Similarly, reason 6.1 # 3 "anti-cpe-signing" seems a little strained
-- don't you have the same problem if you change ISPs?

As a nit, in the SOA description in section 4.2, the SOA Minimum field
was respecified in RFC 2308, so that should be the reference.

Best regards,

A

-- 
Andrew Sullivan
[email-masked]

---

From: Michael Richardson <[email-masked]>
Date: Wed, 12 Nov 2014 16:06:25 -0500

Andrew Sullivan <[email-masked]> wrote:
    > CPE, there'd be a problem in that the CPE zone and the public zone will
    > inevitably be different in the case of any NAT.  (I know, we're all

What about, in the case where the signing is elsewhere, that the CPE should
be a local secondary for the zone?

    > have published on the global Internet.  Presumably those names one will
    > want to access inside the homenet anyway.  I suppose we could say "use
    > only link-local resolution for those cases", though that of course

Use whatever dnssd WG creates for multi-links.

    > driving us was a desire not to have that restriction.  Otherwise, the
    > CPE has to be a DNS server for some but not all names inside the

dnsmasq does exactly this already.... so running code.

-- 
]               Never tell me the odds!                 | ipv6 mesh networks [ 
]   Michael Richardson, Sandelman Software Works        | network architect  [ 
]     [email-masked]  http://www.sandelman.ca/        |   ruby on rails    [

---

From: Andrew Sullivan <[email-masked]>
Date: Wed, 12 Nov 2014 16:27:18 -0500

> be a local secondary for the zone?

Under DNSSEC, either the CPE has to be in the NS RRset (because
otherwise it would fail validation; but this exposes an NS on the CPE
to the world), or else it's not.  I guess the idea is to answer
authoritatively without being in the NS RRset?  Some resilience
mechanisms will treat that as a ijacking attempt, but I suppose if
validation passes they shouldn't.

> Use whatever dnssd WG creates for multi-links.

Yes, well, they're going to have the same problem with DNSSEC for the
same reason.

> dnsmasq does exactly this already.... so running code.

Really?  Last I looked, dnsmasq answered authoritatively for names for
which it was configured.  So you're suggesting that you _not_
configure the names served by the Public Authoritative in the homenet?
The CPE still knows about these, of course, because they're the basis
for the hidden master.

A

-- 
Andrew Sullivan
[email-masked]

---

From: Ted Lemon <[email-masked]>
Date: Wed, 12 Nov 2014 13:19:47 -1000

On Nov 12, 2014, at 11:27 AM, Andrew Sullivan <[email-masked]> wrote:
> I guess the idea is to answer

Why does it need to answer authoritatively?

---

From: Michael Richardson <[email-masked]>
Date: Tue, 18 Nov 2014 00:20:50 -0500

> validation passes they shouldn't.

The CPE is also often the recursive resolvers for the home, so I don't see
the issue.

---

From: James Woodyatt <[email-masked]>
Date: Tue, 18 Nov 2014 10:26:05 -0800

Home gateways are typically not recursive resolvers. They're usually just
translators for non-recursive DNS query/responses. Some have forwarding
servers. There might be some that are recursive resolvers, but there are
lot of good reasons not to put one there, starting with the fact that some
service providers have a nasty habit of running split horizon at their
authoritative resolving servers, and you lose all their lovely additional
differentiating wonderfulness if you bypass their fancy special
star-bellied nameservers and go straight to the root yourself.

On Mon, Nov 17, 2014 at 9:20 PM, Michael Richardson <[email-masked]>
wrote:

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

-- 
james woodyatt <[email-masked]>
Nest Labs, Communications Engineering