dnssd                                                            D. Otis
Internet-Draft                                               Trend Micro
Intended status: Informational                            April 22, 2014
Expires: October 24, 2014


                           mDNS X-link review
                     draft-otis-dnssd-mdns-xlink-03

Abstract

   Multicast DNS will not normally extend beyond the MAC Bridge.  This
   limitation is problematic when desired services are beyond the reach
   of multicast mDNS.  This document explores security considerations
   when overcoming this limitation.

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 October 24, 2014.

Copyright Notice

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

   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



Otis                    Expires October 24, 2014                [Page 1]


Internet-Draft                 mDNS xlinks                    April 2014


   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
   2.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . .  4
   3.  Security Considerations  . . . . . . . . . . . . . . . . . . .  4
     3.1.  Multiple Link Strategies . . . . . . . . . . . . . . . . .  5
     3.2.  Scope of Discovery . . . . . . . . . . . . . . . . . . . .  7
     3.3.  Multiple Namespaces  . . . . . . . . . . . . . . . . . . .  7
     3.4.  Authorization  . . . . . . . . . . . . . . . . . . . . . .  8
     3.5.  Authentication . . . . . . . . . . . . . . . . . . . . . .  8
     3.6.  Privacy Considerations . . . . . . . . . . . . . . . . . .  8
   4.  Acknowledgements . . . . . . . . . . . . . . . . . . . . . . .  8
   5.  References . . . . . . . . . . . . . . . . . . . . . . . . . .  9
     5.1.  References - Informative . . . . . . . . . . . . . . . . .  9
     5.2.  References - Normative . . . . . . . . . . . . . . . . . . 11
   Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 11




























Otis                    Expires October 24, 2014                [Page 2]


Internet-Draft                 mDNS xlinks                    April 2014


1.  Introduction

   On Bridged LANs, as described by [IEEE.802-1D.1993], MAC entities
   make their services known via multicast.  Multicast forms a basis for
   networking and layer 3 protocol initialization. [mDNS] provides a
   structure for multicast announcements within the LAN environment.  A
   Bridge acts as an interconnect mechanism transparent to end stations
   on LANs.  Bridges designated to forward frames is normally
   accomplished by participation in a Spanning Tree Algorithm.  Many
   expect [mDNS] resource records can be safely and automatically placed
   into [DNS] to overcome multicast limitations.  Nevertheless, such a
   process must operate in conjunction with requisite controls necessary
   to retain network security.  These controls will be clarified in a
   TBD companion operations document.

   A Bridge forwards frames based on prior source MAC associations with
   incoming frames on different LAN ports.  Source MAC and LAN port
   associations are recommended to expire in 300 seconds.  Frames
   containing source multicast MACs are silently discarded as invalid.
   Frames containing a destination MAC on the same LAN port already
   associated with the MAC are silently discarded.  A valid incoming
   frame with a destination not previously associated with a different
   LAN port is forwarded (flooded) to all other LAN ports, otherwise
   when a MAC destination address is associated with a different LAN
   port from which the frame was received, the frame is selectively
   forwarded to this port.  All broadcast and multicast MACs are flooded
   to all other LAN ports because they do not represent a valid source.
   Flooding operations may create a storm of replicated frames having an
   unknown MAC destination whenever forwarding is enabled on LAN ports
   connected in a loop.

   In [IEEE.802-11.1999] wireless networks, multicast frames are
   transmitted at a low 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.

   Wireless links may be orders of magnitude less reliable than their
   wired counterparts.  To improve transmission reliability,
   [IEEE.802-11.1999] requires positive acknowledgement of unicast
   frames.  It does not, however, support positive acknowledgement of
   multicast frames.  As a result, it is common to observe much higher
   loss of multicast frames on wireless compared against wired network
   technologies.







Otis                    Expires October 24, 2014                [Page 3]


Internet-Draft                 mDNS xlinks                    April 2014


2.  IANA Considerations

   This document requires no IANA consideration.


3.  Security Considerations

   Scalable DNS-SD (SSD) proposes to automatically gather autonomously
   named link-local resource records by observing [mDNS] traffic to then
   make these resources visible and accessible from other networks.  By
   doing so, address translation is likely needed since typical link-
   local addresses are not usable from other networks.  As such, more
   than just the security considerations discussed in [mDNS] and
   [DNS-SD] are needed.  For example, [DNS-SD] 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."

   By viewing [DNS-SD] as only a catalog structure of the desired
   resources can such a claim be supported.  However, a hybrid proxy
   scheme that bridges adjacent networks may convey resources unable to
   facilitate access without translation.  Instead of using normally
   assigned link-local addresses, routable addresses must be used.  In
   addition, the exchange must ensure source locality prior to its
   conveyance, because afterward source locality can no longer be
   determined.

   This requires a process that limits resources gathered, resolved, and
   propagated to what can be administrated.  As such, an [mDNS] proxy
   scheme represents a profound change to network security.  The
   following sections highlight potential threats posed by deploying
   [DNS-SD] over multiple links through the automated collection and
   translation of [mDNS] resources.  This conveyance expands namespaces
   into .local., .sitelocal., and [DNS] which may also cache Internet
   namespace.  This new routable namespace 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.

   Managing autonomously named resources becomes especially salient
   since visually selected names are not ensured uniquely represented
   nor quickly resolved due to latency uncertainties.  For example,
   [DNS] recommends 5 second timeouts with a doubling on two subsequent



Otis                    Expires October 24, 2014                [Page 4]


Internet-Draft                 mDNS xlinks                    April 2014


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

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

3.1.  Multiple Link Strategies

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

3.1.2.  RBridge

   RBridges [RFC6325] are compatible with previous [IEEE.802-1D.1993]
   customer bridges as well as IPv4 and IPv6 routers and end nodes.
   RBridges may support either [IEEE.802-3.1998] or other link
   technologies.  RBridges are invisible to current IP routers as
   bridges are and, like routers, terminate the Bridge spanning tree
   protocol.  The RBridge design supports VLANs and optimization of the
   distribution of multi-destination frames based on VLAN ID or on IP-
   derived multicast groups.  It also allows unicast forwarding tables
   at transit RBridges to be sized according to the number of RBridges
   (rather than the number of end nodes), which allows their forwarding
   tables to be substantially smaller than in conventional customer
   bridges.

   Consolidating MAC/LAN port association at individual RBridge nodes
   does not necessarily combine all LANs into a flat MAC space.  It is
   possible to filter RBridge to RBridge traffic, however such filtering
   is unlikely needed for a home or small office.  In addition, RBridge



Otis                    Expires October 24, 2014                [Page 5]


Internet-Draft                 mDNS xlinks                    April 2014


   also supports PPP [RFC6361] to facilitate the merger of other
   physical transport technologies.  Use of RBridge can incrementally
   simplify the LAN environment while also eliminating bottlenecks
   imposed by a Spanning Tree Algorithm.  Use of RBridge can also
   satisfy normal link-local network restrictions when necessary.

   [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.1.3.  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.

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

3.1.5.  Automated placement of mDNS resources into DNS

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

   Automated conversion of [mDNS] into unicast [DNS] can be problematic
   from a security standpoint as can the widespread propagation of
   multicast frames. [mDNS] only requires compliance with [RFC5198]
   rather than IDNA2008 [RFC5895].  This means [mDNS] does not ensure
   instances are visually unique and may contain spaces and punctuation
   not permitted by IDNA2008.  As such, this might allow users into
   becoming misled about the scope of a name.

   Public Suffix lists might help simplify creation of A-Labels from
   UTF-8 user input by offering matching items for user selection.  A
   [PublicSuffix] list represents DNS domain names reserved for
   registrations by appropriate authorities.  This still leaves the
   domain registered above the public suffix, but its validation and
   encoding should involve fewer transactions.

   Replacing ASCII punctuation and spaces in the label with the '_'
   character, except when located as the leftmost character, may reduce



Otis                    Expires October 24, 2014                [Page 6]


Internet-Draft                 mDNS xlinks                    April 2014


   some handling issues related to end of string parsing, since labels
   in [DNS] normally do not contain spaces or punctuation.
   Nevertheless, [DNS] is able to handle such labels within sub-domains
   of registered domains.

   Services outside the ".local." domain may have applications obtaining
   domain search lists provided by DHCP ([RFC2131] and [RFC3315] for
   IPv4 and IPv6 respectively or RA DNSSL [RFC6106] also for IPv6.
   Internet domains need to be published in [DNS] as A-Labels [RFC3492]
   because IDNA2008 compliance depends on A-label enforcement by
   registrars.  Therefore A-Labels and not U-Labels must be published in
   DNS for Internet domains at this time.

   The SRV scheme used by [mDNS] 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 which lacked
   sufficient name hierarchy.  Such common use may represent security
   considerations whenever these records can be automatically published.

   It is unknown whether sufficient filtering of [mDNS] to expose just
   those services likely needed will sufficiently protect wireless
   networks.  The extent of RBridge use and something analogous to IGMP
   or MLD for selective forwarding might help to mitigate otherwise
   spurious traffic is unknown.

3.2.  Scope of Discovery

   As [mDNS] 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.  In a multi-link scenario,
   the owner of the advertised service may not have a clear indication
   of the scope of its advertisement.

   If the advertisement propagates to a larger set of links than
   expected, this 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 setup or constrained,
   then information leaks will happen beyond the appropriate network
   which may also expose the network to various forms of attack as well.

3.3.  Multiple Namespaces

   There is a possibility of conflicts between local and global [DNS]
   namespaces.  Without adequate feedback, a client may not know if the
   target service is the correct one, therefore enabling potential



Otis                    Expires October 24, 2014                [Page 7]


Internet-Draft                 mDNS xlinks                    April 2014


   attacks.

   A Host unable to recognize when it is in conflict with itself over
   multiple realms also represents a potential network stability threat.

3.4.  Authorization

   [DNSSEC] can assert the validity but not the veracity of records in a
   zone file.  The trust model of the global [DNS] relies on the fact
   that human administrators either a) manually enter resource records
   into a zone file, or b) configure the [DNS] 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].

3.5.  Authentication

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

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


4.  Acknowledgements

   The authors wish to acknowledge valuable contributions from the
   following: Dave Rand, Michael Tuexen, Hosnieh Rafiee




5.  References





Otis                    Expires October 24, 2014                [Page 8]


Internet-Draft                 mDNS xlinks                    April 2014


5.1.  References - Informative

   [IEEE.802-11.1999]
              "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, 1999, <
              http://standards.ieee.org/getieee802/download/
              802.11-1999.pdf>.

   [IEEE.802-1D.1993]
              Institute of Electrical and Electronics Engineers,
              "Information technology - Telecommunications and
              information exchange between systems - Local area networks
              - Media access control (MAC) bridges", IEEE Standard
              802.1D, July 1993.

   [IEEE.802-3.1998]
              "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, September 1998.

   [PublicSuffix]
              http://www.mozilla.org/, "A public suffix is a set of DNS
              names or wildcards concatenated with dots. It represents
              the part of a domain name which is not under the control
              of the individual registrant.", April 2014,
              <https://www.publicsuffix.org/list/>.

   [RFC1035]  Mockapetris, P., "Domain names - implementation and
              specification", STD 13, RFC 1035, November 1987.

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119, March 1997.

   [RFC2131]  Droms, R., "Dynamic Host Configuration Protocol",
              RFC 2131, March 1997.

   [RFC2251]  Wahl, M., Howes, T., and S. Kille, "Lightweight Directory
              Access Protocol (v3)", RFC 2251, December 1997.

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



Otis                    Expires October 24, 2014                [Page 9]


Internet-Draft                 mDNS xlinks                    April 2014


   [RFC3376]  Cain, B., Deering, S., Kouvelas, I., Fenner, B., and A.
              Thyagarajan, "Internet Group Management Protocol, Version
              3", RFC 3376, October 2002.

   [RFC3492]  Costello, A., "Punycode: A Bootstring encoding of Unicode
              for Internationalized Domain Names in Applications
              (IDNA)", RFC 3492, March 2003.

   [RFC3810]  Vida, R. and L. Costa, "Multicast Listener Discovery
              Version 2 (MLDv2) for IPv6", RFC 3810, June 2004.

   [RFC3927]  Cheshire, S., Aboba, B., and E. Guttman, "Dynamic
              Configuration of IPv4 Link-Local Addresses", RFC 3927,
              May 2005.

   [RFC4291]  Hinden, R. and S. Deering, "IP Version 6 Addressing
              Architecture", RFC 4291, February 2006.

   [RFC4541]  Christensen, M., Kimball, K., and F. Solensky,
              "Considerations for Internet Group Management Protocol
              (IGMP) and Multicast Listener Discovery (MLD) Snooping
              Switches", RFC 4541, May 2006.

   [RFC5198]  Klensin, J. and M. Padlipsky, "Unicode Format for Network
              Interchange", RFC 5198, March 2008.

   [RFC5310]  Bhatia, M., Manral, V., Li, T., Atkinson, R., White, R.,
              and M. Fanto, "IS-IS Generic Cryptographic
              Authentication", RFC 5310, February 2009.

   [RFC5517]  HomChaudhuri, S. and M. Foschiano, "Cisco Systems' Private
              VLANs: Scalable Security in a Multi-Client Environment",
              RFC 5517, February 2010.

   [RFC5895]  Resnick, P. and P. Hoffman, "Mapping Characters for
              Internationalized Domain Names in Applications (IDNA)
              2008", RFC 5895, September 2010.

   [RFC6106]  Jeong, J., Park, S., Beloeil, L., and S. Madanapalli,
              "IPv6 Router Advertisement Options for DNS Configuration",
              RFC 6106, November 2010.

   [RFC6165]  Banerjee, A. and D. Ward, "Extensions to IS-IS for Layer-2
              Systems", RFC 6165, April 2011.

   [RFC6325]  Perlman, R., Eastlake, D., Dutt, D., Gai, S., and A.
              Ghanwani, "Routing Bridges (RBridges): Base Protocol
              Specification", RFC 6325, July 2011.



Otis                    Expires October 24, 2014               [Page 10]


Internet-Draft                 mDNS xlinks                    April 2014


   [RFC6361]  Carlson, J. and D. Eastlake, "PPP Transparent
              Interconnection of Lots of Links (TRILL) Protocol Control
              Protocol", RFC 6361, August 2011.

   [RFC6951]  Tuexen, M. and R. Stewart, "UDP Encapsulation of Stream
              Control Transmission Protocol (SCTP) Packets for End-Host
              to End-Host Communication", RFC 6951, May 2013.

5.2.  References - Normative

   [DNS]      Mockapetris, P., "Domain names - concepts and facilities",
              STD 13, RFC 1034, November 1987.

   [DNS-SD]   Cheshire, S. and M. Krochmal, "DNS-Based Service
              Discovery", RFC 6763, February 2013.

   [DNSSEC]   Arends, R., Austein, R., Larson, M., Massey, D., and S.
              Rose, "DNS Security Introduction and Requirements",
              RFC 4033, March 2005,
              <http://tools.ietf.org/html/rfc4033>.

   [RFC1034]  Mockapetris, P., "Domain names - concepts and facilities",
              STD 13, RFC 1034, November 1987.

   [RFC4033]  Arends, R., Austein, R., Larson, M., Massey, D., and S.
              Rose, "DNS Security Introduction and Requirements",
              RFC 4033, March 2005.

   [RFC6762]  Cheshire, S. and M. Krochmal, "Multicast DNS", RFC 6762,
              February 2013.

   [RFC6763]  Cheshire, S. and M. Krochmal, "DNS-Based Service
              Discovery", RFC 6763, February 2013.

   [mDNS]     Cheshire, S. and M. Krochmal, "Multicast DNS", RFC 6762,
              February 2013.















Otis                    Expires October 24, 2014               [Page 11]


Internet-Draft                 mDNS xlinks                    April 2014


Author's Address

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

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









































Otis                    Expires October 24, 2014               [Page 12]