--- 1/draft-ietf-dnssd-requirements-03.txt 2014-10-08 08:14:39.643605784 -0700 +++ 2/draft-ietf-dnssd-requirements-04.txt 2014-10-08 08:14:39.671606468 -0700 @@ -1,23 +1,23 @@ -DNS-SD/mDNS Extensions K. Lynn, Ed. +DNS-SD/mDNS Extensions K. Lynn Internet-Draft Consultant Intended status: Informational S. Cheshire -Expires: January 5, 2015 Apple, Inc. +Expires: April 11, 2015 Apple, Inc. M. Blanchet Viagenie D. Migault Orange - July 4, 2014 + October 8, 2014 Requirements for Scalable DNS-SD/mDNS Extensions - draft-ietf-dnssd-requirements-03 + draft-ietf-dnssd-requirements-04 Abstract DNS-SD/mDNS is widely used today for discovery and resolution of services and names on a local link, but there are use cases to extend DNS-SD/mDNS to enable service discovery beyond the local link. This document provides a problem statement and a list of requirements. Status of This Memo @@ -27,21 +27,21 @@ 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 5, 2015. + This Internet-Draft will expire on April 11, 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 @@ -53,129 +53,122 @@ Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 2. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 3 3. Basic Use Cases . . . . . . . . . . . . . . . . . . . . . . . 5 4. Requirements . . . . . . . . . . . . . . . . . . . . . . . . 6 5. Namespace Considerations . . . . . . . . . . . . . . . . . . 8 6. Security Considerations . . . . . . . . . . . . . . . . . . . 8 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 - 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 10 - 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 10 - Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 11 + 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 11 + 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 11 + Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 12 1. Introduction DNS-Based Service Discovery [DNS-SD] in combination with its companion technology Multicast DNS [mDNS] is widely used today for discovery and resolution of services and names on a local link. However, as users move to multi-link home or campus networks they find that mDNS does not work across routers. DNS-SD can also be used in conjunction with conventional unicast DNS to enable wide-area service discovery, but this capability is not yet widely deployed. This disconnect between customer needs and current practice has led to calls for improvement, such as the Educause petition [EP]. In response to this and similar evidence of market demand, several products now enable service discovery beyond the local link using different ad-hoc techniques. As yet, no consensus has emerged regarding which approach represents the best long-term direction for DNS-based service discovery protocol development. - mDNS in its present form is also not optimized for network + Multicast DNS in its present form is also not optimized for network technologies where multicast transmissions are relatively expensive. - Wireless networks such as [IEEE.802.11] may be adversely affected by - excessive mDNS traffic due to the higher network overhead of - multicast transmissions. Wireless mesh networks such as 6LoWPAN + Wireless networks such as Wi-Fi [IEEE.802.11] may be adversely + affected by excessive mDNS traffic due to the higher network overhead + of multicast transmissions. Wireless mesh networks such as 6LoWPAN [RFC4944] are effectively multi-link subnets [RFC4903] where multicasts must be forwarded by intermediate nodes. It is in the best interests of end users, network administrators, and vendors for all interested parties to cooperate within the context of the IETF to develop an efficient, scalable, and interoperable standards-based solution. This document defines the problem statement and gathers requirements for Scalable DNS-SD/mDNS Extensions. -1.1. 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 "Key words for use in - RFCs to Indicate Requirement Levels" [RFC2119]. - -1.2. Terminology and Acronyms +1.1. Terminology and Acronyms - Service: An endpoint (host and port) for a given application + Service: A listening endpoint (host and port) for a given application protocol. Services are identified by Service Instance Names. - DNS-SD: DNS-Based Service Discovery, as specified in [DNS-SD], is a - conventional application of DNS Resource Records and messages to - facilitate the discovery and location of services. + DNS-SD: DNS-Based Service Discovery [DNS-SD] is a conventional + application of DNS Resource Records and messages to facilitate the + discovery and location of services. - mDNS: Multicast DNS, as specified in [mDNS], is a transport protocol - that facilitates DNS-SD on a local link in the absence of DNS - infrastructure. + mDNS: Multicast DNS [mDNS] is a mechanism that facilitates DNS-SD on + a local link in the absence of traditional DNS infrastructure. SSD: Scalable DNS-SD is a future extension of DNS-SD (and perhaps mDNS) that meets the requirements set forth in this document. Scope of Discovery: A subset of a local or global namespace, e.g., a - DNS zone, that is the target of a given SSD query. + DNS subdomain, that is the target of a given SSD query. Zero Configuration: A deployment of SSD that requires no administration (although some administration may be optional). Incremental Deployment: An orderly transition, as a network installation evolves, from DNS-SD/mDNS to SSD. 2. Problem Statement Service discovery beyond the local link is perhaps the most important feature currently missing from the DNS-SD/mDNS framework. Other issues and requirements are summarized below. 2.1. Multi-link Naming and Discovery A list of desired DNS-SD/mDNS improvements from network administrators in the research and education community was issued in the form of the Educause petition [EP]. The following is a summary - of the technical issues: + of their technical issues: o Products that advertise services such as printing and multimedia streaming via DNS-SD/mDNS are not currently discoverable by devices on other links. It is common practice for enterprises and institutions to use wireless links for client access and wired networks for server infrastructure, typically on different subnets. DNS-SD used with conventional unicast DNS does work when devices are on different links, but the resource records that describe the service must somehow be entered into the unicast DNS namespace. o DNS-SD resource records may be entered manually into a unicast DNS - zone file, but this task must be performed by a DNS administrator. - It is labor-intensive and brittle when IP addresses of devices - change dynamically, as is common when DHCP is used. + zone file [static], but this task must be performed by a DNS + administrator. It is labor-intensive and brittle when IP + addresses of devices change dynamically, as is common when DHCP is + used. o Automatically adding DNS-SD records using DNS Update works, but requires that the DNS server be configured to allow DNS Updates, and requires that devices be configured with the DNS Update credentials to permit such updates, which has proven to be onerous. o Therefore, a mechanism is desired that populates the DNS namespace with the appropriate DNS-SD records with less manual administration than typically needed for a unicast DNS server. - The following is a summary of the technical requirements: + The following is a summary of their technical requirements: o It must scale to a range of hundreds to thousands of DNS-SD/mDNS enabled devices in a given environment. o It must simultaneously operate over a variety of network link technologies, such as wired and wireless networks. o It must not significantly increase network traffic (wired or wireless). @@ -183,89 +176,97 @@ 2.2. IEEE 802.11 Wireless LANs Multicast DNS was originally designed to run on Ethernet - the dominant link-layer at the time. In shared Ethernet networks, multicast frames place little additional demand on the shared network medium compared to unicast frames. In IEEE 802.11 networks however, multicast frames are transmitted at a low data rate supported by all receivers. In practice, this data rate leads to a larger fraction of airtime being devoted to multicast transmission. Some network - administrators block multicast traffic or convert it to a series of - link-layer unicast frames. + administrators block multicast traffic, or use access points that + transmit multicast frames using a series of link-layer unicast + frames. Wireless links may be orders of magnitude less reliable than their wired counterparts. To improve transmission reliability, the IEEE 802.11 MAC 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 as compared to wired network technologies. Enabling service discovery on IEEE 802.11 networks requires that the number of multicast frames be restricted to a suitably low value, or replaced with unicast frames to use the MAC's reliability features. 2.3. Low Power and Lossy Networks (LLNs) Emerging wireless mesh networking technologies such as RPL [RFC6550] and 6LoWPAN present several challenges for the current DNS-SD/mDNS design. First, Link-Local multicast scope [RFC4291] is defined as a single-hop neighborhood. A single subnet prefix in a wireless mesh network may often span multiple links, therefore a larger multicast - scope is required to span it [I-D.ietf-6man-multicast-scopes]. mDNS - is not currently specified for greater than Link-Local scope. + scope is required to span it [RFC7346]. Multicast DNS is + intentionally not specified for greater than Link-Local scope, + because of the additional multicast traffic that would generate. Additionally, low-power nodes may be offline for significant periods either because they are "sleeping" or due to connectivity problems. In such cases LLN nodes might fail to respond to queries or defend their names using the current design. 3. Basic Use Cases The following use cases are defined with different characteristics to help motivate, distinguish, and classify the target requirements. They cover a spectrum of increasing deployment and administrative complexity. (A) Personal Area networks (PANs): the simplest example of a network may consist of a single client and server, e.g., one laptop and one printer, on a common link. PANs that do not - contain a router may use Zero Configuration to assign network - addresses and mDNS to provide naming and service discovery. + contain a router may use Zero Configuration Networking [ZC] to + self-assign link-local addresses [RFC3927] [RFC4862], and + Multicast DNS [mDNS] to provide naming and service discovery. - (B) Classic home or 'hotspot' networks, consisting of: + (B) Classic home or 'hotspot' networks, with the following + properties: - * Single exit router: the network may have multiple upstream + * Single exit router: the network may have one or more upstream providers or networks, but all outgoing and incoming traffic goes through a single router. - * One-level depth: multiple links on the network are bridged to - form a single subnet, which is connected to the default router. + * One-level depth: a single physical link, or multiple physical + links bridged to form a single logical link, that is connected + to the default router. The single logical link provides a + single broadcast domain, facilitating use of link-local + Multicast DNS, and also ARP, which enables the home or + 'hotspot' network to consist of just a single IPv4 subnet. - * Single administrative domain: all nodes under the same admin - entity. (However, this does not necessarily imply a network - administrator.) + * Single administrative domain: all nodes under the same + administrative authority. (However, this does not necessarily + imply a network administrator.) (C) Advanced home and small business networks [I-D.ietf-homenet-arch]: Like B but consist of multiple wired and/or wireless links, connected by routers, behind the single exit router. However, the forwarding nodes are largely self-configuring and do not require routing protocol administration. Such networks should also not require DNS administration. (D) Enterprise networks: Like C but consist of arbitrary network diameter under a single - administrative domain. A large majority of the forwarding and + administrative authority. A large majority of the forwarding and security devices are configured. Large-scale conference-style networks, which are predominantly wireless access, e.g., as available at IETF meetings, also fall within this category. (E) Higher Education networks: Like D but the core network may be under a central administrative domain while leaf networks are under local administrative domains. (F) Mesh networks such as RPL/6LoWPAN: @@ -287,211 +288,246 @@ services, respectively. REQ2: For use cases C, D, and E, there should be a way to configure Scopes of Discovery that support a range of topologically- independent zones (e.g., from department to campus-wide). If multiple scopes are available, there must be a way to enumerate the choices from which a selection can be made. REQ3: As stated in REQ2 above, the discovery scope need not be aligned to network topology. For example, it may instead be - aligned to physical proximity or organizational structure. + aligned to physical proximity (e.g. building) or + organizational structure. REQ4: For use cases C, D, and E, there should be an incremental way to deploy the solution. REQ5: SSD should integrate with current link scope DNS-SD/mDNS protocols and deployments. REQ6: SSD must not adversely affect or break any other current protocols or deployments. REQ7: SSD must be capable of operating across networks that are not limited to a single link or network technology, including clients and services on non-adjacent links. - REQ8: It is desirable that a user or device, when away from such a - site, is still able to discover services within that site, - e.g., a user discovering services in their home network while - remote from it. + REQ8: It is desirable that a user or device be able to discover + services within the sites or networks to which the user or + device is connected. - REQ9: SSD should operate efficiently in all networks, with - particular consideration for potentially lossy or multicast- - challenged wireless networks. + REQ9: SSD should operate efficiently on common link layers and link + types. REQ10: SSD should be considerate of networks where power consumption is a critical factor and, for example, nodes may be in a low power or sleeping state. REQ11: SSD must be scalable to thousands of nodes with minimal configuration and without degrading network performance. A possible figure of merit is that, as the number of services increases, the amount of traffic due to SSD on a given link remains relatively constant. REQ12: SSD should enable a way to provide a consistent user - experience whether local or global services are being + experience whether local or remote services are being discovered. - REQ13: The information presented by SSD should reflect reality. - That is, new information should be available in a timely - fashion and stale information should not persist. + REQ13: The information presented by SSD should closely reflect + reality. That is, new information should be available within + a few seconds and stale information should not persist + indefinitely. In networking all information is necessarily + somewhat out-of-date by the time it reaches the receiver, + even if only by a few microseconds, or less. Thus timeliness + is always an engineering trade-off against efficiency. The + engineering decisions for SSD should appropriately balance + timeliness against network efficiency. REQ14: SSD should operate over existing networks (as described by use cases A-F above) without requiring changes to the network technology or deployment. 5. Namespace Considerations - The unicast DNS namespace contains globally unique names. The mDNS - namespace contains locally unique names. Clients discovering - services may need to differentiate between local and global names or - to determine that names in different namespaces identify the same + The traditional unicast DNS namespace contains, for the most part, + globally unique names. Multicast DNS provides every link with its + own separate link-local namespace, where names are unique only within + the context of that link. Clients discovering services may need to + differentiate between local and global names, and may need to + determine when names in different namespaces identify the same service. - Multiple devices in different subnets may share the same label - (perhaps due to vendor defaults) or have similarly appearing labels. + Devices on different links may have the same mDNS name (perhaps due + to vendor defaults), because link-local mDNS names are only + guaranteed to be unique on a per-link basis. Also, even devices that + are on the same link may have similar-looking names, such as one + device with the name "Bill" and another device using the similar- + looking name "Bi11" (using the digit "1" in place of the letter "l"). This may lead to a local label disambiguation problem between presented results. SSD should support rich internationalized labels within Service Instance Names, as DNS-SD/mDNS does today. SSD must not negatively impact the global DNS namespace or infrastructure. The problem of publishing local services in the global DNS namespace may be generally viewed as exporting local resource records and their associated labels into some DNS zone. The issues related to defining labels that are interoperable between local and global namespaces are - discussed in [I-D.sullivan-dnssd-mdns-dns-interop]. + discussed in a separate document + [I-D.sullivan-dnssd-mdns-dns-interop]. 6. Security Considerations Insofar as SSD may automatically gather DNS-SD resource records and - publish them over a wide area, the security issues are likely to be - the union of those discussed in [mDNS] and [DNS-SD]. The following + publish them over a wide area, the security issues are likely to + include the union of those discussed in the Multicast DNS [mDNS] and + DNS-Based Service Discovery [DNS-SD] specifications. The following sections highlight potential threats that are posed by deploying DNS- SD over multiple links or by automating DNS-SD administration. 6.1. 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 server. In a multi-link scenario, the owner of the - advertised service may not have a clear indication of the scope of - its advertisement. + In some scenarios, 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) discovering and then potentially attempting - to connect to the advertised service. It also discloses information - (about the host and service) to a larger set of potential attackers. + For example, since mDNS is currently restricted to a single link, the + scope of the advertisement is limited, by design, to the shared link + between client and server. If the advertisement propagates to a + larger set of links than expected, this may result in unauthorized + clients (from the perspective of the owner) discovering and then + potentially attempting to connect to the advertised service. It also + discloses information (about the host and service) to a larger set of + potential attackers. Note that discovery of a service does not necessarily imply that the service is reachable or can be connected to. Specific access control mechanisms are out of scope of this document. If the scope of the discovery is not properly setup or constrained, then information leaks will happen outside the appropriate network. 6.2. Multiple Namespaces There is a possibility of conflicts between the local and global DNS namespaces. Without adequate feedback, a discovering client may not know if the advertised service is the correct one, therefore enabling potential attacks. 6.3. Authorization - DNSSEC can assert the validity but not the veracity of records in a + DNSSEC can assert the validity but not the accuracy 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. + 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 + An impostor may register on the local link and appear as a legitimate service. Such "rogue" services may then be automatically registered in unicast DNS-SD. 6.4. Authentication Up to now, the "plug-and-play" nature of mDNS devices has relied only on physical connectivity. If a device is visible via mDNS then it is assumed to be trusted. This is not likely to be the case in foreign networks. If there is a risk that clients may be fooled by the deployment of rogue services, then application layer authentication should be considered as part of any security solution. Authentication of any particular service is outside the scope of this document. -6.5. Privacy Considerations +6.5. Access Control - 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 ("opt-in") of their users. - However, it should be possible to configure one or more "safe" zones - in which mobile devices may automatically register their services. + Access Control refers to the ability to restrict which users are able + to use a particular service that might be advertised via DNS-SD. In + this case, "use" of a service is different from the ability to + "discover" or "reach" a service. + + While access control to an advertised service is outside the scope of + DNS-SD, we note that access control today often is provided by + existing site infrastructure (e.g. router access control lists, + firewalls) and/or by service-specific mechanisms (e.g. user + authentication to the service). For example, many networked printers + already support access controls via a user-id and password. At least + one widely deployed DNS-SD + mDNS implementation supports such access + controls for printers. So the reliance on existing service-specific + security mechanisms (i.e. outside the scope of DNS-SD) does not + create new security considerations. + +6.6. Privacy Considerations + + Mobile devices such as smart phones or laptops 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 ("opt-in") of their + users. However, it should be possible to configure one or more + "safe" zones in which mobile devices may automatically register their + services. 7. IANA Considerations This document currently makes no request of IANA. Note to RFC Editor: this section may be removed upon publication as an RFC. 8. Acknowledgments We gratefully acknowledge contributions and review comments made by RJ Atkinson, Tim Chown, Guangqing Deng, Ralph Droms, Educause, David - Farmer, Matthew Gast, Thomas Narten, David Thaler, and Peter Van Der - Stok. + Farmer, Matthew Gast, Thomas Narten, Doug Otis, David Thaler, and + Peter Van Der Stok. 9. References 9.1. Normative References - [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate - Requirement Levels", BCP 14, RFC 2119, March 1997. + [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. + [RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless + Address Autoconfiguration", RFC 4862, September 2007. + [RFC4903] Thaler, D., "Multi-Link Subnet Issues", RFC 4903, June 2007. [RFC4944] Montenegro, G., Kushalnagar, N., Hui, J., and D. Culler, "Transmission of IPv6 Packets over IEEE 802.15.4 Networks", RFC 4944, September 2007. [RFC6550] Winter, T., Thubert, P., Brandt, A., Hui, J., Kelsey, R., Levis, P., Pister, K., Struik, R., Vasseur, JP., and R. Alexander, "RPL: IPv6 Routing Protocol for Low-Power and Lossy Networks", RFC 6550, March 2012. + [RFC7346] Droms, R., "IPv6 Multicast Address Scopes", RFC 7346, + August 2014. + [mDNS] Cheshire, S. and M. Krochmal, "Multicast DNS", RFC 6762, February 2013. [DNS-SD] Cheshire, S. and M. Krochmal, "DNS-Based Service Discovery", RFC 6763, February 2013. 9.2. Informative References - [I-D.ietf-6man-multicast-scopes] - Droms, R., "IPv6 Multicast Address Scopes", draft-ietf- - 6man-multicast-scopes-07 (work in progress), June 2014. - [I-D.ietf-homenet-arch] Chown, T., Arkko, J., Brandt, A., Troan, O., and J. Weil, "IPv6 Home Networking Architecture Principles", draft- - ietf-homenet-arch-16 (work in progress), June 2014. + ietf-homenet-arch-17 (work in progress), July 2014. [I-D.sullivan-dnssd-mdns-dns-interop] Sullivan, A., "Requirements for Labels to Interoperate Between mDNS and DNS", draft-sullivan-dnssd-mdns-dns- interop-00 (work in progress), January 2014. [EP] "Educause Petition", https://www.change.org/petitions/ from-educause-higher-ed-wireless-networking-admin-group, July 2012. @@ -501,43 +537,47 @@ metropolitan area networks - Specific requirements - Part 11: Wireless LAN Medium Access Control (MAC) and Physical Layer (PHY) Specifications", IEEE Std 802.11-2012, 2012, . [static] "Manually Adding DNS-SD Service Discovery Records to an Existing Name Server", July 2013, . + [ZC] Cheshire, S. and D. Steinberg, "Zero Configuration + Networking: The Definitive Guide", O'Reilly Media, Inc. , + ISBN 0-596-10100-7, December 2005. + Authors' Addresses - Kerry Lynn (editor) + Kerry Lynn Consultant Phone: +1 978 460 4253 Email: kerlyn@ieee.org + Stuart Cheshire Apple, Inc. 1 Infinite Loop Cupertino , California 95014 USA Phone: +1 408 974 3207 Email: cheshire@apple.com - Marc Blanchet Viagenie 246 Aberdeen Quebec , Quebec G1R 2E1 Canada Email: Marc.Blanchet@viagenie.ca - URI: http://www.viagenie.ca + URI: http://viagenie.ca Daniel Migault Orange 38-40 rue du General Leclerc Issy-les-Moulineaux 92130 France Phone: +33 1 45 29 60 52 Email: mglt.biz@gmail.com