idnits 2.17.00 (12 Aug 2021) /tmp/idnits50282/draft-lemon-homenet-naming-architecture-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 : ---------------------------------------------------------------------------- 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 (July 8, 2016) is 2136 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- -- Looks like a reference, but probably isn't: 'TBD1' on line 674 -- Looks like a reference, but probably isn't: 'TBD2' on line 730 -- Looks like a reference, but probably isn't: 'GNRP' on line 769 == Outdated reference: draft-ietf-dnssd-hybrid has been published as RFC 8766 == Outdated reference: draft-ietf-dnssd-push has been published as RFC 8765 == Outdated reference: draft-ietf-tokbind-https has been published as RFC 8473 Summary: 0 errors (**), 0 flaws (~~), 4 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 July 8, 2016 5 Expires: January 9, 2017 7 Homenet Naming and Service Discovery Architecture 8 draft-lemon-homenet-naming-architecture-01 10 Abstract 12 This document recommends a naming and service discovery resolution 13 architecture for homenets. This architecture covers local and global 14 publication of names, discusses security and privacy implications, 15 and addresses those implications. The architecture also covers name 16 resolution and service discovery for hosts on the homenet, and for 17 hosts that roam off of the homenet and still need access to homenet 18 services. 20 Status of This Memo 22 This Internet-Draft is submitted in full conformance with the 23 provisions of BCP 78 and BCP 79. 25 Internet-Drafts are working documents of the Internet Engineering 26 Task Force (IETF). Note that other groups may also distribute 27 working documents as Internet-Drafts. The list of current Internet- 28 Drafts is at http://datatracker.ietf.org/drafts/current/. 30 Internet-Drafts are draft documents valid for a maximum of six months 31 and may be updated, replaced, or obsoleted by other documents at any 32 time. It is inappropriate to use Internet-Drafts as reference 33 material or to cite them other than as "work in progress." 35 This Internet-Draft will expire on January 9, 2017. 37 Copyright Notice 39 Copyright (c) 2016 IETF Trust and the persons identified as the 40 document authors. All rights reserved. 42 This document is subject to BCP 78 and the IETF Trust's Legal 43 Provisions Relating to IETF Documents 44 (http://trustee.ietf.org/license-info) in effect on the date of 45 publication of this document. Please review these documents 46 carefully, as they describe your rights and restrictions with respect 47 to this document. Code Components extracted from this document must 48 include Simplified BSD License text as described in Section 4.e of 49 the Trust Legal Provisions and are provided without warranty as 50 described in the Simplified BSD License. 52 Table of Contents 54 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 55 1.1. Existing solutions . . . . . . . . . . . . . . . . . . . 4 56 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 57 3. Homenet Naming Database . . . . . . . . . . . . . . . . . . . 5 58 3.1. Global Name . . . . . . . . . . . . . . . . . . . . . . . 6 59 3.2. Local namespaces . . . . . . . . . . . . . . . . . . . . 6 60 3.3. Public namespaces . . . . . . . . . . . . . . . . . . . . 8 61 3.4. Maintaining Namespaces . . . . . . . . . . . . . . . . . 9 62 3.4.1. Multicast DNS . . . . . . . . . . . . . . . . . . . . 9 63 3.4.2. DNS Update . . . . . . . . . . . . . . . . . . . . . 10 64 3.5. Recovery from loss . . . . . . . . . . . . . . . . . . . 10 65 3.6. Well-known names . . . . . . . . . . . . . . . . . . . . 11 66 4. Name Resolution . . . . . . . . . . . . . . . . . . . . . . . 12 67 4.1. Configuring Resolvers . . . . . . . . . . . . . . . . . . 12 68 4.2. Configuring Service Discovery . . . . . . . . . . . . . . 12 69 4.3. Resolution of local namespaces . . . . . . . . . . . . . 13 70 4.4. Service Discovery Resolution . . . . . . . . . . . . . . 13 71 4.5. Local and Public Zones . . . . . . . . . . . . . . . . . 14 72 4.6. DNSSEC Validation . . . . . . . . . . . . . . . . . . . . 15 73 4.7. Support for Multiple Provisioning Domains . . . . . . . . 15 74 4.8. Using the Local Namespace While Away From Home . . . . . 16 75 5. Publishing the Public Namespace . . . . . . . . . . . . . . . 17 76 5.1. Acquiring the Global Name . . . . . . . . . . . . . . . . 17 77 5.2. Hidden Primary/Public Secondaries . . . . . . . . . . . . 17 78 5.3. PKI security . . . . . . . . . . . . . . . . . . . . . . 18 79 5.4. Renumbering . . . . . . . . . . . . . . . . . . . . . . . 18 80 5.5. ULA . . . . . . . . . . . . . . . . . . . . . . . . . . . 18 81 6. Management . . . . . . . . . . . . . . . . . . . . . . . . . 18 82 6.1. End-user management . . . . . . . . . . . . . . . . . . . 18 83 6.2. Central management . . . . . . . . . . . . . . . . . . . 18 84 7. Privacy Considerations . . . . . . . . . . . . . . . . . . . 19 85 8. Security Considerations . . . . . . . . . . . . . . . . . . . 19 86 9. IANA considerations . . . . . . . . . . . . . . . . . . . . . 19 87 10. Normative References . . . . . . . . . . . . . . . . . . . . 20 88 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 21 90 1. Introduction 92 Associating domain names with hosts on the Internet is a key factor 93 in enabling communication with hosts, particularly for service 94 discovery. In order to provide name service, several provisioning 95 mechanisms must be available: 97 o Provisioning of a domain name under which names can be published 98 and services advertised 100 o Associating names that are subdomains of that name with hosts. 102 o Advertising services available on the local network by publishing 103 resource records on those names. 105 o Distribution of names published in that namespace to servers that 106 can be queried in order to resolve names 108 o Correct advertisement of name servers that can be queried in order 109 to resolve names 111 o Timely removal of published names and resource records when they 112 are no longer in use 114 Homenet adds the following considerations: 116 1. Some names may be published in a broader scope than others. For 117 example, it may be desirable to advertise some homenet services 118 to users who are not connected to the homenet. However, it is 119 unlikely that all services published on the home network would 120 be appropriate to publish outside of the home network. In many 121 cases, no services will be appropriate to publish outside of the 122 network, but the ability to do so is required. 124 2. Users cannot be assumed to be skilled or knowledgeable in name 125 service operation, or even to have any sort of mental model of 126 how these functions work. With the possible exception of policy 127 decisions, all of the operations mentioned here must reliably 128 function automatically, without any user intervention or 129 debugging. 131 3. Even to the extent that users may provide input on policy, such 132 as whether a service should or should not be advertised outside 133 of the home, the user must be able to safely provide such input 134 without having a correct mental model of how naming and service 135 discovery work, and without being able to reason about security 136 in a nuanced way. 138 4. Because user intervention cannot be required, naming conflicts 139 must be resolved automatically, and, to the extent possible, 140 transparently. 142 5. Where services are advertised both on and off the home network, 143 differences in naming conventions that may vary depending on the 144 user's location must likewise be transparent to the end user. 146 6. Hosts that do not implement any homenet-specific capabilities 147 must still be able to discover and access services on the 148 homenet, to the extent possible. 150 7. Devices that provide services must be able to publish those 151 services on the homenet, and those services must be available 152 from any part of the homenet, not just the link to which the 153 device is attached. 155 8. Homenet explicitly supports multihoming--connecting to more than 156 one Internet Service Provider--and therefore support for 157 multiple provisioning domains [9] is required to deal with 158 situations where the DNS may give a different answer depending 159 on whether caching resolvers at one ISP or another are queried. 161 9. Multihomed homenets may treat all service provider links as 162 equivalent, or may treat some links as primary and some as 163 backup, either because of differing transit costs or differing 164 performance. Services advertised off-network may therefore be 165 advertised for some links and not others. 167 10. To the extent possible, the homenet should support DNSSEC. If 168 the homenet local domain is not unique, there should still be a 169 mechanism that homenet-aware devices can use to bootstrap trust 170 for a particular homenet. 172 In addition to these considerations, there may be a need to provide 173 for secure communication between end users and the user interface of 174 the home network, as well as to provide secure name validation (e.g., 175 DNSSEC). Secure communications require that the entity being secured 176 have a name that is unique and can be cryptographically authenticated 177 within the scope of use of all devices that must communicate with 178 that entity. Because it is very likely that devices connecting to 179 one homenet will be sufficiently portable that they may connect to 180 many homenets, the scope of use must be assumed to be global. 181 Therefore, each homenet must have a globally unique identifier. 183 1.1. Existing solutions 185 Previous attempts to automate naming and service discovery in the 186 context of a home network are able to function with varying degrees 187 of success depending on the topology of the home network. For 188 example, Multicast DNS [7] can provide naming and service discovery 189 [8], but only within a single multicast domain. 191 The Domain Name System provides a hierarchical namespace [1], a 192 mechanism for querying name servers to resolve names [2], a mechanism 193 for updating namespaces by adding and removing names [4], and a 194 mechanism for discovering services [8]. Unfortunately, DNS provides 195 no mechanism for automatically provisioning new namespaces, and 196 secure updates to namespaces require pre-shared keys, which won't 197 work for an unmanaged network. DHCP can be used to populate names in 198 a DNS namespace; however at present DHCP cannot provision service 199 discovery information. 201 Hybrid Multicast DNS [10] proposes a mechanism for extending 202 multicast DNS beyond a single multicast domain.. However, it has 203 serious shortcomings as a solution to the Homenet naming problem. 204 The most obvious shortcoming is that it requires that every multicast 205 domain have a separate name. This then requires that the homenet 206 generate names for every multicast domain, and requires that the end 207 user have a mental model of the topology of the network in order to 208 guess on which link a given service may appear. [xxx is this really 209 true at the UI?] 211 2. Terminology 213 This document uses the following terms and abbreviations: 215 HNR Homenet Router 217 ISP Internet Service Provider 219 GNRP Global Name Registration Provider 221 3. Homenet Naming Database 223 In order to resolve names, there must be a place where names are 224 stored. There are two ways to go about this: either names are stored 225 on the devices that own them, or they are stored in the network 226 infrastructure. This isn't a clean division of responsibility, 227 however. It's possible for the device to maintain change control 228 over its own name, while still performing name resolution for that 229 name in the network infrastructure. 231 If devices maintain change control on their own names, conflicts can 232 arise. Two devices might present the same name, either because their 233 default names or the same, or as a result of accidental. Devices can 234 be attached to more than one link, in which case we want the same 235 name to identify them on both networks. Although homenets are self- 236 configuring, user customization is permitted and useful, and while 237 some devices may provide a user interface for setting their name, it 238 may be worthwhile to provide a user interface and underlying support 239 for allowing the user to specify a device's name in the homenet 240 infrastructure. 242 In order to achieve this, the Homenet Naming Database (HNDB) provides 243 a persistent central store into which names can be registered. 245 3.1. Global Name 247 Every homenet must be able to have a name in the global DNS hierarchy 248 which serves as the root of the zone in which the homenet publishes 249 its public namespaces. Homenets that do not yet have a name in the 250 global namespace use the homenet special-use top-level name [TBD1] as 251 their "global name" until they are configured with a global name. 253 A homenet's global name can be a name that the homenet user has 254 registered on their own in the DNS using a public DNS registrar. 255 However, this is not required and, indeed, presents some operational 256 challenges. It can also be a subdomain of a domain owned by one of 257 the user's ISP, or managed by some DNS service provider that 258 specifically provides homenet naming services. 260 For most end-users, the second or third options will be preferable. 261 It will allow them to choose an easily-remembered homenet domain name 262 under an easily-remembered service provider subdomain, and will not 263 require them to maintain a DNS registration. 265 Homenets must support automatic configuration of the homenet global 266 name in a secure manner, as well as manual configuration of the name. 267 The solution must allow a user with a smartphone application or a 268 user with a web browser to successfully configure the homenet's 269 global name without manual data entry. The security implications of 270 this process must be identified and, to the extent possible, 271 addressed. 273 3.2. Local namespaces 275 Every homenet has two or more non-hierarchical local namespaces, one 276 for names of hosts--the host namespace--and one or more for IP 277 addresses--the address namespaces. A namespace is a database table 278 mapping each of a set keys to its value. "Local" in this context 279 means "visible to users of the homenet," as opposed to "public," 280 meaning visible to anyone. 282 For the host namespace, the key is the set of labels in a name, 283 excluding whatever labels represent the domain name of the namespace. 284 So for example if the homenet's global name is "dog- 285 pixel.example.com" and the name being looked up is "alice.dog- 286 pixel.example.com", the key will be "alice". 288 The local namespace may be available both in the global DNS namespace 289 and under the [TBD1] special-use name. The set of keys is the same 290 in both cases--in the above example, the name could be either 291 'alice.dog-pixel.example.com' or 'alice.[TBD1]'. Whichever one of 292 the two representations is used, the key is simply 'alice'. 294 For each address namespace, the key is the locally-significant 295 portion of the IP address. For example, if the local prefix assigned 296 by an ISP is 2001:DB8:bee7::/48, the name of that address namespace 297 will be '7.e.e.b.8.b.d.0.1.0.0.2.ip6.arpa'. An IP address of 298 2001:db8:bee7::1 would therefore yield a key of 299 '1.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0' 301 Every prefix in use on the homenet has an address namespace, whether 302 its subdomain is delegated in the DNS or not. This includes any 303 public or private IPv4 prefixes in use [3] as well as any ULA 304 prefixes in use [5], which can't be delegated [6]. When the valid 305 lifetime for a prefix that had been in use on the homenet ends, the 306 address namespace for that prefix is discarded. Namespaces for 307 prefixes that are manually configured, like IPv4 public prefixes and 308 IPv4 private prefixes, persist as long as the prefix is configured. 309 Since ULA prefixes have lifetimes, the lifetime rule applies to their 310 address namespaces. 312 In all namespaces, the value that the key addresses is a sub-table 313 containing one or more RRsets, each of which is identified by its 314 RRtype. In the terminology of the DNS protocol, each of these 315 namespaces is analogous to a DNS zone (but bear in mind that from the 316 perspective of DNS queries, the namespace for names may appear to 317 hosts connected to the homenet as two different zones containing 318 identical data. 320 However, in addition to DNS zone data, each RRset also has two 321 metadata flags: the public flag and the critical flag. The public 322 flag indicates whether the data in this RRset should be publicly 323 visible. The critical flag indicates whether the service should be 324 advertised even on high-cost internet links. 326 Each RR that contains a name (e.g, a CNAME or SRV record) either 327 contains a local name or a name in the public DNS. Local names can 328 be subdomains of the homenet's global name, yet not be public, if no 329 RRsets in the namespace for names is marked public. Local names can 330 also be subdomains of [TBD1]. Names in the public DNS that are not 331 subdomains of the homenet's global name can only be added by explicit 332 action in one of the management interfaces described in Section 6. 334 Each local namespace is maintained as a distributed database with 335 copies on every homenet router. No copy is the master copy. 336 Although the local namespace is non-hierarchical, it is permissible 337 for it to contain RRtypes that contain delegations. However, from an 338 operational perspective is is most likely better for the local 339 namespace to be at the bottom of the delegation hierarchy, and so we 340 do not recommend the use of such delegations. 342 3.3. Public namespaces 344 Every homenet has one or more public namespaces. These are subsets 345 of the local namespaces with the following modifications: 347 1. Names with no RRsets whose public bits are set are not included 348 in the public namespace. 350 2. RRs that contain IP addresses in the homenet's ULA prefix are 351 omitted. 353 3. By default, RRs that contain IPv4 addresses are omitted, because 354 IPv4 doesn't support renumbering. However, there should be a 355 whitelist of IPv4 addresses that may be published, so that if the 356 end user has static IPv4 addresses, those can be published. 357 Private IPv4 addresses, however, are never published. 359 4. If an RRset is marked best-effort rather than critical, RRs 360 containing IP addresses that have prefixes assigned by backup 361 links are omitted. 363 5. If an RRset contains names, names that are subdomains of either 364 the homenet's global name or [TBD1] are checked in the local host 365 namespace to see if they are marked public. If not, they are 366 omitted. 368 Because the public namespaces are subsets of the local namespaces, 369 replication is not necessary: each homenet router automatically 370 produces public namespaces by deriving them from the local namespaces 371 using the above rules. Answers to queries in the public namespaces 372 can be generated on demand. However, it may be preferable to 373 maintain these namespaces as if they were DNS zones. This makes it 374 possible to use DNS zone transfers to offload the contents of public 375 zones to a secondary service provider, eliminating the need to handle 376 arbitrary numbers of queries from off of the homenet. 378 A mechanism will be present that allows devices that have been 379 configured to publicly advertise services to indicate to the homenet 380 that the public bit and/or the backup bit will be set in RRsets that 381 they publish. 383 3.4. Maintaining Namespaces 385 Homenets support three methods for maintaining local namespaces. 386 These rely on Multicast DNS, DNS updates, and any of the management 387 mechanisms mentioned in Section 6. 389 3.4.1. Multicast DNS 391 HNRs cooperate to maintain a DNS mirror of the set of names published 392 by mDNS. This works similarly to the Multicast DNS Hybrid Proxy 393 [10]. However, the DNSSD hybrid proxy exposes the topology of the 394 network in which it operates to the user. 396 In order to avoid this, the homenet solution maintains a host 397 namespace for each non-edge link in the homenet. Queries for names 398 in the host namespace are looked up in the per-link host namespaces 399 as well (and trigger mDNS queries as in the hybrid solution). When a 400 cross-link name conflict is present for a name, the name is presented 401 with a short modifier identifying the link. 403 For example, if two devices on two separate links both advertise the 404 name 'janus' using mDNS, and the name 'janus' is not present in the 405 host namespace, the two hosts' names are modified to, for example, 406 'janus-1' and 'janus-2'. If both devices present the human readable 407 name 'Janus', then that name is presented as 'Janus (1)' and 'Janus 408 (2)'. If the name 'janus' appears in the host namespace, then that 409 name is presented just as 'janus'. 411 If a mDNS service advertises a name that appears in the host 412 namespace, the HNR that hears the advertisement will defend the name, 413 forcing the mDNS service to choose a different name. 415 This solution shares a problem that mdns hybrid has: user interfaces 416 on hosts that present mDNS names in their mDNS format (e.g., 417 'janus.local') will not have a DNS entry for 'janus.local'. 418 Connections to such hosts using the name presented in the UI will 419 work when both hosts are attached to the same link, but not 420 otherwise. 422 It is preferable that devices that are homenet-aware publish their 423 names using DNS updates rather than using mDNS. mDNS is not 424 supported as a query mechanism on homenets, other than in the sense 425 that homeneds do not filter mDNS traffic on the local link. Service 426 discovery is instead done using DNS service discovery [8]. This 427 mechanism is supported on all modern devices that do service 428 discovery, so there is no need to rely on mDNS. 430 3.4.2. DNS Update 432 DNS updates to the resolver on the local link are supported for 433 adding names to local zones. When an update is received, if the name 434 being updated does not exist, or if the update contains the same 435 information as is present in the existing record, then the update is 436 accepted. If a conflicting entry exists, the update is rejected. 438 This update procedure is available to hosts that implement DNS update 439 for DNS service discovery, but are not homenet-aware. Hosts cannot 440 delete records they have added, nor modify them; such records can 441 only time out. Updates to server list records require that the host 442 referenced by the update exist, and that the update come from that 443 host. Such updates are additive, and are removed automatically when 444 they become stale. 446 Hosts that are homenet-aware generate a KEY record containing a 447 public key for which they retain the private key. They then publish 448 their name in the host namespace, with whatever data they intend to 449 publish on the name, and include the KEY record they have generated. 450 The update is signed using SIG(0) on the provided key. If a record 451 already exists, and does not contain the same KEY record, the update 452 is refused. Otherwise it is accepted. 454 Homenet-aware hosts can then update their entries in the address 455 table and in service tables by using their KEY record with SIG(0). 456 Entries can be added _and_ deleted. However, only modifications to 457 RRs that reference the name in the host namespace are allowed; all 458 other RRs must be left as they are. 460 3.5. Recovery from loss 462 In principle the names in the zone aren't precious. If there are 463 multiple HNRs and one is replaced, the replacement recovers by 464 copying the local namespaces and other info from the others. If all 465 are lost, there are a few pieces of persistent data that need to be 466 recovered: 468 o The global name 470 o The ZSK for both local namespaces 472 o Names configured statically through the UI 474 All other names were acquired dynamically, and recovery is simply a 475 matter of waiting for the device to re-announce its name, which will 476 happen when the device is power cycled, and also may happen when it 477 sees a link state transition. The hybrid mDNS implementation will 478 also discover devices automatically when service queries are made. 480 Devices that maintain their state using DNS update, but that are not 481 homenet-aware, may or may not update their information when they see 482 a link state transition. Homenet-aware devices will update whenever 483 they see a link-state transition, and also update periodically. When 484 the Homenet configuration has been lost, HNRs advertise a special ND 485 option that indicates that naming and service discovery on the 486 homenet is in a recovery state. Homenet-aware devices will be 487 sensitive to this ND option, and will update when it is seen. 489 Homenets will present an standard management API, reachable through 490 any homenet router, that allows a device that has stored the DNSSEC 491 ZSK and KSK to re-upload it when it has been lost. This is safest 492 solution for the end user: the keys can be stored on some device they 493 control, under password protection. 495 ZSKs and KSKs can also be saved by the ISP or GNRP and re-installed 496 using one of the management APIs. This solution is not preferable, 497 since it means that the end user's security is reliant on the 498 security of the GNRP or ISP's infrastructure. 500 If the ZSK and KSK are lost, they can be regenerated. This requires 501 that the homenet's global name change: there is no secure way to re- 502 key in this situation. Once the homenet has been renamed and re- 503 keyed, all devices that use the homenet will simply see it as a 504 different homenet. 506 3.6. Well-known names 508 Homenets serve a zone under the special-use top-level name [TBD2] 509 that answers queries for local configuration information and can be 510 used to advertise services provided by the homenet (as opposed to 511 services present on the homenet). This provides a standard means for 512 querying the homenet that can be assumed by management functions and 513 homenet clients. A registry of well-known names for this zone is 514 defined in IANA considerations (Section 9). Names and RRs in this 515 zone are only ever provided by the homenet--this is not a general 516 purpose service discovery zone. 518 All resolvers on the homenet will answer questions about names in 519 this zone. Entries in the zone are guaranteed not to be globally 520 unique: different homenets are guaranteed to give independent and 521 usually different answers to queries against this zone. Hosts and 522 services that use the special names under this TLD are assumed to be 523 aware that it is a special TLD. If such hosts cache DNS entries, DNS 524 entries under this TLD are discarded whenever the host detects a 525 network link state transition. 527 The uuid.[TBD2] name contains a TXT RR that contains the UUID of the 528 homenet. Each homenet generates its own distinct UUID; homenet 529 routers on any particular homenet all use the same UUID, which is 530 agreed upon using HNCP. If the homenet has not yet generated a UUID, 531 queries against this name will return NXDOMAIN. 533 The global-name.[TBD2] name contains a PTR record that contains the 534 global name of the homenet. If the homenet does not have a global 535 name, queries against this name will return NXDOMAIN. 537 The global-name-register.[TBD2] name contains one or more A and/or 538 AAAA records referencing hosts (typically HNRs) that provide a 539 RESTful API over HTTP that can be used to register the global name of 540 the homenet, once that name has been configured. 542 The all-resolver-names.[TBD2] name contains an NS RRset listing a 543 global name for each HNR. It will return NXDOMAIN if the homenet has 544 no global name. These names are generated automatically by each HNR 545 when joining the homenet, or when a homenet to which the HNR is 546 connected establishes a global name. 548 4. Name Resolution 550 4.1. Configuring Resolvers 552 Hosts on the homenet receive a set of resolver IP addresses using 553 either DHCP or RA. IPv4-only hosts will receive IPv4 addresses of 554 resolvers, if available, over DHCP. IPv6-only hosts will receive 555 resolver IPv6 addresses using either stateful (if available) or 556 stateless DHCPv6, or through the domain name option in router 557 advertisements. All homenet routers provide resolver information 558 using both stateless DHCPv6 and RA; support for stateful DHCPv6 and 559 DHCPv4 is optional, however if either service is offered, resolver 560 addresses will be provided using that mechanism as well. Resolver IP 561 addresses will always be IP addresses on the local link: every HNR is 562 required to provide name resolution service. This is necessary to 563 allow DNS update using presence on-link as a mechanism for rejecting 564 off-network attacks. 566 4.2. Configuring Service Discovery 568 DNS-SD uses several default domains for advertising local zones that 569 are available for service discovery. These include the '.local' 570 domain, which is searched using mDNS, and also the IPv4 and IPv6 571 reverse zone corresponding to the prefixes in use on the local 572 network. For the homenet, no support for queries against the 573 ".local" zone is provided by HNRs: a ".local" query will be satisfied 574 or not by services present on the local link. This should not be an 575 issue: all known implementations of DNSSD will do unicast queries 576 using the DNS protocol. 578 Service discovery is configured using the technique described in 579 Section 11 of DNS-Based Service Discovery [8]. HNRs will answer 580 domain enumeration ueries against every IPv4 address prefix 581 advertised on a homenet link, and every IPv6 address prefix 582 advertised on a homenet link, including prefixes derived from the 583 homenet's ULA(s). Whenever the "" sequence appears in this 584 section, it references each of the domains mentioned in this 585 paragraph. 587 Homenets advertise the availability of several browsing zones in the 588 "b._dns_sd." subdomain. The zones advertised are the "well 589 known" zone (TBD2) and the zone containing the local namespace. If 590 the global name is available, only that name is advertised for the 591 local namespace; otherwise [TBD1] is advertised. Similarly, if the 592 global name is available, it is advertised as the default browsing 593 and service registration domain under "db._dns_sd.", 594 "r._dns_sd.", "dr._dns_sd." and 595 "lb._dns_sd."; otherwise, the name [TBD1] is advertised as 596 the default. 598 4.3. Resolution of local namespaces 600 The local namespace appears in two places, under [TBD1] and, if the 601 homenet has a global name, under the global name. Resolution from 602 inside the homenet yields the contents of the local namespaces; 603 resolution outside of the homenet yields the contents of the public 604 namespaces. If there is a global name for the homenet, RRs 605 containing names in both instances of the local namespace are 606 qualified with the global name; otherwise they are qualified with 607 [TBD1]. 609 4.4. Service Discovery Resolution 611 Because homenets provide service discovery over DNS, rather than over 612 mDNS, support for DNS push notifications [11]. When a query arrives 613 for a local namespace, and no data exists in that namespace to answer 614 the query, that query is retransmitted as an mDNS query. Data that 615 exists to answer the query in mdns cached namespaces does not prevent 616 an mDNS query being issued. 618 If there is data available to answer the query in the host namespace 619 or any of the dnssd cached namespaces, that data is aggregated and 620 returned immediately. If the host that sent the query requested push 621 notification, then any mDNS responses that come in subsequent to the 622 initial answer are sent as soon as they are received, and also added 623 to the cache. This means that if a name has been published directly 624 using DNS, no mDNS query for that name is ever generated. 626 4.5. Local and Public Zones 628 The homenet's global name serves both as a unique identifier for the 629 homenet and as a delegation point in the DNS for the zone containing 630 the homenet's forward namespace. There are two versions of the 631 forward namespace: the public version and the private version. Both 632 of these versions of the namespace appear under the global name 633 delegation, depending on which resolver a host is querying. 635 The homenet provides two versions of the zone. One is the public 636 version, and one is the local version. The public version is never 637 visible on the homenet (could be an exception for a guest net). The 638 public version is available outside of the homenet. The local 639 version is visible on the homenet. Whenever the zone is updated, it 640 is signed with the ZSK. Both versions of the zone are signed; the 641 local signed version always has a serial number greater than the 642 public signed version. [we want to not re-sign the public zone if no 643 public names in the private zone changed.] 645 This dual publication model relies on hosts connected to the homenet 646 using the local resolver and not some external resolver. Hosts that 647 use an external resolver will see the public version of the 648 namespace. From a security UI design perspective, allowing queries 649 from hosts on the homenet to resolvers off the homenet is risky, and 650 should be prevented by default. This is because if the user sees 651 inconsistent behavior on hosts that have external resolvers 652 configured, they may attempt to fix this by making all local names 653 public. If an alternate external resolver is to be used, it should 654 be configured on the homenet, not on the individual host. 656 One way to make this work is to intercept all DNS queries to non- 657 homenet IP addresses, check to see if they reference the local 658 namespace, and if so resolve them locally, answering as if from the 659 remote cache. If the query does not reference a local namespace, and 660 is listed as "do not forward" in RFC 6761 or elsewhere, it can be 661 sent to the intended cache server for resolution without any special 662 handling for the response. This functionality is not required for 663 homenet routers, but is likely to present a better user experience. 665 4.6. DNSSEC Validation 667 All namespaces are signed using the same ZSK. The ZSK is signed by a 668 KSK, which is ideally kept offline. Validation for the global name 669 is done using the normal DNSSEC trust hierarchy. Validation for the 670 [TBD1] and [TBD2] zones can be done by fetching the global name from 671 the [TBD2] zone, fetching and validating the ZSK using DNSSEC, and 672 then using that as a trust anchor. 674 Only homenet-aware hosts will be able to validate names in the [TBD1] 675 and [TBD2] zones. The homenet-aware host validates non-global zones 676 by determining which homenet it is connected to querying the 677 uuid.[TBD2] and global-name.[TBD2] names. If there is an answer for 678 the global-name.[TBD2] query, validation can proceed using the trust 679 anchor published in the zone that delegates the global name. If only 680 the uuid is present, then the homenet-aware host can use trust-on- 681 first-use to validate that an answer came from the homenet that 682 presented that UUID. This provides only a limited degree of 683 trustworthiness. 685 4.7. Support for Multiple Provisioning Domains 687 Homenets must support the Multiple Provisioning Domain Architecture 688 [9]. In order to support this architecture, each homenet router that 689 provides name resolution must provide one resolver for each 690 provisioning domain (PvD). Each homenet router will advertise one 691 resolver IP address for each PvD. DNS requests to the resolver 692 associated with a particular PvD, e.g. using RA options [12] will be 693 resolved using the external resolver(s) provisioned by the service 694 provider responsible for that PvD. 696 The homenet is a separate provisioning domain from any of the service 697 providers. The global name of the homenet can be used as a 698 provisioning domain identifier, if one is configured. Homenets 699 should allow the name of the local provisioning domain to be 700 configured; otherwise by default it should be "Home Network xxx", 701 where xxx is the generated portion of the homenet's ULA prefix, 702 represented as a base64 string. 704 The resolver for the homenet PvD is offered as the primary resolver 705 in RAs and through DHCPv4 and DHCPv6. When queries are made to the 706 homenet-PvD-specific resolver for names that are not local to the 707 homenet, the resolver will use a round-robin technique, alternating 708 between service providers with each step in the round-robin process, 709 and then also between external resolvers at a particular service 710 provider if a service provider provides more than one. The round- 711 robining should be done in such a way that no service provider is 712 preferred, so if service provider A provides one caching resolver 713 (A), and service provider B provides two (B1, B2), the round robin 714 order will be (A, B1, A, B2), not (A, B1, B2). 716 Every resolver provided by the homenet, regardless of which 717 provisioning domain it is intended to serve, will accept updates for 718 services in the local service namespace from hosts on the local link. 720 4.8. Using the Local Namespace While Away From Home 722 Homenet routers do not answer unauthenticated DNS queries from off 723 the local network. However, some applications may benefit from the 724 ability to resolve names in the local namespace while off-network. 725 Therefore hosts connected to the homenet can register keys in the 726 host namespace using DNS Update. Such keys must be validated by the 727 end user before queries against the local namespace can be 728 authenticated using that key. A host that will make remote queries 729 to the local namespace caches the names of all DNS servers on the 730 homenet by querying all-resolver-names.[TBD2]. 732 Hosts that require name resolution from the local network must have a 733 stub resolver configured to contact the dns server on one or more 734 routers in the homenet when resolving names in the host or address 735 namespaces. To do this, resolvers must know the global name of the 736 local namespace, which they can retain from previous connections to 737 the homenet. 739 The homenet may not have a stable IP address, so such resolvers 740 cannot merely cache the IP address of the homenet routers. Instead, 741 they cache the NS record listing the HNRs and use those names to 742 determine the IP addresses of the homenet routers at the time of 743 resolution. Such IP addresses can be safely cached for the duration 744 of the TTL of the A or AAAA record that contained them. The names of 745 the homenet router DNS servers should be randomly generated so that 746 they can't be guessed by off-network attackers. 748 To make a homenet DNS query, the host signs the request using SIG(0) 749 with the key that they registered to the homenet. The homenet router 750 first checks the question in the query for validity: it must be a 751 subdomain of the global name. The homenet router then checks the 752 name of the signing key against the list of cached, validated keys; 753 if that key is cached and validated, then the homenet router attempts 754 to validate the SIG(0) signature using that key. If the signature is 755 valid, then the homenet router answers the query. If the zone 756 doesn't have a trust anchor in the parent zone, the responding server 757 signs the answer with its own ZSK. The resolver that sent the query 758 validates the response using DNSSEC if possible, and otherwise using 759 the ZSK directly. 761 5. Publishing the Public Namespace 763 5.1. Acquiring the Global Name 765 There are two ways to acquire a global name: the end-user can 766 register a domain name using a public domain name registry, or the 767 end-user can be assigned a subdomain of a registered domain by a 768 homenet global name service provider. We will refer to this as the 769 Global Name Registration Provider [GNRP]. In either case, the 770 registration process can either be manual or automatic. Homenet 771 routers support automatic registration regardless of the source of 772 the homenet's global name, using a RESTful API. 774 5.2. Hidden Primary/Public Secondaries 776 The default configuration for a homenet's external name service is 777 that the primary server for the zone is not published in an NS record 778 in the zone's delegation. Instead, the GNRP provides authoritative 779 name service for the zone. Whenever the public zone is updated, the 780 hidden primary sends NOTIFY messages to all the secondaries, using 781 the zone's ZSK to sign the message. 783 When any of the GNRP secondary servers receives a notify for the 784 zone, it checks to see that the notify is signed with a valid ZSK for 785 that zone. If so, it contacts the IP address from which the NOTIFY 786 was send and initiates a zone transfer. Using this IP address avoids 787 renumbering issues. Upon finishing the zone transfer, the zone is 788 validated using each ZSK used to sign it. If any validation fails, 789 the new version of the zone is discarded. If updates have been 790 recevied, but no valid updates received, over a user-settable 791 interval defaulting to a day (or?), the GNRP will communicate to the 792 registered user that there is a problem. 794 The reverse zone for any prefix delegated by an ISP should be 795 delegated by that ISP to the home gateway to which the delegation was 796 sent. The list of secondaries for that zone is sent to the home 797 gateway using DHCPv6 prefix delegation. The ZSK is announced to the 798 ISP in each DHCP PD message sent by the home gateway. Whenever an 799 update is made to this zone, the home gateway sends a NOTIFY to each 800 of the listed secondaries for the delegation, and updates occur as 801 described above. Once the delegation is established, the ISP will 802 not accept a different ZSK unless the prefix and its delegated zone 803 are reassigned. 805 5.3. PKI security 807 All communication with the homenet using HTTP is encrypted using 808 opportunistic security. If the homenet is configured with PKI, then 809 the PKI certificate is used. Homenets should automatically acquire a 810 PKI certificate when a global name is established. This certificate 811 should be published in a TLSA record in the host namespace on any 812 hostnames on which HTTP service is offered by HNRs. 814 5.4. Renumbering 816 The homenet may renumber at any time. IP address RRs published in 817 any namespace must never have a TTL that is longer than the valid 818 lifetime for the prefix from which the IP address was allocated. If 819 a particular ISP has deprecated a prefix (its preferred lifetime is 820 zero), IP addresses derived from that prefix are not published in the 821 any namespace. If more than one prefix is provided by the same ISP 822 and some have different valid lifetimes, only IP addresses in the 823 prefix or prefixes with the longest valid lifetime are published. 825 5.5. ULA 827 Homenets have at least one ULA prefix. If a homenet has two ULA 828 prefixes, and one is deprecated, addresses in the second ULA prefix 829 are not published. The default source address selection algorithm 830 ensures that if a service is available on a ULA, that ULA will be 831 used rather than the global address. Therefore, no special effort is 832 made in the DNS to offer only ULAs in response to local queries. 834 6. Management 836 6.1. End-user management 838 Homenets provide two management mechanisms for end users: an HTTP- 839 based user interface and an HTTP-based RESTful API [tbw]. 841 Homenets also provide a notification for end users. By default, when 842 an event occurs that requires user attention, the homenet will 843 attract the user's attention by triggering captive portal detection 844 on user devices. Users can also configure specific devices to 845 received management alerts using the RESTful management API; in this 846 case, no captive portal notification is performed. 848 6.2. Central management 850 Possibly can be done mostly through RESTful API, but might want 851 Netconf/Yang as well. Should be possible to have the local namespace 852 mastered on an external DNS auth server, e.g. in case a bunch of HNRs 853 are actually set up in an org, or in case an ISP wants to provide a 854 service package for users who would rather not have an entirely self- 855 operating network. 857 7. Privacy Considerations 859 Private information must not leak out as a result of publishing the 860 public namespace. The 'public' flag on RRsets in homenet-managed 861 namespaces prevents leakage of information that has not been 862 explicitly marked for publication. 864 The privacy of host information on the local net is left to hosts. 865 Various mechanisms are available to hosts to ensure that tracking 866 does not occur if it is not desired. However, devices that need to 867 have special permission to manage the homenet will inevitably reveal 868 something about themselves when doing so. It may be possible to use 869 something like HTTP token binding[13] to mitigate this risk. 871 8. Security Considerations 873 There are some clear issues with the security model described in this 874 document, which will be documented in a future version of this 875 section. A full analysis of the avenues of attack for the security 876 model presented here have not yet been done, and must be done before 877 the document is published. 879 9. 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 Domain Names 899 registry: 901 TBD1 Suggested value: "homenet" 903 TBD2 Suggested value: "_hnsd" 905 10. 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] Rekhter, Y., Moskowitz, B., Karrenberg, D., de Groot, G., 916 and E. Lear, "Address Allocation for Private Internets", 917 BCP 5, RFC 1918, DOI 10.17487/RFC1918, February 1996, 918 . 920 [4] Vixie, P., Ed., Thomson, S., Rekhter, Y., and J. Bound, 921 "Dynamic Updates in the Domain Name System (DNS UPDATE)", 922 RFC 2136, DOI 10.17487/RFC2136, April 1997, 923 . 925 [5] Hinden, R. and B. Haberman, "Unique Local IPv6 Unicast 926 Addresses", RFC 4193, DOI 10.17487/RFC4193, October 2005, 927 . 929 [6] Andrews, M., "Locally Served DNS Zones", BCP 163, 930 RFC 6303, DOI 10.17487/RFC6303, July 2011, 931 . 933 [7] Cheshire, S. and M. Krochmal, "Multicast DNS", RFC 6762, 934 DOI 10.17487/RFC6762, February 2013, 935 . 937 [8] Cheshire, S. and M. Krochmal, "DNS-Based Service 938 Discovery", RFC 6763, DOI 10.17487/RFC6763, February 2013, 939 . 941 [9] Anipko, D., Ed., "Multiple Provisioning Domain 942 Architecture", RFC 7556, DOI 10.17487/RFC7556, June 2015, 943 . 945 [10] Cheshire, S., "Hybrid Unicast/Multicast DNS-Based Service 946 Discovery", draft-ietf-dnssd-hybrid-03 (work in progress), 947 February 2016. 949 [11] Pusateri, T. and S. Cheshire, "DNS Push Notifications", 950 draft-ietf-dnssd-push-07 (work in progress), April 2016. 952 [12] Korhonen, J., Krishnan, S., and S. Gundavelli, "Support 953 for multiple provisioning domains in IPv6 Neighbor 954 Discovery Protocol", draft-ietf-mif-mpvd-ndp-support-03 955 (work in progress), February 2016. 957 [13] Popov, A., Nystrom, M., Balfanz, D., Langley, A., and J. 958 Hodges, "Token Binding over HTTP", draft-ietf-tokbind- 959 https-05 (work in progress), July 2016. 961 Author's Address 963 Ted Lemon 964 Nominum, Inc. 965 800 Bridge Parkway 966 Redwood City, California 94065 967 United States of America 969 Phone: +1 650 381 6000 970 Email: ted.lemon@nominum.com