idnits 2.17.1 draft-tldm-simple-homenet-naming-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 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 230: '...vertised locally MUST use addresses in...' RFC 2119 keyword, line 235: '... MUST filter out global IP addresses...' RFC 2119 keyword, line 257: '... homenet routers MUST implement the sp...' Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (July 3, 2017) is 2488 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 (-18) exists of draft-ietf-tokbind-https-09 == Outdated reference: A later version (-14) exists of draft-ietf-homenet-dot-07 == Outdated reference: A later version (-02) exists of draft-sctl-service-registration-00 -- No information found for draft-sctl-mdns-relay - is the name correct? Summary: 1 error (**), 0 flaws (~~), 5 warnings (==), 2 comments (--). 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 D. Migault 5 Expires: January 4, 2018 Ericsson 6 July 3, 2017 8 Simple Homenet Naming and Service Discovery Architecture 9 draft-tldm-simple-homenet-naming-01 11 Abstract 13 This document describes a simple name resolution and service 14 discovery architecture for homenets. This architecture covers local 15 publication of names, as well as name resolution for local and global 16 names. 18 Status of This Memo 20 This Internet-Draft is submitted in full conformance with the 21 provisions of BCP 78 and BCP 79. 23 Internet-Drafts are working documents of the Internet Engineering 24 Task Force (IETF). Note that other groups may also distribute 25 working documents as Internet-Drafts. The list of current Internet- 26 Drafts is at http://datatracker.ietf.org/drafts/current/. 28 Internet-Drafts are draft documents valid for a maximum of six months 29 and may be updated, replaced, or obsoleted by other documents at any 30 time. It is inappropriate to use Internet-Drafts as reference 31 material or to cite them other than as "work in progress." 33 This Internet-Draft will expire on January 4, 2018. 35 Copyright Notice 37 Copyright (c) 2017 IETF Trust and the persons identified as the 38 document authors. All rights reserved. 40 This document is subject to BCP 78 and the IETF Trust's Legal 41 Provisions Relating to IETF Documents 42 (http://trustee.ietf.org/license-info) in effect on the date of 43 publication of this document. Please review these documents 44 carefully, as they describe your rights and restrictions with respect 45 to this document. Code Components extracted from this document must 46 include Simplified BSD License text as described in Section 4.e of 47 the Trust Legal Provisions and are provided without warranty as 48 described in the Simplified BSD License. 50 Table of Contents 52 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 53 1.1. Existing solutions . . . . . . . . . . . . . . . . . . . 3 54 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 55 3. Name Resolution . . . . . . . . . . . . . . . . . . . . . . . 4 56 3.1. Configuring Resolvers . . . . . . . . . . . . . . . . . . 4 57 3.2. Configuring Service Discovery . . . . . . . . . . . . . . 5 58 3.3. Resolution of local names . . . . . . . . . . . . . . . . 5 59 3.4. DNSSEC Validation . . . . . . . . . . . . . . . . . . . . 6 60 3.5. Support for Multiple Provisioning Domains . . . . . . . . 6 61 3.6. Using the Local Namespace While Away From Home . . . . . 7 62 4. Management Considerations . . . . . . . . . . . . . . . . . . 7 63 5. Privacy Considerations . . . . . . . . . . . . . . . . . . . 7 64 6. Security Considerations . . . . . . . . . . . . . . . . . . . 8 65 7. IANA considerations . . . . . . . . . . . . . . . . . . . . . 8 66 8. Normative References . . . . . . . . . . . . . . . . . . . . 8 67 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 9 69 1. Introduction 71 Associating domain names with hosts on the Internet is a key factor 72 in enabling communication with hosts, particularly for service 73 discovery. This document describes a simple way of providing name 74 service and service discovery for homenets. In principle, it may 75 make sense to be able to publish names of devices on the homenet, so 76 that services on the homenet can be accessed outside of the homenet. 77 Such publication is out of scope for this document. It may be 78 desirable to secure the homenet zone using DNSSEC. This is likewise 79 out of scope for this document. 81 In order to provide name service, several provisioning mechanisms 82 must be available: 84 o Provisioning of a domain name under which names can be published 85 and services advertised 87 o Associating names that are subdomains of that name with hosts. 89 o Advertising services available on the local network by publishing 90 resource records on those names. 92 o Distribution of names published in that namespace to servers that 93 can be queried in order to resolve names 95 o Correct advertisement of name servers that can be queried in order 96 to resolve names 98 o Timely removal of published names and resource records when they 99 are no longer in use 101 Homenet adds the following considerations: 103 1. Some names may be published in a broader scope than others. For 104 example, it may be desirable to advertise some homenet services 105 to users who are not connected to the homenet. However, it is 106 unlikely that all services published on the home network would be 107 appropriate to publish outside of the home network. In many 108 cases, no services will be appropriate to publish outside of the 109 network, but the ability to do so is required. 111 2. Users cannot be assumed to be skilled or knowledgeable in name 112 service operation, or even to have any sort of mental model of 113 how these functions work. All of the operations mentioned here 114 must reliably function automatically, without any user 115 intervention or debugging. 117 3. Because user intervention cannot be required, naming conflicts 118 must be resolved automatically, and, to the extent possible, 119 transparently. 121 4. Hosts that do not implement any homenet-specific capabilities 122 must still be able to discover and access services on the 123 homenet, to the extent possible. 125 5. Devices that provide services must be able to publish those 126 services on the homenet, and those services must be available 127 from any part of the homenet, not just the link to which the 128 device is attached. 130 6. Homenet explicitly supports multihoming--connecting to more than 131 one Internet Service Provider--and therefore support for multiple 132 provisioning domains [6] is required to deal with situations 133 where the DNS may give a different answer depending on whether 134 caching resolvers at one ISP or another are queried. 136 1.1. Existing solutions 138 Previous attempts to automate naming and service discovery in the 139 context of a home network are able to function with varying degrees 140 of success depending on the topology of the home network. For 141 example, Multicast DNS [4] can provide naming and service discovery 142 [5], but only within a single multicast domain. 144 The Domain Name System provides a hierarchical namespace [1], a 145 mechanism for querying name servers to resolve names [2], a mechanism 146 for updating namespaces by adding and removing names [3], and a 147 mechanism for discovering services [5]. Unfortunately, DNS provides 148 no mechanism for automatically provisioning new namespaces, and 149 secure updates to namespaces require pre-shared keys, which won't 150 work for an unmanaged network. DHCP can be used to populate names in 151 a DNS namespace; however at present DHCP cannot provision service 152 discovery information. 154 Hybrid Multicast DNS [7] proposes a mechanism for extending multicast 155 DNS beyond a single multicast domain.. However, it has serious 156 shortcomings as a solution to the Homenet naming problem. The most 157 obvious shortcoming is that it requires that every multicast domain 158 have a separate name. This then requires that the homenet generate 159 names for every multicast domain, and in degenerate cases requires 160 that the end user have a mental model of the topology of the network 161 in order to guess on which link a given service may appear. 163 2. Terminology 165 This document uses the following terms and abbreviations: 167 HNR Homenet Router 169 ISP Internet Service Provider 171 GNRP Global Name Registration Provider 173 3. Name Resolution 175 3.1. Configuring Resolvers 177 Hosts on the homenet receive a set of resolver IP addresses using 178 either DHCP or RA. IPv4-only hosts will receive IPv4 addresses of 179 resolvers, if available, over DHCP. IPv6-only hosts will receive 180 resolver IPv6 addresses using either stateful (if available) or 181 stateless DHCPv6, or through the domain name option in router 182 advertisements. All homenet routers provide resolver information 183 using both stateless DHCPv6 and RA; support for stateful DHCPv6 and 184 DHCPv4 is optional, however if either service is offered, resolver 185 addresses will be provided using that mechanism as well. Resolver IP 186 addresses will always be IP addresses on the local link: every HNR is 187 required to provide name resolution service. This is necessary to 188 allow DNS update using presence on-link as a mechanism for rejecting 189 off-network attacks. 191 3.2. Configuring Service Discovery 193 DNS-SD uses several default domains for advertising local zones that 194 are available for service discovery. These include the '.local' 195 domain, which is searched using mDNS, and also the IPv4 and IPv6 196 reverse zone corresponding to the prefixes in use on the local 197 network. For the homenet, no support for queries against the 198 ".local" zone is provided by HNRs: a ".local" query will be satisfied 199 or not by services present on the local link. This should not be an 200 issue: all known implementations of DNSSD will do unicast queries 201 using the DNS protocol. 203 Service discovery is configured using the technique described in 204 Section 11 of DNS-Based Service Discovery [5]. HNRs will answer 205 domain enumeration queries against every IPv4 address prefix 206 advertised on a homenet link, and every IPv6 address prefix 207 advertised on a homenet link, including prefixes derived from the 208 homenet's ULA(s). Whenever the "" sequence appears in this 209 section, it references each of the domains mentioned in this 210 paragraph. 212 Homenets advertise the availability of several browsing zones in the 213 "b._dns_sd." subdomain. By default, the 'home.arpa' domain 214 is advertised. Similarly, 'home.arpa' is advertised as the default 215 browsing and service registration domain under "db._dns_sd.", 216 "r._dns_sd.", "dr._dns_sd." and 217 "lb._dns_sd.". 219 3.3. Resolution of local names 221 Local names appear as subdomains of ['home.arpa']. These names can 222 only be resolved within the homenet; not only is ['home.arpa'] not a 223 globally unique name, but queries from outside of the homenet for any 224 name, on or off the homenet, must be rejected with a REFUSED 225 response. 227 In addition, names can appear as subdomains of the locally-served 228 'in-addr.arpa' or 'ip6.addr' zone that corresponding to the RFC1918 229 IPv4 prefix and the IPv6 ULA that is in use on the homenet. IP 230 addresses and names advertised locally MUST use addresses in the 231 homenet's ULA prefix and/or RFC1918 prefix. 233 It is possible that local services may number themselves using more 234 than one of the prefixes advertised locally. Homenet hybrid proxies 235 MUST filter out global IP addresses, providing only ULA addresses, 236 similar to the process described in section 5.5.2 of [7]. [xxx is 237 this going to be a problem?] 238 The Hybrid Proxy model relies on each link having its own name. 239 However, homenets do not actually have a way to name local links that 240 will make any sense to the end user. Consequently, this mechanism 241 will not work without some tweaks. In order to address this, 242 homenets will use Discovery Brokers [11]. The discovery broker will 243 be configured so that a single query for a particular service will be 244 successful in providing the information required to access that 245 service, regardless of the link it is on. 247 Artificial link names will be generated using HNCP. These should 248 only be visible to the user in graphical user interfaces in the event 249 that the same name is claimed by a service on two links. Services 250 that are expected to be accessed by users who type in names should 251 use [12] if it is available. 253 Homenets are not required to support Service Registration. Service 254 registration requires a stateful DNS server; this may be beyond the 255 capability of the minimal homenet router. However, more capable 256 homenet routers should provide this capability. In order to make 257 this work, minimal homenet routers MUST implement the split hybrid 258 proxy described in [13]. This enables a homenet with one or more 259 homenet routers that provide a stateful registration cache to allow 260 those routers to take over service, using Discovery Relays to service 261 links that are connected using homenet routers with more limited 262 functionality. 264 3.4. DNSSEC Validation 266 DNSSEC Validation for the 'home.arpa' zone and for the locally-served 267 'ip6.arpa and 'in-adr.arpa' domains is not possible without a trust 268 anchor. Establishment of a trust anchor for such validation is out 269 of scope for this document. 271 3.5. Support for Multiple Provisioning Domains 273 Homenets must support the Multiple Provisioning Domain Architecture 274 [6]. In order to support this architecture, each homenet router that 275 provides name resolution must provide one resolver for each 276 provisioning domain (PvD). Each homenet router will advertise one 277 resolver IP address for each PvD. DNS requests to the resolver 278 associated with a particular PvD, e.g. using RA options [8] will be 279 resolved using the external resolver(s) provisioned by the service 280 provider responsible for that PvD. 282 The homenet is a separate provisioning domain from any of the service 283 providers. The global name of the homenet can be used as a 284 provisioning domain identifier, if one is configured. Homenets 285 should allow the name of the local provisioning domain to be 286 configured; otherwise by default it should be "Home Network xxx", 287 where xxx is the generated portion of the homenet's ULA prefix, 288 represented as a base64 string. 290 The resolver for the homenet PvD is offered as the primary resolver 291 in RAs and through DHCPv4 and DHCPv6. When queries are made to the 292 homenet-PvD-specific resolver for names that are not local to the 293 homenet, the resolver will use a round-robin technique, alternating 294 between service providers with each step in the round-robin process, 295 and then also between external resolvers at a particular service 296 provider if a service provider provides more than one. The round- 297 robining should be done in such a way that no service provider is 298 preferred, so if service provider A provides one caching resolver 299 (A), and service provider B provides two (B1, B2), the round robin 300 order will be (A, B1, A, B2), not (A, B1, B2). 302 Every resolver provided by the homenet, regardless of which 303 provisioning domain it is intended to serve, will accept updates for 304 subdomains of the 'home.arpa' and locally-served 'ip6.arpa' and 'in- 305 addr.arpa' domains from hosts on the local link. 307 3.6. Using the Local Namespace While Away From Home 309 This architecture does not provide a way for service discovery to be 310 performed on the homenet by devices that are not directly connected 311 to a link that is part of the homenet. 313 4. Management Considerations 315 This architecture is intended to be self-healing, and should not 316 require management. That said, a great deal of debugging and 317 management can be done simply using the DNS service discovery 318 protocol. 320 5. Privacy Considerations 322 Privacy is somewhat protected in the sense that names published on 323 the homenet are only visible to devices connected to the homenet. 324 This may be insufficient privacy in some cases. 326 The privacy of host information on the local net is left to hosts. 327 Various mechanisms are available to hosts to ensure that tracking 328 does not occur if it is not desired. However, devices that need to 329 have special permission to manage the homenet will inevitably reveal 330 something about themselves when doing so. It may be possible to use 331 something like HTTP token binding [9] to mitigate this risk. 333 6. Security Considerations 335 There are some clear issues with the security model described in this 336 document, which will be documented in a future version of this 337 section. A full analysis of the avenues of attack for the security 338 model presented here have not yet been done, and must be done before 339 the document is published. 341 7. IANA considerations 343 This document is relying on the allocation of 'home.arpa' described 344 in Special Use Top Level Domain '.home.arpa' [10]. As such, no new 345 actions are required by IANA, but this document can't proceed until 346 that allocation is done. 348 8. Normative References 350 [1] Mockapetris, P., "Domain names - concepts and facilities", 351 STD 13, RFC 1034, DOI 10.17487/RFC1034, November 1987, 352 . 354 [2] Mockapetris, P., "Domain names - implementation and 355 specification", STD 13, RFC 1035, DOI 10.17487/RFC1035, 356 November 1987, . 358 [3] Vixie, P., Ed., Thomson, S., Rekhter, Y., and J. Bound, 359 "Dynamic Updates in the Domain Name System (DNS UPDATE)", 360 RFC 2136, DOI 10.17487/RFC2136, April 1997, 361 . 363 [4] Cheshire, S. and M. Krochmal, "Multicast DNS", RFC 6762, 364 DOI 10.17487/RFC6762, February 2013, 365 . 367 [5] Cheshire, S. and M. Krochmal, "DNS-Based Service 368 Discovery", RFC 6763, DOI 10.17487/RFC6763, February 2013, 369 . 371 [6] Anipko, D., Ed., "Multiple Provisioning Domain 372 Architecture", RFC 7556, DOI 10.17487/RFC7556, June 2015, 373 . 375 [7] Cheshire, S., "Discovery Proxy for Multicast DNS-Based 376 Service Discovery", draft-ietf-dnssd-hybrid-06 (work in 377 progress), March 2017. 379 [8] Korhonen, J., Krishnan, S., and S. Gundavelli, "Support 380 for multiple provisioning domains in IPv6 Neighbor 381 Discovery Protocol", draft-ietf-mif-mpvd-ndp-support-03 382 (work in progress), February 2016. 384 [9] Popov, A., Nystrom, M., Balfanz, D., Langley, A., and J. 385 Hodges, "Token Binding over HTTP", draft-ietf-tokbind- 386 https-09 (work in progress), April 2017. 388 [10] Pfister, P. and T. Lemon, "Special Use Domain 389 '.home.arpa'", draft-ietf-homenet-dot-07 (work in 390 progress), June 2017. 392 [11] Cheshire, S. and T. Lemon, "Service Discovery Broker", 393 draft-sctl-discovery-broker-00 (work in progress), July 394 2017. 396 [12] Cheshire, S. and T. Lemon, "Service Registration Protocol 397 for DNS-Based Service Discovery", draft-sctl-service- 398 registration-00 (work in progress), July 2017. 400 [13] Cheshire, S. and T. Lemon, "Multicast DNS Discovery 401 Relay", draft-sctl-mdns-relay-00 (work in progress), July 402 2017. 404 Authors' Addresses 406 Ted Lemon 407 Nominum, Inc. 408 800 Bridge Parkway 409 Redwood City, California 94065 410 United States of America 412 Phone: +1 650 381 6000 413 Email: ted.lemon@nominum.com 415 Daniel Migault 416 Ericsson 417 8400 boulevard Decarie 418 Montreal, QC H4P 2N2 419 Canada 421 Email: daniel.migault@ericsson.com