idnits 2.17.1 draft-sctl-service-registration-01.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 : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 136: '...ion, the service SHOULD simply use the...' RFC 2119 keyword, line 192: '.../private key pair. This key pair MUST...' RFC 2119 keyword, line 194: '...ient, the client MUST be pre-configure...' RFC 2119 keyword, line 266: '... The server MAY apply additional cri...' RFC 2119 keyword, line 290: '...y the client, it MUST include include ...' (3 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (July 2, 2018) is 2122 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Outdated reference: A later version (-10) exists of draft-ietf-dnssd-hybrid-08 == Outdated reference: A later version (-03) exists of draft-sekar-dns-ul-01 == Outdated reference: A later version (-03) exists of draft-cheshire-dnssd-roadmap-01 Summary: 2 errors (**), 0 flaws (~~), 4 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Engineering Task Force S. Cheshire 3 Internet-Draft Apple Inc. 4 Intended status: Informational T. Lemon 5 Expires: January 3, 2019 Nibbhaya Consulting 6 July 2, 2018 8 Service Registration Protocol for DNS-Based Service Discovery 9 draft-sctl-service-registration-01 11 Abstract 13 The DNS-SD Service Registration Protocol uses the standard DNS Update 14 mechanism to enable DNS-Based Service Discovery using only unicast 15 packets. This eliminates the dependency on Multicast DNS as the 16 foundation layer, which greatly improves scalability and improves 17 performance on networks where multicast service is not an optimal 18 choice, particularly 802.11 (WiFi) and 802.15 (IoT) networks. DNS-SD 19 Service registration uses public keys and SIG(0) to allow services to 20 defend their registrations against attack. 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 https://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 January 3, 2019. 39 Copyright Notice 41 Copyright (c) 2018 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 (https://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 1. Introduction 56 DNS-Based Service Discovery [RFC6763] is a component of Zero 57 Configuration Networking [RFC6760] [ZC] [I-D.cheshire-dnssd-roadmap]. 59 DNS-Based Service Discovery (DNS-SD) allows services to advertise the 60 fact that they provide service, and to provide the information 61 required to access that service. Clients can then discover the set 62 of services of a particular type that are available. They can then 63 select a service from among those that are available and obtain the 64 information required to use it. 66 The DNS-SD Service Registration protocol, described in this document, 67 provides a reasonably secure mechanism for publishing this 68 information: what services are offered, and how to use them. Once 69 published, these services can be readily discovered by clients using 70 standard DNS lookups. 72 In the DNS-Based Service Discovery specification [RFC6763] Section 10 73 "Populating the DNS with Information" briefly discusses ways that 74 services can publish their information in the DNS namespace. In the 75 case of Multicast DNS [RFC6762], allows clients to directly query 76 services on the local link for names in the ".local" namespace. 78 RFC6763 also allows clients to discover services using the DNS 79 protocol [RFC1035]; this is done either by having a system 80 administrator manually configure service information in the DNS, or 81 by using a Discovery Proxy [I-D.ietf-dnssd-hybrid], which performs 82 mDNS queries on behalf clients issuing queries using DNS. This 83 eliminats the "link local" limitation of mDNS, but provides no 84 additional security, and still relies on multicast. 86 Manual configuration of DNS servers is costly and failure-prone, and 87 requires a knowledgable network administrator. Consequently, 88 although all DNS-SD implementations of which we are aware support it, 89 it is much less frequently used than mDNS. This document describes a 90 solution: a way to provide DNS-SD using DNS that can be as automatic 91 as multicast DNS, but with better performance, scalability and 92 security. 94 2. Service Registration Protocol 96 Services using the DNS-SD Service Registration Protocol use DNS 97 Update [RFC2136] [RFC3007] to publish service information in the DNS. 98 We will discuss several parts to this process: how to know what to 99 publish, how to know where to publish it (under what name), how to 100 publish it, how to secure its publication, and how to maintain the 101 information once published. 103 2.1. What to publish 105 RFC 6763 describes the details of what is to be published. In 106 general terms, a service will have a name under which it offers 107 services ([RFC6763] section 4.1.1) and one or more service names 108 under which that instance name appears ([RFC6763] section 4.1.2). 109 The full details of how this works are described in section 4 of that 110 document in its entirety. A service publishes its contact 111 information using an SRV record on the Service Instance Name. It can 112 also publish TXT records with additional information about the 113 service; this is discussed in section 6 of RFC 6763. 115 RFC 6763 is the definitive source for information about what to 116 publish; the reason for mentioning it here is that the reader may 117 prefer to have an overview of the whole service registration process 118 before digging into the details. Also, the "Service Instance Name" 119 is an important aspect of first-come, first-serve naming, which we 120 describe later on in this document. 122 2.2. Where to publish it 124 Multicast DNS uses a single namespace, ".local", which is valid on 125 the local link. This convenience is not available for DNS-SD using 126 the DNS protocol: the portion of the DNS namespace in which services 127 on the local network are to be published must be discovered by the 128 service before it can register itself. 130 Names published using DNS-SD service registration will be published 131 under some name other than .local. However, the process of 132 discovering what that name is is complicated, and for any given 133 network it should always be the case that there will be just one 134 namespace in which registered names will be published. Rather than 135 requiring the service to discover this name before issuing a 136 registration, the service SHOULD simply use the name ".local." The 137 DNS server that receives the registration request will rewrite all 138 instances of the terminal label ".local" to use the local 139 registration domain name. The response to the DNS Update being used 140 to register the service will contain the rewritten names, instead of 141 ".local". Subsequent updates should still use the ".local" domain 142 and not the registration domain, since the registration domain may 143 change over time or when the service is physically moved to a new 144 network. 146 2.3. How to publish it 148 DNS Updates are very flexible. As a consequence, it is possible to 149 do the entire registration in a single DNS message. The update 150 consists of two elements. The first updates the Service Name by 151 adding a PTR record pointing to the Service Instance Name. The 152 second updates the Service Instance Name. The second creates or 153 updates the Service Instance Name update adds an SRV record and a KEY 154 record, and optionally adds a TXT record with extra information about 155 the service. The contents of the KEY record are described in the 156 section on First-Come First-Served Naming (Section 2.4.1). The 157 update is signed using the private key that corresponds to the public 158 key in the KEY record, using the SIG(0) protocol [RFC2931]. 160 The update may be rejected. If the chosen service instance name is 161 not permitted, or is already taken, the update will be returned with 162 the error code YXDOMAIN. In this case, the service will need to 163 choose a new instance name and try again. 165 2.4. How to secure it 167 Traditional DNS update is secured using the TSIG protocol, which uses 168 a secret key shared between the client (which issues the update) and 169 the server (which authenticates it). This model does not work for 170 automatic service registration. 172 The goal of securing the DNS-SD Registration Protocol is to provide 173 the best possible security given the constraint that service 174 registration has to be automatic. It is possible to layer more 175 operational security on top of what we describe here, but what we 176 describe here improves upon the security of mDNS. The goal is not to 177 provide the level of security of a network managed by a skilled 178 operator. 180 2.4.1. First-Come First-Served Naming 182 First-Come First-Serve naming provides a limited degree of security: 183 a service that registers its service using DNS-SD Registration 184 protocol is given ownership of a name for an extended period of time 185 based on the key used to authenticate the DNS Update. As long as the 186 registration service remembers the Service Instance Name and the key 187 used to register that Service Instance Name, no other service can add 188 or update the information associated with that Service Instance Name. 190 2.4.1.1. Service Behavior 192 The service generates a public/private key pair. This key pair MUST 193 be stored in stable storage; if there is no writable stable storage 194 on the client, the client MUST be pre-configured with a public/ 195 private key pair that can be used. 197 When sending DNS updates, the service includes a KEY record 198 containing the public portion of the key, which is stored as an RRset 199 under the Service Instance Name. It is permissible for a device that 200 offers more than one service under more than one Service Instance 201 Name to use the same KEY on each such name. 203 The update is signed using SIG(0), using the private key that 204 corresponds to the public key in the KEY record. 206 The lifetime of the DNS-SD PTR, SRV and TXT records [RFC6763] is 207 typically set to two hours. This means that if a device is 208 disconnected from the network, it does not appear in the user 209 interfaces of devices looking for services of that type for too long. 211 However, the lifetime of its DNS SIG(0) public key should be set to a 212 much longer time, typically 14 days. The result of this is that even 213 though a device may be temporarily unplugged, disappearing from the 214 network for a few days, it makes a claim on its name that lasts much 215 longer. 217 This way, even if a device is unplugged from the network for a few 218 days, and its services are not available for that time, no other 219 rogue device can come along and immediately claim its name the moment 220 it disappears from the network, and yet the name is eventually 221 cleaned up and made available for re-use. 223 2.4.1.2. Registration Server Behavior 225 The Registration server checks that the DNS update contains a Service 226 Instance Name. In principle, each name in the update should be 227 evaluated as a candidate Service Instance Name. However, some names 228 will obviously be Service Names, and these can be skipped when 229 evaluating candidates. In order for a candidate to actually be a 230 service instance name, the following conditions must be true: 232 o There is at least one name that turns out NOT to be a Service 233 Instance Name for which there is a PTR RRset update that includes 234 a record pointing to the candidate. 236 o The candidate includes an SRV record 237 o The candidate includes a KEY record 239 If an update does not contain a valid Service Instance Name, or if it 240 contains an update to a PTR RRset that references a name that is not 241 the Service Instance Name being updated, the update is rejected with 242 the NOTAUTH RCODE. 244 If an update contains an SRV record that contains an IP address other 245 than the IP address from which the update was recieved, the update is 246 rejected with the NOTAUTH RCODE. 248 Once each name for which there are updates in the DNS Update has been 249 considered as a candidate, it should be the case that only one name 250 is actually a possible Service Instance Name. If more than one name 251 is still a possible candidate, then the DNS Update is rejected with 252 the FORMERR RCODE. 254 If there is only one candidate, then the server checks to see if that 255 name already exists. If it does already exist, then the server 256 checks to see if the KEY record on the name is the same as the one in 257 the update for that name. If it is not, then the DNS Update is 258 rejected with the YXDOMAIN RCODE. 260 Otherwise, the server validates the update using SIG(0). If the 261 validation fails, the update is rejected with NOTAUTH. Otherwise, 262 the update is evaluated according to the rules described in RFC2136 263 for processing DNS updates, and whatever the correct result is is 264 returned. 266 The server MAY apply additional criteria when accepting updates. In 267 some networks, it may be possible to do out-of-band registration of 268 keys, and only accept updates from pre-registered keys. In this 269 case, an update for a key that has not been registered should be 270 rejected using NOTAUTH. 272 There are at least two benefits to doing this rather than simply 273 using normal SIG(0) DNS updates. First, the same registration 274 protocol can be used in both cases, so both use cases can be 275 addressed by the same implementation. Second, the registration 276 protocol includes maintenance functionality not present with normal 277 DNS updates. 279 The server may also have a dictionary of names or name patterns that 280 are not permitted. If such a list is used, updates for Service 281 Instance Names that match entries in the dictionary are rejected with 282 YXDOMAIN. 284 2.5. Maintenance 286 2.5.1. Cleaning up stale data 288 Because the DNS-SD registration protocol is automatic, and not 289 managed by humans, some additional bookkeeping is required. When an 290 update is constructed by the client, it MUST include include an 291 EDNS(0) Update Lease option and an EDNS(0) Instance Lease option. 293 These leases are promises, similar to DHCP leases [RFC2131], from the 294 client that it will send a new update for the service registration 295 before the lease time expires. The Update Lease time is chosen to 296 represent the time after the update during which the registered 297 records other than the KEY record should be assumed to be valid. The 298 Instance Lease time represents the time after the update during which 299 the KEY record should be assumed to be valid. 301 The reasoning behind the different lease times is discussed in the 302 section on first-come, first-served naming Section 2.4.1. DNS-SD 303 Registration Protocol servers may be configured with limits for these 304 values. A default limit of two hours for the Update Lease and 30 305 days for the Instance Lease are currently thought to be good choices. 306 Clients that are going to continue to use names on which they hold 307 leases should update well before the lease ends, in case the 308 registration service is unavailable or under heavy load. 310 Clients should assume that each lease ends N seconds after the update 311 was first transmitted, where N is the number included in the option. 312 Servers should assume that each lease ends N seconds after the update 313 that was successfully processed was received. Because the server 314 will always receive the update after the client sent it, this avoids 315 the possibility of misunderstandings. 317 DNS-SD Registration Protocol servers SHOULD reject updates that do 318 not include a DNS update lease time. Dual-use servers may accept 319 updates that don't include leases, but SHOULD differentiate between 320 DNS-SD registration protocol updates and other updates, and SHOULD 321 reject updates that are known to be DNS-SD registration protocol 322 updates if they do not include leases. 324 2.5.2. Sleep Proxy 326 Another use of Service Registration Protocol is for devices that 327 sleep to reduce power consumption. 329 In this case, in addition to the DNS Update Lease option 330 [I-D.sekar-dns-ul] described above, the device includes an EDNS(0) 331 OWNER Option [I-D.cheshire-edns0-owner-option]. 333 The DNS Update Lease option constitutes a promise by the device that 334 it will wake up before this time elapses, to renew its records and 335 thereby demonstrate that it is still attached to the network. If it 336 fails to renew the records by this time, that indicates that it is no 337 longer attached to the network, and its records should be deleted. 339 The EDNS(0) OWNER Option indicates that the device will be asleep, 340 and will not be receptive to normal network traffic. When a DNS 341 server receives a DNS Update with an EDNS(0) OWNER Option, that 342 signifies that the DNS server should act as a proxy for any IPv4 or 343 IPv6 address records in the DNS Update message. This means that the 344 DNS server should send ARP or ND messages claiming ownership of the 345 IPv4 and/or IPv6 addresses in the records in question. In addition, 346 the DNS server should answer future ARP or ND requests for those IPv4 347 and/or IPv6 addresses, claiming ownership of them. When the DNS 348 server receives a TCP SYN or UDP packet addressed to one of the IPv4 349 or IPv6 addresses for which it proxying, it should then wake up the 350 sleeping device using the information in the EDNS(0) OWNER Option. 351 At present version 0 of the OWNER Option specifies the "Wake-on-LAN 352 Magic Packet" that needs to be sent; future versions could be 353 extended to specify other wakeup mechanisms. 355 3. Security Considerations 357 DNS-SD Service Registration Protocol updates have no authorization 358 semantics other than first-come, first-served. This means that if an 359 attacker from outside of the administrative domain of the server 360 knows the server's IP address, it can in principle send updates to 361 the server that will be processed successfully. Servers should 362 therefore be configured to reject updates from source addresses 363 outside of the administrative domain of the server. 365 Note that these rules only apply to the validation of DNS-SD 366 registration protocol updates. A server that accepts updates from 367 DNS-SD registration protocol clients may also accept other DNS 368 updates, and those DNS updates may be validated using different 369 rules. However, in the case of a DNS service that accepts automatic 370 updates, the intersection of the DNS-SD service registration update 371 rules and whatever other update rules are present must be considered 372 very carefully. 374 4. Privacy Considerations 376 5. References 377 5.1. Normative References 379 [RFC6763] Cheshire, S. and M. Krochmal, "DNS-Based Service 380 Discovery", RFC 6763, DOI 10.17487/RFC6763, February 2013, 381 . 383 5.2. Informative References 385 [RFC1035] Mockapetris, P., "Domain names - implementation and 386 specification", STD 13, RFC 1035, DOI 10.17487/RFC1035, 387 November 1987, . 389 [RFC2131] Droms, R., "Dynamic Host Configuration Protocol", 390 RFC 2131, DOI 10.17487/RFC2131, March 1997, 391 . 393 [RFC2136] Vixie, P., Ed., Thomson, S., Rekhter, Y., and J. Bound, 394 "Dynamic Updates in the Domain Name System (DNS UPDATE)", 395 RFC 2136, DOI 10.17487/RFC2136, April 1997, 396 . 398 [RFC2931] Eastlake 3rd, D., "DNS Request and Transaction Signatures 399 ( SIG(0)s )", RFC 2931, DOI 10.17487/RFC2931, September 400 2000, . 402 [RFC3007] Wellington, B., "Secure Domain Name System (DNS) Dynamic 403 Update", RFC 3007, DOI 10.17487/RFC3007, November 2000, 404 . 406 [RFC6760] Cheshire, S. and M. Krochmal, "Requirements for a Protocol 407 to Replace the AppleTalk Name Binding Protocol (NBP)", 408 RFC 6760, DOI 10.17487/RFC6760, February 2013, 409 . 411 [RFC6762] Cheshire, S. and M. Krochmal, "Multicast DNS", RFC 6762, 412 DOI 10.17487/RFC6762, February 2013, 413 . 415 [I-D.ietf-dnssd-hybrid] 416 Cheshire, S., "Discovery Proxy for Multicast DNS-Based 417 Service Discovery", draft-ietf-dnssd-hybrid-08 (work in 418 progress), March 2018. 420 [I-D.sekar-dns-ul] 421 Sekar, K., "Dynamic DNS Update Leases", draft-sekar-dns- 422 ul-01 (work in progress), August 2006. 424 [I-D.cheshire-dnssd-roadmap] 425 Cheshire, S., "Service Discovery Road Map", draft- 426 cheshire-dnssd-roadmap-01 (work in progress), March 2018. 428 [I-D.cheshire-edns0-owner-option] 429 Cheshire, S. and M. Krochmal, "EDNS0 OWNER Option", draft- 430 cheshire-edns0-owner-option-01 (work in progress), July 431 2017. 433 [ZC] Cheshire, S. and D. Steinberg, "Zero Configuration 434 Networking: The Definitive Guide", O'Reilly Media, Inc. , 435 ISBN 0-596-10100-7, December 2005. 437 Authors' Addresses 439 Stuart Cheshire 440 Apple Inc. 441 1 Infinite Loop 442 Cupertino, California 95014 443 USA 445 Phone: +1 408 974 3207 446 Email: cheshire@apple.com 448 Ted Lemon 449 Nibbhaya Consulting 450 P.O. Box 958 451 Brattleboro, Vermont 05302 452 United States of America 454 Email: mellon@fugue.com