idnits 2.17.1 draft-lemon-homenet-naming-architecture-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 : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (March 21, 2016) is 2950 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- -- Looks like a reference, but probably isn't: 'TBD1' on line 799 -- Looks like a reference, but probably isn't: 'TBD2' on line 799 -- Looks like a reference, but probably isn't: 'GNRP' on line 708 == Outdated reference: A later version (-10) exists of draft-ietf-dnssd-hybrid-03 Summary: 0 errors (**), 0 flaws (~~), 2 warnings (==), 4 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 March 21, 2016 5 Expires: September 22, 2016 7 Homenet Naming and Service Discovery Architecture 8 draft-lemon-homenet-naming-architecture-00 10 Abstract 12 This document recommends a naming and service discovery resolution 13 architecture for homenets. This architecture covers the publication 14 and resolution of names of hosts on the homenet both within the 15 homenet and on the public internet, and the use of such names for 16 offering and discovering services that exist on the homenet both 17 within the homenet and on the public internet. Security and privacy 18 implications and techniques for automatically and administratively 19 setting security and privacy policies for such names are also 20 described. 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 September 22, 2016. 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 . . . . . . . . . . . . . . . . . . . . . . . . 3 57 1.1. Existing solutions . . . . . . . . . . . . . . . . . . . 4 58 2. Homenet Naming Database . . . . . . . . . . . . . . . . . . . 5 59 2.1. Global Name . . . . . . . . . . . . . . . . . . . . . . . 5 60 2.2. Local namespaces . . . . . . . . . . . . . . . . . . . . 7 61 2.3. Public namespaces . . . . . . . . . . . . . . . . . . . . 7 62 2.4. Adding Names . . . . . . . . . . . . . . . . . . . . . . 8 63 2.4.1. mDNS Snooping . . . . . . . . . . . . . . . . . . . . 8 64 2.4.2. DHCP DNS Update (stateful or stateless) . . . . . . . 9 65 2.4.3. DNS Update . . . . . . . . . . . . . . . . . . . . . 9 66 2.5. Removing Names . . . . . . . . . . . . . . . . . . . . . 9 67 2.6. Name Collisions . . . . . . . . . . . . . . . . . . . . . 10 68 2.7. Recovery from loss . . . . . . . . . . . . . . . . . . . 10 69 2.8. Persistence . . . . . . . . . . . . . . . . . . . . . . . 10 70 2.9. Well-known names . . . . . . . . . . . . . . . . . . . . 11 71 3. Name Resolution . . . . . . . . . . . . . . . . . . . . . . . 11 72 3.1. Configuring Resolvers . . . . . . . . . . . . . . . . . . 11 73 3.2. Configuring Service Discovery . . . . . . . . . . . . . . 12 74 3.3. Resolution of local namespaces . . . . . . . . . . . . . 12 75 3.4. Local and Public Zones . . . . . . . . . . . . . . . . . 12 76 3.5. Legacy support . . . . . . . . . . . . . . . . . . . . . 13 77 3.6. DNSSEC Validation . . . . . . . . . . . . . . . . . . . . 13 78 3.7. Support for Multiple Provisioning Domains . . . . . . . . 14 79 3.8. Using the Local Namespace While Away From Home . . . . . 14 80 4. Publishing the Public Namespace . . . . . . . . . . . . . . . 15 81 4.1. Acquiring the Global Name . . . . . . . . . . . . . . . . 15 82 4.2. Hidden Primary/Public Secondaries . . . . . . . . . . . . 16 83 4.3. DNSSEC security . . . . . . . . . . . . . . . . . . . . . 17 84 4.4. PKI security . . . . . . . . . . . . . . . . . . . . . . 17 85 4.5. Renumbering . . . . . . . . . . . . . . . . . . . . . . . 18 86 4.6. ULA . . . . . . . . . . . . . . . . . . . . . . . . . . . 18 87 5. Management . . . . . . . . . . . . . . . . . . . . . . . . . 18 88 5.1. End-user management . . . . . . . . . . . . . . . . . . . 18 89 5.2. Central management . . . . . . . . . . . . . . . . . . . 19 90 6. Privacy Considerations . . . . . . . . . . . . . . . . . . . 19 91 7. Security Considerations . . . . . . . . . . . . . . . . . . . 19 92 8. IANA considerations . . . . . . . . . . . . . . . . . . . . . 19 93 9. Normative References . . . . . . . . . . . . . . . . . . . . 20 94 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 20 96 1. Introduction 98 Associating domain names with hosts on the Internet is a key factor 99 in enabling communication with hosts, particularly service discovery. 100 In order to provide name service, several provisioning mechanisms 101 must be available: 103 o Provisioning of a namespace in which names can be published and 104 services advertised 106 o Associating a name within that namespace to the set of IP 107 addresses on which a host is reachable 109 o Advertising services available on the local network and 110 associating those services with names published in the namespace 112 o Distribution of names published in that namespace to servers that 113 can be queried in order to resolve names 115 o Correct advertisement of name servers that can be queried in order 116 to resolve names 118 o Timely removal of published names when they are no longer in use 120 Homenet adds the following considerations: 122 1. Some names may be published in a broader scope than others. For 123 example, it may be desirable to advertise some homenet services 124 to users who are not connected to the homenet. However, it is 125 unlikely that all services published on the home network would be 126 appropriate to publish outside of the home network. In many 127 cases, no services will be appropriate to publish outside of the 128 network, but the ability to do so is required. 130 2. Users cannot be assumed to be skilled or knowledgeable in name 131 service operation, or even to have any sort of mental model of 132 how these functions work. With the possible exception of policy 133 decisions, all of the operations mentioned here must reliably 134 function automatically, without any user intervention or 135 debugging. Even to the extent that users may provide input on 136 policy, such as whether a service should or should not be 137 advertised outside of the home, the user must be able to safely 138 provide such input without having a correct mental model of how 139 naming and service discovery work, and without being able to 140 reason about security in a nuanced way. 142 3. Because user intervention cannot be required, naming conflicts 143 must be resolved automatically, and, to the extent possible, 144 transparently. 146 4. Where services are advertised both on and off the home network, 147 differences in naming conventions that may vary depending on the 148 user's location must likewise be transparent to the end user. 150 5. Hosts that do not implement any homenet-specific capabilities 151 must still be able to discover and access services on the 152 homenet, to the extent possible. 154 6. Homenet explicitly supports multihoming--connecting to more than 155 one Internet Service Provider--and therefore support for multiple 156 provisioning domains [6] is required to deal with situations 157 where the DNS may give a different answer depending on whether 158 caching resolvers at one ISP or another are queried. 160 7. Multihomed homenets may treat all service provider links as 161 equivalent, or may treat some links as primary and some as 162 backup, either because of differing transit costs or differing 163 performance. Services advertised off-network may therefore be 164 advertised for some links and not others. 166 In addition to these considerations, there may be a need to provide 167 for secure communication between end users and the user interface of 168 the home network, as well as to provide secure name validation (e.g., 169 DNSSEC). Secure communications require that the entity being secured 170 have a name that is unique and can be cryptographically authenticated 171 within the scope of use of all devices that must communicate with 172 that entity. Because it is very likely that devices connecting to 173 one homenet will be sufficiently portable that they may connect to 174 many homenets, the scope of use must be assumed to be global. 175 Therefore, each homenet must have a globally unique name. 177 1.1. Existing solutions 179 Previous attempts to automate naming and service discovery in the 180 context of a home network are able to function with varying degrees 181 of success depending on the topology of the home network. For 182 example, Multicast DNS [4] can provide naming and service discovery 183 [5], but only within a single multicast domain. 185 The Domain Name System provides a hierarchical namespace [1], a 186 mechanism for querying name servers to resolve names [2], a mechanism 187 for updating namespaces by adding and removing names [3], and a 188 mechanism for discovering services [5]. Unfortunately, DNS provides 189 no mechanism for automatically provisioning new namespaces, and 190 secure updates to namespaces require pre-shared keys, which won't 191 work for an unmanaged network. DHCP can be used to populate names in 192 a DNS namespace; however at present DHCP cannot provision service 193 discovery information. 195 Hybrid Multicast DNS [7] proposes a mechanism for solving the single- 196 multicast-domain problem. However, it has serious shortcomings as a 197 solution to the Homenet naming problem. The most obvious shortcoming 198 is that it requires that every multicast domain have a separate name. 199 This then requires that the homenet generate names for every 200 multicast domain, and requires that the end user have a mental model 201 of the topology of the network in order to guess on which link a 202 given service may appear. 204 2. Homenet Naming Database 206 In order to resolve names, there must be a place where names are 207 stored. There are two ways to go about this: either names are stored 208 on the devices that own them, or they are stored in the network. 209 This isn't a clean dichotomy, however: it's possible for the source 210 of truth about a name to be owned by the device, while the resolution 211 of the name is owned by a service separate from the device. 212 Additionally, if names are owned by devices, conflicts can arise, 213 since two devices might present the same name by default or by 214 accident. Further, devices can be attached to more than one network, 215 in which case we want the same name to identify them on both 216 networks. Additionally, although homenets are self-configuring, user 217 customization is permitted and useful. 219 In order to achieve this, the Homenet Naming Database (HNDB) provides 220 a persistent central store into which names can be registered 222 2.1. Global Name 224 Every homenet must be able to have a name in the global DNS hierarchy 225 which serves as the root of the zone in which the homenet publishes 226 its public namespaces. Homenets that do not yet have a name in the 227 global namespace use the homenet special-use TLD [TBD1] as their 228 "global name" until they are configured with a global name. 230 [It's tempting to have the homenet generate a UUID-like name that can 231 be used as a global name, but we really don't want that, because it 232 will be quite ugly to the user, difficult to remember, and therefore 233 not protective against the kinds of mistakes we'd want such a name to 234 protect against. It's better as a security UI to have the user see a 235 name that is the same on all homenets. This will allow the user to 236 fairly easily notice that they see the same name on every homenet. 237 To present a name that isn't really unique and isn't easily 238 identified as anything other than "random gibberish," may lull the 239 end user into a sense that they are talking to the right homenet when 240 they see the random gibberish, without realizing that actually it's 241 different gibberish and they aren't talking to their own homenet.] 243 A homenet's global name can be a name that the homenet user has 244 registered on their own in the DNS using a public DNS registrar. 245 However, this is not required and, indeed, presents some operational 246 challenges. It can also be a name under a domain owned by one of the 247 user's service providers, or managed by some service provider that 248 specifically provides homenet naming services. 250 For most end-users, the second or third options will be preferable. 251 It will allow them to choose an easily-remembered homenet domain name 252 under an easily-remembered service provider subdomain, and will not 253 require them to maintain a DNS registration. 255 [This doesn't belong in the arch document, at least not in this part, 256 but I'm writing it down because I think we should discuss it and 257 figure out exactly what we should recommend, and I do believe we 258 should recommend something here and not just hope for the best. I am 259 also hoping to stave off frivolous, privacy-harming patents by 260 publishing this now:] 262 Providers of either of these types of homenet naming service should 263 offer a selection of different provider TLDs rather than a flat 264 namespace, so as to avoid the exampleuser1997 problem. So for 265 example rather than having a single namespace "isp.example.com", the 266 provider should have a series of subdomains, like 267 "grapefruit.example.com", "warrior.example.com", "koala.example.com", 268 "rocket.example.com", and so forth. 270 Some small number of such subdomains should be presented to the user 271 when registering. Subdomains with more than perhaps 50,000 homenets 272 registered in them should never be presented for registration, to 273 avoid chosen name collisions. If the user is unable to find a 274 namespace they like, it may be beneficial to allow the user to cycle 275 through a larger set of namespaces. The user should wind up with a 276 global name like "hamburger.warrior.example.com". 278 This specification may seem frivolous or overly-prescriptive. The 279 reason for being this specific is that it is important for the user 280 to be able to quickly choose a memorable name that doesn't contain 281 personal identifying information. Getting this user interface right 282 has significant implications for the user's privacy and security. 283 Any user interface that meets the criterion that the user can quickly 284 choose a memorable name that doesn't contain personal information 285 will address this requirement. The user should be specifically told 286 not to use personal information like birthdays or names of friends or 287 pets, and should be encouraged to write the chosen name down until 288 they have it memorized. 290 2.2. Local namespaces 292 Every homenet has two non-hierarchical local namespaces, one for 293 associating DNS RRs with names, and one for associating DNS RRs with 294 IP addresses. These namespaces are key-data stores, where for the 295 name mapping the primary key is a single DNS label, and for the IP 296 address mapping the primary key is an IP address. The secondary key 297 is an RRtype, so that there can be more than one RRset per IP 298 address, and each data element is an RRset of the corresponding 299 RRtype. 301 Each RRset in each local namespace is marked with a flag that 302 indicates whether it is to be public or private. Each RRset is also 303 marked with a flag that indicates whether its availability is 304 critical or best-effort. This flag only has meaning if the RRset is 305 marked public. 307 Each RR that contains a name (e.g, a CNAME or SRV record) either 308 contains a name in the local namespace or a global name. All global 309 names are references to external services, not to services on the 310 homenet. All local names are qualified with the homenet-specific 311 special-use TLD, [TBD1]. 313 [Question: do we need RRset granularity for these flags?] 315 The local namespace is maintained as a distributed database with 316 copies on every homenet router. No copy is the master copy. 317 Although the local namespace is non-hierarchical, it is permissible 318 for it to contain RRtypes that contain delegations. However, from an 319 operational perspective is is most likely better for the local 320 namespace to be at the bottom of the delegation hierarchy, and so we 321 do not recommend the use of such delegations. 323 2.3. Public namespaces 325 Every homenet has two public namespaces. These are copies of the 326 private namespaces with four modifications: 328 1. Names with no public RRsets are not included in the public 329 namespace. 331 2. RRs that contain IP addresses in the homenet's ULA prefix are 332 omitted. 334 3. By default, RRs that contain IPv4 addresses are omitted, because 335 IPv4 doesn't support renumbering. However, there should be a 336 whitelist of IPv4 addresses that may be published, so that if the 337 end user has static IPv4 addresses, those can be published. 339 4. If an RRset is marked best-effort rather than critical, RRs 340 containing IP addresses that match prefixes assigned by backup 341 links are omitted. 343 [Are there RRtypes or classes of DNSSD records that we want to always 344 omit?] 346 Because the public namespaces are copies of the private namespaces, 347 replication is not necessary: each homenet router automatically 348 produces public namespaces by deriving them from the private 349 namespaces using the above rules. The public namespaces can be 350 derived on demand, or maintained automatically as updates are made to 351 the private namespaces. 353 [Security/privacy considerations: It can be argued that public 354 namespaces provide a means for botnets to publish rendezvous 355 information. However, in fact this isn't really true because if 356 botnets did so, it would be very obvious, so would wind up being used 357 as a means of tracking and suppressing them. It's probably better to 358 encourage this mistake rather than trying to prevent it, since the 359 former benefits white hats, and the latter limits functionality.] 361 [Presumably we want it to be possible for devices that are meant to 362 be public servers to publish their names in the DNS, but how do we 363 automatically determine that a device is "meant" to be public? This 364 needs thought.] 366 2.4. Adding Names 368 Several mechanisms are available for updating the HNDB. 370 2.4.1. mDNS Snooping 372 Homenet snoops mDNS for device names. Homenet does not defend names. 373 If two devices with the same name appear on a link, mDNS handles 374 collision resolution. If two devices with the same name appear on 375 different links, homenet deterministically generates names for both 376 devices using the link-layer address of each device, plus the name 377 that device claimed. If a device that appears on two links is the 378 same device (presents the same link-layer address or DHCID) then it 379 is treated as a single device, with a single name. This whole 380 discussion probably belongs in a separate draft. 382 2.4.2. DHCP DNS Update (stateful or stateless) 384 A and PTR records can be set up this way. Doesn't work (yet) for 385 service discovery. Should we write a draft, or just rely on: 387 2.4.3. DNS Update 389 DNS updates can be send to any resolver in the homenet to add names 390 to the local zone. If there is no conflict, the name is added; 391 otherwise the update is rejected. 393 [Really, what we ought to do is just allow devices to declare an ID 394 that is a public key, and then do DNS updates to the local service 395 zone signed with the corresponding private key. Devices would also 396 sign their mDNS claims with the same key, so that mDNS updates for 397 devices that support this functionality can be ignored by the mDNS 398 snooping agent.] 400 [Records added to the namespace that contain names are problematic: 401 the hostname label is obvious, but what about the domain name? I 402 think the answer is that these names shouldn't be qualified, and the 403 name server should qualify them appropriately. What does mDNS do?] 405 [Add something about [TBD1] versus global name. If there is a global 406 name, that is what we use for name resolution on the local network. 407 This is necessary because of the security implications, both for 408 DNSSEC and for PKI.] 410 2.5. Removing Names 412 mDNS: names time out 414 DHCP: names go away when lease expires, or, for stateless, when 415 refresh timer expires 417 DNS Update: names have to have a lifetime, determined by the DNS 418 server, and DNSSD devices that do DNS Update have to keep sending 419 updates at appropriate intervals to reset the timer. If the lifetime 420 of a name expires, the name is deleted. Names can also be deleted by 421 a new update, which must either be signed with SIG(0) using a key 422 published on the name, or else must come from an IP address published 423 in the name if no key is published on the name (what if there's no IP 424 address?) 426 2.6. Name Collisions 428 Covered under adding names. Say more? 430 2.7. Recovery from loss 432 In principle the names in the zone aren't precious. If there are 433 multiple HNRs and one is replaced, the replacement recovers by 434 copying the local namespaces and other info from the others. If all 435 are lost, there are a few pieces of persistent data that need to be 436 recovered: 438 o The global name 440 o The ZSK for both local namespaces 442 o Names configured statically through the UI 444 All other names were acquired dynamically, and recovery is simply a 445 matter of waiting for the device to re-announce its name. We should 446 have a protocol for informing devices that they should do this, 447 either using an ND option or a DHCP message, or else devices should 448 know to do a fresh announcement whenever the link goes away (but that 449 doesn't work if the device is connected to the nearest router through 450 a separate switch, so ND option is better). 452 There should be some way (ideally) for the global name to be 453 recovered. How? This will cause problems with DNSSEC, because the 454 private ZSK is lost, and we don't expect the user to be smart about 455 keys. ZSK or KSK could be stored encrypted at the SP. Subject to 456 brute force attacks if so, probably not a good idea. Better to just 457 have a flag day? One answer is the end-user management RESTful API: 458 if the end-user has a phone, the ZSK and other static info can be 459 maintained in an app on the phone; this app can then be in touch with 460 the homenet, and if the homenet finds that it is amnesiac, the app 461 can notify the user. Of course, this is a potential attack--we don't 462 want some other network the phone connects to to be able to steal the 463 ZSK just by telling the app it's amnesiac. 465 2.8. Persistence 467 When the whole homenet goes away, can we recover the zone? Step 1: 468 figure out what name we had: how? Then, if we have off-site 469 secondaries that have copies of the private zone, we can poll for the 470 highest serial number and copy the contents of that zone. If we only 471 have secondaries for the public part of the zone, we can recover 472 that; should we? 474 2.9. Well-known names 476 Homenets serve a zone under the special-use TLD [TBD2], that answers 477 queries for local configuration information and can be used to 478 advertise services provided by the homenet (as opposed to services 479 present on the homenet). This provides a standard means for querying 480 the homenet that can be assumed by management functions and homenet 481 clients. A registry of well-known names for this zone is defined in 482 IANA considerations (Section 8). Names and RRs in this zone are only 483 ever provided by the homenet--this is not a general purpose service 484 discovery zone. 486 All resolvers on the homenet will answer questions about names in 487 this zone; entries in the zone are guaranteed not to be globally 488 unique. Hosts and services that use the special names under this TLD 489 are assumed to be aware that it is a special TLD. If such hosts 490 cache DNS entries, DNS entries under this TLD are discarded whenever 491 the host detects a network reattachment. 493 The uuid.[TBD2] name contains a TXT RR that contains the UUID of the 494 homenet. Each homenet generates its own distinct UUID; homenet 495 routers on any particular homenet all use the same UUID, which is 496 agreed upon using HNCP. If the homenet has not yet generated a UUID, 497 queries against this name will return NXDOMAIN. 499 The global-name.[TBD2] name contains a PTR record that contains the 500 global name of the homenet. If the homenet does not have a global 501 name, queries against this name will return NXDOMAIN. 503 The global-name-register.[TBD2] name contains one or more A and/or 504 AAAA records referencing hosts that provide a RESTful API over HTTP 505 that can be used to register the global name of the homenet, once 506 that name has been configured. 508 3. Name Resolution 510 3.1. Configuring Resolvers 512 Hosts on the homenet receive a set of resolver IP addresses using 513 either DHCP or RA. IPv4-only hosts will receive IPv4 addresses of 514 resolvers, if available, over DHCP. IPv6-only hosts will receive 515 resolver IPv6 addresses using either stateful (if available) or 516 stateless DHCPv6, or through the domain name option in router 517 advertisements. All homenet routers provide resolver information 518 using both stateless DHCPv6 and RA; support for stateful DHCPv6 and 519 DHCPv4 is optional (right?). 521 3.2. Configuring Service Discovery 523 DNS-SD uses several default domains for advertising local zones that 524 are available for service discovery. These include the ".local" 525 domain, which is searched using mDNS, and also the IPv4 and IPv6 526 reverse zone corresponding to the prefixes in use on the local 527 network. For the homenet, queries against the ".local" zone are 528 supported, as well as queries against every IPv4 address prefix 529 advertised on a homenet link, and every IPv6 address prefix 530 advertised on a homenet link, including prefixes derived from the 531 homenet's ULA(s). In addition, the [TBD2] domain can be used, and is 532 preferred. Whenever the "" sequence appears in this section, 533 it references each of the domains mentioned in this paragraph. 535 Homenets advertise the availability of several browsing zones in the 536 "b._dns_sd." subdomain. The zones advertised are the "well 537 known" zone (TBD2) and the zone containing the local namespace. If 538 the global name is available, only that name is advertised for the 539 local namespace; otherwise [TBD1] is advertised. Similarly, if the 540 global name is available, it is advertised as the default browsing 541 and service registration domain under "db._dns_sd.", 542 "r._dns_sd.", "dr._dns_sd." and 543 "lb._dns_sd."; otherwise, the name [TBD1] is advertised as 544 the default. 546 3.3. Resolution of local namespaces 548 The local namespace appears in two places, under [TBD1] and, if the 549 homenet has a global name, under the global name. Resolution from 550 inside the homenet yields the contents of the local namespaces; 551 resolution outside of the homenet yields the contents of the public 552 namespaces. If there is a global name for the homenet, RRs 553 containing names in both instances of the local namespace are 554 qualified with the global name; otherwise they are qualified with 555 [TBD1]. 557 3.4. Local and Public Zones 559 The homenet's global name serves both as a unique identifier for the 560 homenet and as a delegation point in the DNS for the zone containing 561 the homenet's forward namespace. There are two versions of the 562 forward namespace: the public version and the private version. Both 563 of these versions of the namespace appear under the global name 564 delegation, depending on which resolver a host is querying. 566 The homenet provides two versions of the zone. One is the public 567 version, and one is the local version. The public version is never 568 visible on the homenet (could be an exception for a guest net). The 569 public version is available outside of the homenet. The local 570 version is visible on the homenet. Whenever the zone is updated, it 571 is signed with the ZSK. Both versions of the zone are signed; the 572 local signed version always has a serial number greater than the 573 public signed version. [we want to not re-sign the public zone if no 574 public names in the private zone changed.] 576 This dual publication model relies on hosts connected to the homenet 577 using the local resolver and not some external resolver. Hosts that 578 use an external resolver will see the public version of the 579 namespace. From a security UI design perspective, allowing queries 580 from hosts on the homenet to resolvers off the homenet is risky, and 581 should be prevented by default. This is because if the user sees 582 inconsistent behavior on hosts that have external resolvers 583 configured, they may attempt to fix this by making all local names 584 public. If an alternate external resolver is to be used, it should 585 be configured on the homenet, not on the individual host. 587 One way to make this work is to intercept all DNS queries to non- 588 homenet IP addresses, check to see if they reference the local 589 namespace, and if so resolve them locally, answering as if from the 590 remote cache. If the query does not reference a local namespace, and 591 is listed as "do not forward" in RFC 6761 or elsewhere, it can be 592 sent to the intended cache server for resolution without any special 593 handling for the response. This functionality is not required for 594 homenet routers, but is likely to present a better user experience. 596 3.5. Legacy support 598 In principle, devices that support DNSSD should be able to do service 599 discovery using DNS without any special help. Devices that only 600 support mDNS should be able to get a complete list of services from a 601 combination of names published by devices on the same link and by the 602 homenet router that serves that link (what if there's more than 603 one?). In cases where the homenet router has an off-link entry that 604 has the same claimed name as an on-link service, the homenet router 605 does not advertise the off-link service. 607 3.6. DNSSEC Validation 609 The [TBD1] zone is not validated. We could define a special rule, 610 such that any particular local zone publishes a unique identifier for 611 that zone and signs itself with a ZSK; a homenet-aware host could to 612 TOFU on the id/ZSK, and could keep a list of id/ZSKs it has seen, and 613 then do DNSSEC validation on names in the local zone that way, but 614 it's a bit rickety and nonstandard, so I don't know if there's enough 615 benefit to justify the cost. Worth thinking about, though--could be 616 the keystone of a homenet security model if done right. 618 3.7. Support for Multiple Provisioning Domains 620 Homenets must support the Multiple Provisioning Domain Architecture 621 [6]. In order to support this architecture, each homenet router that 622 provides name resolution must provide one resolver for each 623 provisioning domain (PvD). Each homenet router will advertise one 624 resolver IP address for each PvD. DNS requests to the resolver 625 associated with a particular PvD, e.g. using RA options [8] will be 626 resolved using the external resolver(s) provisioned by the service 627 provider responsible for that PvD. 629 The homenet is a separate provisioning domain from any of the service 630 providers. The global name of the homenet can be used as a 631 provisioning domain identifier, if one is configured. Homenets 632 should allow the name of the local provisioning domain to be 633 configured; otherwise by default it should be "Home Network xxx", 634 where xxx is the generated portion of the homenet's ULA prefix, 635 represented as a base64 string. 637 The resolver for the homenet PvD is offered as the primary resolver 638 in RAs and through DHCPv4 and DHCPv6. When queries are made to the 639 homenet-PvD-specific resolver for names that are not local to the 640 homenet, the resolver will use a round-robin technique, alternating 641 between service providers with each step in the round-robin process, 642 and then also between external resolvers at a particular service 643 provider if a service provider provides more than one. The round- 644 robining should be done in such a way that no service provider is 645 preferred, so if service provider A provides one caching resolver 646 (A), and service provider B provides two (B1, B2), the round robin 647 order will be (A, B1, A, B2), not (A, B1, B2). 649 Every resolver provided by the homenet, regardless of which 650 provisioning domain it is intended to serve, will accept updates for 651 services in the local service namespace. 653 3.8. Using the Local Namespace While Away From Home 655 Homenet routers do not answer unauthenticated DNS queries from off 656 the local network. However, some applications may benefit from the 657 ability to resolve names in the local namespace while off-network. 658 Therefore hosts connected to the homenet can register keys in the 659 same way that services are registered, and the homenet will cache 660 such keys. Such keys must be validated by the end user before 661 queries against the local namespace that have been authenticated with 662 that key are permitted. A host that will make remote queries to the 663 local namespace caches the names of all DNS servers on the homenet by 664 querying all-resolver-names.[TBD2]. If the local zone is not signed 665 using DNSSEC, the host also caches each server's SIG(0) key. 667 Hosts that require name resolution from the local network must have a 668 stub resolver configured to contact the dns server on one or more 669 routers in the homenet when resolving names in the local namespace. 670 To do this, resolvers must know the global name of the local 671 namespace, which they can retain from previous connections to the 672 homenet. The homenet may not have a stable IP address, so such 673 resolvers cannot merely cache the IP address of the homenet routers. 674 Instead, they cache the names of the homenet routers that provide DNS 675 service and use those names to determine the IP addresses of the 676 homenet routers at the time of resolution. Such IP addresses can be 677 safely cached for the duration of the TTL of the A or AAAA record 678 that contained them. The names of the homenet router DNS servers 679 should be randomly generated so that they can't be guessed by off- 680 network attackers. [?] 682 To make a homenet DNS query, the host signs the request using SIG(0) 683 with the key that they registered to the homenet. The homenet router 684 first checks the question in the query for validity: it must be a 685 subdomain of the global name. The homenet router then checks the 686 name of the signing key against the list of cached, validated keys; 687 if that key is cached and validated, then the homenet router attempts 688 to validate the SIG(0) signature using that key. If the signature is 689 valid, then the homenet router answers the query. If the zone is not 690 signed, or doesn't have a trust anchor in the parent zone, the 691 responding server signs the answer with its own SIG(0) key. The 692 resolver that sent the query validates the response using DNSSEC if 693 possible, and otherwise using the SIG(0) key. 695 [it can be argued that this isn't necessary for the base spec, and it 696 obviously requires some additional protocol work, so may want to 697 leave it out of the base architecture. It may also make more sense 698 to serve queries using DNS-over-TLS (dprive) rather than SIG(0).] 700 4. Publishing the Public Namespace 702 4.1. Acquiring the Global Name 704 There are two ways to acquire a global name: the end-user can 705 register a domain name using a public domain name registry, or the 706 end-user can be assigned a subdomain of a registered domain by a 707 homenet global name service provider. We will refer to this as the 708 Global Name Registration Provider [GNRP]. In either case, the 709 registration process can either be manual or automatic. Homenet 710 routers support automatic registration regardless of the source of 711 the homenet's global name, using a RESTful API. 713 The RESTful API provides a method for generating a unique URL which 714 can be used for a limited time by the GNRP to register the global 715 name once the end user has chosen one and made payment arrangements 716 (if necessary). When the GNRP is ready to convey the global name to 717 the homenet, it uses the specified URL to submit (POST) the name. 718 The URL will be https, but the certificate will not be valid; its 719 purpose is to provide privacy, not authenticity. 721 In response, the homenet server either rejects the POST, if the URL 722 has expired or is invalid, or else returns a text response containing 723 a single label, '@', representing the local namespace. Under that 724 label, the homenet will include one or more DNSKEY records for zone 725 signing keys, one of which is required, and key signing keys, which 726 are not required. 728 The returned zone will also include a TLSA record. The record has a 729 Usage field value of 0 (PKI Cert), a Selector value of 1 (just the 730 public key), and a matching type of 0 (exact match). The Certificate 731 Association data field contains a public key generated by the homenet 732 for use in authenticating local web traffic. 734 The returned zone may include NS records; if it does, the GNRP is 735 expected to use those NS records in the delegation for the global 736 name. Otherwise, it provides the NS records for its own 737 authoritative servers. 739 The GNRP then sets up a secure delegation using the currently-valid 740 ZSKs included in the zone. The GNRP also signs the public key 741 provided in the TLSA record using a PKI cert owned by the GNRP that 742 can be validated by web browsers, and posts it back to the homenet 743 using the RESTful API URL. 745 More detail on this process will be provided in a future document. 746 [or really, how much detail should there be here?] 748 4.2. Hidden Primary/Public Secondaries 750 The default configuration for a homenet's external name service is 751 that the primary server for the zone is not published in an NS record 752 in the zone's delegation. Instead, the GNRP provides authoritative 753 name service for the zone. Whenever the public zone is updated, the 754 hidden primary sends NOTIFY messages to all the secondaries, using 755 the zone's ZSK (or?) to sign the message. 757 When any of the GNRP secondary servers receives a notify for the 758 zone, it checks to see that the notify is signed with a valid ZSK for 759 that zone. If so, it contacts the IP address from which the NOTIFY 760 was send and initiates a zone transfer. Using this IP address avoids 761 renumbering issues. Upon finishing the zone transfer, the zone is 762 validated using each ZSK used to sign it. If any validation fails, 763 the new version of the zone is discarded. If updates have been 764 recevied, but no valid updates received, over a user-settable 765 interval defaulting to a day (or?), the GNRP will communicate to the 766 registered user that there is a problem. 768 The reverse zone for any prefix delegated by an ISP should be 769 delegated by that ISP to the home gateway to which the delegation was 770 sent. The list of secondaries for that zone is sent to the home 771 gateway using DHCPv6 prefix delegation (or?). The ZSK is announced 772 to the ISP in each DHCP PD message sent by the home gateway. 773 Whenever an update is made to this zone, the home gateway sends a 774 NOTIFY to each of the listed secondaries for the delegation, and 775 updates occur as described above. 777 4.3. DNSSEC security 779 All zones published by the homenet are signed. Internal zones cannot 780 have secure delegations, however. Hosts that are aware of homenets 781 can do TOFU authentication of a particular instance of the homenet 782 zones [TBD1] or [TBD2]. To do this, the host queries the uuid.[TBD2] 783 name. The homenet always publishes this name with a single TXT RR 784 containing a UUID, which is expected to be unique and stable. The 785 homenet will also publish a name, rev.[TBD2] which contains a PTR 786 RRset that enumerates the outer delegations of all reverse zones 787 operated by the homenet at the time of the query that are in private 788 address spaces. 790 The homenet-aware host can then query and cache the ZSKs of the 791 [TBD2] domain on that homenet, using the UUID to identify it. The 792 homenet uses the same ZSK for all zones that it publishes. Homenet- 793 aware hosts can validate any record in the [TBD1] and [TBD2] zones 794 and in reverse zones for private and ULA number spaces using the 795 stashed ZSK for the homenet UUID to which the host is currently 796 connected (may be different on different interfaces). Names in non- 797 private, non-ULA number spaces are validated using secure 798 delegations, not homenet TOFU trust anchors, as are all other zones 799 other than [TBD1] and [TBD2]. 801 4.4. PKI security 803 PKI security is only possible if the homenet has a global name. The 804 homenet should not use TLS unless it has a certificate that will be 805 successfully validated by web servers; otherwise, the homenet will be 806 training end-users to click through certificate warnings, and will be 807 inoperable to web browsers with correct security user interfaces 808 (which never present such warnings). If the homenet has a global 809 name, it should also have gotten a valid PKI certificate as part of 810 the process of acquiring the global name. 812 The homenet tracks the expiration date of the TLS certificate. One 813 month before expiration, the homenet will send a renewal request to 814 the GNRP using the URL provided by the GNRP during registration. The 815 GNRP will then provide a new certificate and a new URL, which the 816 homenet will record for the next renewal (the URL is not required to 817 change). Because the key to be signed is published in the public 818 namespace of the homenet, there is no need for a secondary 819 authentication path for the key. 821 4.5. Renumbering 823 The homenet may renumber at any time. IP address RRs published in 824 either namespace must never have a TTL that is longer than the valid 825 lifetime for the prefix from which the IP address was allocated. If 826 a particular ISP has deprecated a prefix (its preferred lifetime is 827 zero), IP addresses derived from that prefix are not published in the 828 DNS. If more than one prefix is provided by the same ISP and some 829 have different valid lifetimes, only IP addresses in the prefix or 830 prefixes with the longest valid lifetime are. 832 4.6. ULA 834 Question: If the homenet has one or more ULAs, should we only publish 835 the ULAs and not the global addresses in the local namespace? This 836 would prevent renumbering events from having any impact on local 837 communication. Any reason not to do this? Would require some 838 rewording of the local/global namespace text. 840 5. Management 842 5.1. End-user management 844 Need to have well-known name with RESTful API that apps can connect 845 to, so that you can have an app on your phone, laptop or whatever 846 that operates the network. This is a model that seems popular and 847 accepted by end-users; having a well-defined API allows us to avoid a 848 million different undocumented vendor-specific management APIs. Web 849 API would also be nice, but we can't specify that, so better to 850 specify the RESTful API and let vendors decide what sort of frock to 851 put on it. 853 This API should provide a means for notifying end-users of issues on 854 the home network, using whatever app they have installed. The API 855 must provide a mechanism for registering end-users or devices that 856 are permitted to manage the homenet, and a way to recover if all such 857 devices are lost. 859 5.2. Central management 861 Possibly can be done mostly through RESTful API, but might want 862 Netconf/Yang as well. Should be possible to have the local namespace 863 mastered on an external DNS auth server, e.g. in case a bunch of HNRs 864 are actually set up in an org, or in case an ISP wants to provide a 865 service package for users who would rather not have an entirely self- 866 operating network. 868 6. Privacy Considerations 870 Private information must not leak out as a result of publishing the 871 public namespace. We believe the current provisions adequately 872 address this concern. (right?) 874 7. Security Considerations 876 Need someone with security fu to review the registration model, etc., 877 once we have it. 879 8. IANA considerations 881 IANA will add a new registry titled Homenet Management Well-Known 882 Names, which initially contains: 884 uuid Universally Unique Identifier--TXT record containing, in base64 885 encoding, a stable, randomly generated identifier for the homenet 886 that is statistically unlikely to be shared by any other homenet. 888 global-name The homenet's global name, represented as a PTR record 889 to that name. 891 global-name-register The hostname of the homenet's global name 892 registry service, with A and/or AAAA records. 894 all-resolver-names A list of all the names of the homenet's 895 resolvers for the homenet PvD, represented as an RRset containing 896 one or more PTR records. 898 The IANA will allocate two names out of the Special-use TLD names 899 registry: 901 TBD1 Suggested value: "homenet" 903 TBD2 Suggested value: "_hnsd" 905 9. Normative References 907 [1] Mockapetris, P., "Domain names - concepts and facilities", 908 STD 13, RFC 1034, DOI 10.17487/RFC1034, November 1987, 909 . 911 [2] Mockapetris, P., "Domain names - implementation and 912 specification", STD 13, RFC 1035, DOI 10.17487/RFC1035, 913 November 1987, . 915 [3] Vixie, P., Ed., Thomson, S., Rekhter, Y., and J. Bound, 916 "Dynamic Updates in the Domain Name System (DNS UPDATE)", 917 RFC 2136, DOI 10.17487/RFC2136, April 1997, 918 . 920 [4] Cheshire, S. and M. Krochmal, "Multicast DNS", RFC 6762, 921 DOI 10.17487/RFC6762, February 2013, 922 . 924 [5] Cheshire, S. and M. Krochmal, "DNS-Based Service 925 Discovery", RFC 6763, DOI 10.17487/RFC6763, February 2013, 926 . 928 [6] Anipko, D., Ed., "Multiple Provisioning Domain 929 Architecture", RFC 7556, DOI 10.17487/RFC7556, June 2015, 930 . 932 [7] Cheshire, S., "Hybrid Unicast/Multicast DNS-Based Service 933 Discovery", draft-ietf-dnssd-hybrid-03 (work in progress), 934 February 2016. 936 [8] Korhonen, J., Krishnan, S., and S. Gundavelli, "Support 937 for multiple provisioning domains in IPv6 Neighbor 938 Discovery Protocol", draft-ietf-mif-mpvd-ndp-support-03 939 (work in progress), February 2016. 941 Author's Address 943 Ted Lemon 944 Nominum, Inc. 945 800 Bridge Parkway 946 Redwood City, California 94065 947 United States of America 949 Phone: +1 650 381 6000 950 Email: ted.lemon@nominum.com