idnits 2.17.1 draft-lemon-stateful-dnssd-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 (October 31, 2016) is 2734 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Outdated reference: A later version (-05) exists of draft-ietf-dnssd-pairing-00 == Outdated reference: A later version (-10) exists of draft-ietf-dnssd-hybrid-03 == Outdated reference: A later version (-25) exists of draft-ietf-dnssd-push-08 Summary: 1 error (**), 0 flaws (~~), 4 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group T. Lemon 3 Internet-Draft Nominum, Inc. 4 Intended status: Informational October 31, 2016 5 Expires: May 4, 2017 7 Stateful Multi-Link DNS Service Discovery 8 draft-lemon-stateful-dnssd-00 10 Abstract 12 This document proposes a stateful model for automating Multi-Link DNS 13 Service Discovery, as an extension to the existing solution, which 14 relies entirely on multicast DNS for discovering services, and does 15 not formally maintain DNS zone state. When fully deployed this will 16 confer several advantages: the ability to do DNS zone transfers, 17 integrating with existing DNS infrastructure; the elimination of the 18 need for regular multicast queries; and the ability for services to 19 securely register and defend their names, preventing malicious 20 spoofing of services on the network. 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 May 4, 2017. 39 Copyright Notice 41 Copyright (c) 2016 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. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 58 3. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 3 59 4. Service Behavior . . . . . . . . . . . . . . . . . . . . . . 4 60 4.1. Detecting Stateful ML-DNSSD . . . . . . . . . . . . . . . 4 61 4.2. Publishing Services when Stateful ML-DNSSD is present . . 4 62 4.3. Maintenance . . . . . . . . . . . . . . . . . . . . . . . 5 63 5. Discovery . . . . . . . . . . . . . . . . . . . . . . . . . . 6 64 6. DNS Service Infrastructure . . . . . . . . . . . . . . . . . 6 65 7. Legacy Service Discovery . . . . . . . . . . . . . . . . . . 6 66 8. Security Considerations . . . . . . . . . . . . . . . . . . . 6 67 9. Normative References . . . . . . . . . . . . . . . . . . . . 7 68 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 7 70 1. Introduction 72 This document describes a way of doing DNS service discovery using 73 DNS updates [RFC2136] rather than Multicast DNS[RFC6762]. Update 74 validation is done on the same basis as Multicast DNS validation: the 75 assumption is that a device connected to a local link is permitted to 76 advertise services. However, in contrast to mDNS, which provides no 77 mechanism for defending claims made by services, we propose that 78 services should publish keys when initially registering names, and 79 use SIG(0) authentication [RFC2931] when issuing DNS updates, using 80 the published key. 82 Advantages of this proposal over the Multicast DNS Hybrid proposal 83 [I-D.ietf-dnssd-hybrid] are: 85 o Service advertisement does not require multicast. 87 o Names are stored in DNS zone databases, and therefore can be 88 published using standard DNS protocol features such as zone 89 transfers. 91 o Names can be defended by services that register them, so that it 92 is difficult for an attacker to spoof an existing service. 94 There are, however, disadvantages to this approach. The first 95 disadvantage is that this proposal does not actually eliminate 96 multicast except in the case that all local services implement the 97 new update mechanism. Because this approach maintains state, and 98 that state must include existing services that only support 99 advertising via Multicast DNS, additional complexity is required to 100 avoid retaining stale information; this complexity is not required 101 for the stateless model proposed in the mDNS hybrid specification. 103 Another disadvantage of this approach is that it requires a stable 104 naming infrastructure, and requires forwarders on each local link. 106 Some sites may find it preferable to rely on the stateless model for 107 this reason. However, the stateful model provides sufficient 108 advantages that it will make sense for some sites to implement it, 109 even in the legacy mode that still supports service discovery using 110 Multicast DNS. 112 2. Terminology 114 For the sake of brevity this document uses a number of abbreviations. 115 These are expanded here: 117 mDNS Multicast DNS 119 ML-DNSSD Multi-Link DNS Service Discovery 121 3. Overview 123 Stateful Multi-Link DNS service discovery attempts to provide 124 stateful service that is otherwise equivalent to Hybrid Unicast/ 125 Multicast DNS-Based Service Discovery, except that where possible 126 multicast is avoided, and DNS zones are maintained such that full 127 interoperation with the DNS is possible. 129 In order to accomplish this, service providers detect whether the 130 local network supports stateful operation. If not, they simply 131 provide service using mDNS as before. If so, they advertise services 132 solely using DNS updates. 134 The DNS infrastructure is prepared to take DNS updates from devices 135 on served networks; each unique link has a DNS forwarder that can 136 detect that a packet originated locally and was not forwarded; this 137 serves as validation that the service can be advertised. 139 Legacy services are supported using the same query process used in 140 the hybrid model. Unlike with the hybrid model, however, discovered 141 services are added to DNS zones. 143 As with the Hybrid model, services are discovered using unicast DNS. 144 Multicast DNS service discovery is not usable on networks offering 145 stateful multi-link DNS service discovery. 147 4. Service Behavior 149 Hosts offering services using DNS service discovery must advertise 150 these services. When a host offering services is connected to a 151 network that does not offer stateful ML-DNSSD, it offers service 152 discovery using Multicast DNS. When stateful ML-DNSSD is offered, 153 the host does not offer service discovery using Multicast DNS. 155 4.1. Detecting Stateful ML-DNSSD 157 In order to detect the presence of stateful ML-DNSSD, the host first 158 performs registration domain discovery as in section 11 of [RFC6763] 159 to acquire the name of the recommended default domain for registering 160 services. If this process fails, Stateful ML-DNSSD is not present. 161 If the process succeeds, the host looks for a PTR record using the 162 well-known name "_mldnssd.". If a PTR record is present, 163 stateful ML-DNSSD is present. 165 Whenever a host detects a change to the link, a change to the IP 166 addresses of the DNS resolvers provided on the link, or a change to 167 the set of prefixes available on the link, the host re-tries the ML- 168 DNSSD detection process. 170 4.2. Publishing Services when Stateful ML-DNSSD is present 172 When stateful ML-DNSSD is present, a host adds its own information 173 into the DNS. This information is added into three separate domains, 174 as described in [I-D.ietf-dnssd-hybrid], section 4. The subdomain 175 for services and the subdomain for names are a single subdomain, the 176 recommended default domain for registering services. The IPv4 and 177 IPv6 reverse-mapping zones are discovered by querying the well-known 178 names "_inaddr_zone." and "_ipv6_zone." for PTR 179 records. Each PTR record points to a specific zone to which updates 180 are sent for IPv4 and IPv6 PTR records. 182 When a host that offers service first starts, it generates a key that 183 is used to authenticate its DNS updates. This key is included 184 whenever updating the service's name. 186 There are four domain names that are updated when a service 187 advertises itself: the human-readable name, the machine-readable 188 name, the service entry or entries, and the resverse-mapping 189 pointers. The update proceeds by first adding or updating the 190 machine-readable name, then adding a PTR record from the human- 191 readable name to the machine-readable name, then adding the reverse- 192 mapping pointers, then adding the service. All updates are signed 193 using SIG(0), authenticated with the private half of the host's key. 195 To add the machine-readable name, the host creates a DNS update that 196 adds its name. The update is predicated on the nonexistence of the 197 name. The update includes A and AAAA records for all of the hosts IP 198 addresses except its link-local addresses. If this update succeeds, 199 the machine-readable name has been added. 201 The update can fail for one of two reasons: either the signature was 202 invalid, or the name already exists. In the former case, there is a 203 bug, and the host should revert to providing service using mDNS. 205 Otherwise, if the update fails, the name already exists. The host 206 creates a new update that deletes any A and AAAA RRsets and adds A 207 and AAAA as before. There is no predicate for this update because 208 the server should reject it if the name belongs to some other host 209 (that is, has a different key). If this update fails, the host 210 chooses a new machine-readable name and restarts the process. 212 The host then creates a PTR record under "Human Readable 213 Name." pointing to the machine-readable name. If this fails, 214 the host must choose a different name and attempt to add it, until 215 successful. 217 The host now creates updates for the reverse-mapping name of every 218 IPv4 address it has that is not a link-local address, and adds a PTR 219 record for each, pointing back at the machine-readable name. These 220 adds should not fail. The process is repeated for every IPv6 address 221 that is not link-local. 223 Finally, the host updates the well-known name for its service or 224 services, adding an entry for each one. These names may already have 225 SRV RRtypes, so this update must add records. 227 TODO: consider whether this is really the right way to do this--it's 228 really complicated, and might be better done as a single HTTP 229 request. 231 4.3. Maintenance 233 Whenever the host adds its service to the DNS, it queries the 234 machine-readable name to see what the TTL is. When 80% of that TTL 235 has expired, the host refreshes all of its records. This prevents 236 the records from being cleaned up by the DNS server as stale. 238 If the host is being shut down cleanly, it may remove all names and 239 SRV records that it has added, or may remove all SRV records, leaving 240 everything else intact in order to reserve the name. In most cases, 241 it is better to leave the name. 243 5. Discovery 245 Service Discovery is done as per RFC 6763. Service discovery 246 defaults to '.local', which is resolved using mDNS. If ML-DNSSD is 247 present in any form, hosts doing service discovery should 248 successfully discover this following the method described in RFC 249 6763. The service appears to the host doing service discovery the 250 same way whether the hybrid model or the stateful model is being 251 used. Hosts do not do mDNS if ML-DNSSD is present. 253 In order to support progressive queries in situations where legacy 254 service discovery is in operation, hosts should use DNS push 255 [I-D.ietf-dnssd-push]. 257 6. DNS Service Infrastructure 259 Updates are sent to a forwarder on the local link. The forwarder 260 uses neighbor discovery or ARP to validate each of the IP addresses 261 presented in an A or AAAA record. Updates that do not come from 262 local hosts are silently discarded. Other updates are forwarded to 263 the primary name server without changes. 265 The primary server validates all updates by using the key stored on 266 the machine-readable name to which the update points. If the update 267 is an update of the machine-readable name, the update is validated 268 based on the key stored at that name, if any, or else using the key 269 contained in the update. 271 Any number of secondaries may be configured. Secondaries may also 272 serve as forwarders if appropriate. 274 7. Legacy Service Discovery 276 Service discovery done as in mdns-hybrid, except that state is 277 retained. State is periodically probed; stale state is discarded. 278 Discovery service listens for initial service announcements. 280 8. Security Considerations 282 Any host on a network on which service discovery is supported can 283 advertise services, which might be spoofed so as to capture private 284 information. One solution to this is to only accept updates from 285 designated infrastructure networks, so that networks to which regular 286 users connect are not permitted to advertise services. This will, 287 however, limit the usefulness of various services which may be 288 present on user devices. 290 It may be possible to only allow anonymous pairing 291 [I-D.ietf-dnssd-pairing] on public-facing networks, so that 292 infrastructure services cannot be advertised, but users can still 293 rendezvous. 295 9. Normative References 297 [RFC2136] Vixie, P., Ed., Thomson, S., Rekhter, Y., and J. Bound, 298 "Dynamic Updates in the Domain Name System (DNS UPDATE)", 299 RFC 2136, DOI 10.17487/RFC2136, April 1997, 300 . 302 [RFC2931] Eastlake 3rd, D., "DNS Request and Transaction Signatures 303 ( SIG(0)s )", RFC 2931, DOI 10.17487/RFC2931, September 304 2000, . 306 [RFC6762] Cheshire, S. and M. Krochmal, "Multicast DNS", RFC 6762, 307 DOI 10.17487/RFC6762, February 2013, 308 . 310 [RFC6763] Cheshire, S. and M. Krochmal, "DNS-Based Service 311 Discovery", RFC 6763, DOI 10.17487/RFC6763, February 2013, 312 . 314 [I-D.ietf-dnssd-pairing] 315 Huitema, C. and D. Kaiser, "Device Pairing Using Short 316 Authentication Strings", draft-ietf-dnssd-pairing-00 (work 317 in progress), October 2016. 319 [I-D.ietf-dnssd-hybrid] 320 Cheshire, S., "Hybrid Unicast/Multicast DNS-Based Service 321 Discovery", draft-ietf-dnssd-hybrid-03 (work in progress), 322 February 2016. 324 [I-D.ietf-dnssd-push] 325 Pusateri, T. and S. Cheshire, "DNS Push Notifications", 326 draft-ietf-dnssd-push-08 (work in progress), July 2016. 328 Author's Address 329 Ted Lemon 330 Nominum, Inc. 331 800 Bridge Parkway 332 Redwood City, California 94065 333 United States of America 335 Phone: +1 650 381 6000 336 Email: ted.lemon@nominum.com