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

[Ted Lemon <[e-mail]>]

On Mar 14, 2017, at 4:49 AM, Markus Stenberg <[e-mail]> wrote:
> 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 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.

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].