idnits 2.17.1 draft-ietf-homenet-front-end-naming-delegation-15.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 (May 13, 2021) is 1050 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Outdated reference: A later version (-12) exists of draft-ietf-dprive-xfr-over-tls-11 ** Downref: Normative reference to an Informational RFC: RFC 4192 ** Obsolete normative reference: RFC 4960 (Obsoleted by RFC 9260) ** Downref: Normative reference to an Informational RFC: RFC 6092 ** Downref: Normative reference to an Informational RFC: RFC 7010 ** Downref: Normative reference to an Informational RFC: RFC 7084 ** Downref: Normative reference to an Informational RFC: RFC 7368 ** Downref: Normative reference to an Informational RFC: RFC 7558 ** Downref: Normative reference to an Informational RFC: RFC 7707 == Outdated reference: A later version (-12) exists of draft-ietf-dprive-dnsoquic-02 == Outdated reference: A later version (-24) exists of draft-ietf-homenet-naming-architecture-dhc-options-12 == Outdated reference: A later version (-02) exists of draft-richardson-homerouter-provisioning-00 -- Obsolete informational reference (is this intentional?): RFC 2845 (Obsoleted by RFC 8945) -- Obsolete informational reference (is this intentional?): RFC 8499 (Obsoleted by RFC 9499) Summary: 8 errors (**), 0 flaws (~~), 5 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Homenet D. Migault 3 Internet-Draft Ericsson 4 Intended status: Standards Track R. Weber 5 Expires: November 14, 2021 Nominum 6 M. Richardson 7 Sandelman Software Works 8 R. Hunter 9 Globis Consulting BV 10 May 13, 2021 12 Simple Provisioning of Public Names for Residential Networks 13 draft-ietf-homenet-front-end-naming-delegation-15 15 Abstract 17 Home owners often have IPv6 devices that they wish to access over the 18 Internet using names. 19 Outsourcing the DNS servers to a DNS infrastructure protects against 20 possible DDoS attacks as well as sudden renumbering of the home 21 network. It has been possible to register and populate a DNS Zone 22 with names since DNS became a thing, but it has been an activity 23 typically reserved for experts. This document automates the process 24 through creation of a Homenet Naming Authority (HNA), whose 25 responsibility is to select, sign and publish names to a set of 26 publicly visible servers. 28 This document describes the mechanism that enables the HNA to 29 outsource the naming service to the DNS Outsourcing Infrastructure 30 (DOI) via a Distribution Manager (DM). 32 In addition, this document deals with publication of a corresponding 33 reverse zone. 35 Status of This Memo 37 This Internet-Draft is submitted in full conformance with the 38 provisions of BCP 78 and BCP 79. 40 Internet-Drafts are working documents of the Internet Engineering 41 Task Force (IETF). Note that other groups may also distribute 42 working documents as Internet-Drafts. The list of current Internet- 43 Drafts is at https://datatracker.ietf.org/drafts/current/. 45 Internet-Drafts are draft documents valid for a maximum of six months 46 and may be updated, replaced, or obsoleted by other documents at any 47 time. It is inappropriate to use Internet-Drafts as reference 48 material or to cite them other than as "work in progress." 49 This Internet-Draft will expire on November 14, 2021. 51 Copyright Notice 53 Copyright (c) 2021 IETF Trust and the persons identified as the 54 document authors. All rights reserved. 56 This document is subject to BCP 78 and the IETF Trust's Legal 57 Provisions Relating to IETF Documents 58 (https://trustee.ietf.org/license-info) in effect on the date of 59 publication of this document. Please review these documents 60 carefully, as they describe your rights and restrictions with respect 61 to this document. Code Components extracted from this document must 62 include Simplified BSD License text as described in Section 4.e of 63 the Trust Legal Provisions and are provided without warranty as 64 described in the Simplified BSD License. 66 Table of Contents 68 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 69 1.1. Selecting Names to Publish . . . . . . . . . . . . . . . 5 70 1.2. Alternative solutions . . . . . . . . . . . . . . . . . . 6 71 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 7 72 3. Architecture Description . . . . . . . . . . . . . . . . . . 8 73 3.1. Architecture Overview . . . . . . . . . . . . . . . . . . 8 74 3.2. Distribution Manager Communication Channels . . . . . . . 11 75 4. Control Channel . . . . . . . . . . . . . . . . . . . . . . . 12 76 4.1. Information to Build the Public Homenet Zone . . . . . . 13 77 4.2. Information to build the DNSSEC chain of trust . . . . . 13 78 4.3. Information to set the Synchronization Channel . . . . . 14 79 4.4. Deleting the delegation . . . . . . . . . . . . . . . . . 14 80 4.5. Messages Exchange Description . . . . . . . . . . . . . . 14 81 4.5.1. Retrieving information for the Public Homenet Zone. . 14 82 4.5.2. Providing information for the DNSSEC chain of trust . 15 83 4.5.3. Providing information for the Synchronization Channel 16 84 4.5.4. HNA instructing deleting the delegation . . . . . . . 17 85 4.6. Securing the Control Channel . . . . . . . . . . . . . . 17 86 4.7. Implementation Concerns . . . . . . . . . . . . . . . . . 18 87 5. Synchronization Channel . . . . . . . . . . . . . . . . . . . 19 88 5.1. Securing the Synchronization Channel . . . . . . . . . . 20 89 6. DM Distribution Channel . . . . . . . . . . . . . . . . . . . 20 90 7. HNA Security Policies . . . . . . . . . . . . . . . . . . . . 20 91 8. DNSSEC compliant Homenet Architecture . . . . . . . . . . . . 21 92 9. Homenet Reverse Zone Channels Configuration . . . . . . . . . 21 93 10. Homenet Public Zone Channel Configurations . . . . . . . . . 22 94 11. Renumbering . . . . . . . . . . . . . . . . . . . . . . . . . 24 95 11.1. Hidden Primary . . . . . . . . . . . . . . . . . . . . . 24 96 12. Privacy Considerations . . . . . . . . . . . . . . . . . . . 25 97 13. Security Considerations . . . . . . . . . . . . . . . . . . . 26 98 13.1. HNA DM channels . . . . . . . . . . . . . . . . . . . . 26 99 13.2. Names are less secure than IP addresses . . . . . . . . 26 100 13.3. Names are less volatile than IP addresses . . . . . . . 27 101 14. Information Model for Outsourced information . . . . . . . . 27 102 14.1. Outsourced Information Model . . . . . . . . . . . . . . 28 103 15. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 30 104 16. Acknowledgment . . . . . . . . . . . . . . . . . . . . . . . 30 105 17. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 30 106 18. References . . . . . . . . . . . . . . . . . . . . . . . . . 31 107 18.1. Normative References . . . . . . . . . . . . . . . . . . 31 108 18.2. Informative References . . . . . . . . . . . . . . . . . 34 109 Appendix A. Envisioned deployment scenarios . . . . . . . . . . 36 110 A.1. CPE Vendor . . . . . . . . . . . . . . . . . . . . . . . 36 111 A.2. Agnostic CPE . . . . . . . . . . . . . . . . . . . . . . 36 112 Appendix B. Example: A manufacturer provisioned HNA product flow 37 113 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 38 115 1. Introduction 117 The Homenet Naming Authority (HNA) is responsible for making devices 118 within the home network accessible by a public name within the home 119 network as well as from outside the home network (e.g. the Internet). 120 IPv6 connectivity provides the possibility of global end to end IP 121 connectivity. 123 The use of a DNS zone for each home network is a reasonable and 124 scalable way to make the set of public names visible. There are a 125 number of ways to populate such a zone. This specification proposes 126 a way based on a number of assumptions about typical home networks. 128 1. The names of the devices accessible from the Internet are stored 129 in the Public Homenet Zone, served by a DNS authoritative server. 131 2. It is unlikely that home networks will contain sufficiently 132 robust platforms designed to host and expose to the Internet a 133 service such as the DNS and as such would expose the home network 134 to DDoS attacks. 136 3. [RFC7368] emphasizes that the home network is subject to 137 connectivity disruptions with the ISP. But, names used within 138 the home MUST be resilient against such disruption. 140 This specification makes the public names resolvable within both the 141 home network and on the Internet, even when there are disruptions. 143 This is achieved by having a function inside the home network that 144 builds, signs, publishes, and manages a Public Homenet Zone, thus 145 providing bindings between public names, IP addresses, and other RR 146 types. 148 The management of the names can be under the responsibility the 149 Customer Premises Equipment (CPE) does. Other devices within the 150 home network could fulfill this role e.g. a Network Attached Storage 151 server, but for simplicity, this document assumes the function is 152 located on one of the CPE devices. 154 The homenet architecture [RFC7368] makes it clear that a home network 155 may have multiple CPEs. The management of the Public Homenet Zone 156 involves DNS specific mechanisms that cannot be distributed over 157 multiple servers (primary server), when multiple nodes can 158 potentially manage the Public Homenet Zone, a single node needs to be 159 selected per outsourced zone. This selected node is designated as 160 providing the HNA function. 162 The process by which a single HNA is selected per zone is not in 163 scope for this document. It is envisioned that a future document 164 will describe an HNCP mechanism to elect the single HNA. 166 CPEs, which may host the HNA function are usually low powered devices 167 not designed for supporting a heavy traffic. As a result, hosting an 168 authoritative DNS service visible to the Internet may expose the home 169 network to resource exhaustion and other attacks. On the other hand, 170 if the only copy of the public zone is on the Internet, then Internet 171 connectivity disruptions would make the names unavailable inside the 172 homenet. 174 In order to avoid resource exhaustion and other attacks, this 175 document describes in Section 3.1 an architecture that outsources the 176 authoritative naming service of the home network. More specifically, 177 the HNA builds the Public Homenet Zone and outsources it to a DNS 178 Outsourcing Infrastructure (DOI) via a Distribution Manager (DM). 179 The DOI is in charge of publishing the corresponding Public Homenet 180 Zone on the Internet. The transfer of DNS zone information is 181 achieved using standard DNS mechanisms involving primary and 182 secondary DNS servers, with the HNA being a stealth primary, and the 183 DM a secondary. 185 In order to keep the Public Homenet Zone up-to-date Section 5 186 describes how the HNA and the DOI synchronize the Pubic Homenet Zone. 188 The architecture is explicitly designed to enable fully functional 189 DNSSEC, and the Public Homenet Zone is expected to be signed with a 190 secure delegation. DNSSEC key management and zone signing are 191 handled by the HNA. 193 Section 10 discusses management and configuration of the Public 194 Homenet Zone. It shows that the HNA configuration of the DOI can 195 involve no or little interaction with the end user. More 196 specifically, it shows that the existence of an account in the DOI is 197 sufficient for the DOI to push the necessary configuration. In 198 addition, when the DOI and CPE are both managed by an ISP, the 199 configuration can be entirely automated - see Section 9. 201 Section 9 discusses management of one or more reverse zones. It 202 shows that management of the reverse zones can be entirely automated 203 and benefit from a pre-established relation between the ISP and the 204 home network. Note that such scenarios may also be met for the 205 Public Homenet Zone. 207 Section 11 discusses how renumbering should be handled. Finally, 208 Section 12 and Section 13 respectively discuss privacy and security 209 considerations when outsourcing the Public Homenet Zone. 211 The Public Homenet Zone is expected to contain public information 212 only in a single universal view. This document does not define how 213 the information required to construct this view is derived. 215 It is also not in the scope of this document to define names for 216 exclusive use within the boundaries of the local home network. 217 Instead, local scope information is expected to be provided to the 218 home network using local scope naming services. mDNS [RFC6762] and 219 DNS-SD [RFC6763] are two examples of these services. Currently mDNS 220 is limited to a single link network. However, future protocols and 221 architectures [I-D.ietf-homenet-simple-naming] are expected to 222 leverage this constraint as pointed out in [RFC7558]. 224 1.1. Selecting Names to Publish 226 While this document does not create any normative mechanism by which 227 the selection of names to publish, this document anticipates that the 228 home network administrator (a humuan), will be presented with a list 229 of current names and addresses present on the inside of the home 230 network. 232 The administrator would mark which devices (by name), are to be 233 published. The HNA would then collect the IPv6 address(es) 234 associated with that device, and put the name into the Public Homenet 235 Zone. The address of the device can be collected from a number of 236 places: mDNS [RFC6762], DHCP [RFC6644], UPnP, PCP [RFC6887], or 237 manual configuration. 239 A device may have a Global Unicast Address (GUA), a Unique Local IPv6 240 Address (ULA), as as well IPv6-Link-Local addresses, IPv4-Link-Local 241 Addresses, and RFC1918 addresses. Of these the link-local are never 242 useful for the Public Zone, and should be omitted. The IPv6 ULA and 243 the RFC1918 addresses may be useful to publish, if the home network 244 environment features a VPN that would allow the home owner to reach 245 the network. 247 The IPv6 ULA addressees are significantly safer to publish, as the 248 RFC1918 addressees are likely to be confusing to any other entity. 250 In general, one expects the GUA to be the default address to be 251 published. However, during periods when the home network has 252 connectivity problems, the ULA and RFC1918 addressees can be used 253 inside the home, and the mapping from public name to locally useful 254 location address would permit many services secured with HTTPS to 255 continue to operate. 257 1.2. Alternative solutions 259 An alternative existing solution in IPv4 is to have a single zone, 260 where a host uses a RESTful HTTP service to register a single name 261 into a common public zone. This is often called "Dynamic DNS", and 262 there are a number of commercial providers, including Dyn, Gandi etc. 263 These solutions were typically used by a host behind the CPE to make 264 its CPE IPv4 address visible, usually in order to enable incoming 265 connections. This is the most common scenario considered in this 266 section, while some variant may also consider the client being hosted 267 in the CPE. 269 For a very few number (one to three) of hosts, the use of such a 270 system provides an alternative to the architecture described in this 271 document. The alternative - even adapted to IPv6 and ignoring those 272 associated to an IPv4 development - does suffer from some severe 273 limitations: 275 o the CPE/HNA router is unaware of the process, and cannot respond 276 to queries for these names when there are disruptions in 277 connectivity. This makes the home user or application dependent 278 on having to resolve different names in the event of outages or 279 disruptions. 281 o the CPE/HNA router cannot control the process. Any host can do 282 this regardless of whether or not the home network administrator 283 wants the name published or not. There is therefore no possible 284 audit trail. 286 o the credentials for the dynamic DNS server need to be securely 287 transferred to all hosts that wish to use it. This is not a 288 problem for a technical user to do with one or two hosts, but it 289 does not scale to multiple hosts and becomes a problem for non- 290 technical users. 292 o "all the good names are taken" - current services put everyone's 293 names into some small set of zones, and there are often conflicts. 294 Distinguishing similar names by delegation of zones was among the 295 primary design goals of the DNS system. 297 o The RESTful services do not always support all RR types. The 298 homenet user is dependent on the service provider supporting new 299 types. By providing full DNS delegation, this document enables 300 all RR types and also future extensions. 302 There is no technical reason why a RESTful service could not provide 303 solutions to many of these problems, but this document describes a 304 DNS-based solution. 306 2. Terminology 308 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 309 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 310 "OPTIONAL" in this document are to be interpreted as described in 311 BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all 312 capitals, as shown here. 314 Customer Premises Equipment: (CPE) is a router providing 315 connectivity to the home network. 317 Homenet Zone: is the DNS zone for use within the boundaries of the 318 home network: 'home.arpa' (see [RFC8375]). This zone is not 319 considered public and is out of scope for this document. 321 Registered Homenet Domain: is the domain name that is associated 322 with the home network. 324 Public Homenet Zone: contains the names in the home network that are 325 expected to be publicly resolvable on the Internet. 327 Homenet Naming Authority(HNA): is a function responsible for managing 328 the Public Homenet Zone. This includes populating the Public Homenet 329 Zone, signing the zone for DNSSEC, as well as managing the 330 distribution of that Homenet Zone to the DNS Outsourcing 331 Infrastructure (DOI). 333 DNS Outsourcing Infrastructure (DOI): is the infrastructure 334 responsible for receiving the Public Homenet Zone and publishing 335 it on the Internet. It is mainly composed of a Distribution 336 Manager and Public Authoritative Servers. 338 Public Authoritative Servers: are the authoritative name servers for 339 the Public Homenet Zone. Name resolution requests for the Homenet 340 Domain are sent to these servers. For resiliency the Public 341 Homenet Zone SHOULD be hosted on multiple servers. 343 Homenet Authoritative Servers: are authoritative name servers within 344 the Homenet network. 346 Distribution Manager (DM): is the (set of) server(s) to which the 347 HNA synchronizes the Public Homenet Zone, and which then 348 distributes the relevant information to the Public Authoritative 349 Servers. 351 Homenet Reverse Zone: The reverse zone file associated with the 352 Public Homenet Zone. 354 Reverse Public Authoritative Servers: equivalent to Public 355 Authoritative Servers specifically for reverse resolution. 357 Reverse Distribution Manager: equivalent to Distribution Manager 358 specifically for reverse resolution. 360 Homenet DNSSEC Resolver: a resolver that performs a DNSSEC 361 resolution on the home network for the Public Homenet Zone. The 362 resolution is performed requesting the Homenet Authoritative 363 Servers. 365 DNSSEC Resolver: a resolver that performs a DNSSEC resolution on the 366 Internet for the Public Homenet Zone. The resolution is performed 367 requesting the Public Authoritative Servers. 369 3. Architecture Description 371 This section provides an overview of the architecture for outsourcing 372 the authoritative naming service from the HNA to the DOI. Note that 373 Section 14 defines necessary parameter to configure the HNA. 375 3.1. Architecture Overview 377 Figure 1 illustrates the architecture where the HNA outsources the 378 publication of the Public Homenet Zone to the DOI. 380 The Public Homenet Zone is identified by the Registered Homenet 381 Domain Name - myhome.example. The ".local" as well as ".home.arpa" 382 are explicitly not considered as Public Homenet zones and represented 383 as Homenet Zone in Figure 1. 385 The HNA SHOULD build the Public Homenet Zone in a single view 386 populated with all resource records that are expected to be published 387 on the Internet. The HNA also signs the Public Homenet Zone. The 388 HNA handles all operations and keying material required for DNSSEC, 389 so there is no provision made in this architecture for transferring 390 private DNSSEC related keying material between the HNA and the DM. 392 Once the Public Homenet Zone has been built, the HNA outsources it to 393 the DOI as described in Figure 1. The HNA acts as a hidden primary 394 [RFC8499] while the DM behaves as a secondary responsible to 395 distribute the Public Homenet Zone to the multiple Public 396 Authoritative Servers that DOI is responsible for. The DM has three 397 communication channels: 399 o a DM Control Channel (Section 4) to configure the HNA and the DOI, 401 o a DM Synchronization Channel (Section 5) to synchronize the Public 402 Homenet Zone on the HNA and on the DM, 404 o one or more Distribution Channels (Section 6 that distribute the 405 Public Homenet Zone from the DM to the Public Authoritative Server 406 serving the Public Homenet Zone on the Internet. 408 There might be multiple DM's, and multiple servers per DM. This 409 document assumes a single DM server for simplicity, but there is no 410 reason why each channel needs to be implemented on the same server or 411 use the same code base. 413 It is important to note that while the HNA is configured as an 414 authoritative server, it is not expected to answer to DNS requests 415 from the public Internet for the Public Homenet Zone. More 416 specifically, the addresses associated with the HNA SHOULD NOT be 417 mentioned in the NS records of the Public Homenet zone, unless 418 additional security provisions necessary to protect the HNA from 419 external attack have been taken. 421 The DOI is also responsible for ensuring the DS record has been 422 updated in the parent zone. 424 Resolution is performed by the DNSSEC resolvers. When the resolution 425 is performed outside the home network, the DNSSEC Resolver resolves 426 the DS record on the Global DNS and the name associated to the Public 427 Homenet Zone (myhome.example) on the Public Authoritative Servers. 429 When the resolution is performed from within the home network, the 430 Homenet DNSSEC Resolver MAY proceed similarly. On the other hand, to 431 provide resilience to the Public Homenet Zone in case of WAN 432 connectivity disruption, the Homenet DNSSEC Resolver SHOULD be able 433 to perform the resolution on the Homenet Authoritative Servers. 434 These servers are not expected to be mentioned in the Public Homenet 435 Zone, nor to be accessible from the Internet. As such their 436 information as well as the corresponding signed DS record MAY be 437 provided by the HNA to the Homenet DNSSEC Resolvers, e.g., using HNCP 438 [RFC7788]. Such configuration is outside the scope of this document. 439 Since the scope of the Homenet Authoritative Servers is limited to 440 the home network, these servers are expected to serve the Homenet 441 Zone as represented in Figure 1. 443 How the Homenet Authoritative Servers are provisioned is also out of 444 scope of this specification. It could be implemented using primary 445 and secondary servers, or via rsync. In some cases, the HNA and 446 Homenet Authoritative Servers may be combined together which would 447 result in a common instantiation of an authoritative server on the 448 WAN and inner homenet interface. Note that [RFC6092] REC-8 states 449 this must not be the default configuration. Other mechanisms may 450 also be used. 452 Home network | Internet 453 | 454 | +----------------------------+ 455 | | DOI | 456 Control | | | 457 +-----------------------+ Channel | | +-----------------------+ | 458 | HNA |<-------------->| Distribution Manager | | 459 |+---------------------+| | | |+---------------------+| | 460 || Public Homenet Zone ||Synchronization || Public Homenet Zone || | 461 || (myhome.example) || Channel | | || (myhome.example) || | 462 |+---------------------+|<-------------->|+---------------------+| | 463 +-----------^-----------+ | | +-----------------------+ | 464 . | | ^ Distribution | 465 . | | | Channel | 466 +-----------v-----------+ | | v | 467 | Homenet Authoritative | | | +-----------------------+ | 468 | Server(s) | | | | Public Authoritative | | 469 |+---------------------+| | | | Server(s) | | 470 ||Public Homenet Zone || | | |+---------------------+| | 471 || (myhome.example) || | | || Public Homenet Zone || | 472 |+---------------------+| | | || (myhome.example) || | 473 || Homenet Zone || | | |+---------------------+| | 474 || (home.arpa) || | | +-----------------------+ | 475 |+---------------------+| | +----------^---|-------------+ 476 +----------^---|--------+ | | | 477 | | name resolution | | 478 | v | | v 479 +----------------------+ | +-----------------------+ 480 | Homenet | | | Internet | 481 | DNSSEC Resolver | | | DNSSEC Resolver | 482 +----------------------+ | +-----------------------+ 484 Figure 1: Homenet Naming Architecture 486 3.2. Distribution Manager Communication Channels 488 This section details the DM channels, that is the Control Channel, 489 the Synchronization Channel and the Distribution Channel. 491 The Control Channel and the Synchronization Channel are the 492 interfaces used between the HNA and the DOI. The entity within the 493 DOI responsible to handle these communications is the DM and 494 communications between the HNA and the DM MUST be protected and 495 mutually authenticated. While Section 4.6 discusses in more depth 496 the different security protocols that could be used to secure, it is 497 RECOMMENDED to use TLS with mutually authentication based on 498 certificates to secure the channel between the HNA and the DM. 500 The Control Channel is used to set up the Synchronization Channel. 501 We assume that the HNA initiates the Control Channel connection with 502 the DM and as such has a prior knowledge of the DM identity (X509 503 certificate), the IP address and port number to use and protocol to 504 set secure session. We also assume the DM has knowledge of the 505 identity of the HNA (X509 certificate) as well as the Registered 506 Homenet Domain. For more detail to see how this can be achieved, 507 please see Section 10. 509 The information exchanged between the HNA and the DM uses DNS 510 messages protected by DNS over TLS (DoT) [RFC7858]. Other 511 specifications may consider protecting DNS messages with other 512 transport layers, among others, DNS over DTLS [RFC8094], or DNS over 513 HTTPs (DoH) [RFC8484] or DNS over QUIC [I-D.ietf-dprive-dnsoquic]. 514 There was consideration to using a standard TSIG [RFC2845] or SIG(0) 515 [RFC2931] to perform a dynamic DNS update to the DM. There are a 516 number of issues with this. The first one is that TSIG or SIG(0) 517 make scenarios where the end user needs to interact via its web 518 browser more complex. More precisely, authorization and access 519 control granted via OAUTH would be unnecessarily complex with TSIG or 520 SIG(0). 522 The main issue is that the Dynamic DNS update would also update the 523 parent zone's (NS, DS and associated A or AAAA records) while the 524 goal is to update the DM configuration files. The visible NS records 525 SHOULD remain pointing at the cloud provider's anycast addresses. 526 Revealing the address of the HNA in the DNS is not desirable. Refer 527 to Section 4.2 for more details. 529 This specification assumes: 531 o the DM serves both the Control Channel and Synchronization Channel 532 on a single IP address, single port and using a single transport 533 protocol. 535 o By default, the HNA uses a single IP address for both the Control 536 and Synchronization channel. However, the HNA MAY use distinct IP 537 addresses for the Control Channel and the Synchronization Channel 538 - see Section 5 and Section 4.3 for more details. 540 The Distribution Channel is internal to the DOI and as such is not 541 the primary concern of this specification. 543 4. Control Channel 545 The DM Control Channel is used by the HNA and the DOI to exchange 546 information related to the configuration of the delegation which 547 includes information to build the Public Homenet Zone (Section 4.1), 548 information to build the DNSSEC chain of trust (Section 4.2) and 549 information to set the Synchronization Channel (Section 4.3). 551 4.1. Information to Build the Public Homenet Zone 553 When the HNA builds the Public Homenet Zone, it must include 554 information that it retrieves from the DM relating to how the zone is 555 to be published. 557 The information includes at least names and IP addresses of the 558 Public Authoritative Name Servers. In term of RRset information this 559 includes: 561 o the MNAME of the SOA, 563 o the NS and associated A and AAA RRsets of the name servers. 565 The DOI MAY also provide operational parameters such as other fields 566 of SOA (SERIAL, RNAME, REFRESH, RETRY, EXPIRE and MINIMUM). As the 567 information is necessary for the HNA to proceed and the information 568 is associated to the DOI, this information exchange is mandatory. 570 4.2. Information to build the DNSSEC chain of trust 572 The HNA SHOULD provide the hash of the KSK (DS RRset), so the that 573 DOI provides this value to the parent zone. A common deployment use 574 case is that the DOI is the registrar of the Registered Homenet 575 Domain, and as such, its relationship with the registry of the parent 576 zone enables it to update the parent zone. When such relation 577 exists, the HNA should be able to request the DOI to update the DS 578 RRset in the parent zone. A direct update is especially necessary to 579 initialize the chain of trust. 581 Though the HNA may also later directly update the values of the DS 582 via the Control Channel, it is RECOMMENDED to use other mechanisms 583 such as CDS and CDNSKEY [RFC7344] for transparent updates during key 584 roll overs. 586 As some deployments may not provide a DOI that will be able to update 587 the DS in the parent zone, this information exchange is OPTIONAL. 589 By accepting the DS RR, the DM commits in taking care of advertising 590 the DS to the parent zone. Upon refusal, the DM clearly indicates it 591 does not have the capacity to proceed to the update. 593 4.3. Information to set the Synchronization Channel 595 The HNA works as a primary authoritative DNS server, while the DM 596 works like a secondary. As a result, the HNA MUST provide the IP 597 address the DM is using to reach the HNA. The synchronization 598 Channel will be set between that IP address and the IP address of the 599 DM. By default, the IP address used by the HNA in the Control 600 Channel is considered by the DM and the specification of the IP by 601 the HNA is only OPTIONAL. The transport channel (including port 602 number) is the same as the one used between the HNA and the DM for 603 the Control Channel. 605 4.4. Deleting the delegation 607 The purpose of the previous sections were to exchange information in 608 order to set a delegation. The HNA MUST also be able to delete a 609 delegation with a specific DM. Upon an instruction of deleting the 610 delegation, the DM MUST stop serving the Public Homenet Zone. 612 4.5. Messages Exchange Description 614 There are multiple ways this information could be exchanged between 615 the HNA and the DM. This specification defines a mechanism that re- 616 use the DNS exchanges format. The intention is to reuse standard 617 libraries especially to check the format of the exchanged fields as 618 well as to minimize the additional libraries needed for the HNA. The 619 re-use of DNS exchanges achieves these goals. Note that while 620 information is provided using DNS exchanges, the exchanged 621 information is not expected to be set in any zone file, instead this 622 information is uses as commands between the HNA and the DM. 624 The Control Channel is not expected to be a long term session. After 625 a predefined timer - similar to those used for TCP - the Control 626 Channel is expected to be terminated - by closing the transport 627 channel. The Control Channel MAY be re-opened at any time later. 629 The provisioning process SHOULD provide a method of securing the 630 Control Channel, so that the content of messages can be 631 authenticated. This authentication MAY be based on certificates for 632 both the DM and each HNA. The DM may also create the initial 633 configuration for the delegation zone in the parent zone during the 634 provisioning process. 636 4.5.1. Retrieving information for the Public Homenet Zone. 638 The information provided by the DM to the HNA is retrieved by the HNA 639 with an AXFR exchange [RFC1034]. AXFR enables the response to 640 contain any type of RRsets. The response might be extended in the 641 future if additional information will be needed. Alternatively, the 642 information provided by the HNA to the DM is pushed by the HNA via a 643 DNS update exchange [RFC2136]. 645 To retrieve the necessary information to build the Public Homenet 646 Zone, the HNA MUST send a DNS request of type AXFR associated to the 647 Registered Homenet Domain. The DM MUST respond with a zone template. 648 The zone template MUST contain a RRset of type SOA, one or multiple 649 RRset of type NS and zero or more RRset of type A or AAAA. 651 o The SOA RR indicates to the HNA the value of the MNAME of the 652 Public Homenet Zone. 654 o The NAME of the SOA RR MUST be the Registered Homenet Domain. 656 o The MNAME value of the SOA RDATA is the value provided by the DOI 657 to the HNA. 659 o Other RDATA values (RNAME, REFRESH, RETRY, EXPIRE and MINIMUM) are 660 provided by the DOI as suggestions. 662 The NS RRsets carry the Public Authoritative Servers of the DOI. 663 Their associated NAME MUST be the Registered Homenet Domain. 665 The TTL and RDATA are those expected to be published on the Public 666 Homenet Zone. The RRsets of Type A and AAAA MUST have their NAME 667 matching the NSDNAME of one of the NS RRsets. 669 Upon receiving the response, the HNA MUST validate format and 670 properties of the SOA, NS and A or AAAA RRsets. If an error occurs, 671 the HNA MUST stop proceeding and MUST log an error. Otherwise, the 672 HNA builds the Public Homenet Zone by setting the MNAME value of the 673 SOA as indicated by the SOA provided by the AXFR response. The HNA 674 SHOULD set the value of NAME, REFRESH, RETRY, EXPIRE and MINIMUM of 675 the SOA to those provided by the AXFR response. The HNA MUST insert 676 the NS and corresponding A or AAAA RRset in its Public Homenet Zone. 677 The HNA MUST ignore other RRsets. If an error message is returned by 678 the DM, the HNA MUST proceed as a regular DNS resolution. Error 679 messages SHOULD be logged for further analysis. If the resolution 680 does not succeed, the outsourcing operation is aborted and the HNA 681 MUST close the Control Channel. 683 4.5.2. Providing information for the DNSSEC chain of trust 685 To provide the DS RRset to initialize the DNSSEC chain of trust the 686 HNA MAY send a DNS update [RFC2136] message. 688 The DNS update message is composed of a Header section, a Zone 689 section, a Pre-requisite section, and Update section and an 690 additional section. The Zone section MUST set the ZNAME to the 691 parent zone of the Registered Homenet Domain - that is where the DS 692 records should be inserted. As described [RFC2136], ZTYPE is set to 693 SOA and ZCLASS is set to the zone's class. The Pre-requisite section 694 MUST be empty. The Update section is a DS RRset with its NAME set to 695 the Registered Homenet Domain and the associated RDATA corresponds to 696 the value of the DS. The Additional Data section MUST be empty. 698 Though the pre-requisite section MAY be ignored by the DM, this value 699 is fixed to remain coherent with a standard DNS update. 701 Upon receiving the DNS update request, the DM reads the DS RRset in 702 the Update section. The DM checks ZNAME corresponds to the parent 703 zone. The DM SHOULD ignore non empty the Pre-requisite and 704 Additional Data section. The DM MAY update the TTL value before 705 updating the DS RRset in the parent zone. Upon a successful update, 706 the DM should return a NOERROR response as a commitment to update the 707 parent zone with the provided DS. An error indicates the MD does not 708 update the DS, and other method should be used by the HNA. 710 The regular DNS error message SHOULD be returned to the HNA when an 711 error occurs. In particular a FORMERR is returned when a format 712 error is found, this includes when unexpected RRSets are added or 713 when RRsets are missing. A SERVFAIL error is returned when a 714 internal error is encountered. A NOTZONE error is returned when 715 update and Zone sections are not coherent, a NOTAUTH error is 716 returned when the DM is not authoritative for the Zone section. A 717 REFUSED error is returned when the DM refuses to proceed to the 718 configuration and the requested action. 720 4.5.3. Providing information for the Synchronization Channel 722 The default IP address used by the HNA for the Synchronization 723 Channel is the IP address of the Control Channel. To provide a 724 different IP address, the HNA MAY send a DNS Update message. 726 Similarly to the Section 4.5.2, the HNA MAY specify the IP address 727 using a DNS update message. The Zone section sets its ZNAME to the 728 parent zone of the Registered Homenet Domain, ZTYPE is set to SOA and 729 ZCLASS is set to the zone's type. Pre-requisite is empty. The 730 Update section is a RRset of type NS. The Additional Data section 731 contains the RRsets of type A or AAAA that designates the IP 732 addresses associated to the primary (or the HNA). 734 The reason to provide these IP addresses is to keep them unpublished 735 and prevent them to be resolved. 737 Upon receiving the DNS update request, the DM reads the IP addresses 738 and checks the ZNAME corresponds to the parent zone. The DM SHOULD 739 ignore a non empty Pre-requisite section. The DM configures the 740 secondary with the IP addresses and returns a NOERROR response to 741 indicate it is committed to serve as a secondary. 743 Similarly to Section 4.5.2, DNS errors are used and an error 744 indicates the DM is not configured as a secondary. 746 4.5.4. HNA instructing deleting the delegation 748 To instruct to delete the delegation the HNA SHOULD send a DNS UPDATE 749 Delete message. 751 The Zone section sets its ZNAME to the Registered Homenet Domain, the 752 ZTYPE to SOA and the ZCLASS to zone's type. The Pre-requisite 753 section is empty. The Update section is a RRset of type NS with the 754 NAME set to the Registered Domain Name. As indicated by [RFC2136] 755 Section 2.5.2 the delete instruction is set by setting the TTL to 0, 756 the Class to ANY, the RDLENGTH to 0 and the RDATA MUST be empty. The 757 Additional Data section is empty. 759 Upon receiving the DNS update request, the DM checks the request and 760 removes the delegation. The DM returns a NOERROR response to 761 indicate the delegation has been deleted. Similarly to 762 Section 4.5.2, DNS errors are used and an error indicates the 763 delegation has not been deleted. 765 4.6. Securing the Control Channel 767 The control channel between the HNA and the DM MUST be secured at 768 both the HNA and the DM. 770 Secure protocols (like TLS [RFC8446] SHOULD be used to secure the 771 transactions between the DM and the HNA. 773 The advantage of TLS is that this technology is widely deployed, and 774 most of the devices already embed TLS libraries, possibly also taking 775 advantage of hardware acceleration. Further, TLS provides 776 authentication facilities and can use certificates to mutually 777 authenticate the DM and HNA at the application layer, including 778 available API. On the other hand, using TLS requires implementing 779 DNS exchanges over TLS, as well as a new service port. 781 The HNA SHOULD authenticate inbound connections from the DM using 782 standard mechanisms, such as a public certificate with baked-in root 783 certificates on the HNA, or via DANE [RFC6698]. The HNA is expected 784 to be provisioned with a connection to the DM by the manufacturer, or 785 during some user-initiated onboarding process, see Section 10. 787 The DM SHOULD authenticate the HNA and check that inbound messages 788 are from the appropriate client. The DM MAY use a self-signed CA 789 certificate mechanism per HNA, or public certificates for this 790 purpose. 792 IPsec [RFC4301] and IKEv2 [RFC7296] were considered. They would need 793 to operate in transport mode, and the authenticated end points would 794 need to be visible to the applications, and this is not commonly 795 available at the time of this writing. 797 A pure DNS solution using TSIG and/or SIG(0) to authenticate message 798 was also considered. Section 10 envisions one mechanism would 799 involve the end user, with a browser, signing up to a service 800 provider, with a resulting OAUTH2 token to be provided to the HNA. A 801 way to translate this OAUTH2 token from HTTPS web space to DNS SIG(0) 802 space seems overly problematic, and so the enrollment protocol using 803 web APIs was determined to be easier to implement at scale. 805 Note also that authentication of message exchanges between the HNA 806 and the DM SHOULD NOT use the external IP address of the HNA to index 807 the appropriate keys. As detailed in Section 11, the IP addresses of 808 the DM and the hidden primary are subject to change, for example 809 while the network is being renumbered. This means that the necessary 810 keys to authenticate transaction SHOULD NOT be indexed using the IP 811 address, and SHOULD be resilient to IP address changes. 813 4.7. Implementation Concerns 815 The Hidden Primary Server on the HNA differs from a regular 816 authoritative server for the home network due to: 818 Interface Binding: the Hidden Primary Server will almost certainly 819 listen on the WAN Interface, whereas a regular Homenet 820 Authoritative Servers would listen on the internal home network 821 interface. 823 Limited exchanges: the purpose of the Hidden Primary Server is to 824 synchronize with the DM, not to serve any zones to end users, or 825 the public Internet. 827 As a result, exchanges are performed with specific nodes (the DM). 828 Further, exchange types are limited. The only legitimate exchanges 829 are: NOTIFY initiated by the Hidden Primary and IXFR or AXFR 830 exchanges initiated by the DM. 832 On the other hand, regular authoritative servers would respond to any 833 hosts, and any DNS query would be processed. The HNA SHOULD filter 834 IXFR/AXFR traffic and drop traffic not initiated by the DM. The HNA 835 MUST at least allow SOA lookups of the Homenet Zone. 837 5. Synchronization Channel 839 The DM Synchronization Channel is used for communication between the 840 HNA and the DM for synchronizing the Public Homenet Zone. Note that 841 the Control Channel and the Synchronization Channel are by 842 construction different channels even though there they may use the 843 same IP address. In fact the Control Channel is set between the HNA 844 working as a client using port number YYYY (a high range port) toward 845 a service provided by the DM at port number XX (well known port). 847 On the other hand, the Synchronization Channel is set between the DM 848 working as a client using port ZZZZ ( a high range port) toward a 849 service a service provided by the HNA at port XX. 851 As a result, even though the same couple of IP addresses may be 852 involved the Control Channel and the Synchronization Channel are 853 always distinct channels. 855 Uploading and dynamically updating the zone file on the DM can be 856 seen as zone provisioning between the HNA (Hidden Primary) and the DM 857 (Secondary Server). This can be handled via AXFR + DNS Update. 859 The use of a primary / secondary mechanism is RECOMMENDED instead of 860 the use of DNS Update. The primary / secondary mechanism is 861 RECOMMENDED as it scales better and avoids DoS attacks. Note that 862 even when UPDATE messages are used, these messages are using a 863 distinct channel as those used to set the configuration. 865 Note that there is no standard way to distribute a DNS primary 866 between multiple devices. As a result, if multiple devices are 867 candidate for hosting the Hidden Primary, some specific mechanisms 868 should be designed so the home network only selects a single HNA for 869 the Hidden Primary. Selection mechanisms based on HNCP [RFC7788] are 870 good candidates. 872 The HNA acts as a Hidden Primary Server, which is a regular 873 authoritative DNS Server listening on the WAN interface. 875 The DM is configured as a secondary for the Registered Homenet Domain 876 Name. This secondary configuration has been previously agreed 877 between the end user and the provider of the DOI as part of either 878 the provisioning or due to receipt of DNS Update messages on the DM 879 Control Channel. 881 The Homenet Reverse Zone MAY also be updated either with DNS UPDATE 882 [RFC2136] or using a primary / secondary synchronization. 884 5.1. Securing the Synchronization Channel 886 The Synchronization Channel uses standard DNS requests. 888 First the primary notifies the secondary that the zone must be 889 updated and eaves the secondary to proceed with the update when 890 possible/convenient. 892 Then, a NOTIFY message is sent by the primary, which is a small 893 packet that is less likely to load the secondary. 895 Finally, the AXFR [RFC1034] or IXFR [RFC1995] query performed by the 896 secondary is a small packet sent over TCP (Section 4.2 [RFC5936]), 897 which mitigates reflection attacks using a forged NOTIFY. 899 The AXFR request from the DM to the HNA SHOULD be secured and the use 900 of TLS is RECOMMENDED [I-D.ietf-dprive-xfr-over-tls] 902 When using TLS, the HNA MAY authenticate inbound connections from the 903 DM using standard mechanisms, such as a public certificate with 904 baked-in root certificates on the HNA, or via DANE [RFC6698]. In 905 addition, to guarantee the DM remains the same across multiple TLS 906 session, the HNA and DM MAY implement [RFC8672]. 908 The HNA SHOULD apply an ACL on inbound AXFR requests to ensure they 909 only arrive from the DM Synchronization Channel. In this case, the 910 HNA SHOULD regularly check (via DNS resolution) that the address of 911 the DM in the filter is still valid. 913 6. DM Distribution Channel 915 The DM Distribution Channel is used for communication between the DM 916 and the Public Authoritative Servers. The architecture and 917 communication used for the DM Distribution Channels is outside the 918 scope of this document, and there are many existing solutions 919 available e.g. rsynch, DNS AXFR, REST, DB copy. 921 7. HNA Security Policies 923 This section details security policies related to the Hidden Primary 924 / Secondary synchronization. 926 The HNA, as Hidden Primary SHOULD drop any queries from the home 927 network. This could be implemented via port binding and/or firewall 928 rules. The precise mechanism deployed is out of scope of this 929 document. The Hidden Primary SHOULD drop any DNS queries arriving on 930 the WAN interface that are not issued from the DM. The Hidden 931 Primary SHOULD drop any outgoing packets other than DNS NOTIFY query, 932 SOA response, IXFR response or AXFR responses. The Hidden Primary 933 SHOULD drop any incoming packets other than DNS NOTIFY response, SOA 934 query, IXFR query or AXFR query. The Hidden Primary SHOULD drop any 935 non protected IXFR or AXFR exchange,depending on how the 936 synchronization is secured. 938 8. DNSSEC compliant Homenet Architecture 940 [RFC7368] in Section 3.7.3 recommends DNSSEC to be deployed on both 941 the authoritative server and the resolver. The resolver side is out 942 of scope of this document, and only the authoritative part of the 943 server is considered. 945 This document assumes the HNA signs the Public Homenet Zone. 947 Secure delegation is achieved only if the DS RRset is properly set in 948 the parent zone. Secure delegation is performed by the HNA or the 949 DOIs. 951 The DS RRset can be updated manually with nsupdate for example. This 952 requires the HNA or the DOI to be authenticated by the DNS server 953 hosting the parent of the Public Homenet Zone. Such a trust channel 954 between the HNA and the parent DNS server may be hard to maintain 955 with HNAs, and thus may be easier to establish with the DOI. In 956 fact, the Public Authoritative Server(s) may use Automating DNSSEC 957 Delegation Trust Maintenance [RFC7344]. 959 9. Homenet Reverse Zone Channels Configuration 961 The Public Homenet Zone is associated to a Registered Homenet Domain 962 and the ownership of that domain requires a specific registration 963 from the end user as well as the HNA being provisioned with some 964 authentication credentials. Such steps are mandatory unless the DOI 965 has some other means to authenticate the HNA. Such situation may 966 occur, for example, when the ISP provides the Homenet Domain as well 967 as the DOI. 969 In this case, the HNA may be authenticated by the physical link 970 layer, in which case the authentication of the HNA may be performed 971 without additional provisioning of the HNA. While this may not be so 972 common for the Public Homenet Zone, this situation is expected to be 973 quite common for the Reverse Homenet Zone. 975 More specifically, a common case is that the upstream ISP provides 976 the IPv6 prefix to the Homenet with a IA_PD [RFC8415] option and 977 manages the DOI of the associated reverse zone. 979 This leave place for setting up automatically the relation between 980 HNA and the DNS Outsourcing infrastructure as described in 981 [I-D.ietf-homenet-naming-architecture-dhc-options]. 983 In the case of the reverse zone, the DOI authenticates the source of 984 the updates by IPv6 Access Control Lists. In the case of the reverse 985 zone, the ISP knows exactly what addresses have been delegated. The 986 HNA SHOULD therefore always originate Synchronization Channel updates 987 from an IP address within the zone that is being updated. 989 For example, if the ISP has assigned 2001:db8:f00d::/64 to the WAN 990 interface (by DHCPv6, or PPP/RA), then the HNA should originate 991 Synchronization Channel updates from, for example, 2001:db8:f00d::2. 993 An ISP that has delegated 2001:db8:babe::/56 to the HNA via 994 DHCPv6-PD, then HNA should originate Synchronization Channel updates 995 an IP within that subnet, such as 2001:db8:babe:0001::2. 997 With this relation automatically configured, the synchronization 998 between the Home network and the DOI happens similarly as for the 999 Public Homenet Zone described earlier in this document. 1001 Note that for home networks connected to by multiple ISPs, each ISP 1002 provides only the DOI of the reverse zones associated to the 1003 delegated prefix. It is also likely that the DNS exchanges will need 1004 to be performed on dedicated interfaces as to be accepted by the ISP. 1005 More specifically, the reverse zone associated to prefix 1 will not 1006 be possible to be performs by the HNA using an IP address that 1007 belongs to prefix 2. Such constraints does not raise major concerns 1008 either for hot standby or load sharing configuration. 1010 With IPv6, the domain space for IP addresses is so large that reverse 1011 zone may be confronted with scalability issues. How the reverse zone 1012 is generated is out of scope of this document. [RFC8501] provides 1013 guidance on how to address scalability issues. 1015 10. Homenet Public Zone Channel Configurations 1017 This document does not deal with how the HNA is provisioned with a 1018 trusted relationship to the Distribution Manager for the forward 1019 zone. 1021 This section details what needs to be provisioned into the HNA and 1022 serves as a requirements statement for mechanisms. 1024 The HNA needs to be provisioned with: 1026 o the Registered Domain (e.g., myhome.isp.example ) 1028 o the contact info for the Distribution Manager (DM), including the 1029 DNS name (FQDN), possibly including the IP literal, and a 1030 certificate (or anchor) to be used to authenticate the service 1032 o the DM transport protocol and port (the default is DNS over TLS, 1033 on port 853) 1035 o the HNA credentials used by the DM for its authentication. 1037 The HNA will need to select an IP address for communication for the 1038 Synchronization Channel. This is typically the WAN address of the RG 1039 router, but could be an IPv6 LAN address in the case of a home with 1040 multiple ISPs (and multiple border routers). This is detailed in 1041 Section 4.5.3 when the NS and A or AAAA RRsets are communicated. 1043 The above parameters MUST be be provisioned for ISP-specific reverse 1044 zones, as per [I-D.ietf-homenet-naming-architecture-dhc-options]. 1045 ISP-specific forward zones MAY also be provisioned using 1046 [I-D.ietf-homenet-naming-architecture-dhc-options], but zones which 1047 are not related to a specific ISP zone (such as with a DNS provider) 1048 must be provisioned through other means. 1050 Similarly, if the HNA is provided by a registrar, the HNA may be 1051 handed pre-configured to end user. 1053 In the absence of specific pre-established relation, these pieces of 1054 information may be entered manually by the end user. In order to 1055 ease the configuration from the end user the following scheme may be 1056 implemented. 1058 The HNA may present the end user a web interface where it provides 1059 the end user the ability to indicate the Registered Homenet Domain or 1060 the registrar for example a preselected list. Once the registrar has 1061 been selected, the HNA redirects the end user to that registrar in 1062 order to receive a access token. The access token will enable the 1063 HNA to retrieve the DM parameters associated to the Registered 1064 Domain. These parameters will include the credentials used by the 1065 HNA to establish the Control and Synchronization Channels. 1067 Such architecture limits the necessary steps to configure the HNA 1068 from the end user. 1070 11. Renumbering 1072 This section details how renumbering is handled by the Hidden Primary 1073 server or the DM. Both types of renumbering are discussed i.e. 1074 "make-before-break" and "break-before-make" (aka flash renumbering). 1076 In the make-before-break renumbering scenario, the new prefix is 1077 advertised, the network is configured to prepare the transition to 1078 the new prefix. During a period of time, the two prefixes old and 1079 new coexist, before the old prefix is completely removed. 1081 In the break-before-make renumbering scenario, the new prefix is 1082 advertised making the old prefix obsolete. 1084 Renumbering has been extensively described in [RFC4192] and analyzed 1085 in [RFC7010] and the reader is expected to be familiar with them 1086 before reading this section. 1088 11.1. Hidden Primary 1090 In a renumbering scenario, the HNA or Hidden Primary is informed it 1091 is being renumbered. In most cases, this occurs because the whole 1092 home network is being renumbered. As a result, the Public Homenet 1093 Zone will also be updated. Although the new and old IP addresses may 1094 be stored in the Public Homenet Zone, we recommend that only the 1095 newly reachable IP addresses be published. 1097 To avoid reachability disruption, IP connectivity information 1098 provided by the DNS SHOULD be coherent with the IP in use. In our 1099 case, this means the old IP address SHOULD NOT be provided via the 1100 DNS when it is not reachable anymore. Let for example TTL be the TTL 1101 associated with a RRset of the Public Homenet Zone, it may be cached 1102 for TTL seconds. Let T_NEW be the time the new IP address replaces 1103 the old IP address in the Homenet Zone, and T_OLD_UNREACHABLE the 1104 time the old IP is not reachable anymore. 1106 In the case of the make-before-break, seamless reachability is 1107 provided as long as T_OLD_UNREACHABLE - T_NEW > 2 * TTL. If this is 1108 not satisfied, then devices associated with the old IP address in the 1109 home network may become unreachable for 2 * TTL - (T_OLD_UNREACHABLE 1110 - T_NEW). In the case of a break-before-make, T_OLD_UNREACHABLE = 1111 T_NEW, and the device may become unreachable up to 2 * TTL. Of 1112 course if T_NEW >= T_OLD_UNREACHABLE, the disruption is increased. 1114 Once the Public Homenet Zone file has been updated on the Hidden 1115 Primary, the Hidden Primary needs to inform the DOI that the Public 1116 Homenet Zone has been updated and that the IP address to use to 1117 retrieve the updated zone has also been updated. Both notifications 1118 are performed using regular DNS exchanges. Mechanisms to update an 1119 IP address provided by lower layers with protocols like SCTP 1120 [RFC4960], MOBIKE [RFC4555] are not considered in this document. 1121 Instead the IP address of the HNA is updated using the 1122 Synchronization Channel as described in Section 4.3. 1124 12. Privacy Considerations 1126 Outsourcing the DNS Authoritative service from the HNA to a third 1127 party raises a few privacy related concerns. 1129 The Public Homenet Zone lists the names of services hosted in the 1130 home network. Combined with blocking of AXFR queries, the use of 1131 NSEC3 [RFC5155] (vs NSEC [RFC4034]) prevents an attacker from being 1132 able to walk the zone, to discover all the names. However, the 1133 attacker may be able to walk the reverse DNS zone, or use other 1134 reconnaissance techniques to learn this information as described in 1135 [RFC7707]. 1137 In general a home network owner is expected to publish only names for 1138 which there is some need to be able to reference externally. 1139 Publication of the name does not imply that the service is 1140 necessarily reachable from any or all parts of the Internet. 1141 [RFC7084] mandates that the outgoing-only policy [RFC6092] be 1142 available, and in many cases it is configured by default. A well 1143 designed User Interface would combine a policy for making a service 1144 public by a name with a policy on who may access it. 1146 In many cases, the home network owner wishes to publish names for 1147 services that only they will be able to access. The access control 1148 may consist of an IP source address range, or access may be 1149 restricted via some VPN functionality. The purpose of publishing the 1150 name is so that the service may be access by the same name both 1151 within the home, and outside the home. Sending traffic to the 1152 relevant IPv6 address causes the relevant VPN policy to be enacted 1153 upon. 1155 While the problem of getting access to internal names has been solved 1156 in Enterprise configurations with a split-DNS, and such a thing could 1157 be done in the home, many recent improvements to VPN user interfaces 1158 make it more likely that an individual might have multiple 1159 connections configured. For instance, an adult child checking on the 1160 state of a home automation system for a parent. 1162 In addition to the Public Homenet Zone, pervasive DNS monitoring can 1163 also monitor the traffic associated with the Public Homenet Zone. 1164 This traffic may provide an indication of the services an end user 1165 accesses, plus how and when they use these services. Although, 1166 caching may obfuscate this information inside the home network, it is 1167 likely that outside your home network this information will not be 1168 cached. 1170 13. Security Considerations 1172 This document exposes a mechanism that prevents the HNA from being 1173 exposed to the Internet and served DNS request from the Internet. 1174 These requests are instead served by the DOI. While this limits the 1175 level of exposure of the HNA, the HNA remains exposed to the Internet 1176 with communications with the DOI. This section analyses the attack 1177 surface associated to these communications. In addition, the DOI 1178 exposes data that are related to the home network. This section also 1179 analyses the implication of such exposure. 1181 13.1. HNA DM channels 1183 The channels between HNA and DM are mutually authenticated and 1184 encrypted with TLS [RFC8446] and its associated security 1185 considerations apply. To ensure the multiple TLS session are are 1186 continuously authenticating the same entity, TLS may take advantage 1187 of second factor authentication as described in [RFC8672]. 1189 At the time of writing TLS 1.2 or TLS 1.3 can be used and TLS 1.3 (or 1190 newer) SHOULD be supported. 1192 The DNS protocol is subject to reflection attacks, however, these 1193 attacks are largely applicable when DNS is carried over UDP. The 1194 interfaces between the HNA and DM are using TLS over TCP, which 1195 prevents such reflection attacks. Note that Public Authoritative 1196 servers hosted by the DOI are subject to such attacks, but that is 1197 out of scope of our document. 1199 Note that in the case of the Reverse Homenet Zone, the data is less 1200 subject to attacks than in the Public Homenet Zone. In addition, the 1201 DM and RDM may be provided by the ISP - as described in 1202 [I-D.ietf-homenet-naming-architecture-dhc-options], in which case DM 1203 and RDM might be less exposed to attacks - as communications within a 1204 network. 1206 13.2. Names are less secure than IP addresses 1208 This document describes how an end user can make their services and 1209 devices from his home network reachable on the Internet by using 1210 names rather than IP addresses. This exposes the home network to 1211 attackers, since names are expected to include less entropy than IP 1212 addresses. In fact, with IP addresses, the Interface Identifier is 1213 64 bits long leading to up to 2^64 possibilities for a given 1214 subnetwork. This is not to mention that the subnet prefix is also of 1215 64 bits long, thus providing up to 2^64 possibilities. On the other 1216 hand, names used either for the home network domain or for the 1217 devices present less entropy (livebox, router, printer, nicolas, 1218 jennifer, ...) and thus potentially exposes the devices to dictionary 1219 attacks. 1221 13.3. Names are less volatile than IP addresses 1223 IP addresses may be used to locate a device, a host or a service. 1224 However, home networks are not expected to be assigned a time 1225 invariant prefix by ISPs. As a result, observing IP addresses only 1226 provides some ephemeral information about who is accessing the 1227 service. On the other hand, names are not expected to be as volatile 1228 as IP addresses. As a result, logging names over time may be more 1229 valuable than logging IP addresses, especially to profile an end 1230 user's characteristics. 1232 PTR provides a way to bind an IP address to a name. In that sense, 1233 responding to PTR DNS queries may affect the end user's privacy. For 1234 that reason end users may choose not to respond to PTR DNS queries 1235 and MAY instead return a NXDOMAIN response. 1237 14. Information Model for Outsourced information 1239 This section is non-normative for the front-end protocol. It 1240 specifies an optional format for the set of parameters required by 1241 the HNA to configure the naming architecture of this document. 1243 In cases where a home router has not been provisioned by the 1244 manufacturer (when forward zones are provided by the manufacturer), 1245 or by the ISP (when the ISP provides this service), then a home user/ 1246 owner will need to configure these settings via an administrative 1247 interface. 1249 By defining a standard format (in JSON) for this configuration 1250 information, the user/owner may be able to just copy and paste a 1251 configuration blob from the service provider into the administrative 1252 interface of the HNA. 1254 This format may also provide the basis for a future OAUTH2 [RFC6749] 1255 flow that could do the setup automatically. 1257 The HNA needs to be configured with the following parameters as 1258 described by this CDDL [RFC8610]. These are the parameters are 1259 necessary to establish a secure channel between the HNA and the DM as 1260 well as to specify the DNS zone that is in the scope of the 1261 communication. 1263 hna-configuration = { 1264 "registered_domain" : tstr, 1265 "dm" : tstr, 1266 ? "dm_transport" : "DoT" 1267 ? "dm_port" : uint, 1268 ? "dm_acl" : hna-acl / [ +hna-acl ] 1269 ? "hna_auth_method": hna-auth-method 1270 ? "hna_certificate": tstr 1271 } 1273 hna-acl = tstr 1274 hna-auth-method /= "certificate" 1276 For example: 1278 { 1279 "registered_domain" : "n8d234f.r.example.net", 1280 "dm" : "2001:db8:1234:111:222::2", 1281 "dm_transport" : "DoT", 1282 "dm_port" : 4433, 1283 "dm_acl" : "2001:db8:1f15:62e:21c::/64" 1284 or [ "2001:db8:1f15:62e:21c::/64", ... ] 1285 "hna_auth_method" : "certificate", 1286 "hna_certificate" : "-----BEGIN CERTIFICATE-----\nMIIDTjCCFGy....", 1287 } 1289 14.1. Outsourced Information Model 1291 Registered Homenet Domain (zone) The Domain Name of the zone. 1292 Multiple Registered Homenet Domains may be provided. This will 1293 generate the creation of multiple Public Homenet Zones. This 1294 parameter is MANDATORY. 1296 Distribution Manager notification address (dm) The associated FQDNs 1297 or IP addresses of the DM to which DNS notifies should be sent. 1298 This parameter is MANDATORY. IP addresses are optional and the 1299 FQDN is sufficient and preferred. If there are concerns about the 1300 security of the name to IP translation, then DNSSEC should be 1301 employed. 1303 As the session between the HNA and the DM is authenticated with TLS, 1304 the use of names is easier. 1306 As certificates are more commonly emitted for FQDN than for IP 1307 addresses, it is preferred to use names and authenticate the name of 1308 the DM during the TLS session establishment. 1310 Supported Transport (dm_transport) The transport that carries the 1311 DNS exchanges between the HNA and the DM. Typical value is "DoT" 1312 but it may be extended in the future with "DoH", "DoQ" for 1313 example. This parameter is OPTIONAL and by default the HNA uses 1314 DoT. 1316 Distribution Manager Port (dm_port) Indicates the port used by the 1317 DM. This parameter is OPTIONAL and the default value is provided 1318 by the Supported Transport. In the future, additional transport 1319 may not have default port, in which case either a default port 1320 needs to be defined or this parameter become MANDATORY. 1322 Note that HNA does not defines ports for the Synchronization Channel. 1323 In any case, this is not expected to part of the configuration, but 1324 instead negotiated through the Configuration Channel. Currently the 1325 Configuration Channel does not provide this, and limits its agility 1326 to a dedicated IP address. If such agility is needed in the future, 1327 additional exchanges will need to be defined. 1329 Authentication Method ("hna_auth_method"): How the HNA authenticates 1330 itself to the DM within the TLS connection(s). The authentication 1331 meth of can typically be "certificate", "psk" or "none". This 1332 Parameter is OPTIONAL and by default the Authentication Method is 1333 "certificate". 1335 Authentication data ("hna_certificate", "hna_key"): : The certificate 1336 chain used to authenticate the HNA. This parameter is OPTIONAL and 1337 when not specified, a self-signed certificate is used. 1339 Distribution Manager AXFR permission netmask (dm_acl): The subnet 1340 from which the CPE should accept SOA queries and AXFR requests. A 1341 subnet is used in the case where the DNS Outsourced Infrastructure 1342 consists of a number of different systems. An array of addresses 1343 is permitted. This parameter is OPTIONAL and if unspecified, the 1344 CPE the IP addresses specified in the dm_notify parameters or the 1345 IP addresses that result from the DNS(SEC) resolution when 1346 dm_notify specifies a FQDN. 1348 For forward zones, the relationship between the HNA and the forward 1349 zone provider may be the result of a number of transactions: 1351 1. The forward zone outsourcing may be provided by the maker of the 1352 Homenet router. In this case, the identity and authorization 1353 could be built in the device at manufacturer provisioning time. 1354 The device would need to be provisioned with a device-unique 1355 credential, and it is likely that the Registered Homenet Domain 1356 would be derived from a public attribute of the device, such as a 1357 serial number (see Appendix B or 1358 [I-D.richardson-homerouter-provisioning] for more details ). 1360 2. The forward zone outsourcing may be provided by the Internet 1361 Service Provider. In this case, the use of 1362 [I-D.ietf-homenet-naming-architecture-dhc-options] to provide the 1363 credentials is appropriate. 1365 3. The forward zone may be outsourced to a third party, such as a 1366 domain registrar. In this case, the use of the JSON-serialized 1367 YANG data model described in this section is appropriate, as it 1368 can easily be copy and pasted by the user, or downloaded as part 1369 of a web transaction. 1371 For reverse zones, the relationship is always with the upstream ISP 1372 (although there may be more than one), and so 1373 [I-D.ietf-homenet-naming-architecture-dhc-options] is always the 1374 appropriate interface. 1376 The following is an abbridged example of a set of data that 1377 represents the needed configuration parameters for outsourcing. 1379 15. IANA Considerations 1381 This document has no actions for IANA. 1383 16. Acknowledgment 1385 The authors wish to thank Philippe Lemordant for its contributions on 1386 the early versions of the draft; Ole Troan for pointing out issues 1387 with the IPv6 routed home concept and placing the scope of this 1388 document in a wider picture; Mark Townsley for encouragement and 1389 injecting a healthy debate on the merits of the idea; Ulrik de Bie 1390 for providing alternative solutions; Paul Mockapetris, Christian 1391 Jacquenet, Francis Dupont and Ludovic Eschard for their remarks on 1392 HNA and low power devices; Olafur Gudmundsson for clarifying DNSSEC 1393 capabilities of small devices; Simon Kelley for its feedback as 1394 dnsmasq implementer; Andrew Sullivan, Mark Andrew, Ted Lemon, Mikael 1395 Abrahamson, and Ray Bellis for their feedback on handling different 1396 views as well as clarifying the impact of outsourcing the zone 1397 signing operation outside the HNA; Mark Andrew and Peter Koch for 1398 clarifying the renumbering. 1400 17. Contributors 1402 The co-authors would like to thank Chris Griffiths and Wouter 1403 Cloetens that provided a significant contribution in the early 1404 versions of the document. 1406 18. References 1408 18.1. Normative References 1410 [I-D.ietf-dprive-xfr-over-tls] 1411 Toorop, W., Dickinson, S., Sahib, S., Aras, P., and A. 1412 Mankin, "DNS Zone Transfer-over-TLS", draft-ietf-dprive- 1413 xfr-over-tls-11 (work in progress), April 2021. 1415 [RFC1034] Mockapetris, P., "Domain names - concepts and facilities", 1416 STD 13, RFC 1034, DOI 10.17487/RFC1034, November 1987, 1417 . 1419 [RFC1995] Ohta, M., "Incremental Zone Transfer in DNS", RFC 1995, 1420 DOI 10.17487/RFC1995, August 1996, 1421 . 1423 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1424 Requirement Levels", BCP 14, RFC 2119, 1425 DOI 10.17487/RFC2119, March 1997, 1426 . 1428 [RFC2136] Vixie, P., Ed., Thomson, S., Rekhter, Y., and J. Bound, 1429 "Dynamic Updates in the Domain Name System (DNS UPDATE)", 1430 RFC 2136, DOI 10.17487/RFC2136, April 1997, 1431 . 1433 [RFC4034] Arends, R., Austein, R., Larson, M., Massey, D., and S. 1434 Rose, "Resource Records for the DNS Security Extensions", 1435 RFC 4034, DOI 10.17487/RFC4034, March 2005, 1436 . 1438 [RFC4192] Baker, F., Lear, E., and R. Droms, "Procedures for 1439 Renumbering an IPv6 Network without a Flag Day", RFC 4192, 1440 DOI 10.17487/RFC4192, September 2005, 1441 . 1443 [RFC4301] Kent, S. and K. Seo, "Security Architecture for the 1444 Internet Protocol", RFC 4301, DOI 10.17487/RFC4301, 1445 December 2005, . 1447 [RFC4555] Eronen, P., "IKEv2 Mobility and Multihoming Protocol 1448 (MOBIKE)", RFC 4555, DOI 10.17487/RFC4555, June 2006, 1449 . 1451 [RFC4960] Stewart, R., Ed., "Stream Control Transmission Protocol", 1452 RFC 4960, DOI 10.17487/RFC4960, September 2007, 1453 . 1455 [RFC5155] Laurie, B., Sisson, G., Arends, R., and D. Blacka, "DNS 1456 Security (DNSSEC) Hashed Authenticated Denial of 1457 Existence", RFC 5155, DOI 10.17487/RFC5155, March 2008, 1458 . 1460 [RFC5936] Lewis, E. and A. Hoenes, Ed., "DNS Zone Transfer Protocol 1461 (AXFR)", RFC 5936, DOI 10.17487/RFC5936, June 2010, 1462 . 1464 [RFC6092] Woodyatt, J., Ed., "Recommended Simple Security 1465 Capabilities in Customer Premises Equipment (CPE) for 1466 Providing Residential IPv6 Internet Service", RFC 6092, 1467 DOI 10.17487/RFC6092, January 2011, 1468 . 1470 [RFC6644] Evans, D., Droms, R., and S. Jiang, "Rebind Capability in 1471 DHCPv6 Reconfigure Messages", RFC 6644, 1472 DOI 10.17487/RFC6644, July 2012, 1473 . 1475 [RFC6698] Hoffman, P. and J. Schlyter, "The DNS-Based Authentication 1476 of Named Entities (DANE) Transport Layer Security (TLS) 1477 Protocol: TLSA", RFC 6698, DOI 10.17487/RFC6698, August 1478 2012, . 1480 [RFC6762] Cheshire, S. and M. Krochmal, "Multicast DNS", RFC 6762, 1481 DOI 10.17487/RFC6762, February 2013, 1482 . 1484 [RFC6763] Cheshire, S. and M. Krochmal, "DNS-Based Service 1485 Discovery", RFC 6763, DOI 10.17487/RFC6763, February 2013, 1486 . 1488 [RFC6887] Wing, D., Ed., Cheshire, S., Boucadair, M., Penno, R., and 1489 P. Selkirk, "Port Control Protocol (PCP)", RFC 6887, 1490 DOI 10.17487/RFC6887, April 2013, 1491 . 1493 [RFC7010] Liu, B., Jiang, S., Carpenter, B., Venaas, S., and W. 1494 George, "IPv6 Site Renumbering Gap Analysis", RFC 7010, 1495 DOI 10.17487/RFC7010, September 2013, 1496 . 1498 [RFC7084] Singh, H., Beebee, W., Donley, C., and B. Stark, "Basic 1499 Requirements for IPv6 Customer Edge Routers", RFC 7084, 1500 DOI 10.17487/RFC7084, November 2013, 1501 . 1503 [RFC7296] Kaufman, C., Hoffman, P., Nir, Y., Eronen, P., and T. 1504 Kivinen, "Internet Key Exchange Protocol Version 2 1505 (IKEv2)", STD 79, RFC 7296, DOI 10.17487/RFC7296, October 1506 2014, . 1508 [RFC7344] Kumari, W., Gudmundsson, O., and G. Barwood, "Automating 1509 DNSSEC Delegation Trust Maintenance", RFC 7344, 1510 DOI 10.17487/RFC7344, September 2014, 1511 . 1513 [RFC7368] Chown, T., Ed., Arkko, J., Brandt, A., Troan, O., and J. 1514 Weil, "IPv6 Home Networking Architecture Principles", 1515 RFC 7368, DOI 10.17487/RFC7368, October 2014, 1516 . 1518 [RFC7558] Lynn, K., Cheshire, S., Blanchet, M., and D. Migault, 1519 "Requirements for Scalable DNS-Based Service Discovery 1520 (DNS-SD) / Multicast DNS (mDNS) Extensions", RFC 7558, 1521 DOI 10.17487/RFC7558, July 2015, 1522 . 1524 [RFC7707] Gont, F. and T. Chown, "Network Reconnaissance in IPv6 1525 Networks", RFC 7707, DOI 10.17487/RFC7707, March 2016, 1526 . 1528 [RFC7788] Stenberg, M., Barth, S., and P. Pfister, "Home Networking 1529 Control Protocol", RFC 7788, DOI 10.17487/RFC7788, April 1530 2016, . 1532 [RFC7858] Hu, Z., Zhu, L., Heidemann, J., Mankin, A., Wessels, D., 1533 and P. Hoffman, "Specification for DNS over Transport 1534 Layer Security (TLS)", RFC 7858, DOI 10.17487/RFC7858, May 1535 2016, . 1537 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 1538 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 1539 May 2017, . 1541 [RFC8375] Pfister, P. and T. Lemon, "Special-Use Domain 1542 'home.arpa.'", RFC 8375, DOI 10.17487/RFC8375, May 2018, 1543 . 1545 [RFC8415] Mrugalski, T., Siodelski, M., Volz, B., Yourtchenko, A., 1546 Richardson, M., Jiang, S., Lemon, T., and T. Winters, 1547 "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)", 1548 RFC 8415, DOI 10.17487/RFC8415, November 2018, 1549 . 1551 [RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol 1552 Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, 1553 . 1555 [RFC8555] Barnes, R., Hoffman-Andrews, J., McCarney, D., and J. 1556 Kasten, "Automatic Certificate Management Environment 1557 (ACME)", RFC 8555, DOI 10.17487/RFC8555, March 2019, 1558 . 1560 18.2. Informative References 1562 [I-D.ietf-dprive-dnsoquic] 1563 Huitema, C., Mankin, A., and S. Dickinson, "Specification 1564 of DNS over Dedicated QUIC Connections", draft-ietf- 1565 dprive-dnsoquic-02 (work in progress), February 2021. 1567 [I-D.ietf-homenet-naming-architecture-dhc-options] 1568 Migault, D., Weber, R., and T. Mrugalski, "DHCPv6 Options 1569 for Home Network Naming Authority", draft-ietf-homenet- 1570 naming-architecture-dhc-options-12 (work in progress), 1571 April 2021. 1573 [I-D.ietf-homenet-simple-naming] 1574 Lemon, T., Migault, D., and S. Cheshire, "Homenet Naming 1575 and Service Discovery Architecture", draft-ietf-homenet- 1576 simple-naming-03 (work in progress), October 2018. 1578 [I-D.richardson-homerouter-provisioning] 1579 Richardson, M., "Provisioning Initial Device Identifiers 1580 into Home Routers", draft-richardson-homerouter- 1581 provisioning-00 (work in progress), November 2020. 1583 [RFC2845] Vixie, P., Gudmundsson, O., Eastlake 3rd, D., and B. 1584 Wellington, "Secret Key Transaction Authentication for DNS 1585 (TSIG)", RFC 2845, DOI 10.17487/RFC2845, May 2000, 1586 . 1588 [RFC2931] Eastlake 3rd, D., "DNS Request and Transaction Signatures 1589 ( SIG(0)s )", RFC 2931, DOI 10.17487/RFC2931, September 1590 2000, . 1592 [RFC6749] Hardt, D., Ed., "The OAuth 2.0 Authorization Framework", 1593 RFC 6749, DOI 10.17487/RFC6749, October 2012, 1594 . 1596 [RFC8094] Reddy, T., Wing, D., and P. Patil, "DNS over Datagram 1597 Transport Layer Security (DTLS)", RFC 8094, 1598 DOI 10.17487/RFC8094, February 2017, 1599 . 1601 [RFC8484] Hoffman, P. and P. McManus, "DNS Queries over HTTPS 1602 (DoH)", RFC 8484, DOI 10.17487/RFC8484, October 2018, 1603 . 1605 [RFC8499] Hoffman, P., Sullivan, A., and K. Fujiwara, "DNS 1606 Terminology", BCP 219, RFC 8499, DOI 10.17487/RFC8499, 1607 January 2019, . 1609 [RFC8501] Howard, L., "Reverse DNS in IPv6 for Internet Service 1610 Providers", RFC 8501, DOI 10.17487/RFC8501, November 2018, 1611 . 1613 [RFC8610] Birkholz, H., Vigano, C., and C. Bormann, "Concise Data 1614 Definition Language (CDDL): A Notational Convention to 1615 Express Concise Binary Object Representation (CBOR) and 1616 JSON Data Structures", RFC 8610, DOI 10.17487/RFC8610, 1617 June 2019, . 1619 [RFC8672] Sheffer, Y. and D. Migault, "TLS Server Identity Pinning 1620 with Tickets", RFC 8672, DOI 10.17487/RFC8672, October 1621 2019, . 1623 Appendix A. Envisioned deployment scenarios 1625 A number of deployment have been envisioned, this section aims at 1626 providing a brief description. The use cases are not limitations and 1627 this section is not normative. 1629 A.1. CPE Vendor 1631 A specific vendor with specific relations with a registrar or a 1632 registry may sell a CPE that is provisioned with provisioned domain 1633 name. Such domain name does not need to be necessary human readable. 1635 One possible way is that the vendor also provisions the HNA with a 1636 private and public keys as well as a certificate. Note that these 1637 keys are not expected to be used for DNSSEC signing. Instead these 1638 keys are solely used by the HNA to proceed to the authentication. 1639 Normally the keys should be necessary and sufficient to proceed to 1640 the authentication. The reason to combine the domain name and the 1641 key is that DOI are likely handle names better than keys and that 1642 domain names might be used as a login which enables the key to be 1643 regenerated. 1645 When the home network owner plugs the CPE at home, the relation 1646 between HNA and DM is expected to work out-of-the-box. 1648 A.2. Agnostic CPE 1650 An CPE that is not preconfigured may also take advantage to the 1651 protocol defined in this document but some configuration steps will 1652 be needed. 1654 1. The owner of the home network buys a domain name to a registrar, 1655 and as such creates an account on that registrar 1657 2. Either the registrar is also providing the outsourcing 1658 infrastructure or the home network needs to create a specific 1659 account on the outsourcing infrastructure. * If the DOI is the 1660 registrar, it has by design a proof of ownership of the domain 1661 name by the homenet owner. In this case, it is expected the DOI 1662 provides the necessary parameters to the home network owner to 1663 configure the HNA. A good way to provide the parameters would be 1664 the home network be able to copy/paste a JSON object - see 1665 Section 14. What matters at that point is the DOI being able to 1666 generate authentication credentials for the HNA to authenticate 1667 itself to the DOI. This obviously requires the home network to 1668 provide the public key generated by the HNA in a CSR. 1670 o If the DOI is not the registrar, then the proof of ownership needs 1671 to be established using protocols like ACME [RFC8555] for example 1672 that will end in the generation of a certificate. ACME is used 1673 here to the purpose of automating the generation of the 1674 certificate, the CA may be a specific CA or the DOI. With that 1675 being done, the DOI has a roof of ownership and can proceed as 1676 above. 1678 Appendix B. Example: A manufacturer provisioned HNA product flow 1680 This scenario is one where a homenet router device manufacturer 1681 decides to offer DNS hosting as a value add. 1683 [I-D.richardson-homerouter-provisioning] describes a process for a 1684 home router credential provisioning system. The outline of it is 1685 that near the end of the manufacturing process, as part of the 1686 firmware loading, the manufacturer provisions a private key and 1687 certificate into the device. 1689 In addition to having a assymmetric credential known to the 1690 manufacturer, the device also has been provisioned with an agreed 1691 upon name. In the example in the above document, the name 1692 "n8d234f.r.example.net" has already been allocated and confirmed with 1693 the manufacturer. 1695 The HNA can use the above domain for itself. It is not very pretty 1696 or personal, but if the owner wishes a better name, they can arrange 1697 for it. 1699 The configuration would look like: 1701 { 1702 "dm_notify" : "2001:db8:1234:111:222::2", 1703 "dm_acl" : "2001:db8:1234:111:222::/64", 1704 "dm_ctrl" : "manufacturer.example.net", 1705 "dm_port" : "4433", 1706 "ns_list" : [ "ns1.publicdns.example", "ns2.publicdns.example"], 1707 "zone" : "n8d234f.r.example.net", 1708 "auth_method" : "certificate", 1709 "hna_certificate":"-----BEGIN CERTIFICATE-----\nMIIDTjCCFGy....", 1710 } 1712 The dm_ctrl and dm_port values would be built into the firmware. 1714 Authors' Addresses 1716 Daniel Migault 1717 Ericsson 1718 8275 Trans Canada Route 1719 Saint Laurent, QC 4S 0B6 1720 Canada 1722 EMail: daniel.migault@ericsson.com 1724 Ralf Weber 1725 Nominum 1726 2000 Seaport Blvd 1727 Redwood City 94063 1728 US 1730 EMail: ralf.weber@nominum.com 1732 Michael Richardson 1733 Sandelman Software Works 1734 470 Dawson Avenue 1735 Ottawa, ON K1Z 5V7 1736 Canada 1738 EMail: mcr+ietf@sandelman.ca 1740 Ray Hunter 1741 Globis Consulting BV 1742 Weegschaalstraat 3 1743 Eindhoven 5632CW 1744 NL 1746 EMail: v6ops@globis.net