Internet DRAFT - draft-otis-dnssd-scalable-dns-sd-threats

draft-otis-dnssd-scalable-dns-sd-threats






dnssd                                                            D. Otis
Internet-Draft                                               Trend Micro
Intended status: Informational                                 H. Rafiee
Expires: September 18, 2016                                  Rozanak.com
                                                          March 17, 2016


                     Scalable DNS-SD (SSD) Threats
              draft-otis-dnssd-scalable-dns-sd-threats-03

Abstract

   mDNS combined with Service Discovery (DNS-SD) extends network
   resource distribution beyond the reach of multicast normally limited
   by the MAC Bridge.  Since related resources are often not
   authenticated, either local resources are inherently trustworthy or
   are subsequently verified by associated services.  Resource
   distribution becomes complex when a hybrid scheme combines adjacent
   network resources into a common unicast DNS-SD structure.  This
   document explores related security considerations.

Requirements Language

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in [RFC2119].

Status of this Memo

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list of current Internet-
   Drafts is at http://datatracker.ietf.org/drafts/current/.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   This Internet-Draft will expire on September 18, 2016.

Copyright Notice

   Copyright (c) 2016 IETF Trust and the persons identified as the
   document authors.  All rights reserved.



Otis & Rafiee          Expires September 18, 2016               [Page 1]

Internet-Draft        dnssd Scalable DNS-SD Threats           March 2016


   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents
   (http://trustee.ietf.org/license-info) in effect on the date of
   publication of this document.  Please review these documents
   carefully, as they describe your rights and restrictions with respect
   to this document.  Code Components extracted from this document must
   include Simplified BSD License text as described in Section 4.e of
   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.


Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
     1.1.  Terminology and Abbreviations  . . . . . . . . . . . . . .  4
   2.  Scalable DNS-SD (SSD) Realm and Global Namespace . . . . . . .  4
     2.1.  Realm and Global Names . . . . . . . . . . . . . . . . . .  4
     2.2.  Exfiltration and Poisoning . . . . . . . . . . . . . . . .  9
     2.3.  Amplification Concerns . . . . . . . . . . . . . . . . . . 10
   3.  Protection of SSD related interchange  . . . . . . . . . . . . 12
     3.1.  Link-Local . . . . . . . . . . . . . . . . . . . . . . . . 12
     3.2.  Authorization Issues . . . . . . . . . . . . . . . . . . . 12
     3.3.  Authentication Issues  . . . . . . . . . . . . . . . . . . 12
     3.4.  Privacy Considerations . . . . . . . . . . . . . . . . . . 12
   4.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 13
   5.  Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 13
   6.  References . . . . . . . . . . . . . . . . . . . . . . . . . . 13
     6.1.  Normative References . . . . . . . . . . . . . . . . . . . 13
     6.2.  References - Informative . . . . . . . . . . . . . . . . . 15
   Appendix A.  mDNS Example of Device Resolution Information . . . . 19
   Appendix B.  Uncontrolled Access Example . . . . . . . . . . . . . 20
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 21



















Otis & Rafiee          Expires September 18, 2016               [Page 2]

Internet-Draft        dnssd Scalable DNS-SD Threats           March 2016


1.  Introduction

   As described by [IEEE.802-1D.2004], MAC entities normally make
   services known via multicast announcements that do not extend beyond
   the Bridge as a basis for networking and layer 3 protocols.  mDNS
   [RFC6762] allows non-centralized resource collection that can be
   structured as defined in DNS-SD [RFC6763].  This structure, when used
   in conjunction with DNS [RFC1035], provides an alternative to
   multicast announcement to deal with wireless links that are orders of
   magnitude less reliable than their wired counterparts.  To improve
   transmission reliability, [IEEE.802-11.2012] requires positive
   acknowledgement of unicast frames but does not support positive
   acknowledgement of multicast frames.  In [IEEE.802-11.2012] wireless
   networks, multicast frames are transmitted at a lower data rate
   supported by all receivers.  Multicast on wireless networks may
   thereby lower overall network throughput.  Some network
   administrators block some multicast traffic or convert it to a series
   of link-layer unicast frames.  Other types of wireless networks may
   impose more demanding limitations as described by [RFC4944].  As a
   result, it is common to observe much higher loss of multicast frames
   on wireless compared against wired network technologies.

   A namespace structured from adjacent networks using proxy-ed mDNS
   resources lacks a means to quickly resolve unicast name collision.
   Although an expensive promiscuous mode of unicast operation at
   multicast destinations might replicate mDNS features within a unicast
   environment, not well covered in [RFC4903] are issues related to
   wireless upstream clients unable to operate in promiscuous mode,
   indeterminate latency, and PPP links requiring a NAT or IPv4 ARP
   proxy.  As such, a non-hybrid multicast/unicast scheme would be
   problematic.

   Scalable DNS-SD (SSD) proposes to automatically gather autonomously
   named mDNS [RFC6762] resources of adjacent networks within separate
   namespace zones or realms as defined by [RFC7368].  Realms are often
   contained in separate subdomains that correspond with a link-local
   namespace.  Making routable resources visible and accessible from
   other networks via unicast DNS [RFC1035] structured per DNS-SD
   [RFC6763] mitigates the level of multicast mDNS traffic in larger
   networks.  Reliance on DNS [RFC1035] might leverage multi-network
   configurations that use mDNS [RFC6762] that proxy mDNS resources into
   DNS-SD using [I-D.ietf-dnssd-hybrid].









Otis & Rafiee          Expires September 18, 2016               [Page 3]

Internet-Draft        dnssd Scalable DNS-SD Threats           March 2016


1.1.  Terminology and Abbreviations

      o Border: A point, typically resident on a router, between two
      networks at which filtering and forwarding policies for different
      types of traffic may be applied.

      o ISP: Internet Service Provider.  An entity that provides access
      to the Internet.  In this document, a service provider
      specifically offers Internet access using IPv6 and may also offer
      IPv4 Internet access.  The service provider can provide such
      access over a variety of different transport methods such as DSL,
      cable, wireless, and others.

      o Realm: A network delimited by a defined border. i.e. a guest
      network within a homenet may form a realm.

      o ULA: IPv6 Unique Local Address [RFC4193].

      o Global Namespace: A globally unique name resolved within global
      DNS namespace bootstrapped from a root zone.

      o Realm Namespace: A realm specific namespace that may not be
      resolved within the global DNS namespace, perhaps due to Special
      Use domain designations.

      o Local Namespace: A namespace accessible for link-local
      resolution that may be referenced from an Ambiguous Local
      Qualified Domain Name (ALQDN) representing a network segment or
      broadcast domain.


2.  Scalable DNS-SD (SSD) Realm and Global Namespace

2.1.  Realm and Global Names

   Conflicts between a local realm and global DNS [RFC1035] namespaces
   may occur.  Without adequate feedback and latency constraints, a
   client may be unable to determine desired service targets.  Target
   assessment may impair network stability when a cache policy renames
   resources propagated into different realms.  Determining actual
   conflicts might depend on inherent identifiers such as MAC addresses
   or device specific GUIDs, otherwise conflict resolution may become
   increasingly byzantine.








Otis & Rafiee          Expires September 18, 2016               [Page 4]

Internet-Draft        dnssd Scalable DNS-SD Threats           March 2016


2.1.1.  SSD Structures

   SSD locates SRV and TXT RRsets resources in the forms:

           _<sn>._<Proto>.<SrvDOM>.<ParentDOM>.

           <Instance>._<sn>._<Proto>.<SrvDOM>.<ParentDOM>.

           <sub>._sub._<sn>._<Proto>.<SrvDOM>.<ParentDOM>.

   For DNS-SD, Proto="_udp" represents all non-TCP transports otherwise
   it is "_tcp".

   _<sn> = IANA Registered Service Name

   To facilitate browsing, DNS-SD also supports a DNS meta-query of PTR
   RRsets at "_services._dns-sd._udp.<Domain>" which yields service
   names which may vary by host along with a domain name.  Only the
   first two labels in the PTR rdata are relevant in the construction of
   subsequent Service Instance Enumeration PTR queries to further
   discover specific service types.

   [I-D.ietf-dnssd-hybrid] conveyance extends '.local.'  TLD namespace
   into '.home.' or an Ambiguous Local Qualified Domain Name (ALQDN)
   space, such as '.sitelocal.' as described in Section 3.7.4 of
   [RFC7368] where DNS [RFC1035] can be facilitated using split horizon
   methods described by [RFC6950] or similar schemes described by
   [RFC6281].  It seems there is some controversy regarding the
   designation of .home as a special use domain defined by
   [I-D.cheshire-homenet-dot-home] which does not follow conventions
   defined by [I-D.ietf-dnsop-alt-tld].  Either scheme avoids security
   issues related with global DNS publishing DNS-SD, even when
   configured in a split-horizon mode of operation.  Unfortunately, the
   latter can not ensure the single de-facto .home label is formally
   excluded from the global DNS when designating a namespace that does
   not use multicast DNS.  Any scheme supporting a sitelocal namespace
   must ensure queries are not forwarded to the Internet or to global
   DNS servers.

   [I-D.ietf-dnssd-hybrid] suggests a split of traditional namespace
   that is restricted to letters, digits and hyphens and resolves only
   address resources, from the rich text namespace resolving PTR, SRV
   and TXT that facilitate service browsing.  These resources are
   further bifurcated into separate link related namespace resources.







Otis & Rafiee          Expires September 18, 2016               [Page 5]

Internet-Draft        dnssd Scalable DNS-SD Threats           March 2016


2.1.2.  Scope of Discovery

   As mDNS [RFC6762] is currently restricted to a single link, the scope
   of the advertisement is limited, by design, to the shared link
   between client and the device offering a service.  When scaling for
   multi-links, the owner of the advertised service may propagate to a
   larger set of links or a larger realm than expected, which may result
   in unauthorized clients (from the perspective of the owner)
   connecting to the advertised service.  It also discloses information
   (about the host and service) to a larger set of potential attackers.

   If the scope of the discovery is not properly constrained, then
   information leaks may happen beyond the appropriate network and
   expose the network to various forms of attack.  As such, services
   normally limited to local link should be assigned a separate
   subdomain normally not accessible from the Internet.

   To reduce the amount of multicast traffic, widely distributing mDNS
   resources using unicast DNS-SD may scale better, but exposure of mDNS
   [RFC6762] derived resources to the Internet along with possibly
   sensitive details has proven problematic as noted by [CERTvu550620].
   Protocol vulnerabilities can be found in reports published by a large
   number of vendors, Computer Emergency Response Teams (CERT), and
   Computer Security Incident Response Teams (CSIRT).  With this
   diversity of sources, specific concerns may not be captured by
   Request for Comments (RFC) publications of the Internet Engineering
   Task Force (IETF).

   Services might be sought outside the ".local." domain when
   applications obtain domain search lists provided by DHCP ([RFC2131]
   and [RFC3315] for IPv4 and IPv6 respectively or RA DNSSL [RFC6106]
   also for IPv6.  Unfortunately, DHCPv6 does not support ULA assignment
   which instead requires some sort of NAT found with VPNs.  Domains
   also need to be published in DNS [RFC1035] as A-Labels [RFC3492]
   because IDNA2008 compliance depends on A-label enforcement by
   registrars.

   The SRV scheme used by mDNS [RFC6762] has also been widely adopted in
   the Windows OS since it offered a functional replacement for Windows
   Internet Name Service (WINS) as their initial attempt lacked
   sufficient name hierarchy.  Such common use may represent security
   considerations whenever these records might become automatically
   published.

2.1.2.1.  Visual Spoofing

   Visual selection of autonomously named resources becomes especially
   salient when names are not ensured to be uniquely represented.  mDNS



Otis & Rafiee          Expires September 18, 2016               [Page 6]

Internet-Draft        dnssd Scalable DNS-SD Threats           March 2016


   [RFC6762] only requires compliance with [RFC5198] rather than
   IDNA2008 [RFC5895].  This less restrictive use of namespace may
   impair the defense of critical services from look-alike attack.  mDNS
   [RFC6762] does not ensure instances are visually unique and allows
   spaces and punctuation not permitted by IDNA2008.

   To better ensure local namespace can be recognized, alternative zones
   might replace ASCII punctuation and spaces in SrvDOM labels with the
   '_' character except when located as the leftmost character.  Such a
   convention should reduce visual confusion and handling issues related
   to end of string parsing, since labels in DNS [RFC1035] normally do
   not contain spaces or punctuation.  Nevertheless, DNS [RFC1035] is
   able to handle such labels within sub-domains of registered domains.

2.1.3.  Restricted Distribution of Sitelocal Addresses

   ULA or [RFC1918] addresses allow safer automatic publication in DNS
   since these addresses are unlikely to be routed beyond the site.
   These addresses also provide a simple scheme to ascertain which
   addresses should be blocked at a network boundary.  The use of other
   addresses MUST require specific administrative confirmations.  It
   should be noted in the Addendum example, the Brother printer
   published a Globally routable address.

   When doing so, address translation or overlays using Unique Local
   Addresses, ULAs [RFC4193] can offer a significant level of protection
   since typical link-local addresses are not usable from other
   networks.  Although ULAs are to be treated as being globally
   routable, both ULA or [RFC1918] addresses typically indicate site
   local.  Section 3.2 of [RFC4193] are locally defined and handled as
   Global addresses although not intended to be routed beyond the site
   or to those not having explicit routing provisions.

   Section 4.1 of [RFC4193] indicates the default behavior of exterior
   routing protocol sessions between administrative routing regions must
   be to ignore receipt of and not advertise prefixes in the FC00::/7
   block.  A network operator may specifically configure prefixes longer
   than FC00::/7 for inter-site communication.  Specifically, these
   prefixes are not designed to aggregate.  Routers by default do not
   block ULA prefixes which makes it important to confirm how ULA
   traffic is handled by the access provider.

   ULA or [RFC1918] addresses are not normally routed over the Internet
   where their use provides a degree of isolation.  For either home or
   enterprise networks, ULAs as an overlay network avoids dynamic
   network address translation tables and permits local routing that is
   isolated from direct Internet access.  ULAs also permit local
   communications to remain unaffected by Internet related link failures



Otis & Rafiee          Expires September 18, 2016               [Page 7]

Internet-Draft        dnssd Scalable DNS-SD Threats           March 2016


   or scope limitations imposed by use of multicast protocols.

   ULAs avoid a need to renumber internal-only private nodes when
   changing ISPs, or when ISPs restructure their address allocations.
   In these situations, use of ULA offers an effective tool for
   protecting internal-only nodes.  As such, more than just the security
   considerations discussed in mDNS [RFC6762] and DNS-SD [RFC6763] are
   needed.  For example, DNS-SD [RFC6763] states the following: "Since
   DNS-SD is just a specification for how to name and use records in the
   existing DNS, it has no specific additional security requirements
   over and above those that already apply to DNS queries and DNS
   updates."  This simply overlooks that many devices are not
   automatically published in DNS nor can it be assumed they are able to
   handle the access that DNS might permit.

   Current BTMM [RFC6281] only publishes ULAs of hosts in DNS able to
   authenticate when setting up an overlay network.  Remaining devices,
   such as printers, are accessed as services offered by authenticating
   hosts.  DNS resources should never be considered to offer privacy
   even in split-horizon configurations.  DNS is unable to authenticate
   incoming queries nor can it offer application layer protection.
   Since many prefixes are expected to be in use within environments
   served by [I-D.ietf-dnssd-hybrid], errors related to network boundary
   detections becomes critical.  As such, DNS SHOULD NOT publish
   addresses of devices unable to authenticate sessions traversing the
   Internet.

2.1.4.  Avoid publishing DNS-SD resources in global DNS for home
        networks.

   Even when DNSSEC uses NSEC or NSEC3, DNS-SD nevertheless exposes all
   listed services.  Since most home systems use devices having limited
   resources and lack many security mechanisms normally used to ensure
   secure operation, these services should remain obscured from the
   Internet.  Access to DNS-SD resources should be predicated on access
   granted using secure methods such as via VPN or IPSec exchanges.

2.1.5.  Confirming Valid Resources

   [RFC6950] Source Address Validation Improvement (SAVI) for DHCP as
   specified by [RFC7513] may help administrators qualify resources
   published in DNS.  DNS-SD [RFC6763] recommends additional DNS records
   such as associated PTR and TXT SHOULD be generated to improve network
   efficiency for both unicast and multicast DNS-SD responses.  This
   behavior further increases some risks related to query/response
   ratios and the likelihood of exposure of security sensitive
   information.




Otis & Rafiee          Expires September 18, 2016               [Page 8]

Internet-Draft        dnssd Scalable DNS-SD Threats           March 2016


   This new routable namespace also lacks the benefit of registrar
   involvement and may not afford an administrator an ability to
   mitigate nefarious activity, such as spoofing and phishing, without
   requisite controls having been first carefully established.  When a
   device has access to different realms on multiple interfaces, it is
   not even clear how simple conflict resolution avoids threatening
   network stability while resolving names conveyed over disparate
   technologies.

2.1.6.  Selective Forwarding based on IGMP or MLD snooping

   Internet Group Management Protocol (IGMP) [RFC3376] supports
   multicast on IPv4 networks.  Multicast Listener Discovery (MLD)
   [RFC3810] supports multicast management on IPv6 networks using ICMPv6
   messaging in contrast to IGMP's bare IP encapsulation.  This
   management allows routers to announce their multicast membership to
   neighboring routers.  To optimize which LANs receive forwarded
   multicast frames, IGMP or MLD snooping can be used to determine the
   presence of listeners as a means to permit selective forwarding of
   multicast frames as well.

2.1.7.  VLAN

   Use of VLAN such as [RFC5517] can selectively extend multicast
   forwarding beyond Bridge limitations.  While not a general solution,
   use of VLAN can both isolate and unite specific networks.

2.1.8.  DHCP

   IP address assignment and host registration might use a single or
   forwarded DHCP [RFC2131] or [RFC3315] server for IPv4 and IPv6
   respectively that responds to interconnected networks as a means to
   register hosts and addresses.  DHCP does not ensure against name or
   address conflict nor is it intended to configure routers.

2.2.  Exfiltration and Poisoning

   IP addresses made visible by DNSSEC [RFC4033] or DNS [RFC1035] that
   conform with DNS-SD [RFC6763] might be used, but the automated
   population of information into DNS [RFC1035] should be limited to
   administrative systems.

   Automated conversion of mDNS [RFC6762] into unicast DNS [RFC1035] can
   be problematic from a security standpoint as can widespread
   propagation of multicast frames. mDNS [RFC6762] only requires
   compliance with [RFC5198] rather than IDNA2008 [RFC5895].  This means
   mDNS [RFC6762] will not ensure instances are visually unique and may
   contain spaces and punctuation not permitted by IDNA2008.  As such,



Otis & Rafiee          Expires September 18, 2016               [Page 9]

Internet-Draft        dnssd Scalable DNS-SD Threats           March 2016


   this might cause users into becoming misled about the associated
   service.

   SSD MUST include requisite filtering necessary to prevent data ex-
   filtration or the interception of sensitive services.  Any exchanged
   data must first ensure locality, limit the resources gathered,
   resolved, and propagated to just those elements that can be
   effectively administrated.  It is critical to ensure normal network
   protection is not lost for hosts that depend on link-local addressing
   and exclusion of routable traffic.  A printer would be one such
   example of a host that can not be upgraded.

2.3.  Amplification Concerns

   It is unknown whether sufficient filtering of mDNS [RFC6762] to
   expose just those services likely needed will provide sufficient
   network protection.  The extent of using IGMP or MLD for selective
   forwarding to mitigate otherwise spurious traffic is unknown.

   Instance names and <SrvDOM> intended to correspond with link-local
   domains may use Unicode for Network Interchange [RFC5198] encoding
   but excludes ASCII control characters while also allowing escaped
   periods "\." and other punctuation and spaces.

   For DNS-SD, Proto="_udp" represents all non-TCP transports otherwise
   it is "_tcp".

   _<sn> = IANA Registered Service Name

   Optional service browsing and various RRsets could result in large
   responses limited only by an MTU that may become fairly large in
   various HomeNet networking protocols.

   Increased reliance on Resource Record Sets (RRsets) for discovery
   increases DDoS amplification concerns when overall RRset size is
   overlooked.  The extent of this amplification had been constrained by
   the minimum MTU first established by [RFC0791] and noted by [RFC1191]
   of 576 bytes which accommodates 512 byte UDP DNS messages.  Most
   Internet links are now able to handle much larger MTUs.  Per
   [RFC2460], the minimum 1280 byte MTU is specified for IPv6.

   To ensure minimal latency, DNS queries are first made using UDP.
   When a response becomes truncated, TCP is then normally attempted.
   Reliance on UDP has been relaxed by [RFC5966].  The size of a PTR
   RRset can be fairly large and result in UDP amplification issues when
   carried within a large minimum MTU.  The potential query/response
   ratio may have a large impact on ISPs and in turn impact a large
   number of users.



Otis & Rafiee          Expires September 18, 2016              [Page 10]

Internet-Draft        dnssd Scalable DNS-SD Threats           March 2016


   At each of the DNS-SD SRV and TXT Resource Record Sets locations that
   offer instance and service enumerations, administration of the
   resulting RRsets must ensure these resources are suitable for
   distribution and the DNS-SD query to response ratio is suitable for
   Internet access.

   DNS-SD [RFC6763] should not be viewed as a catalog structure of
   desired services suitable for Internet use.  [I-D.ietf-dnssd-hybrid]
   is to be used to bridge adjacent networks but this risks conveying
   resources of hosts unable to safely facilitate Internet access.
   Since [I-D.ietf-dnssd-hybrid] should opt for the most conservative
   address mode when selecting addresses to be distributed, ULAs or
   [RFC1918] address should represent a default option rather than
   selecting GUAs.

   Browsing change notification facilitated with [I-D.ietf-dnssd-push]
   uses the message structure defined by [RFC2136] but is based on TCP.
   TCP eliminates spoofed source query attacks and congestion issues.
   If neither QTYPE nor QCLASS are ANY (255) then this is a specific
   subscription to changes for the given name.  When QTYPE or QCLASS are
   ANY (255) then this becomes a wildcard subscription to changes of the
   given name for any type and/or class, as appropriate.

   Browsing resource synchronization should use [I-D.ietf-dnssd-push]
   instead of depending on expanded RRsets or UDP transactions.
   Directly using DNS when overloaded would be much slower.  This is
   because DNS [RFC1035] recommends 5 second timeouts with a doubling on
   two subsequent retries for a total of 35 seconds.

2.3.1.  Resource Exhaustion Threats

   DNS is currently vulnerable whenever responses are much larger than
   associated queries which could occur when browsing a domain offering
   services from a large number of hosts.  To mitigate specific
   problematic query sources, an experimental mode of DNS operation is
   described in a technical note: DNS Response Rate Limiting
   [ISC-TN-2012-1-Draft1].  Additional information is available at
   [RedBarn].

   Another experiment is [I-D.ietf-dnsop-cookies] which reduces reliance
   on DNS Response Rate Limiting and minimizes resources needed to
   handle random initial exchanges in a manner as described by [RFC6013]
   for forged sources of initial TCP <Syn> where servers keep client
   state within encrypted cookies.







Otis & Rafiee          Expires September 18, 2016              [Page 11]

Internet-Draft        dnssd Scalable DNS-SD Threats           March 2016


3.  Protection of SSD related interchange

   SSD protocols may require additional steps to ensure against the
   poisoning of resource collection where close attention should be
   given to the scope of a ULA or [RFC1918] where the related resources
   are not to be directly exchanged with the Internet.

3.1.  Link-Local

   [RFC3927] provides an overview of IPv4 address complexities related
   to dealing with multiple segments and interfaces.  IPv6 introduces
   new paradigms in respect to interface address assignments which offer
   scoping as explained in [RFC4291].

3.2.  Authorization Issues

   DNSSEC [RFC4033] can assert the validity but not the veracity of
   records in a zone file.  The trust model of the global DNS [RFC1035]
   relies on the fact that human administrators either a) manually enter
   resource records into a zone file, or b) configure the DNS [RFC1035]
   server to authenticate a trusted device (e.g., a DHCP server) that
   can automatically maintain such records.

   An imposter may register on the local link and appear as a legitimate
   service.  Such "rogue" services may then be automatically registered
   in wide area DNS-SD [RFC6763].

3.3.  Authentication Issues

   Up to now, the "plug-and-play" nature of mDNS [RFC6762] devices have
   relied only on physical connectivity to the local network.  If a
   device is visible via mDNS [RFC6762], it had been assumed to be
   trusted.  When multiple networks are involved, verifying a host is
   local using mDNS [RFC6762] is no longer possible so other
   verification schemes will be needed.

3.4.  Privacy Considerations

   Mobile devices such as smart phones that can expose the location of
   their owners by registering services in arbitrary zones pose a risk
   to privacy.  Such devices must not register their services in
   arbitrary zones without the approval of their operators.  However, it
   should be possible to configure one or more "safe" zones, e.g., based
   on subnet prefix, in which mobile devices may automatically register
   their services.

   As noted in [CERTvu550620] private security information is leaked in
   many cases.  This includes hostnames and MACs, networking details,



Otis & Rafiee          Expires September 18, 2016              [Page 12]

Internet-Draft        dnssd Scalable DNS-SD Threats           March 2016


   service related details such as those for Printers and NAS devices.
   Many consumer printers can not authenticate users or block addresses
   when connected with IPv6.  Once this information is leaked,
   malefactors are thereby given unlimited access.


4.  IANA Considerations

   This document requires no IANA consideration.


5.  Acknowledgements

   The authors wish to acknowledge valuable contributions from the
   following: Dave Rand, John C. Klensin, Dan York, Harald Albrecht, and
   Paul Vixie












6.  References

6.1.  Normative References

   [I-D.cheshire-homenet-dot-home]
              Cheshire, S., "Special Use Top Level Domain 'home'",
              draft-cheshire-homenet-dot-home-02 (work in progress),
              November 2015.

   [I-D.ietf-dnsop-alt-tld]
              Kumari, W. and A. Sullivan, "The ALT Special Use Top Level
              Domain", draft-ietf-dnsop-alt-tld-03 (work in progress),
              September 2015.

   [I-D.ietf-dnsop-cookies]
              Eastlake, D. and M. Andrews, "Domain Name System (DNS)
              Cookies", draft-ietf-dnsop-cookies-09 (work in progress),
              January 2016.

   [I-D.ietf-dnssd-hybrid]



Otis & Rafiee          Expires September 18, 2016              [Page 13]

Internet-Draft        dnssd Scalable DNS-SD Threats           March 2016


              Cheshire, S., "Hybrid Unicast/Multicast DNS-Based Service
              Discovery", draft-ietf-dnssd-hybrid-03 (work in progress),
              February 2016.

   [I-D.ietf-dnssd-push]
              Pusateri, T. and S. Cheshire, "DNS Push Notifications",
              draft-ietf-dnssd-push-05 (work in progress), January 2016.

   [RFC1035]  Mockapetris, P., "Domain names - implementation and
              specification", STD 13, RFC 1035, DOI 10.17487/RFC1035,
              November 1987, <http://www.rfc-editor.org/info/rfc1035>.

   [RFC1918]  Rekhter, Y., Moskowitz, B., Karrenberg, D., de Groot, G.,
              and E. Lear, "Address Allocation for Private Internets",
              BCP 5, RFC 1918, DOI 10.17487/RFC1918, February 1996,
              <http://www.rfc-editor.org/info/rfc1918>.

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/
              RFC2119, March 1997,
              <http://www.rfc-editor.org/info/rfc2119>.

   [RFC2460]  Deering, S. and R. Hinden, "Internet Protocol, Version 6
              (IPv6) Specification", RFC 2460, DOI 10.17487/RFC2460,
              December 1998, <http://www.rfc-editor.org/info/rfc2460>.

   [RFC2782]  Gulbrandsen, A., Vixie, P., and L. Esibov, "A DNS RR for
              specifying the location of services (DNS SRV)", RFC 2782,
              DOI 10.17487/RFC2782, February 2000,
              <http://www.rfc-editor.org/info/rfc2782>.

   [RFC3492]  Costello, A., "Punycode: A Bootstring encoding of Unicode
              for Internationalized Domain Names in Applications
              (IDNA)", RFC 3492, DOI 10.17487/RFC3492, March 2003,
              <http://www.rfc-editor.org/info/rfc3492>.

   [RFC3587]  Hinden, R., Deering, S., and E. Nordmark, "IPv6 Global
              Unicast Address Format", RFC 3587, DOI 10.17487/RFC3587,
              August 2003, <http://www.rfc-editor.org/info/rfc3587>.

   [RFC4033]  Arends, R., Austein, R., Larson, M., Massey, D., and S.
              Rose, "DNS Security Introduction and Requirements",
              RFC 4033, DOI 10.17487/RFC4033, March 2005,
              <http://www.rfc-editor.org/info/rfc4033>.

   [RFC4193]  Hinden, R. and B. Haberman, "Unique Local IPv6 Unicast
              Addresses", RFC 4193, DOI 10.17487/RFC4193, October 2005,
              <http://www.rfc-editor.org/info/rfc4193>.



Otis & Rafiee          Expires September 18, 2016              [Page 14]

Internet-Draft        dnssd Scalable DNS-SD Threats           March 2016


   [RFC4291]  Hinden, R. and S. Deering, "IP Version 6 Addressing
              Architecture", RFC 4291, DOI 10.17487/RFC4291,
              February 2006, <http://www.rfc-editor.org/info/rfc4291>.

   [RFC5198]  Klensin, J. and M. Padlipsky, "Unicode Format for Network
              Interchange", RFC 5198, DOI 10.17487/RFC5198, March 2008,
              <http://www.rfc-editor.org/info/rfc5198>.

   [RFC5895]  Resnick, P. and P. Hoffman, "Mapping Characters for
              Internationalized Domain Names in Applications (IDNA)
              2008", RFC 5895, DOI 10.17487/RFC5895, September 2010,
              <http://www.rfc-editor.org/info/rfc5895>.

   [RFC5966]  Bellis, R., "DNS Transport over TCP - Implementation
              Requirements", RFC 5966, DOI 10.17487/RFC5966,
              August 2010, <http://www.rfc-editor.org/info/rfc5966>.

   [RFC6106]  Jeong, J., Park, S., Beloeil, L., and S. Madanapalli,
              "IPv6 Router Advertisement Options for DNS Configuration",
              RFC 6106, DOI 10.17487/RFC6106, November 2010,
              <http://www.rfc-editor.org/info/rfc6106>.

   [RFC6762]  Cheshire, S. and M. Krochmal, "Multicast DNS", RFC 6762,
              DOI 10.17487/RFC6762, February 2013,
              <http://www.rfc-editor.org/info/rfc6762>.

   [RFC6763]  Cheshire, S. and M. Krochmal, "DNS-Based Service
              Discovery", RFC 6763, DOI 10.17487/RFC6763, February 2013,
              <http://www.rfc-editor.org/info/rfc6763>.

6.2.  References - Informative

   [CERTvu550620]
              Seaman, C., "CERT Vulnerability Note VU#550620",
              March 2015, <https://www.kb.cert.org/vuls/id/550620>.

   [IEEE.802-11.2012]
              "Information technology - Telecommunications and
              information exchange between systems - Local and
              metropolitan area networks - Specific requirements - Part
              11: Wireless LAN Medium Access Control (MAC) and Physical
              Layer (PHY) specifications", IEEE Standard 802.11,
              February 2012, <http://standards.ieee.org/getieee802/
              download/802.11-2012.pdf>.

   [IEEE.802-1D.2004]
              Institute of Electrical and Electronics Engineers,
              "Information technology - Telecommunications and



Otis & Rafiee          Expires September 18, 2016              [Page 15]

Internet-Draft        dnssd Scalable DNS-SD Threats           March 2016


              information exchange between systems - Local area networks
              - Media access control (MAC) bridges", IEEE Standard
              802.1D, February 2004, <http://standards.ieee.org/
              getieee802/download/802.1D-2004.pdf>.

   [IEEE.802-3.2012]
              "Information technology - Telecommunications and
              information exchange between systems - Local and
              metropolitan area networks - Specific requirements - Part
              3: Carrier sense multiple access with collision detection
              (CSMA/CD) access method and physical layer
              specifications"", IEEE Standard 802.3, August 2012, <http:
              //standards.ieee.org/getieee802/download/
              802.3-2012_section1.pdf>.

   [ISC-TN-2012-1-Draft1]
              Vixie, P. and Rhyolite, "DNS Response Rate Limiting (DNS
              RRL)", April 2012,
              <http://ss.vix.su/~vixie/isc-tn-2012-1.txt>.

   [RFC0791]  Postel, J., "Internet Protocol", STD 5, RFC 791,
              DOI 10.17487/RFC0791, September 1981,
              <http://www.rfc-editor.org/info/rfc791>.

   [RFC1112]  Deering, S., "Host extensions for IP multicasting", STD 5,
              RFC 1112, DOI 10.17487/RFC1112, August 1989,
              <http://www.rfc-editor.org/info/rfc1112>.

   [RFC1191]  Mogul, J. and S. Deering, "Path MTU discovery", RFC 1191,
              DOI 10.17487/RFC1191, November 1990,
              <http://www.rfc-editor.org/info/rfc1191>.

   [RFC2131]  Droms, R., "Dynamic Host Configuration Protocol",
              RFC 2131, DOI 10.17487/RFC2131, March 1997,
              <http://www.rfc-editor.org/info/rfc2131>.

   [RFC2136]  Vixie, P., Ed., Thomson, S., Rekhter, Y., and J. Bound,
              "Dynamic Updates in the Domain Name System (DNS UPDATE)",
              RFC 2136, DOI 10.17487/RFC2136, April 1997,
              <http://www.rfc-editor.org/info/rfc2136>.

   [RFC3007]  Wellington, B., "Secure Domain Name System (DNS) Dynamic
              Update", RFC 3007, DOI 10.17487/RFC3007, November 2000,
              <http://www.rfc-editor.org/info/rfc3007>.

   [RFC3315]  Droms, R., Ed., Bound, J., Volz, B., Lemon, T., Perkins,
              C., and M. Carney, "Dynamic Host Configuration Protocol
              for IPv6 (DHCPv6)", RFC 3315, DOI 10.17487/RFC3315,



Otis & Rafiee          Expires September 18, 2016              [Page 16]

Internet-Draft        dnssd Scalable DNS-SD Threats           March 2016


              July 2003, <http://www.rfc-editor.org/info/rfc3315>.

   [RFC3376]  Cain, B., Deering, S., Kouvelas, I., Fenner, B., and A.
              Thyagarajan, "Internet Group Management Protocol, Version
              3", RFC 3376, DOI 10.17487/RFC3376, October 2002,
              <http://www.rfc-editor.org/info/rfc3376>.

   [RFC3810]  Vida, R., Ed. and L. Costa, Ed., "Multicast Listener
              Discovery Version 2 (MLDv2) for IPv6", RFC 3810,
              DOI 10.17487/RFC3810, June 2004,
              <http://www.rfc-editor.org/info/rfc3810>.

   [RFC3927]  Cheshire, S., Aboba, B., and E. Guttman, "Dynamic
              Configuration of IPv4 Link-Local Addresses", RFC 3927,
              DOI 10.17487/RFC3927, May 2005,
              <http://www.rfc-editor.org/info/rfc3927>.

   [RFC4043]  Pinkas, D. and T. Gindin, "Internet X.509 Public Key
              Infrastructure Permanent Identifier", RFC 4043,
              DOI 10.17487/RFC4043, May 2005,
              <http://www.rfc-editor.org/info/rfc4043>.

   [RFC4510]  Zeilenga, K., Ed., "Lightweight Directory Access Protocol
              (LDAP): Technical Specification Road Map", RFC 4510,
              DOI 10.17487/RFC4510, June 2006,
              <http://www.rfc-editor.org/info/rfc4510>.

   [RFC4541]  Christensen, M., Kimball, K., and F. Solensky,
              "Considerations for Internet Group Management Protocol
              (IGMP) and Multicast Listener Discovery (MLD) Snooping
              Switches", RFC 4541, DOI 10.17487/RFC4541, May 2006,
              <http://www.rfc-editor.org/info/rfc4541>.

   [RFC4903]  Thaler, D., "Multi-Link Subnet Issues", RFC 4903,
              DOI 10.17487/RFC4903, June 2007,
              <http://www.rfc-editor.org/info/rfc4903>.

   [RFC4944]  Montenegro, G., Kushalnagar, N., Hui, J., and D. Culler,
              "Transmission of IPv6 Packets over IEEE 802.15.4
              Networks", RFC 4944, DOI 10.17487/RFC4944, September 2007,
              <http://www.rfc-editor.org/info/rfc4944>.

   [RFC5517]  HomChaudhuri, S. and M. Foschiano, "Cisco Systems' Private
              VLANs: Scalable Security in a Multi-Client Environment",
              RFC 5517, DOI 10.17487/RFC5517, February 2010,
              <http://www.rfc-editor.org/info/rfc5517>.

   [RFC6013]  Simpson, W., "TCP Cookie Transactions (TCPCT)", RFC 6013,



Otis & Rafiee          Expires September 18, 2016              [Page 17]

Internet-Draft        dnssd Scalable DNS-SD Threats           March 2016


              DOI 10.17487/RFC6013, January 2011,
              <http://www.rfc-editor.org/info/rfc6013>.

   [RFC6281]  Cheshire, S., Zhu, Z., Wakikawa, R., and L. Zhang,
              "Understanding Apple's Back to My Mac (BTMM) Service",
              RFC 6281, DOI 10.17487/RFC6281, June 2011,
              <http://www.rfc-editor.org/info/rfc6281>.

   [RFC6895]  Eastlake 3rd, D., "Domain Name System (DNS) IANA
              Considerations", BCP 42, RFC 6895, DOI 10.17487/RFC6895,
              April 2013, <http://www.rfc-editor.org/info/rfc6895>.

   [RFC6950]  Peterson, J., Kolkman, O., Tschofenig, H., and B. Aboba,
              "Architectural Considerations on Application Features in
              the DNS", RFC 6950, DOI 10.17487/RFC6950, October 2013,
              <http://www.rfc-editor.org/info/rfc6950>.

   [RFC7217]  Gont, F., "A Method for Generating Semantically Opaque
              Interface Identifiers with IPv6 Stateless Address
              Autoconfiguration (SLAAC)", RFC 7217, DOI 10.17487/
              RFC7217, April 2014,
              <http://www.rfc-editor.org/info/rfc7217>.

   [RFC7368]  Chown, T., Ed., Arkko, J., Brandt, A., Troan, O., and J.
              Weil, "IPv6 Home Networking Architecture Principles",
              RFC 7368, DOI 10.17487/RFC7368, October 2014,
              <http://www.rfc-editor.org/info/rfc7368>.

   [RFC7513]  Bi, J., Wu, J., Yao, G., and F. Baker, "Source Address
              Validation Improvement (SAVI) Solution for DHCP",
              RFC 7513, DOI 10.17487/RFC7513, May 2015,
              <http://www.rfc-editor.org/info/rfc7513>.

   [RFC7558]  Lynn, K., Cheshire, S., Blanchet, M., and D. Migault,
              "Requirements for Scalable DNS-Based Service Discovery
              (DNS-SD) / Multicast DNS (mDNS) Extensions", RFC 7558,
              DOI 10.17487/RFC7558, July 2015,
              <http://www.rfc-editor.org/info/rfc7558>.

   [RedBarn]  Vixie, P. and Rhyolite, "Response Rate Limiting in the
              Domain Name System (DNS RRL)", June 2012,
              <http://www.redbarn.org/dns/ratelimits>.









Otis & Rafiee          Expires September 18, 2016              [Page 18]

Internet-Draft        dnssd Scalable DNS-SD Threats           March 2016


Appendix A.  mDNS Example of Device Resolution Information


   dns-sd -L "Brother MFC-9560CDW" _printer._tcp local
     Lookup Brother MFC-9560CDW._printer._tcp.local

   16:00:26.965  Brother\032MFC-9560CDW._printer._tcp.local.
    can be reached at BRN30066C239958.local.:515
   (interface 4) Flags: 2 txtvers=1 qtotal=1
   pdl=application/vnd.hp-PCL,application/vnd.brother-hbp
   rp=duerqxesz5090 ty=Brother\ MFC-9560CDW\
   product=\(Brother\ MFC-9560CDW\)
   adminurl=http://BRN30066C239958.local./
   priority=75 usb_MFG=Brother usb_MDL=MFC-9560CDW
   Color=T Copies=T Duplex=F PaperCustom=T Binary=T Transparent=T TBCP=F

   Timestamp    A/R Flg if Hostname         Address                  TTL
   16:14:34.855 Add  3  4 BRN30066C239958.local.
                          192.168.99.99                              245
   16:14:34.856 Add  2  4 BRN30066C239958.local.
                          2699:9999:7300:1510:3205:5CFF:FE23:9958%<0>245

   dns-sd -L "Canon MX920 series" _printer._tcp local.
   Lookup Canon MX920 series._printer._tcp.local.

   16:47:09.676  Canon\032MX920\032series._printer._tcp.local.
    can be reached at 9299990000.local.:515 (interface 4) Flags: 2
    txtvers=1 rp=auto note= qtotal=1 priority=60 ty=Canon\ MX920
    \ series product=\(Canon\ MX920\ series\)
    pdl=application/octet-stream adminurl=http://929999000000.local.
    usb_MFG=Canon usb_MDL=MX920\ series
    usb_CMD= UUID=00000000-0000-1000-8000-F4813999999
    Color=T Duplex=T Scan=T Fax=F mac=F4:81:39:99:99:99

   dns-sd -G v4v6 "9299999000000.local."
   Timestamp    A/R Flg if Hostname         Address                  TTL
   17:07:12.460 Add  3  4 929999000000.local.
                          FE80:0000:0000:0000:F681:39FF:FE92:9999%en0 65
   17:07:12.461 Add   2 4 929999000000.local.
                           192.168.99.108                             65











Otis & Rafiee          Expires September 18, 2016              [Page 19]

Internet-Draft        dnssd Scalable DNS-SD Threats           March 2016


Appendix B.  Uncontrolled Access Example

   The risk is that adequate IPv6 filtering is simply not available on
   either current printers, scanners, cameras and other devices never
   intended to be used directly on the Internet.

   For example, in the case of a printer:

   ftp [DNS entry]

   Trying 2699:9999:7300:1510:3205:5cff:fe23:9958...
   Connected to [DNS entry]
   220 FTP print service:V-1.13/Use the network password for the ID if
   updating.
   Name (BRN30066C239958.local.:dlr): ftp
   230 User ftp logged in.
   ftp> ls
   229 Entering Extended Passive Mode (|||62468|)
   150 Transfer Start
   total 1
   -r--r--r--   1 root     printer   4096 Sep 28  2001 CFG-PAGE.TXT
   ----------   1 root     printer      0 Sep 28  2001 Toner-Low-------
   226 Data Transfer OK.
   ftp>

   From here, I can print a file with no further authentication.
   But the printer also now appears on the Internet with TCP ports
   21,23,25,80,515,631 and 9100 active.  I can scan a document that
   was left in the flatbed.  I can send a fax.  Or I can print many
   copies of black pages if I want to do a physical DOS.  And, thanks
   to the globally routable address present, I can reach this from
   anywhere in the world.



















Otis & Rafiee          Expires September 18, 2016              [Page 20]

Internet-Draft        dnssd Scalable DNS-SD Threats           March 2016


Authors' Addresses

   Douglas Otis
   Trend Micro
   10101 N. De Anza Blvd
   Cupertino, CA  95014
   USA

   Phone: +1.408.257-1500
   Email: doug_otis@trendmicro.com


   Hosnieh Rafiee
   Rozanak.com
   Munich
   Germany

   Phone: +49 (0)176 57587575
   Email: ietf@rozanak.com
































Otis & Rafiee          Expires September 18, 2016              [Page 21]