Subject: [homenet] Simple Homenet Naming Architecture...

From: Ted Lemon <[email-masked]>
Date: Mon, 13 Mar 2017 17:58:49 -0400

Daniel Migault and I have been working on the Simple Homenet Naming Architecture.   I've posted a -00 that I hope we can discuss in Chicago.

> Begin forwarded message:
> 
> From: [email-masked]
> Subject: I-D Action: draft-tldm-simple-homenet-naming-00.txt
> Date: March 13, 2017 at 5:56:19 PM EDT
> To: <[email-masked]>
> Reply-To: [email-masked]
> 
> 
> A New Internet-Draft is available from the on-line Internet-Drafts directories.
> 
> 
>        Title           : Simple Homenet Naming and Service Discovery Architecture
>        Authors         : Ted Lemon
>                          Daniel Migault
> 	Filename        : draft-tldm-simple-homenet-naming-00.txt
> 	Pages           : 9
> 	Date            : 2017-03-13
> 
> Abstract:
>   This document describes a simple name resolution and service
>   discovery architecture for homenets.  This architecture covers local
>   publication of names, as well as name resolution for local and global
>   names.
> 
> 
> The IETF datatracker status page for this draft is:
> https://datatracker.ietf.org/doc/draft-tldm-simple-homenet-naming/
> 
> There's also a htmlized version available at:
> https://tools.ietf.org/html/draft-tldm-simple-homenet-naming-00
> 
> 
> Please note that it may take a couple of minutes from the time of submission
> until the htmlized version and diff are available at tools.ietf.org.
> 
> Internet-Drafts are also available by anonymous FTP at:
> ftp://ftp.ietf.org/internet-drafts/
> 
> _______________________________________________
> I-D-Announce mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/i-d-announce
> Internet-Draft directories: http://www.ietf.org/shadow.html
> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

---

From: Ted Lemon <[email-masked]>
Date: Mon, 13 Mar 2017 18:04:07 -0400

> Daniel Migault and I have been working on the Simple Homenet Naming Architecture.   I've posted a -00 that I hope we can discuss in Chicago.

To amplify on that slightly, the idea with this document is to provide a naming architecture that gets naming done on the homenet, and nothing else.   There is no support for DNSSEC or PKI, or for publishing names in the global DNS.   However, in principle all of these things _can_ be done on the homenet using this architecture—they will simply require an additional functional box which is not specified in this architecture, but fits into it.

---

From: Markus Stenberg <[email-masked]>
Date: Tue, 14 Mar 2017 10:49:20 +0200

On 13 Mar 2017, at 23.58, Ted Lemon <[email-masked]> wrote:
> Daniel Migault and I have been working on the Simple Homenet Naming Architecture.   I’ve posted a -00 that I hope we can discuss in Chicago.

S1.1: The assumption in UI is false. The visible services (at least in the legacy browse mode, e.g. ‘flat list’, do not need to have topology information visible to the user; in browse mode, full domain is usually shown).

S3.3: Why MUST filter out globals? I do not see the reason, and if I do not, casual reader might not either. If it is just an opinion, it could be SHOULD perhaps.

The subsection lists 3 functions (querying, aggregating, relaying) but says there are only two types of proxies. I am slightly confused.

My reading (which you do not state explicitly) is that you advocate a solution where you have ‘aggregating proxy’ which asks for results from multiple links, and combines them, handling uniqueness of responses; however, the devices themselves will not even know they are ‘computer 72’ and not ‘computer.local’ which they advertise on the link. This gets quite awkward as devices come and go if they do not locally know their name, unless the aggregating function is fully stateful and robust (= mappings stay constant until end of time) and it can somehow determine that moved node (computer.local which moved from link A to link B to new name computer-2.local as there was computer.local already on the link B) is still same.

In my experimentation in 2013, somewhat better working design seemed to be forcing the aggregated name mappings to stay unique by essentially forcing devices to rename themselves until the computer.local thinks it is actually computer 72.local (or whatever) which is network-wide unique and then when it moves its node name part stays same.

Anyway, it looks like a good start, at least no mention of dnssec or crazy delegation to random third party by default. 

Cheers,

-Markus

---

From: Ted Lemon <[email-masked]>
Date: Tue, 14 Mar 2017 11:24:56 -0400

> S3.3: Why MUST filter out globals? I do not see the reason, and if I do not, casual reader might not either. If it is just an opinion, it could be SHOULD perhaps.

Are you talking about this text?

   Local names appear as subdomains of [TBD1].  These names can only be
   resolved within the homenet; not only is [TBD1] not a globally unique
   name, but queries from outside of the homenet for any name, on or off
   the homenet, must be rejected with a REFUSED response.

This text is actually wrong.   The correct behavior is specified in RFC 5625, section 6.2.   The point is to avoid being an amplifier for DDoS attacks.

> The subsection lists 3 functions (querying, aggregating, relaying) but says there are only two types of proxies. I am slightly confused.

The confusion here is twofold.   First, I used the term "relaying proxy" in the first sentence, and then started using the term "querying proxy" to mean the same thing in later sentences, but didn't notice until you pointed it out that I had done this.

The other issue is that there are actually three functions here, and I only really talk in detail about two.   Bear in mind that we talked about a two-layer architecture, and this is the easy layer, but it has to support the other layer.   In order to support the other layer, it's (maybe) necessary to have a DNS proxy on every link that can assert that a DNS query was received on-link, in order to support stateful DNSSD.   We didn't really go into any detail about that in this version of the architecture.

The other two functions are the hybrid that asks questions using mDNS in response to queries over DNS, and the hybrid that asks questions using DNS to proxies that do mDNS.   So the first of these is the querying proxy, and the second is the aggregating proxy.

I'm not actually convinced that we want to do stateful hybrid DNSSD using DNS update; if we don't, then the third function goes away.

> My reading (which you do not state explicitly) is that you advocate a solution where you have ‘aggregating proxy’ which asks for results from multiple links, and combines them, handling uniqueness…

I am not sure, but I think you are alluding here to the problem that if you have a computer that connects to one link sometimes and another link at other times, it will present the same name on both links and this will create a conflict.   Otherwise naming conflicts of this type are quite rare.   But it sounds like you've encountered them enough to be concerned about it.   In the case I'm talking about, defending the name doesn't work, because the device always presents the same name, and so the number keeps creeping up, which is not desirable.

In any case, given that you've done some hacking in this space, it would be helpful if we could have a more detailed conversation about it at IETF, so that I can understand your experiences.

> Anyway, it looks like a good start, at least no mention of dnssec or crazy delegation to random third party by default. 

That's the second layer.   I don't think it's crazy or random, but yes, it's not present in the simple architecture, since there was clearly demand for an architecture that was easier to implement than the DNSSEC/delegation architecture.   Personally, I think that we need a real security model, and so proposing this as a separate architecture is somewhat harmful, but I admit that the real security model is hard [tm].