dnssd D. Otis
Internet-Draft Trend Micro
Intended status: Informational July 2, 2014
Expires: January 3, 2015
mDNS X-link review
draft-otis-dnssd-mdns-xlink-04
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 January 3, 2015.
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 January 3, 2015 [Page 1]
Internet-Draft mDNS xlinks July 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 . . . . . . . . . . . . . . . . . 6
3.2. Scope of Discovery . . . . . . . . . . . . . . . . . . . . 8
3.3. Multiple Namespaces . . . . . . . . . . . . . . . . . . . 8
3.4. Authorization . . . . . . . . . . . . . . . . . . . . . . 8
3.5. Authentication . . . . . . . . . . . . . . . . . . . . . . 9
3.6. Privacy Considerations . . . . . . . . . . . . . . . . . . 9
4. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 9
5. References . . . . . . . . . . . . . . . . . . . . . . . . . . 9
5.1. References - Informative . . . . . . . . . . . . . . . . . 9
5.2. References - Normative . . . . . . . . . . . . . . . . . . 12
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 12
Otis Expires January 3, 2015 [Page 2]
Internet-Draft mDNS xlinks July 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 where [mDNS] together
with [DNS-SD] 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 Bridge to Bridge multicast limitations.
Nevertheless, such a process must operate in conjunction with
requisite controls necessary to retain network security.
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 January 3, 2015 [Page 3]
Internet-Draft mDNS xlinks July 2014
2. IANA Considerations
This document requires no IANA consideration.
3. Security Considerations
Scalable DNS-SD (SSD) proposes to automatically gather autonomously
named [mDNS] resource records by observing announcement traffic to
then make routable resources visible and accessible from other
networks via unicast [DNS] structured per [DNS-SD]. When doing so,
address translation using ULAs [RFC4193] can offer a significant
level of protection since typical link-local addresses are not usable
from other networks. Not all devices exposed by publishing their
resources in DNS can be expected able to handle resulting direct
Internet access. For either home or enterprise networks, ULAs permit
a local routing plane isolated from that of the Internet. As such,
ULAs also permit local communications to remain unaffected by
Internet related link failures.
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] 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." This simply
overlooks many devices are not automatically published in DNS nor can
it be assumed they are able to handle the direct 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 only accessed as shared elements offered by the
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.cheshire-dnssd-hybrid], errors related to
network boundary detections becomes critical. As such, DNS SHOULD
NOT publish addresses of devices unable to authenticate sessions that
traverse the Internet.
[DNS-SD] should not be viewed as only a catalog structure of desired
services. [I-D.cheshire-dnssd-hybrid] is to be used to bridge
adjacent networks, which risks conveying resources of hosts that are
Otis Expires January 3, 2015 [Page 4]
Internet-Draft mDNS xlinks July 2014
unable to safely facilitate Internet access. Since
[I-D.cheshire-dnssd-hybrid] only expects to disclose routable
addresses while also ignoring use of ULAs, this clearly expects
conveyance of globally routable addresses, GUA. Use of ULAs instead
of GUAs represents a significant change in strategy that permits
limited devices to remain isolated from the Internet while still
allowing packet routing between local network realms in much the same
manner as are MACs employed by [RFC6325].
[I-D.cheshire-dnssd-hybrid] lacks a process able to limit resources
being gathered, resolved, and propagated to those that can be
administrated. As such, an [I-D.cheshire-dnssd-hybrid] 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 publication of
[mDNS] resources into [DNS] as proposed by
[I-D.cheshire-dnssd-hybrid]. This conveyance expands namespaces into
.local., .sitelocal., and [DNS] which may also cache Internet
namespace.
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.
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
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 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.
Otis Expires January 3, 2015 [Page 5]
Internet-Draft mDNS xlinks July 2014
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
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,
Otis Expires January 3, 2015 [Page 6]
Internet-Draft mDNS xlinks July 2014
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
[DNS-SD] 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
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
Otis Expires January 3, 2015 [Page 7]
Internet-Draft mDNS xlinks July 2014
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, multi-realm, and
global [DNS] namespaces. Without adequate feedback, a client may not
know whether the target service is the correct one, which can
therefore enabling potential 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
Otis Expires January 3, 2015 [Page 8]
Internet-Draft mDNS xlinks July 2014
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
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
Otis Expires January 3, 2015 [Page 9]
Internet-Draft mDNS xlinks July 2014
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.
[RFC1112] Deering, S., "Host extensions for IP multi-casting",
STD 5, RFC 1112, August 1989.
[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.
[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.
[RFC3587] Hinden, R., Deering, S., and E. Nordmark, "IPv6 Global
Unicast Address Format", RFC 3587, August 2003.
[RFC3810] Vida, R. and L. Costa, "Multicast Listener Discovery
Otis Expires January 3, 2015 [Page 10]
Internet-Draft mDNS xlinks July 2014
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.
[RFC4193] Hinden, R. and B. Haberman, "Unique Local IPv6 Unicast
Addresses", RFC 4193, October 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.
[RFC6281] Cheshire, S., Zhu, Z., Wakikawa, R., and L. Zhang,
"Understanding Apple's Back to My Mac (BTMM) Service",
RFC 6281, June 2011.
[RFC6325] Perlman, R., Eastlake, D., Dutt, D., Gai, S., and A.
Ghanwani, "Routing Bridges (RBridges): Base Protocol
Specification", RFC 6325, July 2011.
[RFC6361] Carlson, J. and D. Eastlake, "PPP Transparent
Otis Expires January 3, 2015 [Page 11]
Internet-Draft mDNS xlinks July 2014
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>.
[I-D.cheshire-dnssd-hybrid]
Cheshire, S., "Hybrid Unicast/Multicast DNS-Based Service
Discovery", draft-cheshire-dnssd-hybrid-01 (work in
progress), January 2014.
[mDNS] Cheshire, S. and M. Krochmal, "Multicast DNS", RFC 6762,
February 2013.
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 January 3, 2015 [Page 12]