Re: [dnssd] I-D Action: draft-ietf-dnssd-mdns-dns-interop-01.txt

On 7/17/15 9:27 AM, Andrew Sullivan wrote:
> Hi Doug,
> 
> It's been 7 days since I sent this, and I haven't seen anything from
> you.  You may have noticed that I'm the stuckee for this discussion in
> Prague.  If I don't have slides for it prepared by Saturday night,
> they may well not get prepared.  Currently, what I think your
> objections are boil down to, "DNS-SD shouldn't use the DNS outside the
> local link."  I therefore think you're challenging the WG's charter,
> not this document, so I don't really have a way to address your
> concerns.  If you think that's wrong, I really need a clear and
> concise outline of what you're saying in the next 24 hours, or you'll
> have to make yourself clear to the WG during the meeting.

Dear Andrew,

Sorry for the delay. I have been attending the MacIT
Conference while seeking inputs from others and reviewing an
impressive number of upcoming changes to OS X and iOS
networking solutions. Unfortunately, documentation at this
time seems a bit scant. Soon enterprise configurations will
be able to arrange extensive tunneling to resolve mDNS
resources as a type of namespace overlay without
configuration size limits being a problem.

The chartered goal was largely aimed at solving Apple's
connectivity issues within school environments.  Satisfying
such a goal should be met while also not exposing hybrid
resources to the Internet or while strictly moderating the
amount of mDNS resources exposed.

Standard DNS lacks many of the mitigation techniques used
with mDNS such as Opportunistic Caching, Duplicate Query
Suppression, Passive Observation Of Failures (POOF), Passive
Conflict Detection, and redefined NSEC functions. That said,
the high levels of multicast traffic has been negatively
affecting WiFi networks which transfer this extensive amount
of data at the lowest possible rate. mDNS also did not
support hashed multicast addresses because the service was
intended to discover names and avoiding naming conflicts was
only secondary.  This means DNS-SD effects for either mDNS
or DNS will be pervasive.

The last thing Apple or schools are likely to want is an
scheme by the IETF that becomes a major security risk for
those using it or for the Internet in general.  What I was
suggesting was to discuss a general strategy that best
avoids DDoS and vulnerability exposures.

This might be done by identifying a locally defined domain
(other than .local) to be used.  Ambiguous Local Qualified
Domain Name (ALQDN) space (See RFC7368), such as .home as
suggested by the draft, or even a domain expressed using
UTF-8 label locally recognized (not encoded and without the
'xn--' prefix).

A local domain might be defined as not having an ('xn--'
prefix while using utf-8 encoding or the special domain
.home, or resources having addresses within RFC1918 space or
below a ULA prefix.  I hope to be at the meeting, if that helps.

Regards,
Douglas Otis

>>> On Jul 8, 2015, at 22:37, Douglas Otis <doug.mtview@gmail.com> wrote:
>>>
>>>> On 7/8/15 7:20 AM, Andrew Sullivan wrote:
>>>>> On Wed, Jul 08, 2015 at 12:48:41AM -0700, Douglas Otis wrote:
>>>>>
>>>>> Section 4.3 seems to conflate DNS as always meaning fully
>>>>> public global DNS. In the case of mDNS, this is likely not
>>>>> the case
>>>>
>>>> I don't know what you mean by "conflate DNS as always meaning fully
>>>> public global DNS".  It is true _by definition_ that "the DNS" entails
>>>> a single tree with a single root.  It's certainly true that you can
>>>> arrange things just right so that query-originators to you will see
>>>> things that query-originators to other name servers will not see.  But
>>>> once you've put things in the DNS, any hope that you have that it will
>>>> be private -- even in your split-brain arrangements -- are just
>>>> wishful thinking.  We have learned this over and over again, and I
>>>> don't see why it ought to be controversial; I also don't know how it's
>>>> relevant here.
>>>
>>> Dear Andrew,
>>>
>>> Many indicated in some environments there is a need to avoid
>>> excessive multicast traffic when it negatively impacts
>>> wireless networks.  To avoid resources being resolved using
>>> mDNS multicast, a different TLD other than .local is needed.
>>> The draft-ietf-dnssd-hybrid-00 proxy scheme offered a
>>> fairly automated method for moving mDNS resources into DNS
>>> which could use an Ambiguous Local Qualified Domain Name
>>> (ALQDN) space, such as .home as suggested by the draft, or
>>> even a domain expressed using UTF-8 label locally recognized
>>> (not encoded and without the 'xn--' prefix).  Since often
>>> these resources are not suitable for the Internet, a
>>> heuristic to identify zones to be filtered from Internet
>>> responses based on a "Profile" seems like a viable solution.
>>>
>>> Establishing a "Profile" offering heuristics to identify
>>> suitable global resources makes sense since different
>>> services normally support local mDNS based resolution which
>>> ignore IDNA. IMHO, a strategy to globally browse DNS using
>>> massive responses should be generally discouraged until the
>>> underlying transport offers effective congestion mitigation.
>>> DNS amplification leading to DDoS still persists largely
>>> due to insufficient ingress filtering compliance with BCP38
>>> one and a half decades later.  That said, DNS-SD may even
>>> place a campus having just a few compromised systems at risk.
>>>
>>>> I also don't know what you mean by the second sentence here, since "in
>>>> the case of mDNS" is by definition not the public global DNS -- it's a
>>>> completely different protocol.
>>>
>>> Except when mDNS resources are automatically transferred to
>>> DNS.  mDNS is even able to cache DNS resources.
>>>
>>>>> Change to:
>>>>> Operators of internationalized domain names frequently
>>>>> publish such names in the DNS as A-labels; these A-labels
>>>>> will be subject to the profile. Any namespace not included
>>>>> in the profile should be excluded from resolving in a global
>>>>> context.
>>>>
>>>> As I said last time, I don't see what "these A-labels will be subject
>>>> to the profile" adds and I find it confusing.  Moreover, we _cannot_
>>>> rule out resolution in the DNS "from resolving in a global context".
>>>> Here's an example of why.
>>>>
>>>> As Stuart has pointed out repeatedly, some enterprises already use
>>>> DNS-SD in its "wide area" form -- that is, in the DNS.  Such a name
>>>> might have the following form:
>>>>
>>>>    3rd Floor Copier Printer.West Wing.example.com
>>>>
>>>> In a zone file, that is encoded as
>>>>
>>>>    3rd\ Floor\ Copier\ Printer.West\ Wing.example.com
>>>
>>> Allowing limited and administrated exceptions is part of the
>>> dnssd requirement document.  That said, it is dangerous to
>>> tamper with domains having UTF-8 TLD labels and assume these
>>> resources can be exposed to the Internet.  Failing to
>>> resolve when using non-local tools would be a desired feature.
>>>
>>>> The hex encoding of this to the wire format is left as an exercise,
>>>> but the key point is that when you query (for instance) the
>>>> example.com zone for that you send the entire owner name as the qname
>>>> you're trying to look up.  Your formulation would prohibit this, and
>>>> we heard in previous meetings that the WG explicitly does _not_ want
>>>> that, but instead wants a fallback to the DNS-SD (and for that matter
>>>> non-IDNA) forms.  I think, moreover, that anything that attempts to
>>>> insist on formal backward incompatibility is doomed to failure.
>>>
>>> Not disagreeing.  A-Labels can support a heuristic able to
>>> identify global resources.  Wasn't that the purpose of your
>>> "profile"? Determining when conversions are appropriate?
>>>
>>>>> Rather than omitting an important consideration, state the
>>>>> need for global exclusions.
>>>>
>>>> But see above.  There is not in fact such a need; rather, stating such
>>>> a need would be false.
>>>
>>> Are you suggesting all locally defined TLDs contained in DNS
>>> (even when it is able to isolate locally defined TLDs such
>>> as .home) must always be encoded per IDNA?  If properly
>>> identified by a Profile, the Internet should never see these
>>> resources. Such a strategy should allow desired multicast
>>> avoidance (such as not using .local. ) without otherwise
>>> changing local namespace handling routines as used with mDNS.
>>>
>>>>> The point missed seems related to risks caused by not
>>>>> differentiating local and global namespaces as illustrated
>>>>> in the following examples.
>>>>
>>>> You seem to think that there are "local" and "global" namespaces and
>>>> we know which is which in advance.  But we don't.  That's _exactly_
>>>> the problem.  If we knew that in advance, we would know which
>>>> resolution system to use, and we would have no issue at all.
>>>
>>> A profile should also establish the labels accessible only
>>> using local resolution tools.  Use of '_' already carves out
>>> encoding exceptions for hosts and instances label.  Why not
>>> carve out entire local zones that are to be excluded from
>>> various resolvers and interfaces?
>>>
>>>>> A DDoS risk occurs whenever RFC6763 DNS-SD resources are
>>>>> given Internet accessed from either mDNS or DNS servers.
>>>>
>>>> There is no such thing as an mDNS server.
>>>
>>> IMHO, an mDNS node acts as its own server when conveying its
>>> resources.
>>>
>>>> I'm having an increasingly
>>>> hard time understanding what you're talking about, and I'm
>>>> decreasingly convinced that this is because of a fault in my own
>>>> understanding.  DDoS is a risk from large answers in the DNS; this is
>>>> well known.  I do not believe that this document is the place to
>>>> attempt to discuss that in detail.  To begin with, DNSOP is another
>>>> WG.  I see nothing wrong with writing a document from DNSOP saying,
>>>> "Large answer sets present a danger to DNS operations," but I don't
>>>> believe that one needs to repeat that advice in every single document
>>>> anywhere that mentions the DNS.
>>>
>>> The situation is serious but not fatal if caution were to
>>> prevail.
>>>
>>>>> See RFC6763 Section 7.2. Granting brows-able access to
>>>>> DNS-SD resources using either mDNS or DNS resolvers allows a
>>>>> wildcard at an instance location to respond with as many as
>>>>> 839 separate and combined resources. Blocking wildcard use
>>>>> defeats its intended use, normally safe on a local network.
>>>>
>>>> So, do you want the security considerations section to have a sentence
>>>> that says, "Any use of the DNS that follows the outlines of this
>>>> document necessarily incurs all DDoS risks resulting from the use of
>>>> DNS"?  I'm prepared to add that if you like.
>>>
>>> It seems it would be more constructive as part of a
>>> comprehensive strategy.
>>>
>>>>> It is not clear why mDNS resources moved to DNS
>>>>
>>>> I don't have any clue what that means.  There are no "mDNS resources"
>>>> that "move to DNS".  Those are different protocols.
>>>>
>>>>> DNS-SD is structured differently.  It combines a large
>>>>> number of sizable service RRsets below an Instance node.
>>>>
>>>> Sure.  It's a use of the DNS.  You seem to be making an argument that
>>>> DNS-SD is unsafe for use on the Internet, period.
>>>
>>> Don't ignore issues the hybrid scheme attempts to solve
>>> (with the aid of careful administration in specific cases to
>>> reduce the risk).  Risks demand either clearly defined
>>> prohibitions against local UTF-8 namespace in DNS (which
>>> seems unlikely) or properly identified handling profiles,
>>> which should be the purpose of this document.
>>>
>>>> If that's your
>>>> argument, then please publish "DNS-SD considered dangerous in the DNS"
>>>> or something like that.  This draft is about what you would do to make
>>>> DNS-SD work predictably _assuming_ that you wanted to use more than
>>>> one resolution mechanism, one of which is DNS, and I think including
>>>> text about why DNS-SD is dangerous is going to be mighty confusing.
>>>> If the WG concludes that DNS-SD is in fact dangerous for Internet use,
>>>> then obviously this draft shouldn't be published at all because you
>>>> shouldn't try to do any of these things in the first place.
>>>
>>> Thanks for the encouragement. I have discussed various
>>> solutions with others having extensive DNS knowledge.  Any
>>> general solution will likely arrive too late to avoid
>>> sizable problems that could occur when needlessly exposing
>>> DNS-SD resources to the Internet.  Allowing a few
>>> administratively managed exceptions should be fine and
>>> keeping within the dnssd requirements.
>>>
>>>>> Labels do not afford operational protection from DDoS or
>>>>> vulnerability exposure whether defined as A-labels, U-labels
>>>>> or neither.
>>>>
>>>> Yes.  The current draft has nothing to do with DDoS risk from the use
>>>> of the DNS, and I agree it is completely silent on that topic.  I
>>>> think that's a feature, but I'm willing to include the sentence noted
>>>> above if that will help.
>>>
>>> Perhaps you can see where this might be headed. Something
>>> along the lines of a profile exclusion of local resources,
>>> to facilitate the conveying of these resources to only local
>>> resolver tools that understand the specific needed
>>> conversions and the scope of their access.  A strategy
>>> mimicking what is currently based on mDNS.
>>>
>>>>> mDNS is inherently safer because it normally is
>>>>> only accessible from the local network.  An issue this draft
>>>>> continues to ignore, even when confronting a CERT notice!
>>>>
>>>> Uh, the CERT notice you sent was complaining about mDNS _not_ being
>>>> accessible only from the local network, which is what the problem was.
>>>> That has absolutely nothing to do with DNS-anythingelse
>>>> interoperation.
>>>
>>> Review researcher's notes at:
>>> https://github.com/chadillac/mdns_recon
>>>
>>> The concerns relate specifically to access granted to mDNS
>>> resources.  Unfettered access may create a rather bleak
>>> situation that can be salvaged by administratively placing
>>> only key resources into non-local zones.  (i.e. not in a
>>> default .home or its multilingual equivalent.)
>>>
>>> Appendix notes found in
>>> http://tools.ietf.org/html/draft-otis-dnssd-mdns-xlink-06
>>> previously noted on this mailing-lists about 6 months prior
>>> further supports these findings.
>>>
>>>>> DNS-SD describes a structure intended to be browsed and
>>>>> displayed having user friendly encoding.
>>>>
>>>> Wait.  So your issue is that DNS-SD owner names are intended to be
>>>> seen by humans?
>>>
>>> Clearly an issue whenever IDNA encoding is imposed on
>>> exclusively local resources where user interfaces don't
>>> support their conversion.
>>>
>>>>> Tools to browse DNS-SD DO NOT employ encoding used by
>>>>> IDNA2008
>>>>
>>>> Yes, which is why only the <Domain> portion is treated as though it
>>>> needs to be processed by IDNA.  This is mostly because that's where
>>>> the names will be in the DNS.  The rest of the Service Instance Name
>>>> continues to work according to the DNS-SD specification, and there are
>>>> no mitigations of any sort about the possibly large number of names
>>>> below the <Domain> portion of a Service Instance Name.  That's because
>>>> we're using DNS-SD.
>>>
>>> Which is why there should be a strategy to restrict global
>>> access to just resources that are administratively permitted.
>>>
>>>>> to be applied, but these actions are normally NEVER needed.
>>>>
>>>> The point of the draft, which I think is explained pretty clearly in
>>>> the introduction, is that you'll need the IDNA processing for the
>>>> <Domain> portion or else DNS will just return RCODE 3 and you won't
>>>> find what you're looking for.
>>>>
>>>>>> I disagree.  mDNS uses the full repertoire of octets available in the
>>>>>> DNS.  DNS operators as a matter of fact (for various reasons explained
>>>>>> elsewhere) use a subset of those octets.
>>>>>
>>>>> DNS is able to use the SAME octets as used by mDNS.
>>>>
>>>> Yes, which is entirely consistent with what I said.  
>>>>
>>>>> There
>>>>> might be cases where global DNS and local DNS wish to share
>>>>> a common zone for reasons likely related to use of
>>>>> certificates or minimizing servers.
>>>>
>>>> What exactly is "local DNS"?
>>>
>>> This might employ a split horizon server excluding interface
>>> and resolver access from specifically "profiled" zones.
>>>
>>>>> We see the problem differently.  There is a real danger
>>>>> attempting to combine these two different namespaces,
>>>>
>>>> I think what you're saying is that the goal of the draft is dangerous
>>>> and bad.  That's ok with me, but it seems really to be an argument
>>>> that the WG shouldn't try to do what it is chartered to do, no?
>>>
>>> This and the poor track record for BCP38 should motivate DNS
>>> transport improvements in the long run.  In the meantime,
>>> not aggressively globally deploying DNS-SD should be an
>>> appropriate and conservative strategy.
>>>
>>> Regards,
>>> Douglas Otis
>>>
>>>
>>> _______________________________________________
>>> dnssd mailing list
>>> dnssd@ietf.org
>>> https://www.ietf.org/mailman/listinfo/dnssd
>>
>> _______________________________________________
>> dnssd mailing list
>> dnssd@ietf.org
>> https://www.ietf.org/mailman/listinfo/dnssd
> 