One document matched: draft-otis-dnssd-mdns-xlink-03.xml
<?xml version='1.0' encoding="UTF-8"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!ENTITY RFC1034 PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.1034.xml'>
<!ENTITY RFC1035 PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.1035.xml'>
<!ENTITY RFC1112 PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.1112.xml'>
<!ENTITY RFC2119 PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml'>
<!ENTITY RFC2131 PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.2131.xml'>
<!ENTITY RFC2251 PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.2251.xml'>
<!ENTITY RFC3315 PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.3315.xml'>
<!ENTITY RFC3376 PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.3376.xml'>
<!ENTITY RFC3492 PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.3492.xml'>
<!ENTITY RFC3810 PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.3810.xml'>
<!ENTITY RFC3927 PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.3927.xml'>
<!ENTITY RFC4033 PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.4033.xml'>
<!ENTITY RFC4188 PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.4188.xml'>
<!ENTITY RFC4291 PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.4291.xml'>
<!ENTITY RFC4541 PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.4541.xml'>
<!ENTITY RFC5198 PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.5198.xml'>
<!ENTITY RFC5310 PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.5310.xml'>
<!ENTITY RFC5517 PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.5517.xml'>
<!ENTITY RFC5895 PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.5895.xml'>
<!ENTITY RFC6106 PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.6106.xml'>
<!ENTITY RFC6165 PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.6165.xml'>
<!ENTITY RFC6325 PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.6325.xml'>
<!ENTITY RFC6361 PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.6361.xml'>
<!ENTITY RFC6762 PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.6762.xml'>
<!ENTITY RFC6763 PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.6763.xml'>
<!ENTITY RFC6951 PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.6951.xml'>
<!ENTITY IEEE.802-1D.1993 PUBLIC '' 'http://xml.resource.org/public/bibxml-misc/reference.IEEE.802-1D.1993.xml'>
<!ENTITY IEEE.802-3.1998 PUBLIC '' 'http://xml.resource.org/public/bibxml-misc/reference.IEEE.802-3.1998.xml'>
<!ENTITY IEEE.802-11.1999 PUBLIC '' 'http://xml.resource.org/public/bibxml-misc/reference.IEEE.802-11.1999.xml'>
]>
<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>
<?rfc compact="yes" ?>
<?rfc subcompact="no" ?>
<?rfc toc="yes" ?>
<?rfc tocindent="yes" ?>
<?rfc tocdepth="2" ?>
<?rfc symrefs="yes" ?>
<?rfc sortrefs="yes"?>
<?rfc iprnotified="no" ?>
<rfc category="info" docName="draft-otis-dnssd-mdns-xlink-03" ipr="trust200902">
<front>
<title abbrev="mDNS xlinks"> mDNS X-link review</title>
<author fullname="Douglas Otis" initials="D." surname="Otis">
<organization>Trend Micro</organization>
<address>
<postal>
<street>10101 N. De Anza Blvd</street>
<city>Cupertino</city>
<region>CA</region>
<code>95014</code>
<country>USA</country>
</postal>
<phone>+1.408.257-1500</phone>
<email>doug_otis@trendmicro.com</email>
</address>
</author>
<date day="22" month="April" year="2014"/>
<area>Internet Area</area>
<workgroup>dnssd</workgroup>
<keyword>bonjour, link-local, utf-8, hostname, service-discovery, gateway, cross-link, xlink,
rbridge, vlan</keyword>
<abstract>
<t>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.</t>
</abstract>
<note title="Requirements Language">
<t>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
<xref target="RFC2119"/>.</t>
</note>
</front>
<middle>
<section title="Introduction">
<t>On Bridged LANs, as described by <xref target="IEEE.802-1D.1993"/>, MAC entities make their
services known via multicast. Multicast forms a basis for networking and layer 3 protocol
initialization. <xref target="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 <xref target="mDNS"/> resource
records can be safely and automatically placed into <xref target="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.</t>
<t>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.</t>
<t>In <xref target="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.</t>
<t>Wireless links may be orders of magnitude less reliable than their wired counterparts. To
improve transmission reliability, <xref target="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.</t>
<t/>
</section>
<section title="IANA Considerations">
<t>This document requires no IANA consideration.</t>
</section>
<section title="Security Considerations">
<t>Scalable DNS-SD (SSD) proposes to automatically gather autonomously named link-local
resource records by observing <xref target="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 <xref target="mDNS"/> and <xref
target="DNS-SD"/> are needed. For example, <xref target="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."</t>
<t>By viewing <xref target="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.</t>
<t>This requires a process that limits resources gathered, resolved, and propagated to what
can be administrated. As such, an <xref target="mDNS"/> proxy scheme represents a profound
change to network security. The following sections highlight potential threats posed by
deploying <xref target="DNS-SD"/> over multiple links through the automated collection and
translation of <xref target="mDNS"/> resources. This conveyance expands namespaces into
.local., .sitelocal., and <xref target="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.</t>
<t>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, <xref target="DNS"/> recommends 5 second timeouts with a
doubling on two subsequent retries for a total of 35 seconds. <xref target="mDNS"/> only
requires compliance with <xref target="RFC5198"/> rather than IDNA2008 <xref
target="RFC5895"/>. This less restrictive use of the name space may impair the defense of
critical services from look-alike attack. <xref target="mDNS"/> does not ensure instances
are visually unique and allows spaces and punctuation not permitted by IDNA2008.</t>
<t>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.</t>
<section title="Multiple Link Strategies">
<section title="Selective Forwarding based on IGMP or MLD snooping">
<t>Internet Group Management Protocol (IGMP) <xref target="RFC3376"/> supports multicast
on IPv4 networks. Multicast Listener Discovery (MLD) <xref target="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.</t>
</section>
<section title="RBridge">
<t>RBridges <xref target="RFC6325"/> are compatible with previous <xref
target="IEEE.802-1D.1993"/> customer bridges as well as IPv4 and IPv6 routers and end
nodes. RBridges may support either <xref target="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.</t>
<t>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 <xref target="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.</t>
<t><xref target="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 <xref
target="RFC4291"/>.</t>
</section>
<section title="VLAN">
<t>Use of VLAN such as <xref target="RFC5517"/> can selectively extend multicast
forwarding beyond Bridge limitations. While not a general solution, use of VLAN can both
isolate and unite specific networks.</t>
</section>
<section title="DHCP">
<t>IP address assignment and host registration might use a single or forwarded DHCP <xref
target="RFC2131"/> or <xref target="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.</t>
</section>
<section title="Automated placement of mDNS resources into DNS">
<t>IP addresses made visible by <xref target="DNSSEC"/> or <xref target="DNS"/> that
conform with <xref target="RFC6763"/> might be used, but the automated population of
information into <xref target="DNS"/> should be limited to administrative systems.</t>
<t>Automated conversion of <xref target="mDNS"/> into unicast <xref target="DNS"/> can be
problematic from a security standpoint as can the widespread propagation of multicast
frames. <xref target="mDNS"/> only requires compliance with <xref target="RFC5198"/>
rather than IDNA2008 <xref target="RFC5895"/>. This means <xref target="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.</t>
<t>Public Suffix lists might help simplify creation of A-Labels from UTF-8 user input by
offering matching items for user selection. A <xref target="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.</t>
<t>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 <xref target="DNS"/> normally do not contain spaces or
punctuation. Nevertheless, <xref target="DNS"/> is able to handle such labels within
sub-domains of registered domains.</t>
<t>Services outside the ".local." domain may have applications obtaining domain search
lists provided by DHCP (<xref target="RFC2131"/> and <xref target="RFC3315"/> for IPv4
and IPv6 respectively or RA DNSSL <xref target="RFC6106"/> also for IPv6. Internet
domains need to be published in <xref target="DNS"/> as A-Labels <xref target="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.</t>
<t>The SRV scheme used by <xref target="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.</t>
<t>It is unknown whether sufficient filtering of <xref target="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.</t>
</section>
</section>
<section title="Scope of Discovery">
<t>As <xref target="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.</t>
<t>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.</t>
<t>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.</t>
</section>
<section title="Multiple Namespaces">
<t>There is a possibility of conflicts between local and global <xref target="DNS"/>
namespaces. Without adequate feedback, a client may not know if the target service is the
correct one, therefore enabling potential attacks.</t>
<t>A Host unable to recognize when it is in conflict with itself over multiple realms also
represents a potential network stability threat.</t>
</section>
<section title="Authorization">
<t><xref target="DNSSEC"/> can assert the validity but not the veracity of records in a zone
file. The trust model of the global <xref target="DNS"/> relies on the fact that human
administrators either a) manually enter resource records into a zone file, or b) configure
the <xref target="DNS"/> server to authenticate a trusted device (e.g., a DHCP server)
that can automatically maintain such records.</t>
<t>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 <xref target="DNS-SD"
/>.</t>
</section>
<section title="Authentication">
<t>Up to now, the "plug-and-play" nature of <xref target="mDNS"/> devices have relied only
on physical connectivity to the local network. If a device is visible via <xref
target="mDNS"/>, it had been assumed to be trusted. When multiple networks are involved,
verifying a host is local using <xref target="mDNS"/> is no longer possible so other
verification schemes must be used.</t>
</section>
<section title="Privacy Considerations">
<t>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.</t>
</section>
</section>
<section anchor="Acknowledgements" title="Acknowledgements">
<t>The authors wish to acknowledge valuable contributions from the following: Dave Rand,
Michael Tuexen, Hosnieh Rafiee <vspace blankLines="2"/></t>
</section>
</middle>
<back>
<references title="References - Informative"> &RFC1035; &RFC2119; &RFC2131; &RFC2251; &RFC3315;
&RFC3376; &RFC3492;&RFC3810; &RFC3927; &RFC4291; &RFC4541; &RFC5198; &RFC5310; &RFC5517;
&RFC5895; &RFC6106; &RFC6165; &RFC6325; &RFC6361; &RFC6951; &IEEE.802-1D.1993;
&IEEE.802-3.1998; &IEEE.802-11.1999; <reference anchor="PublicSuffix"
target="https://www.publicsuffix.org/list/">
<front>
<title>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.</title>
<author>
<organization>http://www.mozilla.org/</organization>
</author>
<date year="2014" month="April"/>
<abstract>
<t>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. Covered by Mozilla Public License Version 2.0. The public suffix is
encoded in ASCII/ACE and normalized according to RFC 3454, i.e. the same encoding
returned by nsIURI::GetAsciiHost(). If consumers wish to compare the result of this
method against the host from another nsIURI, the host should be obtained using
nsIURI::GetAsciiHost(). In the case of nested URIs, the innermost URI will be
used.</t>
</abstract>
</front>
<format type="TXT" target="https://www.publicsuffix.org/list/effective_tld_names.dat"/>
</reference>
</references>
<references title="References - Normative">
<reference anchor="DNSSEC" target="http://tools.ietf.org/html/rfc4033">
<front>
<title>DNS Security Introduction and Requirements</title>
<author initials="R." surname="Arends" fullname="R. Arends">
<organization/>
</author>
<author initials="R." surname="Austein" fullname="R. Austein">
<organization/>
</author>
<author initials="M." surname="Larson" fullname="M. Larson">
<organization/>
</author>
<author initials="D." surname="Massey" fullname="D. Massey">
<organization/>
</author>
<author initials="S." surname="Rose" fullname="S. Rose">
<organization/>
</author>
<date year="2005" month="March"/>
<abstract>
<t>The Domain Name System Security Extensions (DNSSEC) add data origin authentication
and data integrity to the Domain Name System. This document introduces these
extensions and describes their capabilities and limitations. This document also
discusses the services that the DNS security extensions do and do not provide. Last,
this document describes the interrelationships between the documents that collectively
describe DNSSEC. [STANDARDS-TRACK]</t>
</abstract>
</front>
<seriesInfo name="RFC" value="4033"/>
<format type="TXT" octets="52445" target="http://www.rfc-editor.org/rfc/rfc4033.txt"/>
</reference>
<reference anchor="DNS">
<front>
<title abbrev="Domain Concepts and Facilities">Domain names - concepts and
facilities</title>
<author initials="P." surname="Mockapetris" fullname="P. Mockapetris">
<organization>Information Sciences Institute (ISI)</organization>
</author>
<date year="1987" day="1" month="November"/>
</front>
<seriesInfo name="STD" value="13"/>
<seriesInfo name="RFC" value="1034"/>
<format type="TXT" octets="129180" target="http://www.rfc-editor.org/rfc/rfc1034.txt"/>
</reference>
<reference anchor="mDNS">
<front>
<title>Multicast DNS</title>
<author initials="S." surname="Cheshire" fullname="S. Cheshire">
<organization/>
</author>
<author initials="M." surname="Krochmal" fullname="M. Krochmal">
<organization/>
</author>
<date year="2013" month="February"/>
<abstract>
<t>As networked devices become smaller, more portable, and more ubiquitous, the ability
to operate with less configured infrastructure is increasingly important. In
particular, the ability to look up DNS resource record data types (including, but not
limited to, host names) in the absence of a conventional managed DNS server is
useful.</t>
<t> Multicast DNS (mDNS) provides the ability to perform DNS-like operations on the
local link in the absence of any conventional Unicast DNS server. In addition,
Multicast DNS designates a portion of the DNS namespace to be free for local use,
without the need to pay any annual fee, and without the need to set up delegations or
otherwise configure a conventional DNS server to answer for those names.</t>
<t> The primary benefits of Multicast DNS names are that (i) they require little or no
administration or configuration to set them up, (ii) they work when no infrastructure
is present, and (iii) they work during infrastructure failures.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="6762"/>
<format type="TXT" octets="184992" target="http://www.rfc-editor.org/rfc/rfc6762.txt"/>
</reference>
<reference anchor="DNS-SD">
<front>
<title>DNS-Based Service Discovery</title>
<author initials="S." surname="Cheshire" fullname="S. Cheshire">
<organization/>
</author>
<author initials="M." surname="Krochmal" fullname="M. Krochmal">
<organization/>
</author>
<date year="2013" month="February"/>
<abstract>
<t>This document specifies how DNS resource records are named and structured to
facilitate service discovery. Given a type of service that a client is looking for,
and a domain in which the client is looking for that service, this mechanism allows
clients to discover a list of named instances of that desired service, using standard
DNS queries. This mechanism is referred to as DNS-based Service Discovery, or
DNS-SD.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="6763"/>
<format type="TXT" octets="125192" target="http://www.rfc-editor.org/rfc/rfc6763.txt"/>
</reference> &RFC4033; &RFC1034; &RFC6762; &RFC6763; </references>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-24 05:27:26 |