Subject: Re: [homenet] Name service design principles: a proposal

From: Evan Hunt <[email-masked]>
Date: Tue, 3 Jul 2012 22:44:56 +0000

+1 to everything Curtis said here.  I will amplify one point: DNSSEC
trust anchors can be configured when shipped (and are in fact included in
every BIND 9 release, though they're not trusted unless you say so in
named.conf).

The only trust anchor you really need is the key for the root zone, and
optionally for a DNSSEC Lookaside Validation zone such as dlv.isc.org,
and both of these can keep themselves up to date using RFC 5011 trust
anchor management.  Depending on how things are set up on your network,
you might want to have your system automatically generate a key for
.local or .lan or whatever you call the private namespace, but that
shouldn't be necessary in most cases.

This is fiddly, but it's not hard -- my ISCwrt router at home meets
more-or-less all of these needs using BIND 9 and ISC DHCP.

On Sat, Jun 30, 2012 at 10:27:43PM -0400, Curtis Villamizar wrote:
> I'm not sure that some of the respondents later in this thread
> understand what DNS can do already with no changes.
> 
> 1.  An important domain that is visible to the outside world can also
>     remain available even if the Internet is not available.
> 
>     Local hosts which use DHCP can be told to query a local DNS cache.
>     That DNS cache can be a DNS secondary (or primary) to your
>     enterprise's domain, or a local domain.  As a primary, it never
>     expires.  As a DNS secondary it can continue to serve DNS queries
>     for the domain when the Internet is unavailable until the zone
>     file expires (typically days).
> 
>     Example: In every well run enterprise today, the local DNS caches
>     are DNS primary or DNS secondary for the local domain.
> 
> 2.  A local domain can be either visible to the Internet or not
>     visible.  It is also possible to provide different results locally
>     and to the Internet.
> 
>     You can create a .local domain that can't be reached except by 
> 
>     The NS record available to the outside world can point to a
>     different nameserver than the set of nameservers for that same
>     domain that are used internally.  This gets annoying for remote
>     users when switching the enterprise VPN on and off, but otherwise
>     it works just fine.  [btw- An alternate that avoids the VPN issue
>     is to create site specific subdomains that are not visible to the
>     outside world.]
> 
>     Example: Most enterprises reuse their domain internally, serving
>     up their name resolutions to private addresses, but only provide
>     the name resolution for the hosts with global addresses to the
>     outside world.
> 
> 3.  Devices can already register their own host name to IP address
>     mapping.
> 
>     Dynamic DNS is far from a new concept.  A DHCP client can provide
>     its own host name when retrieving an address.  The DHCP server can
>     be coupled to a DNS cache which adds the forward (and optionally
>     reverse) DNS mappings to the appropriate zones until the DHCP
>     lease expires.
> 
>     Example: ISC dhcpd and ISC bind can be coupled in this way.  [Not
>     intended as an endorsement.  No doubt many others can as well.]
> 
> Others have suggested DNSSEC.  That may conflict with the zero
> configuration goal unless a trust anchor is supplied at shipment time.
> Zero configuration and the existing cert hierarchy seem to me to be
> conflicting goals, but I'd be open to being told otherwise.
>
> The "zero configuration" goal implies that the default configuration
> for the homenet router in isolation (no other routers discovered) must
> be to serve as a DNS cache, offer a .local domain, and add an entry
> into the .local domain for any DHCP lease allocated.  If other homenet
> routers are discovered, then some form of election is needed to figure
> out a DNS primary for the .local domain.
> 
> One could argue that the homenet router could also get a proper domain
> name from the provider, but most providers will give their domain name
> in response to DHCP queries.  If the provider is know to provide a
> useful domain name, then trusting the domain offerred by the provider
> can be a simple configuration override.
> 
> Simple configuration could substitute a real domain name for the
> .local default name.  Whether to supress providing local mappings to
> external queries could also be a simple configuration knob.
> 
> We need a extremely strong motivation to reinvent the wheel on
> something as fundamental as name resolution.  I don't see that we have
> any unmet requirement that can't be solved using DNS as the basis.  I
> admit that we can't use any of the existing freely available DNS
> server software (that I am aware of) because it does not do anything
> useful in the absense of configuration and configuration is overly
> complex for homenet use.

--
Evan Hunt -- [email-masked]
Internet Systems Consortium, Inc.

---

From: Curtis Villamizar <[email-masked]>
Date: Mon, 09 Jul 2012 00:16:37 -0400

Evan,

Just one point:

> The only trust anchor you really need is the key for the root zone

If the local network is going to work in the absense of connection to
the Internet (even permanent lack of Internet connectivity as in a low
power homenet with nothing but local devices powered on - home alarm,
thermostats, etc), then a local trust anchor is needed as well.

BTW- The Bind9 ARM gives an example with trusted-keys configured.  The
dnssec-lookaside statement is not well documents, but might also be
useful.

Curtis

In message <[email-masked]>
Evan Hunt writes:

--
Evan Hunt -- [email-masked]
Internet Systems Consortium, Inc.
_______________________________________________
homenet mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/homenet

---

From: Jari Arkko <[email-masked]>
Date: Mon, 09 Jul 2012 13:32:20 +0300

Hi,

We've submitted a new version of our OSPFv3-based prefix assignment draft. This version adds quite a bit of detail to the algorithm, describes ULA prefix generation, etc.

Here's the link:

http://tools.ietf.org/html/draft-arkko-homenet-prefix-assignment-02

Comments appreciated.

Jari

---

From: Mikael Abrahamsson <[email-masked]>
Date: Mon, 9 Jul 2012 13:30:42 +0200 (CEST)

On Mon, 9 Jul 2012, Jari Arkko wrote:

> Hi,
>
> We've submitted a new version of our OSPFv3-based prefix assignment draft. 
> This version adds quite a bit of detail to the algorithm, describes ULA 
> prefix generation, etc.
>
> Here's the link:
>

Hi,

I haven't really read up what has been discussed historically here, so 
please have patience in case I am rehashing what has already been 
discussed.

>From reading the text it is not clear to me exactly what deployment 
scenario the text is meant to handle. Some ascii drawings might help? I've 
been pondering how to solve a few different problems for deployment, for 
instance the problem of the customer having a CPE with a live DHCPv6-PD 
prefix, unplugging it by means of power-off, and then putting in another 
CPE. If only a single prefix is allowed on the link, then the customer 
would have to wait until the PD lease expires until the new CPE can get 
one (the same problem exists for IPv4 as well, in case only a single IPv4 
address is allowed and the customer just powers off the CPE without doing 
DHCP RELEASE first).

I've been considering allowing 4 concurrent PD prefixes, for instance the 
customer has a statically configured /56 as PD pool, a /64 on-link (which 
is not from the /56 space), and then handing out /58 with PD from the 
customer-unique /56. This would mean that the deployment scenario might in 
worse case look like this:

ISP handoff switch/router
           |/64
   -----customer switch----------------
   |      |      |         |      |   |
  CPE1  CPE2   CPE3      CPE4    PC1 PC2
  /58PD /58PD  /58PD     /58PD
   |      |      |---|
  L2    CPE5   CPE6 CPE7
   |      |      |   |
  PC3    PC4   PC5  PC6

This is in a ETTH scenario, or could also be over for instance DSL where 
the modem is a bridged L2 handoff. To solve the "power off" problem, I 
guess it might work with a /57 per CPE as well, and hope the customer long 
term only wants to have a single CPE.

Are CPE1-4 going to talk OSPFv3 between them on the link there according 
to the draft, or is this just for the CPE3/CPE6/CPE7 shared segment?

-- 
Mikael Abrahamsson    email: [email-masked]

---

From: Acee Lindem <[email-masked]>
Date: Mon, 9 Jul 2012 10:21:34 -0400

Hi Mikael,
See inline.

>   -----customer switch----------------

Normally, an auto-configured OSPFv3 CPE will not run OSPFv3 on the link toward the ISP. However, the auto-detection is not standardized. 
Excerpted From the OSPFv3 auto-configration draft:

  2.  OSPFv3 SHOULD be auto-configured on for IPv6 on all interfaces
       intended as general IPv6-capable routers.  Optionally, an
       interface MAY be excluded if it is clear that running OSPFv3 on
       the interface is not required.  For example, if manual
       configuration or an other condition indicates that an interface
       is connected to an Internet Service Provider (ISP), there is
       typically no need to employ OSPv3.  However, note that in many
       environments it can be useful to test whether an OSPFv3 adjacency
       can be established.  In home networking environments, an
       interface where no OSPFv3 neighbors are found but a DHCP prefix
       can be acquired may be considered as an ISP interface.

Thanks,
Acee

---

From: Mikael Abrahamsson <[email-masked]>
Date: Mon, 9 Jul 2012 18:02:06 +0200 (CEST)

On Mon, 9 Jul 2012, Michael Richardson wrote:

> I'm wondering if you can describe your case, which you write as ETTH. 
> The deployments that I've done to date, ETTH has either been GPON (so we 
> have a CPE device just like cable), or we the customer comes in 
> aggregated on a VLAN, so in fact the switch at the data centre annotates 
> the DHCP request when it relays it.

When you say "annotates", do you mean "option 82"? In that case, yes, this 
is done here as well, but if the customer powers off their device, the 
DHCP lease is not invalidated.

Deployment cases are ETTH as in "L2 switch in the basement connecting the 
customer apartment" and DSL as in "L2 dslam and L2 bridging modem" (or 
modem doing "hybrid", ie IRB). In neither case the DHCP lease is 
invalidated when the customer access link goes down.

---

From: Evan Hunt <[email-masked]>
Date: Mon, 9 Jul 2012 16:49:21 +0000

> thermostats, etc), then a local trust anchor is needed as well.

Maybe, not necessarily.

If the validating resolver and the authoritative name server are separate
entities, then yes; the resolver will need a trust anchor to believe what
the authority server says.

If they're the same box, though, then it can answer authoritatively for
names in ".local" and recursively for everything else, and it would only
bother with validation on the recursive answers.  (That's how BIND 9 works,
anyway; I'm not particularly knowledgable about other DNS software.)

---

From: Mikael Abrahamsson <[email-masked]>
Date: Mon, 9 Jul 2012 18:54:45 +0200 (CEST)

On Mon, 9 Jul 2012, Michael Richardson wrote:

> Yes, but the option 82 may let one find the right lease to reuse.

I have not seen this used in real life (as it involves invalidating 
existing lease and tell existing lease owner about it). Do you have any 
references to implementations of this behaviour?

---

From: Mikael Abrahamsson <[email-masked]>
Date: Mon, 9 Jul 2012 18:56:03 +0200 (CEST)

>       can be acquired may be considered as an ISP interface.

Ok, sounds good, sounds like it would do what I want.

PS. There is a typo approx halfway in, text says "OSPv3", not "OSPFv3".

---

From: Curtis Villamizar <[email-masked]>
Date: Mon, 09 Jul 2012 21:16:56 -0400

> anyway; I'm not particularly knowledgable about other DNS software.)

A local trust anchor is needed for the isolated network with more than
one router.  This is true for address allocation and routing if they
are authenticated (they should be IMHO), and for dnssec if used.

Curtis

---

From: Evan Hunt <[email-masked]>
Date: Tue, 10 Jul 2012 02:59:44 +0000

> one router.

Agreed there.

---

From: Michael Thomas <[email-masked]>
Date: Tue, 10 Jul 2012 07:37:15 -0700

>> A local trust anchor is needed for the isolated network with more than

Ok, here's my ignorance. If we want a local DNSsec trust anchor -- which
seems like a reasonable want -- how do those root keys get into each client
host? And what happens if I visit my neighbor's homenet with my phone,
does that imply that I have to enroll with his root keys?

And what happens if I can see more than one homenet domain and I use
multiple interfaces, say, depending on WIFI strength. Do I enroll in both?
Do I use both? Isn't there the implication that I'd want to use each namespace?
As in what does it mean to have washer.local and dryer.local when we both
have a washer.local and dryer.local in our respective namespaces?

Mike, this is not entirely academic for me...

---

From: Michael Thomas <[email-masked]>
Date: Tue, 10 Jul 2012 09:18:45 -0700

On 07/10/2012 08:14 AM, Michael Richardson wrote:
>
>      >>> A local trust anchor is needed for the isolated network with
>      >>> more than one router.
>
>      >> Agreed there.
>
>      Michael> Ok, here's my ignorance. If we want a local DNSsec trust
>      Michael> anchor -- which seems like a reasonable want -- how do
>      Michael> those root keys get into each client host? And what happens
>      Michael> if I visit my neighbor's homenet with my phone, does that
>      Michael> imply that I have to enroll with his root keys?
>
> I really think we should find a way to limit our scope here.
>
> First, we need a bit of localhost behaviour on the part of secure
> resolvers to understand that the trust anchor for .local (or .home.lan
> or... have we even decided that part yet?) is network dependant.
>
> Given that, we might not actually care that multiple routers answer
> a signed .local with different signatures.
> We either trust one, some, or none.  We might create some mechanism
> whereby a .local trust anchor goes into global DNS somewhere.
> e.g. _router1._local_trust_anchor.michaelthomas.com
> but, can we make that out of scope for now?

Even if we only have one .local, or whatever the root is, how
does that root's key get into clients?

And I'd think it's pretty important that the local names for my house
cannot be spoofed by a local name for your house just because I
happened to visit and some auto-conf magic happened because I
wanted to talk to your fridge. Which to me seems that a .local root
gets into a lot of trouble with (malicious) namespace collisions when
you're talking about mobile devices.

>
>
> Second, if we agree that if we have more than one router with a .local
> name server that answers securely, then we need to decide how things
> are signed.

Is this specifically coupled to a "router", or just the generic "thing
in my house that might have a DNS server in it"?

>
> Third, maybe we do not need more than one secure .local name server
> in a network that has more than one router.
>

Seriously, I can see my neighbor's wifi, and I have access to his
(guest) net. This problem is already here.

Mike

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 10 Jul 2012 17:32:27 +0100

On 10/07/2012 17:18, Michael Thomas wrote:
...
> (guest) net. This problem is already here.

.local is a problem in exactly the same way that RFC1918 is a problem.
For homenet, we should really do better (as ULAs do better than RFC1918).

If you want something that walks and talks like a locally defined,
locally significant TLD, then that's exactly what you'd better have.
So it needs to be .<uniqueString> not .<wellKnownString>

   Brian

---

From: Don Sturek <[email-masked]>
Date: Tue, 10 Jul 2012 09:50:34 -0700

Hi Brian,

The complication to what you wrote below is the current sale of internet
suffixes by ICANN.   It will no longer be clear that .<uniqueString> would
not conflict with another suffix on the wider internet (or could in the
future).

I think, in the current environment, we will be lucky to get allocation of
a fixed string like <.wellknownString> for free in local home
environments.  We (the Homenet group) should decide on a useful, unique
suffix for local services and see if we can get that reserved by ICANN for
local services (and not later sold).

Don

---

From: Michael Thomas <[email-masked]>
Date: Tue, 10 Jul 2012 10:01:06 -0700

> So it needs to be .<uniqueString> not .<wellKnownString>

I agree. Though it's a little unfriendly to type in a FQDN for a
ULA-like-statistically-unique name, right? It would be sort of nice
to finesse this.

Mike

---

From: Ray Hunter <[email-masked]>
Date: Tue, 10 Jul 2012 19:48:22 +0200

+1 on the need for a local trust anchor if users want authentication

Without a local trust anchor, how are we ever going to do authenticated 
reverse resolution of the ULA space?
Without a local trust anchor, how would we guarantee stand-alone 
operations (of DNSSEC)?

+1 on the need for a unique/identifiable name space

<uniqueString>.<well-known-string>. might work. e.g. .<ULA>.homenet.

then indeed you'd have to "enroll" with a homenet to be able to trust 
it's namespace if you wanted authentication.
But at least the namespace would be pretty unique once you did so, even 
for highly mobile devices.
Bootstrapping the namespace wouldn't seem to be a problem, as the ULA 
prefix can be detected by all devices.

In the unlikely event of two homenets choosing the same ULA, and thus 
having overlapping namespace as detected by a highly mobile device, I 
guess there'd have to be some sort of tie-breaker e.g. the trust anchor 
itself, or the user is warned and manually regenerates a new ULA for one 
of her homenets. FYI RFC6821 uses ULA as a unique host identifier.

regards,
RayH

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 10 Jul 2012 20:15:16 +0100

Don,

> local services (and not later sold).

<politics>
I don't think we should worry unduly about this. The IETF/IANA MoU allows
the IETF to define TLDs for technical purposes, and instruct IANA accordingly.
A family of TLDs for local use is clearly within that scope.
</politics>

On 10/07/2012 18:01, Michael Thomas wrote:

> ...Though it's a little unfriendly to type in a FQDN for a

Good point. Maybe we can use some kind of wild card trick.

    Brian

---

From: Ted Lemon <[email-masked]>
Date: Tue, 10 Jul 2012 15:30:19 -0400

> Good point. Maybe we can use some kind of wild card trick.

I think it's wrong-headed to try to use unqualified domain names to make the user's life easier.   The problem is that in doing so, you are setting up a security model for them that has implications they typically have no hope of understanding.   If you really want convenient naming, the security model has to be carefully thought out, and the method of delivery of those names has to be carefully specified.   Whatever you wind up with, it will not be DNS or mDNS.   Trying to use DNS to securely deliver site-local naming with a shared root is trying to fit a square peg into a round hole.

---

From: SM <[email-masked]>
Date: Tue, 10 Jul 2012 12:30:52 -0700

Hi Brain,
>A family of TLDs for local use is clearly within that scope.

   'IANA understands that a single IANA action is required to be completed
    upon approval of this document.

    IANA will create a new registry for "Special Use Domain Names."  The
    registry will consist of domain names and references to IETF Standards
    Action documents that document the special meaning of the name. The
    initial registry is empty. Adding new entries to the registry for
    Special Use Domain Names requires Standards Action.'

The document is in the RFC Editor queue.

Regards,
-sm

---

From: james woodyatt <[email-masked]>
Date: Tue, 10 Jul 2012 12:52:16 -0700

On Jul 10, 2012, at 10:01 , Michael Thomas <[email-masked]> wrote:
> 
> ...Though it's a little unfriendly to type in a FQDN for a ULA-like-statistically-unique name, right?

Hummm, or maybe we should think about whether typing characters on keyboards is *ever* a good human interface for the most common home networking scenarios.

What if we designed a name service that, rather than expecting humans to have a keyboard with which to type out wackily encoded FQDNs--character by character, and hoping they spell the name right with all the fiddly punctuation and everything--we instead designed one that naturally facilitates a human interface built around presenting the human with ordered, readable, collections of names, which allows them to choose the ones corresponding to the services they want to use? What if we went further and designed it with a meta-service discovery feature, so you could use it to discover the domains in which services may be discovered?

Would that help?

What if IETF already had such a name service in hand, i.e. I-D.cheshire-dnsext-dns-sd, which is already designed, deployed and proven to work well in home networking scenarios? (Yes, it has the meta-service discovery feature too, c.f. section 11, Discovery of Browsing and Registration Domains.)

Would *that* help?

--
james woodyatt <[email-masked]>
member of technical staff, core os networking

---

From: Ted Lemon <[email-masked]>
Date: Tue, 10 Jul 2012 16:33:36 -0400

> What if IETF already had such a name service in hand, i.e. I-D.cheshire-dnsext-dns-sd, which is already designed, deployed and proven to work well in home networking scenarios? (Yes, it has the met…

Yes, that's the sort of thing I was talking about.   However, I don't think it answers the trust anchor question.

---

From: james woodyatt <[email-masked]>
Date: Tue, 10 Jul 2012 15:26:50 -0700

On Jul 10, 2012, at 13:33 , Ted Lemon <[email-masked]> wrote:
> 
> However, I don't think it answers the trust anchor question.

I think we can answer your "trust anchor question" as posed, then we will *also* have figured out how to use DNSSEC to secure the "local." domain as it is used in I-D.cheshire-dnsext-mdns.  Before going there, I think I would start by questioning whether any cryptographic system based on the PKI is the right choice in these scenarios.

---

From: Michael Thomas <[email-masked]>
Date: Tue, 10 Jul 2012 18:11:06 -0700

On 07/10/2012 01:10 PM, Michael Richardson wrote:
> I'm gonna repeat what I said:
>
>      >> resolvers to understand that the trust anchor for .local (or
>      >> .home.lan or... have we even decided that part yet?) is network
>      >> dependant.
>
>      Michael> Even if we only have one .local, or whatever the root is,
>      Michael> how does that root's key get into clients?
>
> So, it's not just a question, as you observed, of getting the .local
> anchor in, but to know *which* .local anchor to use.
> They are all valid "from a certain point of view".
> ("This is not the androids.local you are looking for!")

Yes. As in, enrollment is hard :)

>
> If .local was never signed, but in a homenet-compliant network, instead
> returned
>        foo.local IN CNAME foo.myhouse.something-unique.someisp.net

Just out of curiosity, is there any significance to .someisp.net in
your example? I'd think -- and it's the way I read Brian's note --
that it would stop at .something-unique.

>
> then we are back to how to get a local delegation done.
>
> If you are on your neighbour's wifi, and your fridge is accessible, and
> you have the name fridge.michaelthomashouse.something-unique.someisp.net,
> then you are set, right?

Assuming that I'm not running a split horizon DNS for my .unique, I
suppose it would be. But that sort of leads to weirdness with local
DNS leakage beyond the homenet. I'm not sure what the working
group thinks about boundaries (my bad most likely), but wouldn't
that be one of them?

I believe that James asked whether integrity of some sort was
needed. I wonder if one practical reason why the answer might be
yes is because without it these phones shifting back and forth between
administrative domains purely for network reasons (eg, better
signal strength) wouldn't be able to know which local namespace
they should resolve from.

Mike

---

From: Michael Thomas <[email-masked]>
Date: Wed, 11 Jul 2012 09:28:21 -0700

> Hummm, or maybe we should think about whether typing characters on keyboards is *ever* a good human interface for the most common home networking scenarios.

On the internet at large, I think the world has already decided what interface
it prefers. Search. For better or worse.

Mike

---

From: Michael Richardson <[email-masked]>
Date: Mon, 23 Jul 2012 18:23:21 -0400

>>>>> "Mikael" == Mikael Abrahamsson <[email-masked]> writes:

    Mikael> I have not seen this used in real life (as it involves invalidating existing
    Mikael> lease and tell existing lease owner about it). Do you have any references to
    Mikael> implementations of this behaviour?

I thought that cable networks used the subscriber ID which was inserted
somewhere (option 82 was the obvious place) by the CMTS (the "modem") to
manage leases.  I asked a cable operator and was told, no.  If the
subscribe changes their CPE router, they get new leases in IPv4 land.

It seems, however, to me that a DHCPv6 PD server ought to therefore use
some additional DHCP identifiers to avoid the problem that you noted,
that you wind up having to allocate many prefixes to what ought to be
recognized as a single customer.

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