idnits 2.17.1 draft-ietf-dnssd-requirements-05.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (March 4, 2015) is 3340 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- No issues found here. Summary: 0 errors (**), 0 flaws (~~), 1 warning (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 DNS-SD/mDNS Extensions K. Lynn 3 Internet-Draft Verizon 4 Intended status: Informational S. Cheshire 5 Expires: September 5, 2015 Apple, Inc. 6 M. Blanchet 7 Viagenie 8 D. Migault 9 Ericsson 10 March 4, 2015 12 Requirements for Scalable DNS-SD/mDNS Extensions 13 draft-ietf-dnssd-requirements-05 15 Abstract 17 DNS-SD over mDNS is widely used today for discovery and resolution of 18 services and names on a local link, but there are use cases to extend 19 DNS-SD/mDNS to enable service discovery beyond the local link. This 20 document provides a problem statement and a list of requirements. 22 Status of This Memo 24 This Internet-Draft is submitted in full conformance with the 25 provisions of BCP 78 and BCP 79. 27 Internet-Drafts are working documents of the Internet Engineering 28 Task Force (IETF). Note that other groups may also distribute 29 working documents as Internet-Drafts. The list of current Internet- 30 Drafts is at http://datatracker.ietf.org/drafts/current/. 32 Internet-Drafts are draft documents valid for a maximum of six months 33 and may be updated, replaced, or obsoleted by other documents at any 34 time. It is inappropriate to use Internet-Drafts as reference 35 material or to cite them other than as "work in progress." 37 This Internet-Draft will expire on September 5, 2015. 39 Copyright Notice 41 Copyright (c) 2015 IETF Trust and the persons identified as the 42 document authors. All rights reserved. 44 This document is subject to BCP 78 and the IETF Trust's Legal 45 Provisions Relating to IETF Documents 46 (http://trustee.ietf.org/license-info) in effect on the date of 47 publication of this document. Please review these documents 48 carefully, as they describe your rights and restrictions with respect 49 to this document. Code Components extracted from this document must 50 include Simplified BSD License text as described in Section 4.e of 51 the Trust Legal Provisions and are provided without warranty as 52 described in the Simplified BSD License. 54 Table of Contents 56 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 57 2. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 3 58 3. Basic Use Cases . . . . . . . . . . . . . . . . . . . . . . . 5 59 4. Requirements . . . . . . . . . . . . . . . . . . . . . . . . 7 60 5. Namespace Considerations . . . . . . . . . . . . . . . . . . 8 61 6. Security Considerations . . . . . . . . . . . . . . . . . . . 9 62 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 63 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 11 64 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 11 65 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 13 67 1. Introduction 69 DNS-Based Service Discovery [DNS-SD] in combination with its 70 companion technology Multicast DNS [mDNS] is widely used today for 71 discovery and resolution of services and names on a local link. 72 However, as users move to multi-link home or campus networks they 73 find that mDNS (by design) does not work across routers. DNS-SD can 74 also be used in conjunction with conventional unicast DNS to enable 75 wide-area service discovery, but this capability is not yet widely 76 deployed. This disconnect between customer needs and current 77 practice has led to calls for improvement, such as the Educause 78 petition [EP]. 80 In response to this and similar evidence of market demand, several 81 products now enable service discovery beyond the local link using 82 different ad hoc techniques. As yet, no consensus has emerged 83 regarding which approach represents the best long-term direction for 84 DNS-based service discovery protocol development. 86 Multicast DNS in its present form is also not optimized for network 87 technologies where multicast transmissions are relatively expensive. 88 Wireless networks such as Wi-Fi [IEEE.802.11] may be adversely 89 affected by excessive mDNS traffic due to the higher network overhead 90 of multicast transmissions. Wireless mesh networks such as 6LoWPAN 91 [RFC4944] are effectively multi-link subnets [RFC4903] where 92 multicasts must be forwarded by intermediate nodes. 94 It is in the best interests of end users, network administrators, and 95 vendors for all interested parties to cooperate within the context of 96 the IETF to develop an efficient, scalable, and interoperable 97 standards-based solution. 99 This document defines the problem statement and gathers requirements 100 for Scalable DNS-SD/mDNS Extensions. 102 1.1. Terminology and Acronyms 104 Service: A listening endpoint (host and port) for a given application 105 protocol. Services are identified by Service Instance Names. 107 DNS-SD: DNS-Based Service Discovery [DNS-SD] is a conventional 108 application of DNS Resource Records and messages to facilitate the 109 naming, discovery, and location of services. When used alone, it 110 generally refers to the wide-area unicast protocol. 112 mDNS: Multicast DNS [mDNS] is a mechanism that facilitates 113 distributed DNS-like capabilities (including DNS-SD) on a local link 114 without need of traditional DNS infrastructure. 116 SSD: Scalable Service Discovery (or Scalable DNS-SD) is a future 117 extension of DNS-SD (and perhaps mDNS) that meets the requirements 118 set forth in this document. 120 Scope of Discovery: A subset of a local or global namespace, e.g., a 121 DNS subdomain, that is the target of a given SSD query. 123 Zero Configuration: A deployment of SSD that requires no 124 administration (although some administration may be optional). 126 Incremental Deployment: An orderly transition, as a network 127 installation evolves, from DNS-SD/mDNS to SSD. 129 2. Problem Statement 131 Service discovery beyond the local link is perhaps the most important 132 feature currently missing from the DNS-SD-over-mDNS framework (also 133 written as "DNS-SD over mDNS" or "DNS-SD/mDNS"). Other issues and 134 requirements are summarized below. 136 2.1. Multi-link Naming and Discovery 138 A list of desired DNS-SD/mDNS improvements from network 139 administrators in the research and education community was issued in 140 the form of the Educause petition [EP]. The following is a summary 141 of their technical issues: 143 o Products that advertise services such as printing and multimedia 144 streaming via DNS-SD over mDNS are not currently discoverable by 145 devices on other links. It is common practice for enterprises and 146 institutions to use wireless links for client access and wired 147 networks for server infrastructure, typically on different 148 subnets. DNS-SD used with conventional unicast DNS does work when 149 devices are on different links, but the resource records that 150 describe the service must somehow be entered into the unicast DNS 151 namespace. 153 o DNS-SD resource records may be entered manually into a unicast DNS 154 zone file [STATIC], but this task must be performed by a DNS 155 administrator. It is labor-intensive and brittle when IP 156 addresses of devices change dynamically, as is common when DHCP is 157 used. 159 o Automatically adding DNS-SD records using DNS Update works, but 160 requires that the DNS server be configured to allow DNS Updates, 161 and requires that devices be configured with the DNS Update 162 credentials to permit such updates, which has proven to be 163 onerous. 165 Therefore, a mechanism is desired that populates the DNS namespace 166 with the appropriate DNS-SD records with less manual administration 167 than typically needed for a unicast DNS server. 169 The following is a summary of their technical requirements: 171 o It must scale to a range of hundreds to thousands of DNS-SD/mDNS- 172 enabled devices in a given environment. 174 o It must simultaneously operate over a variety of network link 175 technologies, such as wired and wireless networks. 177 o It must not significantly increase network traffic (wired or 178 wireless). 180 o It must be cost-effective to manage at up to enterprise scale. 182 2.2. IEEE 802.11 Wireless LANs 184 Multicast DNS was originally designed to run on Ethernet - the 185 dominant link-layer at the time. In shared Ethernet networks, 186 multicast frames place little additional demand on the shared network 187 medium compared to unicast frames. In IEEE 802.11 networks however, 188 multicast frames are transmitted at a low data rate supported by all 189 receivers. In practice, this data rate leads to a larger fraction of 190 airtime being devoted to multicast transmission. Some network 191 administrators block multicast traffic, or use access points that 192 transmit multicast frames using a series of link-layer unicast 193 frames. 195 Wireless links may be orders of magnitude less reliable than their 196 wired counterparts. To improve transmission reliability, the IEEE 197 802.11 MAC requires positive acknowledgement of unicast frames. It 198 does not, however, support positive acknowledgement of multicast 199 frames. As a result, it is common to observe much higher loss of 200 multicast frames on wireless as compared to wired network 201 technologies. 203 Enabling service discovery on IEEE 802.11 networks requires that the 204 number of multicast frames be restricted to a suitably low value, or 205 replaced with unicast frames to use the MAC's reliability features. 207 2.3. Low Power and Lossy Networks (LLNs) 209 Emerging wireless mesh networking technologies such as RPL [RFC6550] 210 and 6LoWPAN present several challenges for the current DNS-SD/mDNS 211 design. First, Link-Local multicast scope [RFC4291] is defined as a 212 single-hop neighborhood. A wireless mesh network representing a 213 single logical subnet may often extend to multiple hops [RFC4903], 214 therefore a larger multicast scope is required to span it [RFC7346]. 215 Multicast DNS was intentionally not specified for greater than Link- 216 Local scope, because of the additional off-link multicast traffic 217 that would generate. 219 Additionally, low-power nodes may be offline for significant periods 220 either because they are "sleeping" or due to connectivity problems. 221 In such cases LLN nodes might fail to respond to queries or defend 222 their names using the current design. 224 3. Basic Use Cases 226 The following use cases are defined with different characteristics to 227 help motivate, distinguish, and classify the target requirements. 228 They cover a spectrum of increasing deployment and administrative 229 complexity. 231 (A) Personal Area networks (PANs): the simplest example of a 232 network may consist of a single client and server, e.g., one 233 laptop and one printer, on a common link. PANs that do not 234 contain a router may use Zero Configuration Networking [ZC] to 235 self-assign link-local addresses [RFC3927] [RFC4862], and 236 Multicast DNS [mDNS] to provide naming and service discovery, as 237 currently implemented and deployed in Mac OS X, iOS, Windows [B4W] 238 and Android [NSD]. 240 (B) Classic home or 'hotspot' networks, with the following 241 properties: 243 * Single exit router: the network may have one or more upstream 244 providers or networks, but all outgoing and incoming traffic 245 goes through a single router. 247 * One-level depth: a single physical link, or multiple physical 248 links bridged to form a single logical link, that is connected 249 to the default router. The single logical link provides a 250 single broadcast domain, facilitating use of link-local 251 Multicast DNS, and also ARP, which enables the home or 252 'hotspot' network to consist of just a single IPv4 subnet. 254 * Single administrative domain: all nodes under the same 255 administrative authority. (However, this does not necessarily 256 imply a network administrator.) 258 (C) Advanced home and small business networks [RFC7368]: 260 Like B, but consist of multiple wired and/or wireless links, 261 connected by routers, generally behind a single exit router. 262 However, the forwarding nodes are largely self-configuring and do 263 not require routing protocol administration. Such networks should 264 also not require DNS administration. 266 (D) Enterprise networks: 268 Consist of arbitrary network diameter under a single 269 administrative authority. A large majority of the forwarding and 270 security devices are configured and multiple exit routers are more 271 common. Large-scale conference-style networks, which are 272 predominantly wireless access, e.g., as available at IETF 273 meetings, also fall within this category. 275 (E) Higher Education networks: 277 Like D but the core network may be under a central administrative 278 domain while leaf networks are under local administrative domains. 280 (F) Mesh networks such as RPL/6LoWPAN: 282 Multi-link subnets with prefixes defined by one or more border 283 routers. May comprise any part of networks C, D, or E. 285 4. Requirements 287 Any successful SSD solution(s) will have to strike the proper balance 288 between competing goals such as scalability, deployability, and 289 usability. With that in mind, none of the requirements listed below 290 should be considered in isolation. 292 REQ1: For use cases A, B, and C, there should be a Zero 293 Configuration mode of operation. This implies that servers 294 and clients should be able to automatically determine a 295 default Scope of Discovery in which to advertise and discover 296 services, respectively. 298 REQ2: For use cases C, D, and E, there should be a way to configure 299 Scopes of Discovery that support a range of topologically- 300 independent zones (e.g., from department to campus-wide). 301 This capability must exist in the protocol; individual 302 operators are not required to use this capability in all 303 cases -- in particular, use case C should support Zero 304 Configuration operation where that is desired. If multiple 305 scopes are available, there must be a way to enumerate the 306 choices from which a selection can be made. In use case C, 307 either Zero Configuration (one flat list of resources) or 308 configured (e.g., resources sorted by room) modes of 309 operation should be available. 311 REQ3: As stated in REQ2 above, the discovery scope need not be 312 aligned to network topology. For example, it may instead be 313 aligned to physical proximity (e.g., building) or 314 organizational structure, (e.g., "Sales" vs. "Engineering"). 316 REQ4: For use cases C, D, and E, there should be an incremental way 317 to deploy the solution. 319 REQ5: SSD should leverage and build upon current link scope DNS-SD/ 320 mDNS protocols and deployments. 322 REQ6: SSD must not adversely affect or break any other current 323 protocols or deployments. 325 REQ7: SSD must be capable of operating across networks that are not 326 limited to a single link or network technology, including 327 clients and services on non-adjacent links. 329 REQ8: It is desirable that a user or device be able to discover 330 services within the sites or networks to which the user or 331 device is connected. 333 REQ9: SSD should operate efficiently on common link layers and link 334 types. 336 REQ10: SSD should be considerate of networks where power consumption 337 is a critical factor and, for example, nodes may be in a low 338 power or sleeping state. 340 REQ11: SSD must be scalable to thousands of nodes with minimal 341 configuration and without degrading network performance. A 342 possible figure of merit is that, as the number of services 343 increases, the amount of traffic due to SSD on a given link 344 remains relatively constant. 346 REQ12: SSD should enable a way to provide a consistent user 347 experience whether local or remote services are being 348 discovered. 350 REQ13: The information presented by SSD should closely reflect the 351 current state of discoverable services on the network. That 352 is, new information should be available within a few seconds 353 and stale information should not persist indefinitely. In 354 networking all information is necessarily somewhat out-of- 355 date by the time it reaches the receiver, even if only by a 356 few microseconds, or less. Thus timeliness is always an 357 engineering trade-off against efficiency. The engineering 358 decisions for SSD should appropriately balance timeliness 359 against network efficiency. 361 REQ14: SSD should operate over existing networks (as described by 362 use cases A-F above) without requiring changes to the network 363 at the physical, link, or internetworking layers. 365 5. Namespace Considerations 367 The traditional unicast DNS namespace contains, for the most part, 368 globally unique names. Multicast DNS provides every link with its 369 own separate link-local namespace, where names are unique only within 370 the context of that link. Clients discovering services may need to 371 differentiate between local and global names, and may need to 372 determine when names in different namespaces identify the same 373 service. 375 Devices on different links may have the same mDNS name (perhaps due 376 to vendor defaults), because link-local mDNS names are only 377 guaranteed to be unique on a per-link basis. Also, even devices that 378 are on the same link may have similar-looking names, such as one 379 device with the name "Bill" and another device using the similar- 380 looking name "Bi11" (using the digit "1" in place of the letter "l"). 382 This may lead to a local label disambiguation problem between 383 presented results. 385 SSD should support rich internationalized labels within Service 386 Instance Names, as DNS-SD/mDNS does today. SSD must not negatively 387 impact the global DNS namespace or infrastructure. 389 The problem of publishing local services in the global DNS namespace 390 may be generally viewed as exporting local resource records and their 391 associated labels into some DNS zone. The issues related to defining 392 labels that are interoperable between local and global namespaces are 393 discussed in a separate document 394 [I-D.sullivan-dnssd-mdns-dns-interop]. 396 6. Security Considerations 398 Insofar as SSD may automatically gather DNS-SD resource records and 399 publish them over a wide area, the security issues are likely to 400 include the union of those discussed in the Multicast DNS [mDNS] and 401 DNS-Based Service Discovery [DNS-SD] specifications. The following 402 sections highlight potential threats that are posed by deploying DNS- 403 SD over multiple links or by automating DNS-SD administration. 405 6.1. Scope of Discovery 407 In some scenarios, the owner of the advertised service may not have a 408 clear indication of the scope of its advertisement. 410 For example, since mDNS is currently restricted to a single link, the 411 scope of the advertisement is limited, by design, to the shared link 412 between client and server. If the advertisement propagates to a 413 larger set of links than expected, this may result in unauthorized 414 clients (from the perspective of the owner) discovering and then 415 potentially attempting to connect to the advertised service. It also 416 discloses information (about the host and service) to a larger set of 417 potential attackers. 419 Note that discovery of a service does not necessarily imply that the 420 service is reachable by, or can be connected to, or can be used by, a 421 given client. Specific access control mechanisms are out of scope of 422 this document. 424 If the scope of the discovery is not properly set up or constrained, 425 then information leaks will happen outside the appropriate network. 427 6.2. Multiple Namespaces 429 There is a possibility of conflicts between the local and global DNS 430 namespaces. Without adequate feedback, a discovering client may not 431 know if the advertised service is the correct one, therefore enabling 432 potential attacks. 434 6.3. Authorization 436 DNSSEC can assert the validity but not the accuracy of records in a 437 zone file. The trust model of the global DNS relies on the fact that 438 human administrators either (a) manually enter resource records into 439 a zone file, or (b) configure the DNS server to authenticate a 440 trusted device (e.g., a DHCP server) that can automatically maintain 441 such records. 443 An impostor may register on the local link and appear as a legitimate 444 service. Such "rogue" services may then be automatically registered 445 in unicast DNS-SD. 447 6.4. Authentication 449 Up to now, the "plug-and-play" nature of mDNS devices has relied only 450 on physical connectivity. If a device is visible via mDNS then it is 451 assumed to be trusted. This is not likely to be the case in foreign 452 networks. 454 If there is a risk that clients may be fooled by the deployment of 455 rogue services, then application layer authentication should be 456 considered as part of any security solution. Authentication of any 457 particular service is outside the scope of this document. 459 6.5. Access Control 461 Access Control refers to the ability to restrict which users are able 462 to use a particular service that might be advertised via DNS-SD. In 463 this case, "use" of a service is different from the ability to 464 "discover" or "reach" a service. 466 While controlling access to an advertised service is outside the 467 scope of DNS-SD, we note that access control today often is provided 468 by existing site infrastructure (e.g., router access control lists, 469 firewalls) and/or by service-specific mechanisms (e.g., user 470 authentication to the service). For example, networked printers can 471 control access via a user-id and password. Apple's software supports 472 such access control for USB printers shared via Mac OS X Printer 473 Sharing, as do many networked printers themselves. So the reliance 474 on existing service-specific security mechanisms (i.e. outside the 475 scope of DNS-SD) does not create new security considerations. 477 6.6. Privacy Considerations 479 Mobile devices such as smart phones or laptops that can expose the 480 location of their owners by registering services in arbitrary zones 481 pose a risk to privacy. Such devices must not register their 482 services in arbitrary zones without the approval ("opt-in") of their 483 users. However, it should be possible to configure one or more 484 "safe" zones in which mobile devices may automatically register their 485 services. 487 7. IANA Considerations 489 This document makes no request of IANA. 491 8. Acknowledgments 493 We gratefully acknowledge contributions and review comments made by 494 RJ Atkinson, Tim Chown, Guangqing Deng, Ralph Droms, Educause, David 495 Farmer, Matthew Gast, Thomas Narten, Doug Otis, David Thaler, and 496 Peter Van Der Stok. 498 9. References 500 9.1. Normative References 502 [RFC3927] Cheshire, S., Aboba, B., and E. Guttman, "Dynamic 503 Configuration of IPv4 Link-Local Addresses", RFC 3927, May 504 2005. 506 [RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing 507 Architecture", RFC 4291, February 2006. 509 [RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless 510 Address Autoconfiguration", RFC 4862, September 2007. 512 [RFC4903] Thaler, D., "Multi-Link Subnet Issues", RFC 4903, June 513 2007. 515 [RFC4944] Montenegro, G., Kushalnagar, N., Hui, J., and D. Culler, 516 "Transmission of IPv6 Packets over IEEE 802.15.4 517 Networks", RFC 4944, September 2007. 519 [RFC6550] Winter, T., Thubert, P., Brandt, A., Hui, J., Kelsey, R., 520 Levis, P., Pister, K., Struik, R., Vasseur, JP., and R. 521 Alexander, "RPL: IPv6 Routing Protocol for Low-Power and 522 Lossy Networks", RFC 6550, March 2012. 524 [RFC7346] Droms, R., "IPv6 Multicast Address Scopes", RFC 7346, 525 August 2014. 527 [RFC7368] Chown, T., Arkko, J., Brandt, A., Troan, O., and J. Weil, 528 "IPv6 Home Networking Architecture Principles", RFC 7368, 529 October 2014. 531 [mDNS] Cheshire, S. and M. Krochmal, "Multicast DNS", RFC 6762, 532 February 2013. 534 [DNS-SD] Cheshire, S. and M. Krochmal, "DNS-Based Service 535 Discovery", RFC 6763, February 2013. 537 9.2. Informative References 539 [B4W] "Bonjour for Windows", 540 . 542 [I-D.sullivan-dnssd-mdns-dns-interop] 543 Sullivan, A., "On Interoperation of Labels Between mDNS 544 and DNS", draft-sullivan-dnssd-mdns-dns-interop-01 (work 545 in progress), October 2014. 547 [EP] "Educause Petition", https://www.change.org/petitions/ 548 from-educause-higher-ed-wireless-networking-admin-group, 549 July 2012. 551 [IEEE.802.11] 552 "Information technology - Telecommunications and 553 information exchange between systems - Local and 554 metropolitan area networks - Specific requirements - Part 555 11: Wireless LAN Medium Access Control (MAC) and Physical 556 Layer (PHY) Specifications", IEEE Std 802.11-2012, 2012, 557 . 560 [NSD] "NsdManager | Android Developer", June 2012, 561 . 564 [STATIC] "Manually Adding DNS-SD Service Discovery Records to an 565 Existing Name Server", July 2013, 566 . 568 [ZC] Cheshire, S. and D. Steinberg, "Zero Configuration 569 Networking: The Definitive Guide", O'Reilly Media, Inc. , 570 ISBN 0-596-10100-7, December 2005. 572 Authors' Addresses 574 Kerry Lynn 575 Verizon 576 50 Sylvan Road 577 Waltham , MA 95014 578 USA 580 Phone: +1 781 296 9722 581 Email: kerry.lynn@verizon.com 583 Stuart Cheshire 584 Apple, Inc. 585 1 Infinite Loop 586 Cupertino , CA 95014 587 USA 589 Phone: +1 408 974 3207 590 Email: cheshire@apple.com 592 Marc Blanchet 593 Viagenie 594 246 Aberdeen 595 Quebec , QC G1R 2E1 596 Canada 598 Email: Marc.Blanchet@viagenie.ca 599 URI: http://viagenie.ca 601 Daniel Migault 602 Ericsson 603 8400 boulevard Decarie 604 Montreal , QC H4P 2N2 605 Canada 607 Phone: +1 514 452 2160 608 Email: daniel.migault@ericsson.com