idnits 2.17.1 draft-ietf-dnssd-requirements-04.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 (October 8, 2014) is 3481 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Outdated reference: A later version (-01) exists of draft-sullivan-dnssd-mdns-dns-interop-00 Summary: 0 errors (**), 0 flaws (~~), 2 warnings (==), 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 Consultant 4 Intended status: Informational S. Cheshire 5 Expires: April 11, 2015 Apple, Inc. 6 M. Blanchet 7 Viagenie 8 D. Migault 9 Orange 10 October 8, 2014 12 Requirements for Scalable DNS-SD/mDNS Extensions 13 draft-ietf-dnssd-requirements-04 15 Abstract 17 DNS-SD/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 April 11, 2015. 39 Copyright Notice 41 Copyright (c) 2014 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 . . . . . . . . . . . . . . . . . . . . . . . . 6 60 5. Namespace Considerations . . . . . . . . . . . . . . . . . . 8 61 6. Security Considerations . . . . . . . . . . . . . . . . . . . 8 62 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 63 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 11 64 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 11 65 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 12 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 does not work across routers. DNS-SD can also be used 74 in conjunction with conventional unicast DNS to enable wide-area 75 service discovery, but this capability is not yet widely deployed. 76 This disconnect between customer needs and current practice has led 77 to calls for improvement, such as the Educause petition [EP]. 79 In response to this and similar evidence of market demand, several 80 products now enable service discovery beyond the local link using 81 different ad-hoc techniques. As yet, no consensus has emerged 82 regarding which approach represents the best long-term direction for 83 DNS-based service discovery protocol development. 85 Multicast DNS in its present form is also not optimized for network 86 technologies where multicast transmissions are relatively expensive. 87 Wireless networks such as Wi-Fi [IEEE.802.11] may be adversely 88 affected by excessive mDNS traffic due to the higher network overhead 89 of multicast transmissions. Wireless mesh networks such as 6LoWPAN 90 [RFC4944] are effectively multi-link subnets [RFC4903] where 91 multicasts must be forwarded by intermediate nodes. 93 It is in the best interests of end users, network administrators, and 94 vendors for all interested parties to cooperate within the context of 95 the IETF to develop an efficient, scalable, and interoperable 96 standards-based solution. 98 This document defines the problem statement and gathers requirements 99 for Scalable DNS-SD/mDNS Extensions. 101 1.1. Terminology and Acronyms 103 Service: A listening endpoint (host and port) for a given application 104 protocol. Services are identified by Service Instance Names. 106 DNS-SD: DNS-Based Service Discovery [DNS-SD] is a conventional 107 application of DNS Resource Records and messages to facilitate the 108 discovery and location of services. 110 mDNS: Multicast DNS [mDNS] is a mechanism that facilitates DNS-SD on 111 a local link in the absence of traditional DNS infrastructure. 113 SSD: Scalable DNS-SD is a future extension of DNS-SD (and perhaps 114 mDNS) that meets the requirements set forth in this document. 116 Scope of Discovery: A subset of a local or global namespace, e.g., a 117 DNS subdomain, that is the target of a given SSD query. 119 Zero Configuration: A deployment of SSD that requires no 120 administration (although some administration may be optional). 122 Incremental Deployment: An orderly transition, as a network 123 installation evolves, from DNS-SD/mDNS to SSD. 125 2. Problem Statement 127 Service discovery beyond the local link is perhaps the most important 128 feature currently missing from the DNS-SD/mDNS framework. Other 129 issues and requirements are summarized below. 131 2.1. Multi-link Naming and Discovery 133 A list of desired DNS-SD/mDNS improvements from network 134 administrators in the research and education community was issued in 135 the form of the Educause petition [EP]. The following is a summary 136 of their technical issues: 138 o Products that advertise services such as printing and multimedia 139 streaming via DNS-SD/mDNS are not currently discoverable by 140 devices on other links. It is common practice for enterprises and 141 institutions to use wireless links for client access and wired 142 networks for server infrastructure, typically on different 143 subnets. DNS-SD used with conventional unicast DNS does work when 144 devices are on different links, but the resource records that 145 describe the service must somehow be entered into the unicast DNS 146 namespace. 148 o DNS-SD resource records may be entered manually into a unicast DNS 149 zone file [static], but this task must be performed by a DNS 150 administrator. It is labor-intensive and brittle when IP 151 addresses of devices change dynamically, as is common when DHCP is 152 used. 154 o Automatically adding DNS-SD records using DNS Update works, but 155 requires that the DNS server be configured to allow DNS Updates, 156 and requires that devices be configured with the DNS Update 157 credentials to permit such updates, which has proven to be 158 onerous. 160 o Therefore, a mechanism is desired that populates the DNS namespace 161 with the appropriate DNS-SD records with less manual 162 administration than typically needed for a unicast DNS server. 164 The following is a summary of their technical requirements: 166 o It must scale to a range of hundreds to thousands of DNS-SD/mDNS 167 enabled devices in a given environment. 169 o It must simultaneously operate over a variety of network link 170 technologies, such as wired and wireless networks. 172 o It must not significantly increase network traffic (wired or 173 wireless). 175 o It must be cost-effective to manage at up to enterprise scale. 177 2.2. IEEE 802.11 Wireless LANs 179 Multicast DNS was originally designed to run on Ethernet - the 180 dominant link-layer at the time. In shared Ethernet networks, 181 multicast frames place little additional demand on the shared network 182 medium compared to unicast frames. In IEEE 802.11 networks however, 183 multicast frames are transmitted at a low data rate supported by all 184 receivers. In practice, this data rate leads to a larger fraction of 185 airtime being devoted to multicast transmission. Some network 186 administrators block multicast traffic, or use access points that 187 transmit multicast frames using a series of link-layer unicast 188 frames. 190 Wireless links may be orders of magnitude less reliable than their 191 wired counterparts. To improve transmission reliability, the IEEE 192 802.11 MAC requires positive acknowledgement of unicast frames. It 193 does not, however, support positive acknowledgement of multicast 194 frames. As a result, it is common to observe much higher loss of 195 multicast frames on wireless as compared to wired network 196 technologies. 198 Enabling service discovery on IEEE 802.11 networks requires that the 199 number of multicast frames be restricted to a suitably low value, or 200 replaced with unicast frames to use the MAC's reliability features. 202 2.3. Low Power and Lossy Networks (LLNs) 204 Emerging wireless mesh networking technologies such as RPL [RFC6550] 205 and 6LoWPAN present several challenges for the current DNS-SD/mDNS 206 design. First, Link-Local multicast scope [RFC4291] is defined as a 207 single-hop neighborhood. A single subnet prefix in a wireless mesh 208 network may often span multiple links, therefore a larger multicast 209 scope is required to span it [RFC7346]. Multicast DNS is 210 intentionally not specified for greater than Link-Local scope, 211 because of the additional multicast traffic that would generate. 213 Additionally, low-power nodes may be offline for significant periods 214 either because they are "sleeping" or due to connectivity problems. 215 In such cases LLN nodes might fail to respond to queries or defend 216 their names using the current design. 218 3. Basic Use Cases 220 The following use cases are defined with different characteristics to 221 help motivate, distinguish, and classify the target requirements. 222 They cover a spectrum of increasing deployment and administrative 223 complexity. 225 (A) Personal Area networks (PANs): the simplest example of a 226 network may consist of a single client and server, e.g., one 227 laptop and one printer, on a common link. PANs that do not 228 contain a router may use Zero Configuration Networking [ZC] to 229 self-assign link-local addresses [RFC3927] [RFC4862], and 230 Multicast DNS [mDNS] to provide naming and service discovery. 232 (B) Classic home or 'hotspot' networks, with the following 233 properties: 235 * Single exit router: the network may have one or more upstream 236 providers or networks, but all outgoing and incoming traffic 237 goes through a single router. 239 * One-level depth: a single physical link, or multiple physical 240 links bridged to form a single logical link, that is connected 241 to the default router. The single logical link provides a 242 single broadcast domain, facilitating use of link-local 243 Multicast DNS, and also ARP, which enables the home or 244 'hotspot' network to consist of just a single IPv4 subnet. 246 * Single administrative domain: all nodes under the same 247 administrative authority. (However, this does not necessarily 248 imply a network administrator.) 250 (C) Advanced home and small business networks 251 [I-D.ietf-homenet-arch]: 253 Like B but consist of multiple wired and/or wireless links, 254 connected by routers, behind the single exit router. However, the 255 forwarding nodes are largely self-configuring and do not require 256 routing protocol administration. Such networks should also not 257 require DNS administration. 259 (D) Enterprise networks: 261 Like C but consist of arbitrary network diameter under a single 262 administrative authority. A large majority of the forwarding and 263 security devices are configured. Large-scale conference-style 264 networks, which are predominantly wireless access, e.g., as 265 available at IETF meetings, also fall within this category. 267 (E) Higher Education networks: 269 Like D but the core network may be under a central administrative 270 domain while leaf networks are under local administrative domains. 272 (F) Mesh networks such as RPL/6LoWPAN: 274 Multi-link subnets with prefixes defined by one or more border 275 routers. May comprise any part of networks C, D, or E. 277 4. Requirements 279 Any successful SSD solution(s) will have to strike the proper balance 280 between competing goals such as scalability, deployability, and 281 usability. With that in mind, none of the requirements listed below 282 should be considered in isolation. 284 REQ1: For use cases A, B, and C, there should be a Zero 285 Configuration mode of operation. This implies that servers 286 and clients should be able to automatically determine a 287 default Scope of Discovery in which to advertise and discover 288 services, respectively. 290 REQ2: For use cases C, D, and E, there should be a way to configure 291 Scopes of Discovery that support a range of topologically- 292 independent zones (e.g., from department to campus-wide). If 293 multiple scopes are available, there must be a way to 294 enumerate the choices from which a selection can be made. 296 REQ3: As stated in REQ2 above, the discovery scope need not be 297 aligned to network topology. For example, it may instead be 298 aligned to physical proximity (e.g. building) or 299 organizational structure. 301 REQ4: For use cases C, D, and E, there should be an incremental way 302 to deploy the solution. 304 REQ5: SSD should integrate with current link scope DNS-SD/mDNS 305 protocols and deployments. 307 REQ6: SSD must not adversely affect or break any other current 308 protocols or deployments. 310 REQ7: SSD must be capable of operating across networks that are not 311 limited to a single link or network technology, including 312 clients and services on non-adjacent links. 314 REQ8: It is desirable that a user or device be able to discover 315 services within the sites or networks to which the user or 316 device is connected. 318 REQ9: SSD should operate efficiently on common link layers and link 319 types. 321 REQ10: SSD should be considerate of networks where power consumption 322 is a critical factor and, for example, nodes may be in a low 323 power or sleeping state. 325 REQ11: SSD must be scalable to thousands of nodes with minimal 326 configuration and without degrading network performance. A 327 possible figure of merit is that, as the number of services 328 increases, the amount of traffic due to SSD on a given link 329 remains relatively constant. 331 REQ12: SSD should enable a way to provide a consistent user 332 experience whether local or remote services are being 333 discovered. 335 REQ13: The information presented by SSD should closely reflect 336 reality. That is, new information should be available within 337 a few seconds and stale information should not persist 338 indefinitely. In networking all information is necessarily 339 somewhat out-of-date by the time it reaches the receiver, 340 even if only by a few microseconds, or less. Thus timeliness 341 is always an engineering trade-off against efficiency. The 342 engineering decisions for SSD should appropriately balance 343 timeliness against network efficiency. 345 REQ14: SSD should operate over existing networks (as described by 346 use cases A-F above) without requiring changes to the network 347 technology or deployment. 349 5. Namespace Considerations 351 The traditional unicast DNS namespace contains, for the most part, 352 globally unique names. Multicast DNS provides every link with its 353 own separate link-local namespace, where names are unique only within 354 the context of that link. Clients discovering services may need to 355 differentiate between local and global names, and may need to 356 determine when names in different namespaces identify the same 357 service. 359 Devices on different links may have the same mDNS name (perhaps due 360 to vendor defaults), because link-local mDNS names are only 361 guaranteed to be unique on a per-link basis. Also, even devices that 362 are on the same link may have similar-looking names, such as one 363 device with the name "Bill" and another device using the similar- 364 looking name "Bi11" (using the digit "1" in place of the letter "l"). 365 This may lead to a local label disambiguation problem between 366 presented results. 368 SSD should support rich internationalized labels within Service 369 Instance Names, as DNS-SD/mDNS does today. SSD must not negatively 370 impact the global DNS namespace or infrastructure. 372 The problem of publishing local services in the global DNS namespace 373 may be generally viewed as exporting local resource records and their 374 associated labels into some DNS zone. The issues related to defining 375 labels that are interoperable between local and global namespaces are 376 discussed in a separate document 377 [I-D.sullivan-dnssd-mdns-dns-interop]. 379 6. Security Considerations 381 Insofar as SSD may automatically gather DNS-SD resource records and 382 publish them over a wide area, the security issues are likely to 383 include the union of those discussed in the Multicast DNS [mDNS] and 384 DNS-Based Service Discovery [DNS-SD] specifications. The following 385 sections highlight potential threats that are posed by deploying DNS- 386 SD over multiple links or by automating DNS-SD administration. 388 6.1. Scope of Discovery 390 In some scenarios, the owner of the advertised service may not have a 391 clear indication of the scope of its advertisement. 393 For example, since mDNS is currently restricted to a single link, the 394 scope of the advertisement is limited, by design, to the shared link 395 between client and server. If the advertisement propagates to a 396 larger set of links than expected, this may result in unauthorized 397 clients (from the perspective of the owner) discovering and then 398 potentially attempting to connect to the advertised service. It also 399 discloses information (about the host and service) to a larger set of 400 potential attackers. 402 Note that discovery of a service does not necessarily imply that the 403 service is reachable or can be connected to. Specific access control 404 mechanisms are out of scope of this document. 406 If the scope of the discovery is not properly set up or constrained, 407 then information leaks will happen outside the appropriate network. 409 6.2. Multiple Namespaces 411 There is a possibility of conflicts between the local and global DNS 412 namespaces. Without adequate feedback, a discovering client may not 413 know if the advertised service is the correct one, therefore enabling 414 potential attacks. 416 6.3. Authorization 418 DNSSEC can assert the validity but not the accuracy of records in a 419 zone file. The trust model of the global DNS relies on the fact that 420 human administrators either (a) manually enter resource records into 421 a zone file, or (b) configure the DNS server to authenticate a 422 trusted device (e.g., a DHCP server) that can automatically maintain 423 such records. 425 An impostor may register on the local link and appear as a legitimate 426 service. Such "rogue" services may then be automatically registered 427 in unicast DNS-SD. 429 6.4. Authentication 431 Up to now, the "plug-and-play" nature of mDNS devices has relied only 432 on physical connectivity. If a device is visible via mDNS then it is 433 assumed to be trusted. This is not likely to be the case in foreign 434 networks. 436 If there is a risk that clients may be fooled by the deployment of 437 rogue services, then application layer authentication should be 438 considered as part of any security solution. Authentication of any 439 particular service is outside the scope of this document. 441 6.5. Access Control 443 Access Control refers to the ability to restrict which users are able 444 to use a particular service that might be advertised via DNS-SD. In 445 this case, "use" of a service is different from the ability to 446 "discover" or "reach" a service. 448 While access control to an advertised service is outside the scope of 449 DNS-SD, we note that access control today often is provided by 450 existing site infrastructure (e.g. router access control lists, 451 firewalls) and/or by service-specific mechanisms (e.g. user 452 authentication to the service). For example, many networked printers 453 already support access controls via a user-id and password. At least 454 one widely deployed DNS-SD + mDNS implementation supports such access 455 controls for printers. So the reliance on existing service-specific 456 security mechanisms (i.e. outside the scope of DNS-SD) does not 457 create new security considerations. 459 6.6. Privacy Considerations 461 Mobile devices such as smart phones or laptops that can expose the 462 location of their owners by registering services in arbitrary zones 463 pose a risk to privacy. Such devices must not register their 464 services in arbitrary zones without the approval ("opt-in") of their 465 users. However, it should be possible to configure one or more 466 "safe" zones in which mobile devices may automatically register their 467 services. 469 7. IANA Considerations 471 This document currently makes no request of IANA. 473 Note to RFC Editor: this section may be removed upon publication as 474 an RFC. 476 8. Acknowledgments 478 We gratefully acknowledge contributions and review comments made by 479 RJ Atkinson, Tim Chown, Guangqing Deng, Ralph Droms, Educause, David 480 Farmer, Matthew Gast, Thomas Narten, Doug Otis, David Thaler, and 481 Peter Van Der Stok. 483 9. References 485 9.1. Normative References 487 [RFC3927] Cheshire, S., Aboba, B., and E. Guttman, "Dynamic 488 Configuration of IPv4 Link-Local Addresses", RFC 3927, May 489 2005. 491 [RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing 492 Architecture", RFC 4291, February 2006. 494 [RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless 495 Address Autoconfiguration", RFC 4862, September 2007. 497 [RFC4903] Thaler, D., "Multi-Link Subnet Issues", RFC 4903, June 498 2007. 500 [RFC4944] Montenegro, G., Kushalnagar, N., Hui, J., and D. Culler, 501 "Transmission of IPv6 Packets over IEEE 802.15.4 502 Networks", RFC 4944, September 2007. 504 [RFC6550] Winter, T., Thubert, P., Brandt, A., Hui, J., Kelsey, R., 505 Levis, P., Pister, K., Struik, R., Vasseur, JP., and R. 506 Alexander, "RPL: IPv6 Routing Protocol for Low-Power and 507 Lossy Networks", RFC 6550, March 2012. 509 [RFC7346] Droms, R., "IPv6 Multicast Address Scopes", RFC 7346, 510 August 2014. 512 [mDNS] Cheshire, S. and M. Krochmal, "Multicast DNS", RFC 6762, 513 February 2013. 515 [DNS-SD] Cheshire, S. and M. Krochmal, "DNS-Based Service 516 Discovery", RFC 6763, February 2013. 518 9.2. Informative References 520 [I-D.ietf-homenet-arch] 521 Chown, T., Arkko, J., Brandt, A., Troan, O., and J. Weil, 522 "IPv6 Home Networking Architecture Principles", draft- 523 ietf-homenet-arch-17 (work in progress), July 2014. 525 [I-D.sullivan-dnssd-mdns-dns-interop] 526 Sullivan, A., "Requirements for Labels to Interoperate 527 Between mDNS and DNS", draft-sullivan-dnssd-mdns-dns- 528 interop-00 (work in progress), January 2014. 530 [EP] "Educause Petition", https://www.change.org/petitions/ 531 from-educause-higher-ed-wireless-networking-admin-group, 532 July 2012. 534 [IEEE.802.11] 535 "Information technology - Telecommunications and 536 information exchange between systems - Local and 537 metropolitan area networks - Specific requirements - Part 538 11: Wireless LAN Medium Access Control (MAC) and Physical 539 Layer (PHY) Specifications", IEEE Std 802.11-2012, 2012, 540 . 543 [static] "Manually Adding DNS-SD Service Discovery Records to an 544 Existing Name Server", July 2013, 545 . 547 [ZC] Cheshire, S. and D. Steinberg, "Zero Configuration 548 Networking: The Definitive Guide", O'Reilly Media, Inc. , 549 ISBN 0-596-10100-7, December 2005. 551 Authors' Addresses 553 Kerry Lynn 554 Consultant 556 Phone: +1 978 460 4253 557 Email: kerlyn@ieee.org 559 Stuart Cheshire 560 Apple, Inc. 561 1 Infinite Loop 562 Cupertino , California 95014 563 USA 565 Phone: +1 408 974 3207 566 Email: cheshire@apple.com 567 Marc Blanchet 568 Viagenie 569 246 Aberdeen 570 Quebec , Quebec G1R 2E1 571 Canada 573 Email: Marc.Blanchet@viagenie.ca 574 URI: http://viagenie.ca 576 Daniel Migault 577 Orange 578 38-40 rue du General Leclerc 579 Issy-les-Moulineaux 92130 580 France 582 Phone: +33 1 45 29 60 52 583 Email: mglt.biz@gmail.com