idnits 2.17.1 draft-ietf-homenet-simple-naming-02.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 : ---------------------------------------------------------------------------- == There are 2 instances of lines with private range IPv4 addresses in the document. If these are generic example addresses, they should be changed to use any of the ranges defined in RFC 6890 (or successor): 192.0.2.x, 198.51.100.x or 203.0.113.x. ** 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 285: '... MUST filter out global IP addresses...' RFC 2119 keyword, line 328: '...mal Homenet routers MUST implement the...' RFC 2119 keyword, line 464: '.... However, homenet servers MUST allow...' RFC 2119 keyword, line 467: '... homenet routers MUST NOT answer queri...' RFC 2119 keyword, line 477: '...red with a globally unique domain MUST...' (1 more instance...) 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 2096 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- -- Looks like a reference, but probably isn't: 'RFC7556' on line 178 -- Looks like a reference, but probably isn't: 'CITE' on line 511 == Unused Reference: '8' is defined on line 589, but no explicit reference was found in the text == Unused Reference: '14' is defined on line 615, but no explicit reference was found in the text == Outdated reference: A later version (-10) exists of draft-ietf-dnssd-hybrid-08 == Outdated reference: A later version (-02) exists of draft-sctl-service-registration-00 Summary: 1 error (**), 0 flaws (~~), 6 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group T. Lemon 3 Internet-Draft Nibbhaya Consulting 4 Intended status: Informational D. Migault 5 Expires: January 3, 2019 Ericsson 6 S. Cheshire 7 Apple Inc. 8 July 2, 2018 10 Simple Homenet Naming and Service Discovery Architecture 11 draft-ietf-homenet-simple-naming-02 13 Abstract 15 This document describes how names are published and resolved on 16 homenets, and how hosts are configured to use these names to discover 17 services on homenets. It presents the complete architecture, and 18 describes a simple subset of that architecture that can be used in 19 low-cost homenet routers. 21 Status of This Memo 23 This Internet-Draft is submitted in full conformance with the 24 provisions of BCP 78 and BCP 79. 26 Internet-Drafts are working documents of the Internet Engineering 27 Task Force (IETF). Note that other groups may also distribute 28 working documents as Internet-Drafts. The list of current Internet- 29 Drafts is at https://datatracker.ietf.org/drafts/current/. 31 Internet-Drafts are draft documents valid for a maximum of six months 32 and may be updated, replaced, or obsoleted by other documents at any 33 time. It is inappropriate to use Internet-Drafts as reference 34 material or to cite them other than as "work in progress." 36 This Internet-Draft will expire on January 3, 2019. 38 Copyright Notice 40 Copyright (c) 2018 IETF Trust and the persons identified as the 41 document authors. All rights reserved. 43 This document is subject to BCP 78 and the IETF Trust's Legal 44 Provisions Relating to IETF Documents 45 (https://trustee.ietf.org/license-info) in effect on the date of 46 publication of this document. Please review these documents 47 carefully, as they describe your rights and restrictions with respect 48 to this document. Code Components extracted from this document must 49 include Simplified BSD License text as described in Section 4.e of 50 the Trust Legal Provisions and are provided without warranty as 51 described in the Simplified BSD License. 53 Table of Contents 55 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 56 2. Requirements . . . . . . . . . . . . . . . . . . . . . . . . 3 57 2.1. Managed LAN versus Homenet . . . . . . . . . . . . . . . 4 58 2.2. Homenet-specific considerations . . . . . . . . . . . . . 4 59 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 60 4. Name . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 61 5. Authority . . . . . . . . . . . . . . . . . . . . . . . . . . 6 62 6. Resolution . . . . . . . . . . . . . . . . . . . . . . . . . 7 63 7. Publication . . . . . . . . . . . . . . . . . . . . . . . . . 7 64 7.1. DNS Service Discovery Registration Protocol . . . . . . . 7 65 7.2. Configuring Service Discovery . . . . . . . . . . . . . . 8 66 8. Host Configurtion . . . . . . . . . . . . . . . . . . . . . . 10 67 9. Globally Unique Name . . . . . . . . . . . . . . . . . . . . 10 68 10. DNSSEC Validation . . . . . . . . . . . . . . . . . . . . . . 10 69 11. Support for Multiple Provisioning Domains . . . . . . . . . . 11 70 12. Using the Local Namespace While Away From Home . . . . . . . 11 71 13. Management Considerations . . . . . . . . . . . . . . . . . . 11 72 14. Privacy Considerations . . . . . . . . . . . . . . . . . . . 12 73 15. Security Considerations . . . . . . . . . . . . . . . . . . . 12 74 16. IANA considerations . . . . . . . . . . . . . . . . . . . . . 12 75 17. Normative References . . . . . . . . . . . . . . . . . . . . 12 76 Appendix A. Existing solutions . . . . . . . . . . . . . . . . . 14 77 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 15 79 1. Introduction 81 This document is a homenet architecture document. The term 'homenet' 82 refers to a set of technologies that allow home network users to have 83 a local-area network (LAN) with more than one physical link and, 84 optionally, more than one internet service provider. Home network 85 users are assumed not to be knowledgable in network operations, so 86 homenets automatically configure themselves, providing connectivity 87 and service discovery within the home with no operator intervention. 88 This document describes the aspect of homenet automatic configuration 89 that has to do with service discovery and name resolution. 91 The homenet naming architecture consists of two parts: the simple 92 naming architecture, and the advanced naming architecture. The 93 advanced architecture provides approximate parity of features with a 94 managed network, including the ability to publish services on the 95 internet. The simple architecture provides a minimal set of features 96 required to enable seamless service discovery on a multi-link home 97 network, but does not attempt to provide feature parity with a 98 managed LAN. 100 This document begins by presenting a motivational list of 101 requirements and considerations, which should give the reader a clear 102 idea of the scope of the problem being solved. It then explains how 103 each requirement is addressed, and provides references for relevant 104 standards documents describing the details of the implementation. 105 Some requirements are not satisfied by the simple architecture; these 106 are discussed in this document, but explained in more detail in the 107 Advanced Homenet Naming Architecture document, which is to follow. 109 2. Requirements 111 Name service on a local area network (LAN) requires the following: 113 o Name: a forward domain under which information about local 114 services will be published 116 o Authority: a name server that is authoritative for at least one 117 forward domain and one or two reverse domains that are applicable 118 to that network and is capable of signing and publishing the zones 119 using DNSSEC 121 o Resolution: a full-service caching DNS resolver that fully 122 supports EDNS(0) and queries with the DO bit set 124 o Publication: a mechanism that 126 * allows services on the LAN to publish information about the 127 services they provide 129 * allows services to publish information on how to reach them 131 * manages the lifetime of such information, so that it persists 132 long enough to prevent spoofing, but protects end users from 133 seeing stale information 135 o Host configuration: one or more automatic mechanisms (e.g. DHCP 136 or RA) that provide: 138 * caching resolver information to hosts on the LAN 140 * information about how services on the LAN can publish 141 information 143 o Trust: some basis for trusting the information that is provided by 144 the service discovery system 146 2.1. Managed LAN versus Homenet 148 A managed network is one that has a (human) manager, or operator. 149 The operator has authority over the network, and the authority to 150 publish names in a forward DNS tree, and reverse names in the reverse 151 tree. The operator has the authority to sign the respective trees 152 with DNSSEC, and acquire TLS certificates for hosts/servers within 153 the network. 155 On a managed LAN, many of these services can be provided by 156 operators. When a new printer is added to the network, it can be 157 added to the service discovery system (the authoritative server) 158 manually. When a printer is taken out of service, it can be removed. 159 In this scenario, the role of "publisher" is filled by the network 160 operator. 162 In many managed LANs, establishment of trust for service discovery is 163 simply on the basis of a belief that the local resolver will give a 164 correct answer. Once the service has been discovered and chosen, 165 there may be some security (e.g., TLS) that protects the connection 166 to the service, but the trust model is often just "you're connected 167 to a network you trust, so you can trust the printer that you 168 discovered on this network." 170 A homenet does not have an operator, so functions that would normally 171 be performed by the operator have to happen automatically. This has 172 implications for trust establishment--since there is no operator 173 controlling what services are published locally, some other mechanism 174 is required for basic trust establishment. Additionally, whereas in 175 a managed LAN with multiple links to the Internet, the network 176 operator can configure the network so that multihoming is handled 177 seamlessly, in a homenet, multihoming must be handled using multiple 178 provisioning domains [RFC7556]. 180 2.2. Homenet-specific considerations 182 A naming architecture for homenets therefore adds the following 183 considerations: 185 o All of the operations mentioned here must reliably function 186 automatically, without any user intervention or debugging. 188 o Because user intervention cannot be required, naming conflicts 189 must be resolved automatically, and, to the extent possible, 190 transparently. 192 o Devices that provide services must be able to publish those 193 services on the homenet, and those services must be available from 194 any part of the homenet, not just the link to which the device is 195 attached. 197 o Homenets must address the problem of multiple provisioning 198 domains, in the sense that the DNS may give a different answer 199 depending on whether caching resolvers at one ISP or another are 200 queried. 202 An additional requirement from the Homenet Architecture [9] is that 203 hosts are not required to implement any homenet-specific capabilities 204 in order to discover and access services on the homenet. This 205 architecture may define optional homenet-specific features, but hosts 206 that do not implement these features must work on homenets. 208 3. Terminology 210 This document uses the following terms and abbreviations: 212 HNR Homenet Router 214 SHNR Homenet Router implementing simple homenet naming architecture 216 AHNR Homenet Router implementing advanced homenet naming 217 architecture 219 ISP Internet Service Provider 221 4. Name 223 In order for names to be published on a homenet, it is necessary that 224 there be a set of domain names under which such names are published. 225 These domain names, together, are referred to as the "local domains." 226 By default, homenets use the reserved domain 'home.arpa.' for 227 publishing names for forward lookups. So a host called 'example' 228 that published its name on the homenet would publish its records on 229 the domain name 'example.home.arpa.'. Because 'home.arpa.' is used 230 by all homenets, it has no global meaning, and names published under 231 the domain 'home.arpa' cannot be used outside of the homenet on which 232 they are published. 234 Homenet routers that implement advanced homenet naming may also be 235 configured with a global domain. How such a domain is configured is 236 out of scope for this document, and is described in the Advanced 237 Homenet Naming Architecture document [advanced]. 239 In addition to the name, which defaults to 'home.arpa.', names are 240 needed for reverse lookups. These names are dependent on the IP 241 addressing used on the homenet. If the homenet is addressed with 242 IPv4, a reverse domain corresponding to the IPv4 subnet [1] section 243 5.2.1 should be constructed. For example, if the homenet is 244 allocating local IP addresses out of net 10 [3], a domain, '10.in- 245 addr.arpa' would be required. Like 'home.arpa.', '10.in-addr.arpa' 246 is a locally-served zone, and has no validity outside of the homenet. 248 If the homenet is addressed with IPv6, it is expected to have a 249 unique local address prefix; subsets of this prefix will be 250 advertised on every link on the homenet. Every service on the 251 homenet that supports IPv6 is expected to be reachable at an address 252 that is configured using the ULA prefix. Therefore there is no need 253 for any IPv6 reverse zone to be populated other than the ULA zone. 254 So for example if the homenet's ULA prefix is fd00:2001:db8::/48, 255 then the reverse domain name for the homenet would end in 256 '8.b.d.0.1.0.0.2.0.0.d.f.ip6.arpa'. 258 5. Authority 260 The authority role is provided by a name server that is authoritative 261 for each of the local domains. SHNRs provide authoritative service 262 for the homenet using DNSSD Discovery Broker [17]. SHNRs also 263 provide Discovery Relay service [12]. On a homenet that has only 264 SHNRs, each SHNR individually provides authoritative service for the 265 whole homenet by using Discovery relays to discover services off the 266 local link. 268 The Discovery Proxy model relies on each link having its own name. 269 However, homenets do not actually have a way to name local links that 270 will make any sense to the end user. Consequently, this mechanism 271 will not work without some tweaks. In order to address this, 272 homenets will use Discovery Brokers [17]. The discovery broker will 273 be configured so that a single query for a particular service will be 274 successful in providing the information required to access that 275 service, regardless of the link it is on. 277 Artificial link names will be generated using HNCP. These should 278 only be visible to the user in graphical user interfaces in the event 279 that the same name is claimed by a service on two links. Services 280 that are expected to be accessed by users who type in names should 281 use [13] if it is available. 283 It is possible that local services may offer services available on IP 284 addresses in public as well as ULA prefixes. Homenet hybrid proxies 285 MUST filter out global IP addresses, providing only ULA addresses, 286 similar to the process described in section 5.5.2 of [11]. 288 This filtering applies to queries within the homenet; it is 289 appropriate for non-ULA addresses to be used for offering services, 290 because in some cases end users may want such services to be 291 reachable outside of the homenet. Configuring this is however out of 292 scope for this document. 294 6. Resolution 296 Name resolution is provided by a local DNS cache or proxy on the 297 homenet, henceforth the "local resolver." All host queries are sent 298 to this local resolver. The local resolver may either act as a full- 299 service caching resolver, or as a DNS proxy. Its responsibility with 300 respect to queries on the homenet is to notice queries for names for 301 which the local authoritative server is authoritative. Queries for 302 such names are handled through the local authoritative server. 303 Queries for all other names are resolved either by forwarding them to 304 an ISP-provided full service resolver, or by providing the full 305 service resolver function locally. 307 7. Publication 309 7.1. DNS Service Discovery Registration Protocol 311 The DNSSD Service Registration protocol [13] requires that DNS 312 updates be validated on the basis that they are received on the local 313 link. To ensure that such registrations are actually received on 314 local links in the homenet, updates are sent to the local relay proxy 315 ([12]) (XXX how?). 317 The relay proxy encapsulates the update and sends it to whatever 318 Discovery Proxy is listening on the link; the Discovery proxy then 319 either consumes the update directly, or forwards it to the 320 authoritative resolver for the local service discovery zone. If the 321 registration protocol is not supported on the homenet, the Discovery 322 Proxy rejects the update with a ??? RCODE. 324 Homenets are not required to support Service Registration. Service 325 registration requires a stateful authoritative DNS server; this may 326 be beyond the capability of the minimal Homenet router. However, 327 more capable Homenet routers should provide this capability. In 328 order to make this work, minimal Homenet routers MUST implement the 329 split hybrid proxy [12]. This enables a Homenet with one or more 330 Homenet routers that provide a stateful registration cache to allow 331 those routers to take over service, using Discovery Relays to service 332 links that are connected using Homenet routers with more limited 333 functionality. 335 7.2. Configuring Service Discovery 337 Clients discovering services using DNS-SD [7] follow a two-step 338 process. The first step is for the client device to determine in 339 which domain(s) to attempt to discover services. The second step is 340 for the client device to then seek desired service(s) in those 341 domain(s). For an example of the second step, given the desired 342 service type "IPP Printing", and the domains "local" and 343 "meeting.ietf.org", the client device forms the queries 344 "_ipp._tcp.local. PTR ?" (resolved using Multicast DNS) and 345 "_ipp._tcp.meeting.ietf.org PTR. ?" (resolved using Unicast DNS) and 346 then presents the combined list of results to the user. 348 The first step, determining in which domain(s) to attempt to discover 349 services, is performed in a variety of ways, as described in 350 Section 11 of the DNS-Based Service Discovery specification [7]. 352 The domain "local" is generally always in the set of domains in which 353 the client devices attempt to discover services, and other domains 354 for service discovery may be configured manually by the user. 356 The device also learns additional domains automatically from its 357 network environment. For this automatic configuration discovery, 358 special DNS queries are formulated. To learn additional domain(s) in 359 which to attempt to discover services, the query string 360 "lb._dns_sd._udp" is prepended onto three different kinds of 361 "bootstrap domain" to form DNS queries that allow the device to learn 362 the configuration information. 364 One of these bootstrap domains is the fixed string "local". The 365 device issues the query "lb._dns_sd._udp.local. PTR ?" (resolved 366 using Multicast DNS), and if any answers are received, then they are 367 added to the set of domains in which the client devices attempt to 368 discover services. 370 Another kind of these bootstrap domains is name-based, derived from 371 the DHCPv4 "domain name" option (code 15) [4] (for IPv4) or the DNS 372 Search List (DNSSL) Router Advertisement option [10] (for IPv6). If 373 a domain in the DNSSL is "example.com", then the device issues the 374 query "lb._dns_sd._udp.example.com. PTR ?" (resolved using Unicast 375 DNS), and if any answers are received, then they are likewise added 376 to the set of domains in which the client devices attempt to discover 377 services. 379 Finally, the third kind of bootstrap domain is address-based, derived 380 from the device's IP address(es) themselves. If the device has IP 381 address 192.168.1.100/24, then the device issues the query 382 "lb._dns_sd._udp.0.1.168.192.in-addr.arpa. PTR ?" (resolved using 383 Unicast DNS), and if any answers are received, then they are also 384 added to the set of domains in which the client devices attempt to 385 discover services. 387 Since there is an HNR on every link of a homenet, automatic 388 configuration could be performed by having HNRs answer the 389 "lb._dns_sd._udp.local. PTR ?" (Multicast DNS) queries. However, 390 because multicast is slow and unreliable on many modern network 391 technologies like Wi-Fi, we prefer to avoid using it. Instead we 392 require that a homenet be configured to answer the name-based 393 bootstrap queries. By default the domain in the DNSSL communicated 394 to the client devices will be "home.arpa", and the homenet will be 395 configured to correctly answer queries such as 396 "lb._dns_sd._udp.example.com. PTR ?", though client devices must not 397 assume that the name will always be "home.arpa". A client could be 398 configured with any valid DNSSL, and should construct the appropriate 399 bootstrap queries derived from the name(s) in their configured DNS 400 Search List. 402 HNRs will answer domain enumeration queries against every IPv4 403 address prefix advertised on a homenet link, and every IPv6 address 404 prefix advertised on a homenet link, including prefixes derived from 405 the homenet's ULA(s). Whenever the "" sequence appears in 406 this section, it references each of the domains mentioned in this 407 paragraph. 409 Homenets advertise the availability of several browsing zones in the 410 "b._dns_sd._udp." subdomain. By default, the 'home.arpa' 411 domain is advertised. Similarly, 'home.arpa' is advertised as the 412 default browsing and service registration domain under 413 "db._dns_sd._udp.", "r._dns_sd._udp.", 414 "dr._dns_sd._udp." and "lb._dns_sd._udp.". 416 In order for this discovery process to work, the homenet must provide 417 authoritative answers for each of the domains that might be queried. 418 To do this, it provides authoritative name service for the 'ip6.arpa' 419 and 'in-addr.arpa' subdomains corresponding to each of the prefixes 420 advertised on the homenet. For example, consider a homenet with the 421 192.168.1.0/24, 2001:db8:1234:5600::/56 and fc01:2345:6789:1000::/56 422 prefixes. This homenet will have to provide a name server that 423 claims to be authoritative for 1.168.192.in-addr.arpa, 424 6.5.4.3.2.1.8.b.d.0.1.0.0.2.ip6.arpa and 425 0.0.9.8.7.6.5.4.3.2.1.0.c.f.ip6.arpa. 427 An IPv6-only homenet would not have an authoritative server for a 428 subdomain of in-addr.arpa. These public authoritative zones are 429 required for the public prefixes even if the prefixes are not 430 delegated. However, they need not be accessible outside of the 431 homenet. 433 It is out of the scope of this document to specify ISP behavior, but 434 we note that ISPs have the option of securely delegating the zone, or 435 providing an unsigned delegation, or providing no delegation. Any 436 delegation tree that does not include an unsigned delegation at or 437 above the zone cut for the ip6.arpa reverse zone for the assigned 438 prefix will fail to validate. 440 Ideally, an ISP should provide a secure delegation using a zone- 441 signing key provided by the homenet. However, that too is out of 442 scope for this document. Therefore, an ISP that wishes to support 443 users of the simple homenet naming architecture will have to provide 444 an unsigned delegation. We do not wish, however, to discourage 445 provisioning of signed delegations when that is possible. 447 8. Host Configurtion 449 Hosts on the homenet receive a set of resolver IP addresses using 450 either DHCP or RA. IPv4-only hosts will receive IPv4 addresses of 451 resolvers, if available, over DHCP. IPv6-only hosts will receive 452 resolver IPv6 addresses using either stateful (if available) or 453 stateless DHCPv6, or through the Recursive DNS Server Option ([10], 454 Section 5.1) in router advertisements. 456 All Homenet routers provide resolver information using both stateless 457 DHCPv6 and RA; support for stateful DHCPv6 and DHCPv4 is optional, 458 however if either service is offered, resolver addresses will be 459 provided using that mechanism as well. 461 9. Globally Unique Name 463 Automatic configuration of a globally unique name for the homenet is 464 out of scope for this document. However, homenet servers MUST allow 465 the user to configure a globally unique name in place of the default 466 name, 'home.arpa.' By default, even if configured with a global 467 name, homenet routers MUST NOT answer queries from outside of the 468 homenet for subdomains of that name. 470 10. DNSSEC Validation 472 DNSSEC Validation for the 'home.arpa' zone and for the locally-served 473 'ip6.arpa and 'in-adr.arpa' domains is not possible without a trust 474 anchor. Establishment of a trust anchor for such validation is out 475 of scope for this document. 477 Homenets that have been configured with a globally unique domain MUST 478 support DNSSEC signing of local names, and must provide a way to 479 generate a KSK that can be used in the secure delegation of the 480 globally unique domain assigned to the homenet. 482 11. Support for Multiple Provisioning Domains 484 Homenets must support the Multiple Provisioning Domain Architecture 485 [9]. Hosts connected to the homenet may or may not support multiple 486 provisioning domains. For hosts that do not support multiple 487 provisioning domains, the homenet provides one or more resolvers that 488 will answer queries for any provisioning domain. Such hosts may 489 receive answers to queries that either do not work as well if the 490 host chooses a source address from a different provisioning domain, 491 or does not work at all. However, the default source address 492 selection policy, longest-match [CITE], will result in the correct 493 source address being chosen as long as the destination address has a 494 close match to the prefix assigned by the ISP. 496 Hosts that support multiple provisioning domains will be provisioned 497 with one or more resolvers per provisioning domain. Such hosts can 498 use the IP address of the resolver to determine which provisioning 499 domain is applicable for a particular answer. 501 Each ISP has its own provisioning domain. Because ISPs connections 502 cannot be assumed to be persistent, the homenet has its own separate 503 provisioning domain. 505 Configuration from the IPv4 DHCP server are treated as being part of 506 the homenet provisioning domain. The case where a homenet advertises 507 IPv4 addresses from one or more public prefixes is out of scope for 508 this document. Such a configuration is NOT RECOMMENDED for homenets. 510 Configuration for IPv6 provisioning domains is done using the 511 Multiple Provisioning Domain RA option [CITE]. 513 12. Using the Local Namespace While Away From Home 515 This architecture does not provide a way for service discovery to be 516 performed on the homenet by devices that are not directly connected 517 to a link that is part of the homenet. 519 13. Management Considerations 521 This architecture is intended to be self-healing, and should not 522 require management. That said, a great deal of debugging and 523 management can be done simply using the DNS Service Discovery 524 protocol. 526 14. Privacy Considerations 528 Privacy is somewhat protected in the sense that names published on 529 the homenet are only visible to devices connected to the homenet. 530 This may be insufficient privacy in some cases. 532 The privacy of host information on the homenet is left to hosts. 533 Various mechanisms are available to hosts to ensure that tracking 534 does not occur if it is not desired. However, devices that need to 535 have special permission to manage the homenet will inevitably reveal 536 something about themselves when doing so. It may be possible to use 537 something like HTTP token binding [15] to mitigate this risk. 539 15. Security Considerations 541 There are some clear issues with the security model described in this 542 document, which will be documented in a future version of this 543 section. A full analysis of the avenues of attack for the security 544 model presented here have not yet been done, and must be done before 545 the document is published. 547 16. IANA considerations 549 No new actions are required by IANA for this document. 551 Note however that this document is relying on the allocation of 552 'home.arpa' described in Special Use Top Level Domain '.home.arpa' 553 [16]. This document therefore can't proceed until that allocation is 554 done. [RFC EDITOR PLEASE REMOVE THIS PARAGRAPH PRIOR TO 555 PUBLICATION]. 557 17. Normative References 559 [1] Mockapetris, P., "Domain names - concepts and facilities", 560 STD 13, RFC 1034, DOI 10.17487/RFC1034, November 1987, 561 . 563 [2] Mockapetris, P., "Domain names - implementation and 564 specification", STD 13, RFC 1035, DOI 10.17487/RFC1035, 565 November 1987, . 567 [3] Rekhter, Y., Moskowitz, B., Karrenberg, D., de Groot, G., 568 and E. Lear, "Address Allocation for Private Internets", 569 BCP 5, RFC 1918, DOI 10.17487/RFC1918, February 1996, 570 . 572 [4] Alexander, S. and R. Droms, "DHCP Options and BOOTP Vendor 573 Extensions", RFC 2132, DOI 10.17487/RFC2132, March 1997, 574 . 576 [5] Vixie, P., Ed., Thomson, S., Rekhter, Y., and J. Bound, 577 "Dynamic Updates in the Domain Name System (DNS UPDATE)", 578 RFC 2136, DOI 10.17487/RFC2136, April 1997, 579 . 581 [6] Cheshire, S. and M. Krochmal, "Multicast DNS", RFC 6762, 582 DOI 10.17487/RFC6762, February 2013, 583 . 585 [7] Cheshire, S. and M. Krochmal, "DNS-Based Service 586 Discovery", RFC 6763, DOI 10.17487/RFC6763, February 2013, 587 . 589 [8] Chown, T., Ed., Arkko, J., Brandt, A., Troan, O., and J. 590 Weil, "IPv6 Home Networking Architecture Principles", 591 RFC 7368, DOI 10.17487/RFC7368, October 2014, 592 . 594 [9] Anipko, D., Ed., "Multiple Provisioning Domain 595 Architecture", RFC 7556, DOI 10.17487/RFC7556, June 2015, 596 . 598 [10] Jeong, J., Park, S., Beloeil, L., and S. Madanapalli, 599 "IPv6 Router Advertisement Options for DNS Configuration", 600 RFC 8106, DOI 10.17487/RFC8106, March 2017, 601 . 603 [11] Cheshire, S., "Discovery Proxy for Multicast DNS-Based 604 Service Discovery", draft-ietf-dnssd-hybrid-08 (work in 605 progress), March 2018. 607 [12] Cheshire, S. and T. Lemon, "Multicast DNS Discovery 608 Relay", draft-sctl-dnssd-mdns-relay-04 (work in progress), 609 March 2018. 611 [13] Cheshire, S. and T. Lemon, "Service Registration Protocol 612 for DNS-Based Service Discovery", draft-sctl-service- 613 registration-00 (work in progress), July 2017. 615 [14] Korhonen, J., Krishnan, S., and S. Gundavelli, "Support 616 for multiple provisioning domains in IPv6 Neighbor 617 Discovery Protocol", draft-ietf-mif-mpvd-ndp-support-03 618 (work in progress), February 2016. 620 [15] Popov, A., Nystrom, M., Balfanz, D., Langley, A., Harper, 621 N., and J. Hodges, "Token Binding over HTTP", draft-ietf- 622 tokbind-https-18 (work in progress), June 2018. 624 [16] Pfister, P. and T. Lemon, "Special Use Domain 625 'home.arpa.'", draft-ietf-homenet-dot-14 (work in 626 progress), September 2017. 628 [17] Cheshire, S. and T. Lemon, "Service Discovery Broker", 629 draft-sctl-discovery-broker-00 (work in progress), July 630 2017. 632 Appendix A. Existing solutions 634 Previous attempts to automate naming and service discovery in the 635 context of a home network are able to function with varying degrees 636 of success depending on the topology of the home network. 637 Unfortunately, these solutions do not fully address the requirements 638 of homenets. 640 For example, Multicast DNS [6] can provide naming and service 641 discovery [7], but only within a single multicast domain. 643 The Domain Name System provides a hierarchical namespace [1], a 644 mechanism for querying name servers to resolve names [2], a mechanism 645 for updating namespaces by adding and removing names [5], and a 646 mechanism for discovering services [7]. Unfortunately, DNS provides 647 no mechanism for automatically provisioning new namespaces, and 648 secure updates to namespaces require that the host submitting the 649 update have a public or symmetric key that is known to the network 650 and authorized for updates. In an unmanaged network, the publication 651 of and authorization of these keys is an unsolved problem. 653 Some managed networks get around this problem by having the DHCP 654 server do DNS updates. However, this doesn't really work, because 655 DHCP doesn't provide a mechanism for updating service discovery 656 records: it only supports publishing A and AAAA records. 658 This partially solves the trust problem: DHCP can validate that a 659 device is at least connected to a network link that is actually part 660 of the managed network. This prevents an off-network attacker from 661 registering a name, but provides no mechanism for actually validating 662 the identity of the host registering the name. For example, it would 663 be easy for an attacker on the network to steal a registered name. 665 Hybrid Multicast DNS [11] proposes a mechanism for extending 666 multicast DNS beyond a single multicast domain. However, in order to 667 use this as a solution, some shortcomings need to be considered. 669 Most obviously, it requires that every multicast domain have a 670 separate name. This then requires that the homenet generate names 671 for every multicast domain. These names would then be revealed to 672 the end user. But since they would be generated automatically and 673 arbitrarily, they would likely cause confusion rather than clarity, 674 and in degenerate cases requires that the end user have a mental 675 model of the topology of the network in order to guess on which link 676 a given service may appear. 678 At present, the approach we intend to take with respect to 679 disambiguation is that this will not be solved at a protocol level 680 for devices that do not implement the registration protocol. 682 Authors' Addresses 684 Ted Lemon 685 Nibbhaya Consulting 686 P.O. Box 958 687 Brattleboro, Vermont 05301 688 United States of America 690 Email: mellon@fugue.com 692 Daniel Migault 693 Ericsson 694 8400 boulevard Decarie 695 Montreal, QC H4P 2N2 696 Canada 698 Email: daniel.migault@ericsson.com 700 Stuart Cheshire 701 Apple Inc. 702 1 Infinite Loop 703 Cupertino, California 95014 704 USA 706 Phone: +1 408 974 3207 707 Email: cheshire@apple.com