On Mar 14, 2017, at 4:49 AM, Markus Stenberg <markus.stenb...@iki.fi> 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].
_______________________________________________
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet
