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]
