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