Subject: [homenet] naming, what's the problem?

From: Michael Thomas <[email-masked]>
Date: Mon, 06 Aug 2012 11:30:18 -0700

I've been rereading the charter and the -arch document and they both
seem to make a presumption that we actually know what the problems
are in a homenet. At the very least, I'm not convinced that we've captured
what those problems are. The charter seems to say that we have some
tools (dns, zeroconf...) that we should be able to tweak. The -arch document
seems to be very "device" oriented -- as in from the dns-sd perspective,
where my printer is the canonical example. I think there's more to this.

Maybe an example is in order. I have a weather station:

http://mtcc.com/~mike/sanchez.php

This is not a service to be discovered like a printer, though I might want
to discover it were I to get an off-the-shelf IP enabled version from, say,
oregon scientific. It's much more like a web site. I want to be able to see
it not only at home, but when I'm away so that I can see whether my
Pioneer house has snow in the driveway.

I've done this using v4, but I'm a geek. What I think we want to enable is
non-geeks to be able to install these kinds of devices in a v6 world
with some minimum muss and fuss. That is, we need to account for not
just services, but *servers* in the form of traditional web-headed servers.
That is, the normal browser-centric view of the world.

That browser-centric view of the world knows nothing about .local. Nor
do I want to learn about .local either. I want to have a real name that I
can use as a real URL to send -- as I just did -- to people that might want
to see my weather station. And I want -- literally -- for my mother to be
able to do the same. It is beyond her now.

So there's one problem.

Mike

---

From: David R Oran <[email-masked]>
Date: Wed, 8 Aug 2012 08:32:01 -0400

On Aug 6, 2012, at 2:30 PM, Michael Thomas <[email-masked]> wrote:

> This is not a service to be discovered like a printer,
Why not?

> though I might want
> oregon scientific.
Isn't that the kind of thing we're talking about? If your weather station doesn't do IP, then perhaps it's simply out of scope.

> It's much more like a web site. I want to be able to see
Sure. 

> That is, the normal browser-centric view of the world.
Right, which is why I can bookmark things like OranHomeNas1.local, and my browser does mDNS lookups and finds it just fine.

> That browser-centric view of the world knows nothing about .local.
What browser are you using? Safari and I think Chrome know about .local just fine.

> Nor
For that you definitely need a global DNS domain registration, so we've cycled back to where we started - things you want to be accessed globally from anywhere on the internet need global names that can be resolved from anywhere on the internet.

> So there's one problem.
Yes, and a fairly hard one given the manual/administrative nature of domain registrations and the geek factor of secure dynamic DNS updates for all services to the global DNS. Much as it would be great for Homenet to solve this problem and get a lot more functionality for users, this may be a bridge too far for the current work, which is focused on getting routing and naming INSIDE the home seamless and completely auto-configuring.

I think the problem of disambiguating names of resources in the home has to be dealt with to prevent users whose devices are mobile from violating the principle of least astonishment. I don't think the ability to resolve names of home resources from anywhere on the Internet has to be solved in order to solve the disambiguation problem.

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

---

From: Andrew Sullivan <[email-masked]>
Date: Wed, 8 Aug 2012 09:35:33 -0400

On Wed, Aug 08, 2012 at 08:32:01AM -0400, David R Oran wrote:
> Yes, and a fairly hard one given the manual/administrative nature of
> domain registrations and the geek factor of secure dynamic DNS
> updates for all services to the global DNS.

What is this "geek factor" whereof you speak?  Once you have a name
registered, registered your service with a service like dyn.com's
DynDNS service, and told your gateway about it, everything else Just
Works.  I know this mostly because I know people who don't know
anything about what they are doing, but who are able to navigate this
far.  

What probably is true is at least the following:

    1.  Many people don't want to pay for (thereby use) their own
    name, and don't want to pay extra for a service like this.  Dyn
    and (I believe) some of its competitors have free services of this
    sort, but they're somewhat restricted in what they can do.  (Still,
    you can do this today when you buy shipping product from some
    vendors, without doing a single extra thing.)

    2.  Registering DNS names and somehow hooking them up to edge systems
    remains hard.  DNSOP is actually investigating this problem, but
    maybe this WG ought to collaborate on that.

    3.  Split-horizon DNS isn't that reliable, and tends to leak.

    4.  Trying to make this work smoothly with .local addresses is probably a
    good way to cause confusion

For what it's worth, after the discussion in Vancouver I went back to
colleagues at Dyn to ask about previous work on standardizing what I
might call the CPE-to-DNS-provider link, as I was pretty sure there'd
been previous work.  Indeed there had, and I'm attempting to dust it
off.  If we're serious about systems inside our target networks being
somehow addressable from the global Internet, then it seems to me a
mechanism to integrate easily to the global DNS without requiring
major lock-in (or major upgrade of DHCP) is going to be something
we'll have to tackle.

> Much as it would be great for Homenet to solve this problem and get
> a lot more functionality for users, this may be a bridge too far for
> the current work, which is focused on getting routing and naming
> INSIDE the home seamless and completely auto-configuring.

If, on the other hand, we are in fact going to limit our scope to
inside the home network (and what problem is it, exactly, that we
have?  My network can already do this, I think?) then of course the
above is just needless extra work.
 
> I think the problem of disambiguating names of resources in the home
> has to be dealt with to prevent users whose devices are mobile from
> violating the principle of least astonishment. I don't think the
> ability to resolve names of home resources from anywhere on the
> Internet has to be solved in order to solve the disambiguation
> problem.
 
I think that's a little optimistic.  As soon as you have the problem,
"The name in context X is the same as in context Y and I want to be
able to tell the difference when I cross context," you are already in
Internet land.  That's an interoperation problem, at least from the
user's point of view.

Best,

A

-- 
Andrew Sullivan
[email-masked]

---

From: Michael Thomas <[email-masked]>
Date: Wed, 08 Aug 2012 08:29:00 -0700

> What browser are you using? Safari and I think Chrome know about .local just fine.

I'm talking about people, not technology. People know nothing of this, and
would be confused that they need to type in weatherstation.local, and doubly
more confused by why it doesn't work once they leave the house. It just doesn't
map to the way people view naming anymore.

 > For that you definitely need a global DNS domain registration, so we've cycled back to where we started - things you want to be accessed globally from anywhere on the internet need global names th…

The global namespace is what people have been taught in the last 20 years
and almost nobody remembers NBP. I think that it is an important requirement
that we do not mess with people's mental model of what we've forced upon them
which is the global DNS. .[site]local fails on that account. When I type an address
(or better, search) in a location bar, I want it to seem like it's an fqdn even if it's
walled off from the rest of the world -- people understand firewalls to a degree --
and perhaps even if it's a locally synthesized fqdn (ie, camping on a name that I
don't have registered). I don't want to think about the antiquated notion of filtering
by categories that I didn't create and probably make no sense to me whatsoever
as there becomes a vast array of internet-enabled widgets in the house.

 >> So there's one problem.
 >>
 > Yes, and a fairly hard one given the manual/administrative nature of domain registrations and the geek factor of secure dynamic DNS updates for all services to the global

There's much that could be done to make this seamless, and probably many business
opportunities given that. The main problem right now is that we don't have a very big
internet that supports this feature. Once the v6 internet gets to a critical mass, there
will be a land rush of purpose built widgets vying for their homenet acreage. I think it
would be extremely short sighted to blow that off as "too hard" because it's not, and
especially if we stop spending an inordinate amount of brain cycles trying to do unnatural
acts with a naming mechanism that nobody even knows about.

Mike

---

From: Curtis Villamizar <[email-masked]>
Date: Wed, 08 Aug 2012 14:48:55 -0400

In message <[email-masked]>
 
> Internet land.  That's an interoperation problem, at least from the

One solution, the one you are describing is where the CPE runs DHCP
only and uses the dyndns protocol to make addresses available
globally.

Another solution is have the CPE run both DHCP and bind (or equiv) and
run dyndns.  The provider could delegate and secondary a subdomain of
the provider with no need to contact a domain registry.

When a domain registrar is needed is only when the homenet needs or
wants (maybe for ego reasons) a domain residing in a TLD (such as .com
or .org) and would not accept a subdomain from the provider.  For
example the homenet user wants foo.com and would not accept something
of the form foo.site.provider.com, which would be less permanet (the
delegation is lost if switching providers).

Curtis

---

From: Wouter Cloetens <[email-masked]>
Date: Fri, 17 Aug 2012 16:49:06 +0200

> the provider with no need to contact a domain registry.

Yes, that is exactly the 13 months old solution, described in these drafts:

http://www.ietf.org/id/draft-mglt-homenet-naming-delegation-00.txt
http://www.ietf.org/id/draft-mglt-homenet-front-end-naming-delegation-00.txt

> delegation is lost if switching providers).

For security reasons documented in one of the drafts above, it should be 
disabled by default. A user-defined configuration could open the DNS 
port to the world, and allow additional domains.

bfn, Wouter

---

From: Curtis Villamizar <[email-masked]>
Date: Fri, 17 Aug 2012 23:05:16 -0400

In message <[email-masked]>
 
> http://www.ietf.org/id/draft-mglt-homenet-front-end-naming-delegation-00.txt

Thank you for pointing these out.  I will take a look at them.

> port to the world, and allow additional domains.

I think you missed the point.  This is not a security issue.

The homenet user that wants foo.com needs to go to a domain registrar.
The provider can only give out foo.site.provider.com but if this is
for true home use and not business use, then that should be fine.  The
point is to be able to reach the home without typing in an IPv6
address.  The same type of user happily accepts an email address of
the form <namestring>@provider.com where namestring often has to
contain numbers to keep it unique because all first names and most
last names are already taken at the provider.

It would be perfectly fine for the provider to offer
<namestring>.site.provider.com as a domain delegation if namestring
has already been assigned to the home as an account ID and email
address.  If the user want a domain name in a TLD, they need a domain
name registrar.

Curtis

---

From: Wouter Cloetens <[email-masked]>
Date: Sat, 18 Aug 2012 18:11:32 +0200

> I think you missed the point.  This is not a security issue.

Yes, I got your point, but I'm adding an implication.
The draft explains that this requires opening up the gateway's DNS port 
to the world, rather than only to the trusted DNS infrastructure of the 
provider. That has some security issues.
Also, only the provider can give you reverse DNS.

Whereas the provider-delegated domain can be a fully automatic feature, 
setting up a personal domain requires the user to do some work. 
Registering a domain (could be made simple, from a gateway's web UI), 
pointing a nameserver at his gateway (could be automated, DynDNS-style). 
It is only logical that a user should also have to disable the secure 
default source address restriction of DNS requests.

Nonetheless, it is a perfectly valid use case; the IPv6 functional 
equivalent of widely used DynDNS in the IPv4 world today. And, of 
course, not every operator may implement the automated domain delegation.

bfn, Wouter

---

From: Curtis Villamizar <[email-masked]>
Date: Tue, 21 Aug 2012 10:03:29 -0400

In message <[email-masked]>
 
> provider. That has some security issues.

There is the option for split horzon, but I don't think it should be
the default.  Having a GUA and not having a DNS name is not a
*security* feature.  More like paranoia IMHO.  Security by obscurity
has never worked.

> Also, only the provider can give you reverse DNS.

The provider can delegate reverse DNS.  That is a problem with
uncooperative providers.

Otherwise accurate rDNS is site local only, but at least it is
accurate at the site.

> default source address restriction of DNS requests.

If the user wants no work, the provider delegated subdomain can be
reduced to zero work on the part of the customer, and a one time
mechanical configuration on the part of the provider at the time that
service is initiated (when new customer buys service for first time).

Working with a registrar could be made simpler by the registrar, but
most homes will never need a *vanity* domain in a TLD.

> course, not every operator may implement the automated domain delegation.

It seems that today, getting operators to do anything is difficult.
Too bad we have so little competition in Internet service.  :-(

Curtis

---

From: Wouter Cloetens <[email-masked]>
Date: Wed, 29 Aug 2012 01:21:49 +0200

On 21/08/12 16:03, Curtis Villamizar wrote:
>
> In message<[email-masked]>
> Wouter Cloetens writes:
>

Well, there is the issue of discoverability of the addresses in the 
home. A /64 for your home network is prohibitively expensive to scan by 
enumerating IP addresses. Scanning a list of hostnames based on a 
dictionary reduces the space considerably. Personally, I agree that not 
having a DNS name is indeed security by obscurity. Your IP address can 
be seen by any server with which you communicate already, so I think the 
whole discoverability security element will just shift attackers' focus 
to XSS attacks on web pages. I also think that the advantages of the DNS 
name outweigh the (IMHO small) security risks.

> The provider can delegate reverse DNS.  That is a problem with

True, and well, that's a matter of making a business case. If the 
customer is willing to pay for it, or if it creates a competitive 
advantage, then yes. I suspect that there is just not enough money in it 
to make it worth their effort.

> most homes will never need a *vanity* domain in a TLD.

Exactly.
It isn't necessarily a registrar that needs to offer the option though. 
A DynDNS provider could offer a vanity non-TLD domain, and delegate 
queries to the gateway. It's even perfect to combine the existing IPv4 
service (e.g. foo.homeunix.net from dyn.com) with the new IPv6 
delegation (router.foo.homeunix.net, printer.foo.homeunix.net, 
mylaptop.foo.homeunix.net, ...)

> Too bad we have so little competition in Internet service.  :-(

Note the list of authors on the drafts. ;-) I realised that without 
operator cooperation, nothing is likely to happen, so I was delighted 
when an operator contacted me, and even more delighted when they showed 
a working proof of concept implementation, and were willing to co-author 
the draft.

---

From: Mark Andrews <[email-masked]>
Date: Wed, 29 Aug 2012 10:42:30 +1000

> name outweigh the (IMHO small) security risks.

It is trivial to scan a /48 if ip6.arpa is populated for it.  There
is too much structure in ip6.arpa to prevent the scan succeeding.
This is independent of whether the zones are signed or not or
whether NSEC or NSEC3 is used when signing the zone.

You query for [0-9a-z].</48-reverse>.  For each of these that return
NOERROR you scan for [0-9a-z].</52-reverse>.  Repeat until you have
the entire 128 bits for all registered nodes in the /48.

> to make it worth their effort.

There are existing DNS servers that make automatic delegation trivial
to support.

There is deployed code that allows clients to update the delegation
of a /48 that was designed to allow 6to4 reverses to be delegated
in band using TCP as the authenticator.  If the update request comes
from the /48 over TCP it is accepted otherwise it is rejected.  This
code supports any /48.  It is trivial to make it support /52, /56,
/60 and /64 (20 minutes work).

zone "8.B.D.0.1.0.0.2.ip6.arpa" {
	type master;
	file "8.B.D.0.1.0.0.2.ip6.arpa";
	update-policy {
		grant dhcpserver subdomain 8.B.D.0.1.0.0.2.ip6.arpa ANY;  // cleanup when lease expires
		grant * 6to4-self . NS DNAME DS;			  // CPE added these using a TCP
	};
};

It was designed to be used like this where updates could be done
over both IPv4 (constructs the matching 2.0.0.2.IP6.ARPA /48 reverse)
and IPv6.  Geoff/APNIC went with a HTTP interface rather than a DNS
interface.

zone "2.0.0.2.IP6.ARPA" {
	type master;
	file "2.0.0.2.ip6.arpa";
	update-policy {
		grant * 6to4-self . NS DNAME DS;
	};
};

Finer grained control is available so you can allow this for subsets
of the reverse space.

zone "8.B.D.0.1.0.0.2.ip6.arpa" {
	type master;
	file "8.B.D.0.1.0.0.2.ip6.arpa";
	update-policy {
		grant local:path external . NS DNAME DS;
	};
};

-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: [email-masked]

---

From: james woodyatt <[email-masked]>
Date: Tue, 28 Aug 2012 18:35:48 -0700

On Aug 28, 2012, at 17:42 , Mark Andrews <[email-masked]> wrote:
> 
> Repeat until you have the entire 128 bits for all registered nodes in the /48.

You shouldn't expect to get the temporary addresses.  Only the persistent ones, and some nodes-- particularly the ones that host only clients and no services-- should neither be listening at persistent addresses, nor advertising pointers to their persistent addresses in ip6.arpa.

I'm not terribly exercised about the other kinds of nodes.  The problem of globally reachable servers being findable by iterating the ip6.arpa reverse domain name system doesn't seem very pressing to me.  Sounds like a feature not an error.

--james

---

From: Mark Andrews <[email-masked]>
Date: Wed, 29 Aug 2012 11:50:20 +1000

In message <[email-masked]>, james woodyatt wri
tes:
> You shouldn't expect to get the temporary addresses.  Only the persistent one
> s, and some nodes-- particularly the ones that host only clients and no servi
> ces-- should neither be listening at persistent addresses, nor advertising po
> inters to their persistent addresses in ip6.arpa.

This is debatable.  There are enough services that require a working reverse
for not registering to be a problem.  One can always register like this and
still maintain anonymity.

		<reverse-name> PTR <reverse-name>
		<reverse-name> AAAA <addresss>
 
> I'm not terribly exercised about the other kinds of nodes.  The problem of gl
> obally reachable servers being findable by iterating the ip6.arpa reverse dom
> ain name system doesn't seem very pressing to me.  Sounds like a feature not 
> an error.

I don't think it is a error either.  Just a observation that one should be
aware of.

---

From: Andrew Sullivan <[email-masked]>
Date: Wed, 29 Aug 2012 02:31:17 -0400

On Wed, Aug 29, 2012 at 11:50:20AM +1000, Mark Andrews wrote:
 
> There are enough services that require a working reverse for not
> registering to be a problem.

Please name one.  When we went through this argument in DNSOP some
years ago, we were unable to reach consensus on that claim.  I'd be
delighted to learn it is true, but I haven't so far found a convincing
story.  

Best,

A

-- 
Andrew Sullivan
[email-masked]

---

From: Mark Andrews <[email-masked]>
Date: Wed, 29 Aug 2012 17:38:06 +1000

In message <[email-masked]>, Andrew Sullivan writes:
> Please name one.

Millions of SMTP servers or are we going to force SMTP MTAs to not
use temporary addresses when transmitting mail?

I know it is a useless test but it exists.

Do you think ISP generate fake IPv4 reverse entries for no reason?  There
are just enough sites that do this that it is a pain to not provide the
entries.

> When we went through this argument in DNSOP some

---

From: Mikael Abrahamsson <[email-masked]>
Date: Wed, 29 Aug 2012 10:07:30 +0200 (CEST)

> delighted to learn it is true, but I haven't so far found a convincing

If the incoming TCP/25 call comes from an IPv4 address with working 
forward/reverse is used as one of many parameters to rate liklyhood of the 
email being a spam.

I am not saying this is going to work the same in IPv6, but my money would 
be that serious MTA owners would continue to emulate this, by not running 
SLAAC on their MTA:s and just having a single static address and giving a 
proper forward/reverse DNS to this address.

<http://en.wikipedia.org/wiki/Anti-spam_techniques#PTR.2Freverse_DNS_checks>

-- 
Mikael Abrahamsson    email: [email-masked]

---

From: SM <[email-masked]>
Date: Wed, 29 Aug 2012 14:31:58 -0700

At 01:07 29-08-2012, Mikael Abrahamsson wrote:
>I am not saying this is going to work the same in IPv6, but my money 
>would be that serious MTA owners would continue to emulate this, by 
>not running SLAAC on their MTA:s and just having a single static 
>address and giving a proper forward/reverse DNS to this address.

It's easier not to run SLAAC on the MTA.

Regards,
-sm