--- 1/draft-ietf-dnssd-requirements-02.txt 2014-07-04 11:14:41.836415412 -0700 +++ 2/draft-ietf-dnssd-requirements-03.txt 2014-07-04 11:14:41.860415993 -0700 @@ -1,23 +1,23 @@ DNS-SD/mDNS Extensions K. Lynn, Ed. Internet-Draft Consultant Intended status: Informational S. Cheshire -Expires: December 12, 2014 Apple, Inc. +Expires: January 5, 2015 Apple, Inc. M. Blanchet Viagenie D. Migault Orange - June 10, 2014 + July 4, 2014 Requirements for Scalable DNS-SD/mDNS Extensions - draft-ietf-dnssd-requirements-02 + draft-ietf-dnssd-requirements-03 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 December 12, 2014. + This Internet-Draft will expire on January 5, 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 @@ -50,25 +50,25 @@ 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 . . . . . . . . . . . . . . . . . . . . . . . . 2 2. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 3 3. Basic Use Cases . . . . . . . . . . . . . . . . . . . . . . . 5 4. Requirements . . . . . . . . . . . . . . . . . . . . . . . . 6 - 5. Namespace Considerations . . . . . . . . . . . . . . . . . . 7 + 5. Namespace Considerations . . . . . . . . . . . . . . . . . . 8 6. Security Considerations . . . . . . . . . . . . . . . . . . . 8 - 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 - 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 9 - 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 9 + 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 + 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 10 + 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 10 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 11 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 @@ -226,21 +226,21 @@ 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. - (B) Classic home networks, consisting of: + (B) Classic home or 'hotspot' networks, consisting of: * Single exit router: the network may have multiple 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. * Single administrative domain: all nodes under the same admin entity. (However, this does not necessarily imply a network @@ -252,82 +252,114 @@ 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 - security devices are configured. + 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: Multi-link subnets with prefixes defined by one or more border routers. May comprise any part of networks C, D, or E. 4. Requirements Any successful SSD solution(s) will have to strike the proper balance between competing goals such as scalability, deployability, and usability. With that in mind, none of the requirements listed below should be considered in isolation. REQ1: For use cases A, B, and C, there should be a Zero - Configuration mode of operation. This implies that devices - should be able to automatically determine a default Scope of - Discovery in which to advertise and discover services. + Configuration mode of operation. This implies that servers + and clients should be able to automatically determine a + default Scope of Discovery in which to advertise and discover + 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: For use cases C, D, and E, there should be an incremental way + 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. + + REQ4: For use cases C, D, and E, there should be an incremental way to deploy the solution. - REQ4: SSD should integrate or at least should not break any current - link scope DNS-SD/mDNS protocols and deployments. SSD must - not adversely affect any other protocol. + REQ5: SSD should integrate with current link scope DNS-SD/mDNS + protocols and deployments. - REQ5: SSD must be capable of spanning multiple links (hops) and - network technologies. + REQ6: SSD must not adversely affect or break any other current + protocols or deployments. - REQ6: SSD must be scalable to thousands of nodes with minimal + 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. + + REQ9: SSD should operate efficiently in all networks, with + particular consideration for potentially lossy or multicast- + challenged wireless networks. + + 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. - REQ7: SSD should enable a way to provide a consistent user + REQ12: SSD should enable a way to provide a consistent user experience whether local or global services are being discovered. - REQ8: 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 reflect reality. + That is, new information should be available in a timely + fashion and stale information should not persist. + + 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 service. + Multiple devices in different subnets may share the same label + (perhaps due to vendor defaults) or have similarly appearing labels. + 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]. @@ -342,23 +374,27 @@ 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. 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. + 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. @@ -436,26 +472,26 @@ [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-06 (work in progress), June 2014. + 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-14 (work in progress), June 2014. + ietf-homenet-arch-16 (work in progress), June 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.