idnits 2.17.1 draft-sctl-service-registration-00.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.) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (July 2, 2017) is 2490 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-06 == 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-00 Summary: 1 error (**), 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, 2018 Nominum, Inc. 6 July 2, 2017 8 Service Registration Protocol for DNS-Based Service Discovery 9 draft-sctl-service-registration-00 11 Abstract 13 The DNS-SD Service Registration Protocol provides a way to perform 14 DNS-Based Service Discovery using only unicast packets. This 15 eliminates the dependency on Multicast DNS as the foundation layer, 16 which has worked well in some environments, like the simplest of home 17 networks, but not in others, like large enterprise networks (where 18 multicast does not scale well to thousands of devices) and mesh 19 networks (where multicast and broadcast are supported poorly, if at 20 all). Broadly speaking, the DNS-SD Service Registration Protocol is 21 DNS Update, with a few additions. 23 Status of This Memo 25 This Internet-Draft is submitted in full conformance with the 26 provisions of BCP 78 and BCP 79. 28 Internet-Drafts are working documents of the Internet Engineering 29 Task Force (IETF). Note that other groups may also distribute 30 working documents as Internet-Drafts. The list of current Internet- 31 Drafts is at http://datatracker.ietf.org/drafts/current/. 33 Internet-Drafts are draft documents valid for a maximum of six months 34 and may be updated, replaced, or obsoleted by other documents at any 35 time. It is inappropriate to use Internet-Drafts as reference 36 material or to cite them other than as "work in progress." 38 This Internet-Draft will expire on January 3, 2018. 40 Copyright Notice 42 Copyright (c) 2017 IETF Trust and the persons identified as the 43 document authors. All rights reserved. 45 This document is subject to BCP 78 and the IETF Trust's Legal 46 Provisions Relating to IETF Documents 47 (http://trustee.ietf.org/license-info) in effect on the date of 48 publication of this document. Please review these documents 49 carefully, as they describe your rights and restrictions with respect 50 to this document. Code Components extracted from this document must 51 include Simplified BSD License text as described in Section 4.e of 52 the Trust Legal Provisions and are provided without warranty as 53 described in the Simplified BSD License. 55 1. Introduction 57 DNS-Based Service Discovery [RFC6763] is a component of Zero 58 Configuration Networking [RFC6760] [ZC] [Roadmap]. 60 There are two facets of DNS-Based Service Discovery to consider: 61 how relevant information makes its way into the DNS namespace 62 (how a server offers its services to interested clients) and how 63 clients access that information (how an interested client discovers 64 and uses a service instance). 66 This document is concerned with the first of those two facets: 67 how relevant information makes its way into the DNS namespace. 69 In the DNS-Based Service Discovery specification [RFC6763] Section 10 70 "Populating the DNS with Information" briefly discusses ways that 71 relevant information can make its way into the DNS namespace. In the 72 case of Multicast DNS [RFC6762], the relevant information trivially 73 becomes visible in the ".local" namespace by virtue of devices 74 answering for themselves. For unicast DNS names, ways that 75 information makes its way into the DNS namespace include manual 76 configuration of DNS zone files, possibly assisted using tools such 77 as the "dns-sd -Z" command, automated tools such as a Discovery Proxy 78 [DisProx], or explicit registration by the services themselves. It 79 is the last option -- explicit registration by the services 80 themselves -- that is the subject of this document. 82 2. Service Registration Protocol 84 The DNS-SD Service Registration Protocol is largely built on DNS 85 Update [RFC2136] [RFC3007], with some additions. 87 When a device advertises services using Multicast DNS, the parent 88 domain is implicitly ".local". 90 When a device advertises services in the traditional unicast DNS 91 namespace, it needs to know the parent domain name for its services. 92 This parent domain can be manually configured by a human operator, or 93 learned from the network. In the DNS-SD specification [RFC6763] 94 section 11, "Discovery of Browsing and Registration Domains (Domain 95 Enumeration)", describes how a client device can learn a recommended 96 default registration domain from the network. 98 In the remainder of this document, Section 3 covers cleanup of stale 99 data, and Section 4 covers advertising services on behalf of devices 100 that are sleeping to reduce power consumption. 102 The final question is security. Most dynamic DNS servers will not 103 accept unauthenticated updates. In the case of manual configuration 104 of registration domain by a human operator, the human operator can 105 also configure an appropriate TSIG security key. In the case of 106 automatic configuration via DNS-SD Domain Enumeration queries, it 107 would be nice to also have zero-configuration security. While at 108 first glance zero-configuration security may seem to be a self- 109 contradiction, this document proposes a simple first-come first- 110 served security mechanism, described below in Section 5. 112 3. Cleanup of Stale Data 114 The traditional DNS Update mechanisms [RFC2136] [RFC3007] implicitly 115 assume they are being used by a human operator. If a human operator 116 uses DNS Update (perhaps via the 'nsupdate' command) to create a 117 record, then that record should stay created until the human operator 118 decides to remove it. 120 The same assumptions do not apply to machine-generated records. If a 121 mobile device creates one or more records using DNS Update, and later 122 unceremoniously departs the network, then those stale records should 123 eventually be removed. 125 The mechanism proposed here is modeled on DHCP. Just like a DHCP 126 address lease, a record created using DNS Update has a lifetime. If 127 the record is not refreshed before its lifetime expires, then the 128 record is deleted. 130 When a client performs a DNS Update, it includes a EDNS(0) Update 131 Lease option [DNS-UL]. The DNS Update Lease option indicates the 132 requested lifetime of the records created or updated in the 133 associated DNS Update message. In the DNS Update reply, the server 134 returns its own EDNS(0) Update Lease option indicating the granted 135 lifetime, which may be shorter, the same, or longer than the client 136 requested. If the records are not refreshed before the granted 137 lifetime expires, then the records are deleted. 139 DNS servers may be configured to refuse DNS Updates that do not 140 include a DNS Update Lease option. 142 4. Sleep Proxy 144 Another use of Service Registration Protocol is for devices that 145 sleep to reduce power consumption. 147 In this case, in addition to the DNS Update Lease option [DNS-UL] 148 described above, the device includes an EDNS(0) OWNER Option [Owner]. 150 The DNS Update Lease option constitutes a promise by the device that 151 it will wake up before this time elapses, to renew its records and 152 thereby demonstrate that it is still attached to the network. If it 153 fails to renew the records by this time, that indicates that it is no 154 longer attached to the network, and its records should be deleted. 156 The EDNS(0) OWNER Option indicates that the device will be asleep, 157 and will not be receptive to normal network traffic. When a DNS 158 server receives a DNS Update with an EDNS(0) OWNER Option, that 159 signifies that the DNS server should act as a proxy for any IPv4 or 160 IPv6 address records in the DNS Update message. This means that the 161 DNS server should send ARP or ND messages claiming ownership of the 162 IPv4 and/or IPv6 addresses in the records in question. In addition, 163 the DNS server should answer future ARP or ND requests for those IPv4 164 and/or IPv6 addresses, claiming ownership of them. When the DNS 165 server receives a TCP SYN or UDP packet addressed to one of the IPv4 166 or IPv6 addresses for which it proxying, it should then wake up the 167 sleeping device using the information in the EDNS(0) OWNER Option. 168 At present version 0 of the OWNER Option specifies the "Wake-on-LAN 169 Magic Packet" that needs to be sent; future versions could be 170 extended to specify other wakeup mechanisms. 172 5. First-Come First-Served Naming 174 In some environments, such as home networks with an appropriate 175 border gateway, it may be preferable to have some limited security on 176 the protected internal network rather than no security at all. 178 Users have shown limited willingness to endure complicated 179 configuration for their networked home devices. It is rare for home 180 users to change even the factory-default name for their wireless 181 printer, so it's questionable whether it's reasonable to expect them 182 to configure passwords or security keys. 184 This document presents a zero-configuration first-come first-served 185 naming mechanism. 187 Instead of requiring a preconfigured key installed by manual 188 administration, a new device optimistically creates its DNS Service 189 Discovery records, plus a DNS SIG(0) public key, using a DNS Update 190 signed with its DNS SIG(0) private key. 192 The DNS server validates the signature on the message using the 193 SIG(0) key already stored on the name, if present, and otherwise with 194 the key sent in the update, if the requested name is not yet present. 195 The server may check that the two public keys are the same before 196 validating, and refuse the update if they are not, to avoid the cost 197 of verifying the signature. 199 The lifetime of the DNS-SD PTR, SRV and TXT records [RFC6763] is 200 typically set to two hours. That way, if a device is disconnected 201 from the network, its stale data does not persist for too long, 202 advertising a service that is not accessible. 204 However, the lifetime of its DNS SIG(0) public key should be set to a 205 much longer time, typically 14 days. The result of this is that even 206 though a device may be temporarily unplugged, disappearing from the 207 network for a few days, it makes a claim on its name that lasts much 208 longer. 210 This way, even if a device is unplugged from the network for a few 211 days, and its services are not available for that time, no other 212 rogue device can come along and immediately claim its name the moment 213 it disappears from the network. It takes a much longer time before 214 an abandoned name becomes available for re-use. 216 When using this first-come first-served security mechanism, the 217 server accepting or rejecting the updates utilizes knowledge of the 218 DNS-Based Service Discovery semantics [RFC6763]. Specifically, for 219 all records aside from PTR records, the update must be validly signed 220 using the SIG(0) key with the same DNS resource record owner name 221 (the name on the left in a traditional textual zone file). For 222 additions or deletions of PTR records, the update must be validly 223 signed using the SIG(0) key with the same DNS resource record owner 224 name as the rdata in the PTR record (the name on the right in a 225 traditional textual zone file). 227 6. Security Considerations 229 To be completed. 231 7. References 233 7.1. Normative References 235 [RFC6763] Cheshire, S. and M. Krochmal, "DNS-Based Service 236 Discovery", RFC 6763, DOI 10.17487/RFC6763, February 2013, 237 . 239 7.2. Informative References 241 [RFC2136] Vixie, P., Ed., Thomson, S., Rekhter, Y., and J. Bound, 242 "Dynamic Updates in the Domain Name System (DNS UPDATE)", 243 RFC 2136, DOI 10.17487/RFC2136, April 1997, 244 . 246 [RFC3007] Wellington, B., "Secure Domain Name System (DNS) Dynamic 247 Update", RFC 3007, DOI 10.17487/RFC3007, November 2000, 248 . 250 [RFC6760] Cheshire, S. and M. Krochmal, "Requirements for a Protocol 251 to Replace the AppleTalk Name Binding Protocol (NBP)", 252 RFC 6760, DOI 10.17487/RFC6760, February 2013, 253 . 255 [RFC6762] Cheshire, S. and M. Krochmal, "Multicast DNS", RFC 6762, 256 DOI 10.17487/RFC6762, February 2013, 257 . 259 [DisProx] Cheshire, S., "Discovery Proxy for Multicast DNS-Based 260 Service Discovery", draft-ietf-dnssd-hybrid-06 (work in 261 progress), March 2017. 263 [DNS-UL] Sekar, K., "Dynamic DNS Update Leases", draft-sekar-dns- 264 ul-01 (work in progress), August 2006. 266 [Roadmap] Cheshire, S., "Service Discovery Road Map", draft- 267 cheshire-dnssd-roadmap-00 (work in progress), July 2017. 269 [Owner] Cheshire, S. and M. Krochmal, "EDNS0 OWNER Option", draft- 270 cheshire-edns0-owner-option-01 (work in progress), July 271 2017. 273 [ZC] Cheshire, S. and D. Steinberg, "Zero Configuration 274 Networking: The Definitive Guide", O'Reilly Media, Inc. , 275 ISBN 0-596-10100-7, December 2005. 277 Authors' Addresses 279 Stuart Cheshire 280 Apple Inc. 281 1 Infinite Loop 282 Cupertino, California 95014 283 USA 285 Phone: +1 408 974 3207 286 Email: cheshire@apple.com 288 Ted Lemon 289 Nominum, Inc. 290 800 Bridge Parkway 291 Redwood City, California 94065 292 United States of America 294 Phone: +1 650 381 6000 295 Email: ted.lemon@nominum.com