idnits 2.17.1 draft-ietf-homenet-front-end-naming-delegation-11.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 (April 19, 2020) is 1462 days in the past. Is this intentional? -- Found something which looks like a code comment -- if you have code sections in the document, please surround them with '' and '' lines. Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'RFC2181' is defined on line 1393, but no explicit reference was found in the text == Unused Reference: 'RFC6672' is defined on line 1455, but no explicit reference was found in the text == Unused Reference: 'I-D.sury-dnsext-cname-dname' is defined on line 1538, but no explicit reference was found in the text ** Obsolete normative reference: RFC 2845 (Obsoleted by RFC 8945) ** Obsolete normative reference: RFC 4960 (Obsoleted by RFC 9260) ** Obsolete normative reference: RFC 5246 (Obsoleted by RFC 8446) ** Obsolete normative reference: RFC 6347 (Obsoleted by RFC 9147) == Outdated reference: A later version (-24) exists of draft-ietf-homenet-naming-architecture-dhc-options-06 Summary: 4 errors (**), 0 flaws (~~), 5 warnings (==), 2 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: Informational R. Weber 5 Expires: October 21, 2020 Nominum 6 M. Richardson 7 Sandelman Software Works 8 R. Hunter 9 Globis Consulting BV 10 C. Griffiths 12 W. Cloetens 13 SoftAtHome 14 April 19, 2020 16 Outsourcing Home Network Authoritative Naming Service 17 draft-ietf-homenet-front-end-naming-delegation-11 19 Abstract 21 The Homenet Naming authority is responsible for making devices within 22 the home network accessible by name within the home network as well 23 as from outside the home network (e.g. the Internet). The names of 24 the devices accessible from the Internet are stored in the Public 25 Homenet Zone, served by a DNS authoritative server. It is unlikely 26 that home networks will contain sufficiently robust platforms 27 designed to host a service such as the DNS on the Internet and as 28 such would expose the home network to DDoS attacks. 30 This document describes a mechanism that enables the Home Network 31 Authority (HNA) to outsource the naming service to the Outsourcing 32 Infrastructure via a Distribution Master (DM). 34 Status of This Memo 36 This Internet-Draft is submitted in full conformance with the 37 provisions of BCP 78 and BCP 79. 39 Internet-Drafts are working documents of the Internet Engineering 40 Task Force (IETF). Note that other groups may also distribute 41 working documents as Internet-Drafts. The list of current Internet- 42 Drafts is at https://datatracker.ietf.org/drafts/current/. 44 Internet-Drafts are draft documents valid for a maximum of six months 45 and may be updated, replaced, or obsoleted by other documents at any 46 time. It is inappropriate to use Internet-Drafts as reference 47 material or to cite them other than as "work in progress." 48 This Internet-Draft will expire on October 21, 2020. 50 Copyright Notice 52 Copyright (c) 2020 IETF Trust and the persons identified as the 53 document authors. All rights reserved. 55 This document is subject to BCP 78 and the IETF Trust's Legal 56 Provisions Relating to IETF Documents 57 (https://trustee.ietf.org/license-info) in effect on the date of 58 publication of this document. Please review these documents 59 carefully, as they describe your rights and restrictions with respect 60 to this document. Code Components extracted from this document must 61 include Simplified BSD License text as described in Section 4.e of 62 the Trust Legal Provisions and are provided without warranty as 63 described in the Simplified BSD License. 65 Table of Contents 67 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 68 1.1. Alternative solutions . . . . . . . . . . . . . . . . . . 5 69 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 6 70 3. Architecture Description . . . . . . . . . . . . . . . . . . 8 71 3.1. Architecture Overview . . . . . . . . . . . . . . . . . . 8 72 3.2. Distribution Master Communication Channels . . . . . . . 10 73 4. Control Channel between Homenet Naming Authority (HNA) and 74 Distribution Master (DM) . . . . . . . . . . . . . . . . . . 11 75 4.1. Information to build the Public Homenet Zone. . . . . . . 12 76 4.2. Information to build the DNSSEC chain of trust. . . . . . 12 77 4.3. Information to set the Synchronization Channel, . . . . . 12 78 4.4. Deleting the delegation . . . . . . . . . . . . . . . . . 13 79 4.5. Messages Exchange Description . . . . . . . . . . . . . . 13 80 4.5.1. Retrieving information for the Public Homenet Zone. . 13 81 4.5.2. Providing information for the DNSSEC chain of trust . 14 82 4.5.3. Providing information for the Synchronization Channel 15 83 4.5.4. HNA instructing deleting the delegation . . . . . . . 15 84 4.6. Securing the Control Channel between Homenet Naming 85 Authority (HNA) and Distribution Master (DM) . . . . . . 15 86 4.7. Implementation Tips . . . . . . . . . . . . . . . . . . . 16 87 5. DM Synchronization Channel between HNA and DM . . . . . . . . 17 88 5.1. Securing the Synchronization Channel between HNA and DM . 18 89 6. DM Distribution Channel . . . . . . . . . . . . . . . . . . . 18 90 7. HNA Security Policies . . . . . . . . . . . . . . . . . . . . 19 91 8. DNSSEC compliant Homenet Architecture . . . . . . . . . . . . 19 92 9. Homenet Reverse Zone . . . . . . . . . . . . . . . . . . . . 19 93 10. Renumbering . . . . . . . . . . . . . . . . . . . . . . . . . 20 94 10.1. Hidden Primary . . . . . . . . . . . . . . . . . . . . . 21 95 10.2. Distribution Master . . . . . . . . . . . . . . . . . . 22 97 11. Operational considerations for Offline/Disconnected 98 resolution . . . . . . . . . . . . . . . . . . . . . . . . . 22 99 12. provisioning of the Homenet Naming Authority (HNA) . . . . . 22 100 13. Privacy Considerations . . . . . . . . . . . . . . . . . . . 23 101 14. Security Considerations . . . . . . . . . . . . . . . . . . . 23 102 14.1. HNA DM channels . . . . . . . . . . . . . . . . . . . . 24 103 14.2. Names are less secure than IP addresses . . . . . . . . 24 104 14.3. Names are less volatile than IP addresses . . . . . . . 24 105 14.4. DNS Reflection Attacks . . . . . . . . . . . . . . . . . 25 106 14.5. Reflection Attack involving the Hidden Primary . . . . . 25 107 14.6. Reflection Attacks involving the DM . . . . . . . . . . 26 108 14.7. Reflection Attacks involving the Public Authoritative 109 Servers . . . . . . . . . . . . . . . . . . . . . . . . 27 110 14.8. Flooding Attack . . . . . . . . . . . . . . . . . . . . 27 111 14.9. Replay Attack . . . . . . . . . . . . . . . . . . . . . 28 112 15. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 29 113 16. Acknowledgment . . . . . . . . . . . . . . . . . . . . . . . 29 114 17. References . . . . . . . . . . . . . . . . . . . . . . . . . 29 115 17.1. Normative References . . . . . . . . . . . . . . . . . . 29 116 17.2. Informative References . . . . . . . . . . . . . . . . . 32 117 Appendix A. Envisioned deployment scenarios . . . . . . . . . . 34 118 A.1. CPE Vendor . . . . . . . . . . . . . . . . . . . . . . . 34 119 A.2. Agnostic CPE . . . . . . . . . . . . . . . . . . . . . . 34 120 Appendix B. Example: Homenet Zone . . . . . . . . . . . . . . . 35 121 Appendix C. Example: HNA necessary parameters for outsourcing . 37 122 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 38 124 1. Introduction 126 The Homenet Naming authority is responsible for making devices within 127 the home network accessible by name within the home network as well 128 as from outside the home network (e.g. the Internet). IPv6 129 connectivity provides the possibility of global end to end IP 130 connectivity. End users will be able to transparently make use of 131 this connectivity if they can use names to access the services they 132 want from their home network. 134 The use of a DNS zone for each home network is a reasonable and 135 scalable way to make the set of public names visible. There are a 136 number of ways to populate such a zone. This specification proposes 137 a way to do with based upon a number of assumptions about typical 138 home networks. 140 1. The names of the devices accessible from the Internet are stored 141 in the Public Homenet Zone, served by a DNS authoritative server. 143 2. It is unlikely that home networks will contain sufficiently 144 robust platforms designed to host a service such as the DNS on 145 the Internet and as such would expose the home network to DDoS 146 attacks. 148 3. [RFC7368] emphazes that the home network is subject to 149 connectivity disruptions with the ISP. But, names used within 150 the home MUST be resilient against such disruption. 152 So a goal of this specification is to make the public names 153 resolvable within both the home network and on the Internet, even 154 when there are disruptions. 156 This is achieved by having a device inside the home network that 157 builds, publishes, and manages a Public Homenet Zone, thus providing 158 bindings between public names, IP addresses, and other RR types. 160 The management of the names can be a role that the Customer Premises 161 Equipment (CPE) does. Other devices in the home network could 162 fulfill this role e.g. a NAS server, but for simplicity, this 163 document assumes the function is located on one of the CPE devices. 165 The homenet architecture [RFC7368] makes it clear that a home network 166 may have multiple CPEs. The management of the Public Homenet Zone 167 involves DNS specific mechanisms that cannot be distributed over 168 multiple servers (primary server), when multiple nodes can 169 potentially manage the Public Homenet Zone, a single node needs to be 170 selected per outsourced zone. This selected node is designated as 171 providing the Homenet Naming Authority (HNA) function. 173 The process by which a single HNA is selected per zone is not in 174 scope for this document. It is envisioned that a future document 175 will describe an HNCP mechanism to elect the single HNA. 177 CPEs, which may host the HNA function, as well as home network 178 devices, are usually low powered devices not designed for terminating 179 heavy traffic. As a result, hosting an authoritative DNS service 180 visible to the Internet may expose the home network to resource 181 exhaustion and other attacks. On the other hand, if the only copy of 182 the public zone is on the Internet, then Internet connectivity 183 disruptions would make the names unavailable inside the homenet. 185 In order to avoid resource exhaustion and other attacks, this 186 document describes an architecture that outsources the authoritative 187 naming service of the home network. More specifically, the HNA 188 builds the Public Homenet Zone and outsources it to an Outsourcing 189 Infrastructure via a Distribution Master (DM). The Outsourcing 190 Infrastructure is in charge of publishing the corresponding Public 191 Homenet Zone on the Internet. The transfer of DNS zone information 192 is achieved using standard DNS mechanisms involving primary and 193 secondary DNS servers, with the HNA hosted primary being a stealth 194 primary, and the Distribution Master a secondary. 196 Section 3.1 provides an architecture description that describes the 197 relation between the HNA and the Outsourcing Architecture. In order 198 to keep the Public Homenet Zone up-to-date Section 5 describes how 199 the HNA and the Outsourcing Infrastructure synchronizes the Pubic 200 Homenet Zone. 202 The proposed architecture is explicitly designed to enable fully 203 functional DNSSEC, and the Public Homenet Zone is expected to be 204 signed with a secure delegation. DNSSEC key management and zone 205 signing is handled by the HNA. 207 Section 9 discusses management of one or more reverse zones. It 208 shows that management of the reverse zones can be entirely automated 209 and benefit from a pre-established relation between the ISP and the 210 home network. Note that such scenarios may also be met for the 211 Public Homenet Zone, but not necessarily. 213 Section 10 discusses how renumbering should be handled. Finally, 214 Section 13 and Section 14 respectively discuss privacy and security 215 considerations when outsourcing the Public Homenet Zone. 217 The Public Homenet Zone is expected to contain public information 218 only in a single universal view. This document does not define how 219 the information required to construct this view is derived. 221 It is also not in the scope of this document to define names for 222 exclusive use within the boundaries of the local home network. 223 Instead, local scope information is expected to be provided to the 224 home network using local scope naming services. mDNS [RFC6762] DNS-SD 225 [RFC6763] are two examples of these services. Currently mDNS is 226 limited to a single link network. However, future protocols and 227 architectures [I-D.ietf-homenet-simple-naming] are expected to 228 leverage this constraint as pointed out in [RFC7558]. 230 1.1. Alternative solutions 232 An alternative existing solution in IPv4 is to have a single zone, 233 where a host uses a RESTful HTTP service to register a single name 234 into a common public zone. This is often called "Dynamic DNS", and 235 there are a number of commercial providers, including Dyn, Gandi etc. 236 These solutions were typically used by a host behind the CPE to make 237 it's CPE IPv4 address visible, usually in order to enable incoming 238 connections. 240 For a small number (one to three) of hosts, use of such a system 241 provides an alternative to the architecture described in this 242 document. 244 The alternative does suffer from some severe limitations: 246 o the CPE/HNA router is unaware of the process, and cannot respond 247 to queries for these names when there are disruptions in 248 connectivity. This makes the home user or application dependent 249 on having to resolve different names in the event of outages or 250 disruptions. 252 o the CPE/HNA router cannot control the process. Any host can do 253 this regardless of whether or not the home network administrator 254 wants the name published or not. There is therefore no possible 255 audit trail. 257 o the credentials for the dynamic DNS server need to be securely 258 transferred to all hosts that wish to use it. This is not a 259 problem for a technical user to do with one or two hosts, but it 260 does not scale to multiple hosts and becomes a problem for non- 261 technical users. 263 o "all the good names are taken" - current services put everyone's 264 names into some small set of zones, and there are often conflicts. 265 Distinguishing similar names by delegation of zones was among the 266 primary design goals of the DNS system. 268 o The RESTful services do not always support all RR types. The 269 homenet user is dependent on the service provider supporting new 270 types. By providing full DNS delegation, this document enables 271 all RR types and also future extensions. 273 There is no technical reason why a RESTful cloud service could not 274 provide solutions to many of these problems, but this document 275 describes a DNS based solution. 277 2. Terminology 279 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 280 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 281 "OPTIONAL" in this document are to be interpreted as described in 282 BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all 283 capitals, as shown here. 285 o Customer Premises Equipment: (CPE) is a router providing 286 connectivity to the home network. 288 o Homenet Zone: is the DNS zone for use within the boundaries of the 289 home network: home.arpa, see [RFC8375]). This zone is not 290 considered public and is out of scope for this document. 292 o Registered Homenet Domain: is the Domain Name associated with the 293 home network. 295 o Public Homenet Zone: contains the names in the home network that 296 are expected to be publicly resolvable on the Internet. 298 o Homenet Naming Authority: (HNA) is a function responsible for 299 managing the Public Homenet Zone. This includes populating the 300 Public Homenet Zone, signing the zone for DNSSEC, as well as 301 managing the distribution of that Homenet Zone to the Outsourcing 302 Infrastructure. 304 o Outsourcing Infrastructure: is the infrastructure responsible for 305 receiving the Public Homenet Zone and publishing it on the 306 Internet. It is mainly composed of a Distribution Master and 307 Public Authoritative Servers. 309 o Public Authoritative Servers: are the authoritative name servers 310 for the Public Homenet Zone. Name resolution requests for the 311 Homenet Domain are sent to these servers. For resiliency the 312 Public Homenet Zone SHOULD be hosted on multiple servers. 314 o Homenet Authoritative Servers: are authoritative name servers 315 within the Homenet network. 317 o Distribution Master (DM): is the (set of) server(s) to which the 318 HNA synchronizes the Public Homenet Zone, and which then 319 distributes the relevant information to the Public Authoritative 320 Servers. 322 o Homenet Reverse Zone: The reverse zone file associated with the 323 Public Homenet Zone. 325 o Reverse Public Authoritative Servers: equivalent to Public 326 Authoritative Servers specifically for reverse resolution. 328 o Reverse Distribution Master: equivalent to Distribution Master 329 specifically for reverse resolution. 331 o Homenet DNSSEC Resolver: a resolver that performs a DNSSEC 332 resolution on the home network for the Public Homenet Zone. The 333 resolution is performed requesting the Homenet Authoritative 334 Servers. 336 o DNSSEC Resolver: a resolver that performs a DNSSEC resolution on 337 the Internet for the Public Homenet Zone. The resolution is 338 performed requesting the Public Authoritative Servers. 340 3. Architecture Description 342 This section provides an overview of the architecture for outsourcing 343 the authoritative naming service from the HNA to the Outsourcing 344 Infrastructure in Section 3.1. Section Appendix B and Appendix C 345 illustrates this architecture with the example of a Public Homenet 346 Zone as well as necessary parameter to configure the HNA. 348 3.1. Architecture Overview 350 Figure 1 illustrates the architecture where the HNA outsources the 351 publication of the Public Homenet Zone to the Outsourcing 352 Infrastructure. 354 The Public Homenet Zone is identified by the Registered Homenet 355 Domain Name - example.com. 357 ".local" as well as ".home.arpa" are explicitly not considered as 358 Public Homenet zones. 360 The HNA SHOULD build the Public Homenet Zone in a single view 361 populated with all resource records that are expected to be published 362 on the Internet. 364 How the Public Homenet Zone is populated is out of the scope of this 365 document. The node providing the HNA function may also host or 366 interact with multiple services to determine name-to-address 367 mappings, such as a web GUI, DHCP [RFC6644] or mDNS [RFC6762]. These 368 services may coexist and may be used to populate the Public Homenet 369 Zone. 371 The HNA also signs the Public Homenet Zone. The HNA handles all 372 operations and keying material required for DNSSEC, so there is no 373 provision made in this architecture for transferring private DNSSEC 374 related keying material between the HNA and the DM. 376 Once the Public Homenet Zone has been built, the HNA outsources it to 377 the Outsourcing Infrastructure as described in Figure 1. 379 The HNA acts as a hidden primary while the DM behaves as a secondary 380 responsible to distribute the Public Homenet Zone to the multiple 381 Public Authoritative Servers that Outsourcing Infrastructure is 382 responsible for. 384 The DM has 3 communication channels: 386 o a DM Control Channel (see section Section 4) to configure the HNA 387 and the Outsourcing Infrastructure, 389 o a DM Synchronization Channel (see section Section 5 to synchronize 390 the Public Homenet Zone on the HNA and on the DM. 392 o one or more Distribution Channels (see section Section 6 that 393 distributes the Public Homenet Zone from the DM to the Public 394 Authoritative Server serving the Public Homenet Zone on the 395 Internet. 397 There MAY be multiple DM's, and multiple servers per DM. This text 398 assumes a single DM server for simplicity, but there is no reason why 399 each channel need to be implemented on the same server, or indeed use 400 the same code base. 402 It is important to note that while the HNA is configured as an 403 authoritative server, it is not expected to answer to DNS requests 404 from the public Internet for the Public Homenet Zone. The function 405 of the HNA is limited to building the zone and synchronization with 406 the DM. 408 The addresses associated with the HNA SHOULD NOT be mentioned in the 409 NS records of the Public Homenet zone, unless additional security 410 provisions necessary to protect the HNA from external attack have 411 been taken. 413 The Outsourcing Infrastructure is also responsible for ensuring the 414 DS record has been updated in the parent zone. 416 Resolution is performed by the DNSSEC resolvers. When the resolution 417 is performed outside the home network, the DNSSEC Resolver resolves 418 the DS record on the Global DNS and the name associated to the Public 419 Homenet Zone (example.com) on the Public Authoritative Servers. 421 When the resolution is performed from within the home network, the 422 Homenet DNSSEC Resolver may proceed similarly. On the other hand, to 423 provide resilience to the Public Homenet Zone in case of disruption, 424 the Homenet DNSSEC Resolver SHOULD be able to perform the resolution 425 on the authoritative name service of the home network implemented by 426 the Homenet Authoritative Servers. These servers are not expected to 427 be mentioned in the Public Homenet Zone, nor to be accessible from 428 the Internet. As such their information as well as the corresponding 429 signed DS record MAY be provided by the HNA to the Homenet DNSSEC 430 Resolvers e.g. using HNCP. Such configuration is outside the scope 431 of this document. 433 How the Homenet Authoritative Servers are provisioned is also out of 434 scope of this specification. It could be implemented using primary 435 secondaries servers, or via rsync. In some cases, the HNA and 436 Homenet Authoritative Servers may be combined together which would 437 result in a common instantiation of an authoritative server on the 438 WAN and inner interface. Other mechanisms may also be used. 440 Home network | Internet 441 | 442 | +----------------------------+ 443 | | Outsourcing Infrastructure | 444 Control | | | 445 +-----------------------+Channel | | +-----------------------+ | 446 | HNA |<-------------->| Distribution Master | | 447 |+---------------------+| | | |+---------------------+| | 448 || Public Homenet Zone ||Synchronization || Public Homenet Zone || | 449 || (example.com) ||Channel | | || (example.com) || | 450 |+---------------------+|<-------------->|+---------------------+| | 451 +----------------------+| | | +-----------------------+ | 452 | | ^ Distribution | 453 | | | Channel | 454 +-----------------------+ | | v | 455 | Homenet Authoritative | | | +-----------------------+ | 456 | Server(s) | | | | Public Authoritative | | 457 |+---------------------+| | | | Server(s) | | 458 ||Public Homenet Zone || | | |+---------------------+| | 459 || (example.com) || | | || Public Homenet Zone || | 460 |+---------------------+| | | || (example.com) || | 461 +-----------------------+ | | |+---------------------+| | 462 ^ | | | +-----------------------+ | 463 | | | +----------^---|-------------+ 464 | | | | | 465 | | name resolution | | 466 | v | | v 467 +----------------------+ | +-----------------------+ 468 | Homenet | | | Internet | 469 | DNSSEC Resolver | | | DNSSEC Resolver | 470 +----------------------+ | +-----------------------+ 472 Figure 1: Homenet Naming Architecture Name Resolution 474 3.2. Distribution Master Communication Channels 476 This section details the interfaces and channels of the DM, that is 477 the Control Channel, the Synchronization Channel and the Distribution 478 Channel. 480 The Control Channel and the Synchronization Channel are the 481 interfaces used between the HNA and the Outsourcing Infrastructure. 482 The entity within the Outsourcing Infrastructure responsible to 483 handle these communications is the DM and communications between the 484 HNA and the DM SHOULD be protected and mutually authenticated. While 485 section Section 4.6 discusses in more depth the different security 486 protocols that could be used to secure, this specification RECOMMENDS 487 the use of TLS with mutually authentication based on certificates to 488 secure the channel between the HNA and the DM. 490 The Control Channel is used to set up the Synchronization Channel. 491 We assume that the HNA initiates the Control Channel connection with 492 the DM and as such has a prior knowledge of the DM identity (X509 493 certificate), the IP address and port to use and protocol to set 494 secure session. We also assume the DM has knowledge of the identity 495 of the HNA (X509 certificate) as well as the Registered Homenet 496 Domain. 498 The information exchanged between the HNA and the DM is using DNS 499 messages. DNS messages can be protected using various kind of 500 transport layers, among others, UDP:53/DTLS, TLS/TCP:53, HTTPS:443. 501 There was consideration to using a standard TSIG [RFC2845] or SIG(0) 502 [RFC2931] to perform a dynamic DNS update to the DM. There are a 503 number of issues with this. The main one is that the Dynamic DNS 504 update would also update the zone's NS records, while the goal is to 505 update the Distribution Master's configuration files. The visible NS 506 records SHOULD remain pointing at the cloud provider's anycast 507 addresses. Revealing the address of the HNA in the DNS is not 508 desireable. 510 This specification also assumes the same transport protocol and ports 511 used by the DM to serve the Control Channel and by the HNA to serve 512 the Synchronization Channel are the same. 514 The Distribution Channel is internal to the Outsourcing 515 Infrastructure and as such is not the primary concern of this 516 specification. 518 4. Control Channel between Homenet Naming Authority (HNA) and 519 Distribution Master (DM) 521 The DM Control Channel is used by the HNA and the Outsourcing 522 Infrastructure to exchange information related to the configuration 523 of the delegation which includes: 525 4.1. Information to build the Public Homenet Zone. 527 When the Homenet Naming Authority builds the public zone, it must 528 include information that it retrieves from the Distribution Master 529 relating to how the zone is to be published. 531 The information includes at least names and IP addresses of the 532 Public Authoritative Name Servers. In term of RRset information: 534 o this includes the MNAME of the SOA, 536 o the NS and associated A and AAA RRsets of the name servers. 538 Optionally the Outsourcing Infrastructure MAY also provide 539 operational parameters such as other fields of SOA (SERIAL, RNAME, 540 REFRESH, RETRY, EXPIRE and MINIMUM). As the information is necessary 541 for the HNA to proceed and the information is associated to the 542 Outsourcing Infrastructure, this information exchange is mandatory. 544 4.2. Information to build the DNSSEC chain of trust. 546 The HNA SHOULD provide the hash of the KSK (DS RRset), so the that 547 Outsourcing Infrastructure provides this value to the parent zone. A 548 common deployment use case is that the Outsourcing Infrastructure is 549 the registrar of the Registered Homenet Domain, and as such, its 550 relationship with the registry of the parent zone enables it to 551 update the parent zone. When such relation exists, the HNA should be 552 able to request the Outsourcing Infrastructure to update the DS RRset 553 in the parent zone. A direct update is especially necessary to 554 initialize the chain of trust. 556 Though the HNA may also later directly update the values of the DS 557 via the Control Channel, it is RECOMMENDED to use other mechanisms 558 such as CDS and CDNSKEY [RFC7344] are used for key roll overs. 560 As some deployment may not provide an Outsourcing Infrastructure that 561 will be able to update the DS in the parent zone, this information 562 exchange is OPTIONAL. 564 By accepting the DS, the DM commits in taking care of advertising the 565 DS to the parent zone. Upon refusal, the DM MUST clearly indicate 566 the DM does not have the capacity to proceed to the update. 568 4.3. Information to set the Synchronization Channel, 570 That information sets the primary/secondary relation between the HNA 571 and the DM. The HNA works as a primary authoritative DNS server, and 572 MUST provide the corresponding IP address. 574 The specified IP address on the HNA side and the currently used IP 575 address of the DM defines the IP addresses involved in the 576 Synchronization Channel. Ports and transport protocol are the same 577 as those used by the Control Channel. By default, the same IP 578 address used by the HNA is considered by the DM. Exchange of this 579 information is OPTIONAL. 581 4.4. Deleting the delegation 583 The purpose of the previous sections were to exchange information in 584 order to set a delegation. The HNA MUST also be able to delete a 585 delegation with a specific DM. Upon an instruction of deleting the 586 delegation, the DM MUST stop serving the Public Homenet Zone. 588 4.5. Messages Exchange Description 590 There are multiple ways these information could be exchanged between 591 the HNA and the DM. This specification defines a mechanism that re- 592 use the DNS exchanges format. The intention is to reuse standard 593 libraries especially to check the format of the exchanged fields as 594 well as to minimize the additional libraries needed for the HNA. The 595 re-use of DNS exchanges achieves these goals. Note that while 596 information is provided using DNS exchanges, the exchanged 597 information is not expected to be set in any zone file, instead this 598 information is expected to be processed appropriately. 600 The Control Channel is not expected to be a long term session. After 601 a predefined timer the Control Channel is expected to be terminated. 602 The Control Channel MAY Be re-opened at any time later. 604 The provisioning process SHOULD provide a method of securing the 605 control channel, so that the content of messages can be 606 authenticated. This authentication MAY be based on certificates for 607 both the DM and each HNA. The DM may also create the initial 608 configuration for the delegation zone in the parent zone during the 609 provisioning process. 611 4.5.1. Retrieving information for the Public Homenet Zone. 613 The information provided by the DM to the HNA is retrieved by the HNA 614 with a AXFR exchange. The AXFR message enables the response to 615 contain any type of RRsets. The response might be extended in the 616 future if additional information will be needed. Alternatively, the 617 information provided by the HNA to the DM is pushed by the HNA via a 618 DNS update exchange. 620 To retrieve the necessary information to build the Public Homenet 621 Zone, the HNA MUST send an DNS request of type AXFR associated to the 622 Registered Homenet Domain. The DM MUST respond with a zone template. 623 The zone template MUST contain a RRset of type SOA, one or multiple 624 RRset of type NS and zero or more RRset of type A or AAAA. 626 The SOA RR is used to indicate to the HNA the value of the MNAME of 627 the Public Homenet Zone. The NAME of the SOA RR MUST be the 628 Registered Homenet Domain. The MNAME value of the SOA RDATA is the 629 value provided by the Outsourcing Infrastructure to the HNA. Other 630 RDATA values (RNAME, REFRESH, RETRY, EXPIRE and MINIMUM) are provided 631 by the Outsourcing Infrastructure as suggestions. The NS RRsets are 632 used to carry the Public Authoritative Servers of the Outsourcing 633 Infrastructure. Their associated NAME MUST be the Registered Homenet 634 Domain. The TTL and RDATA are those expected to be published on the 635 Public Homenet Zone. The RRsets of Type A and AAAA MUST have their 636 NAME matching the NSDNAME of one of the NS RRsets. 638 Upon receiving the response, the HNA MUST validate the conditions on 639 the SOA, NS and A or AAAA RRsets. If an error occurs, the HNA MUST 640 stop proceeding and MUST report an error. Otherwise, the HNA builds 641 the Public Homenet Zone by setting the MNAME value of the SOA as 642 indicated by the SOA provided by the AXFR response. The HNA SHOULD 643 set the value of NAME, REFRESH, RETRY, EXPIRE and MINIMUM of the SOA 644 to those provided by the AXFR response. The HNA MUST insert the NS 645 and corresponding A or AAAA RRset in its Public Homenet Zone. The 646 HNA MUST ignore other RRsets. If an error message is returned by the 647 DM, the HNA MUST proceed as a regular DNS resolution. Error messages 648 SHOULD be logged for further analysis. If the resolution does not 649 succeed, the outsourcing operation is aborted and the HNA MUST close 650 the Control Channel. 652 4.5.2. Providing information for the DNSSEC chain of trust 654 To provide the DS RRset to initialize the DNSSEC chain of trust the 655 HNA MAY send a DNS UPDATE [RFC2136] message. The NAME in the SOA 656 MUST be set to the parent zone of the Registered Homenet Domain - 657 that is where the DS records should be inserted. The DS RRset MUST 658 be placed in the Update section of the UPDATE query, and the NAME 659 SHOULD be set to the Registered Homenet Domain. The rdata of the DS 660 RR SHOULD correspond to the DS record to be inserted in the parent 661 zone. 663 A NOERROR response from the MD is a commitment to update the parent 664 zone with the provided DS. An error indicates the MD will not update 665 the DS, and other method should be used by the HNA. 667 4.5.3. Providing information for the Synchronization Channel 669 To provide the IP address of the primary, the HNA MAY send a DNS 670 UPDATE message. The NAME in the SOA MUST be the parent zone of the 671 Registered Homenet Domain. The Update section MUST be a RRset of 672 Type NS. The NAME associated to the NS RRSet MUST be the Registered 673 Domain Name. The RDATA MUST be a FQDN that designates the IP 674 addresses associated to the primary. There may be multiple IP 675 addresses. These IP addresses MUST be provided in the additional 676 section. The reason to provide these IP addresses is that it is NOT 677 RECOMMENDED to publish these IP addresses. As a result, it is not 678 expected to resolve them. IP addresses are provided via RRsets of 679 type A or AAAA. The NAME associated to RRsets of type A and AAAA 680 MUST be the Registered Homenet Domain. 682 A NOERROR response indicates the DM has configured the secondary and 683 is committed to serve as a secondary. An error indicates the DM is 684 not configured as a secondary. 686 The regular DNS error message SHOULD be returned to the HNA when an 687 error occurs. In particular a FORMERR is returned when a format 688 error is found, this error includes when unexpected RRSets are added 689 or when RRsets are missing. A SERVFAIL error is returned when a 690 internal error is encountered. a NOTZONE error is returned when 691 update and Zone sections are not coherent, a NOTAUTH error is 692 returned when the DM is not authoritative for the Zone section. A 693 REFUSED error is returned when the DM refuses to proceed to the 694 configuration and the requested action. 696 4.5.4. HNA instructing deleting the delegation 698 To instruct to delete the delegation the HNA MAY send a DNS UPDATE 699 Delete message. The NAME in the SOA MUST be the parent zone of the 700 Registered Homenet Domain. The Update section MUST be a RRset of 701 Type NS. The NAME associated to the NS RRSet MUST be the Registered 702 Domain Name. As indictaed by [RFC2136] section 2.5.2 the delete 703 instruction is set by setting the TTL to 0, the CLass to ANY, the 704 RDLENGTH to 0 and the RDATA MUST be empty. 706 4.6. Securing the Control Channel between Homenet Naming Authority 707 (HNA) and Distribution Master (DM) 709 The control channel between the HNA and the DM MUST be secured at 710 both the HNA and the DM. 712 Secure protocols (like TLS [RFC5246] / DTLS [RFC6347]) SHOULD be used 713 to secure the transactions between the DM and the HNA. 715 The advantage of TLS/DTLS is that this technology is widely deployed, 716 and most of the devices already embed TLS/DTLS libraries, possibly 717 also taking advantage of hardware acceleration. Further, TLS/DTLS 718 provides authentication facilities and can use certificates to 719 mutually authenticate the DM and HNA at the applicationlayer, 720 including available API. On the other hand, using TLS/DTLS requires 721 implementing DNS exchanges over TLS/DTLS, as well as a new service 722 port. 724 The HNA SHOULD authenticate inbound connections from the DM using 725 standard mechanisms, such as a public certificate with baked-in root 726 certificates on the HNA, or via DANE {!RFC6698}}. The HNA is expected 727 to be provisioned with a connection to the DM by the manufacturer, or 728 during some user-initiated onboarding process, see Section 12. 730 The DM SHOULD authenticate the HNA and check that inbound messages 731 are from the appropriate client. The DM MAY use a self-signed CA 732 certificate mechanism per HNA, or public certificates for this 733 purpose. 735 IPsec [RFC4301] and IKEv2 [RFC7296] were considered. They would need 736 to operate in transport mode, and the authenticated end points would 737 need to be visible to the applications, and this is not commonly 738 available at the time of this writing. 740 A pure DNS solution using TSIG and/or SIG(0) to authenticate message 741 was also considered. Section 12 envisions one mechanism would 742 involve the end user, with a browser, signing up to a service 743 provider, with a resulting OAUTH2 token to be provided to the HNA. A 744 way to translate this OAUTH2 token from HTTPS web space to DNS SIG(0) 745 space seems overly problematic, and so the enrollment protocol using 746 web APIs was determined to be easier to implement at scale. 748 Note also that authentication of message exchanges between the HNA 749 and the DM SHOULD NOT use the external IP address of the HNA to index 750 the appropriate keys. As detailed in Section 10, the IP addresses of 751 the DM and the Hidden Primary are subject to change, for example 752 while the network is being renumbered. This means that the necessary 753 keys to authenticate transaction SHOULD NOT be indexed using the IP 754 address, and SHOULD be resilient to IP address changes. This should 755 apply to any OAUTH2 token produced as envisioned by Section 12. 757 4.7. Implementation Tips 759 The Hidden Primary Server on the HNA differs from a regular 760 authoritative server for the home network due to: 762 o Interface Binding: the Hidden Primary Server will almost certainly 763 listen on the WAN Interface, whereas a regular authoritative 764 server for the home network would listen on the internal home 765 network interface. 767 o Limited exchanges: the purpose of the Hidden Primary Server is to 768 synchronize with the DM, not to serve any zones to end users, or 769 the public Internet. 771 As a result, exchanges are performed with specific nodes (the DM). 772 Further, exchange types are limited. The only legitimate exchanges 773 are: NOTIFY initiated by the Hidden Primary and IXFR or AXFR 774 exchanges initiated by the DM. On the other hand, regular 775 authoritative servers would respond to any hosts, and any DNS query 776 would be processed. The HNA SHOULD filter IXFR/AXFR traffic and drop 777 traffic not initiated by the DM. The HNA MUST listen for DNS on TCP 778 and UDP and MUST at least allow SOA lookups of the Homenet Zone. 780 5. DM Synchronization Channel between HNA and DM 782 The DM Synchronization Channel is used for communication between the 783 HNA and the DM for synchronizing the Public Homenet Zone. Note that 784 the Control Channel and the Synchronization Channel are by 785 construction different channels even though there they MAY use the 786 same IP addresses. In fact the Control Channel is set between the 787 HNA working as a client using port YYYY (a high range port) toward a 788 service provided by the MD at port XX (well known port). On the 789 other hand, the Synchronization Channel is set between the MD working 790 as a client using port ZZZZ ( a high range port) toward a service a 791 service provided by the HNA at port XX. As a result, even though the 792 same couple of IP addresses may be involved the Control Channel and 793 the Synchronization Channel are always disc tint channels. 795 Uploading and dynamically updating the zone file on the DM can be 796 seen as zone provisioning between the HNA (Hidden Primary) and the DM 797 (Secondary Server). This can be handled via AXFR + DNS UPDATE. 799 This document RECOMMENDS use of a primary / secondary mechanism 800 instead of the use of DNS UPDATE. The primary / secondary mechanism 801 is RECOMMENDED as it scales better and avoids DoS attacks. Note that 802 even when UPDATE messages are used, these messages are using a 803 distinct channel as those used to set the configuration. 805 Note that there is no standard way to distribute a DNS primary 806 between multiple devices. As a result, if multiple devices are 807 candidate for hosting the Hidden Primary, some specific mechanisms 808 should be designed so the home network only selects a single HNA for 809 the Hidden Primary. Selection mechanisms based on HNCP [RFC7788] are 810 good candidates. 812 The HNA acts as a Hidden Primary Server, which is a regular 813 authoritative DNS Server listening on the WAN interface. 815 The DM is configured as a secondary for the Homenet Domain Name. 816 This secondary configuration has been previously agreed between the 817 end user and the provider of the Outsourcing Infrastructure as part 818 of either the provisioning or due to receipt of UPDATE messages on 819 the DM Control Channel. 821 The Homenet Reverse Zone MAY also be updated either with DNS UPDATE 822 [RFC2136] or using a primary / secondary synchronization. 824 5.1. Securing the Synchronization Channel between HNA and DM 826 The Synchronization Channel used standard DNS request. 828 First the primary notifies the secondary that the zone must be 829 updated and eaves the secondary to proceed with the update when 830 possible/ convenient. 832 Then, a NOTIFY message is sent by the primary, which is a small 833 packet that is less likely to load the secondary. 835 Finally, the AXFR [RFC1034] or IXFR [RFC1995] query performed by the 836 secondary is a small packet sent over TCP (section 4.2 [RFC5936]), 837 which mitigates reflection attacks using a forged NOTIFY. 839 The AXFR request from the DM to the HNA SHOULD be secured. DNS over 840 TLS [RFC7858] is RECOMMENDED. 842 When using TLS, the HNA MAY authenticate inbound connections from the 843 DM using standard mechanisms, such as a public certificate with 844 baked-in root certificates on the HNA, or via DANE {!RFC6698}} 846 The HNA MAY apply a simple IP filter on inbound AXFR requests to 847 ensure they only arrive from the DM Synchronization Channel. In this 848 case, the HNA SHOULD regularly check (via DNS resolution) that the 849 address of the DM in the filter is still valid. 851 6. DM Distribution Channel 853 The DM Distribution Channel is used for communication between the DM 854 and the Public Authoritative Servers. The architecture and 855 communication used for the DM Distribution Channels is outside the 856 scope of this document, and there are many existing solutions 857 available e.g. rsynch, DNS AXFR, REST, DB copy. 859 7. HNA Security Policies 861 This section details security policies related to the Hidden Primary 862 / Secondary synchronization. 864 The Hidden Primary, as described in this document SHOULD drop any 865 queries from the home network. This could be implemented via port 866 binding and/or firewall rules. The precise mechanism deployed is out 867 of scope of this document. The Hidden Primary SHOULD drop any DNS 868 queries arriving on the WAN interface that are not issued from the 869 DM. The Hidden Primary SHOULD drop any outgoing packets other than 870 DNS NOTIFY query, SOA response, IXFR response or AXFR responses. The 871 Hidden Primary SHOULD drop any incoming packets other than DNS NOTIFY 872 response, SOA query, IXFR query or AXFR query. The Hidden Primary 873 SHOULD drop any non protected IXFR or AXFR exchange,depending on how 874 the synchronization is secured. 876 8. DNSSEC compliant Homenet Architecture 878 [RFC7368] in Section 3.7.3 recommends DNSSEC to be deployed on both 879 the authoritative server and the resolver. The resolver side is out 880 of scope of this document, and only the authoritative part of the 881 server is considered. 883 This document assumes the HNA signs the Public Homenet Zone. 885 Secure delegation is achieved only if the DS RRset is properly set in 886 the parent zone. Secure delegation is performed by the HNA or the 887 Outsourcing Infrastructures. 889 The DS RRset can be updated manually with nsupdate for example. This 890 requires the HNA or the Outsourcing Infrastructure to be 891 authenticated by the DNS server hosting the parent of the Public 892 Homenet Zone. Such a trust channel between the HNA and the parent 893 DNS server may be hard to maintain with HNAs, and thus may be easier 894 to establish with the Outsourcing Infrastructure. In fact, the 895 Public Authoritative Server(s) may use Automating DNSSEC Delegation 896 Trust Maintenance [RFC7344]. 898 9. Homenet Reverse Zone 900 The Public Homenet Zone is associated to a Registered Homenet Domain 901 and the ownership of that domain requires a specific registration 902 from the end user as well as the HNA being provisioned with some 903 authentication credentials . Such steps are mandatory unless the 904 Outsourcing Infrastructure has some other means to authenticate the 905 HNA. Such situation may occur, for example, when the ISP provides 906 the Homenet Domain as well as the Outsourcing Infrastructure. In 907 this case, the HNA may be authenticated by the physical link layer, 908 in which case the authentication of the HNA may be performed without 909 additional provisioning of the HNA. While this may be not so common 910 for the Public Homenet Zone, this situation is expected to be quite 911 common for the Reverse Homenet Zone. 913 More specifically, a common case is that the upstream ISP provides 914 the IPv6 prefix to the Homenet with a IA_PD [RFC8415] option and 915 manages the Outsourcing Infrastructure of the associated reverse 916 zone. This leave place for setting up automatically the relation 917 between HNA and the Outsourcing infrastructure as described in 918 [I-D.ietf-homenet-naming-architecture-dhc-options]. 920 With this relation automatically configured, the synchronization 921 between the Home network and the Outsourcing infrastructure happens 922 similarly as for the Public Homenet Zone described earlier in this 923 document. 925 Note that for home networks hosted by multiple ISPs, each ISP 926 provides only the Outsourcing Infrastructure of the reverse zones 927 associated to the delegated prefix. It is also likely that the DNS 928 exchanges will need to be performed on dedicated interfaces as to be 929 accepted by the ISP. More specifically, the reverse zone associated 930 to prefix 1 will not be possible to be performs by the HNA using an 931 IP address that belongs to prefix 2. Such constraints does not raise 932 major concerns either for hot standby or load sharing configuration. 934 With IPv6, the domain space for IP addresses is so large that reverse 935 zone may be confronted with scalability issues. How the reverse zone 936 is generated is out of scope of this document. 937 [I-D.howard-dnsop-ip6rdns] provides guidance on how to address 938 scalability issues. 940 10. Renumbering 942 This section details how renumbering is handled by the Hidden Primary 943 server or the DM. Both types of renumbering are discussed i.e. 944 "make-before-break" and "break-before-make". 946 In the make-before-break renumbering scenario, the new prefix is 947 advertised, the network is configured to prepare the transition to 948 the new prefix. During a period of time, the two prefixes old and 949 new coexist, before the old prefix is completely removed. In the 950 break-before-make renumbering scenario, the new prefix is advertised 951 making the old prefix obsolete. 953 Renumbering has been extensively described in [RFC4192] and analyzed 954 in [RFC7010] and the reader is expected to be familiar with them 955 before reading this section. 957 10.1. Hidden Primary 959 In a renumbering scenario, the Hidden Primary is informed it is being 960 renumbered. In most cases, this occurs because the whole home 961 network is being renumbered. As a result, the Public Homenet Zone 962 will also be updated. Although the new and old IP addresses may be 963 stored in the Public Homenet Zone, we recommend that only the newly 964 reachable IP addresses be published. 966 To avoid reachability disruption, IP connectivity information 967 provided by the DNS SHOULD be coherent with the IP plane. In our 968 case, this means the old IP address SHOULD NOT be provided via the 969 DNS when it is not reachable anymore. Let for example TTL be the TTL 970 associated with a RRset of the Public Homenet Zone, it may be cached 971 for TTL seconds. Let T_NEW be the time the new IP address replaces 972 the old IP address in the Homenet Zone, and T_OLD_UNREACHABLE the 973 time the old IP is not reachable anymore. 975 In the case of the make-before-break, seamless reachability is 976 provided as long as T_OLD_UNREACHABLE - T_NEW > 2 * TTL. If this is 977 not satisfied, then devices associated with the old IP address in the 978 home network may become unreachable for 2 * TTL - (T_OLD_UNREACHABLE 979 - T_NEW). In the case of a break-before-make, T_OLD_UNREACHABLE = 980 T_NEW, and the device may become unreachable up to 2 * TTL. 982 Once the Public Homenet Zone file has been updated on the Hidden 983 Primary, the Hidden Primary needs to inform the Outsourcing 984 Infrastructure that the Public Homenet Zone has been updated and that 985 the IP address to use to retrieve the updated zone has also been 986 updated. Both notifications are performed using regular DNS 987 exchanges. Mechanisms to update an IP address provided by lower 988 layers with protocols like SCTP [RFC4960], MOBIKE [RFC4555] are not 989 considered in this document. 991 The Hidden Primary SHOULD inform the DM that the Public Homenet Zone 992 has been updated by sending a NOTIFY payload with the new IP address. 993 In addition, this NOTIFY payload SHOULD be authenticated using SIG(0) 994 or TSIG. When the DM receives the NOTIFY payload, it MUST 995 authenticate it. Note that the cryptographic key used for the 996 authentication SHOULD be indexed by the Registered Homenet Domain 997 contained in the NOTIFY payload as well as the RRSIG. In other 998 words, the IP address SHOULD NOT be used as an index. If 999 authentication succeeds, the DM MUST also notice the IP address has 1000 been modified and perform a reachability check before updating its 1001 primary configuration. The routability check MAY performed by 1002 sending a SOA request to the Hidden Primary using the source IP 1003 address of the NOTIFY. This exchange is also secured, and if an 1004 authenticated response is received from the Hidden Primary with the 1005 new IP address, the DM SHOULD update its configuration file and 1006 retrieve the Public Homenet Zone using an AXFR or a IXFR exchange. 1008 Note that the primary reason for providing the IP address is that the 1009 Hidden Primary is not publicly announced in the DNS. If the Hidden 1010 Primary were publicly announced in the DNS, then the IP address 1011 update could have been performed using the DNS as described in 1012 Section 10.2. 1014 10.2. Distribution Master 1016 Renumbering of the Distribution Master results in it changing its IP 1017 address. As the DM is a secondary, the destination of DNS NOTIFY 1018 payloads MUST be changed, and any configuration/firewalling that 1019 restricts DNS AXFR/IXFR operations MUST be updated. 1021 If the DM is configured in the Hidden Primary configuration file 1022 using a FQDN, then the update of the IP address is performed by DNS. 1023 More specifically, before sending the NOTIFY, the Hidden Primary 1024 performs a DNS resolution to retrieve the IP address of the 1025 secondary. 1027 As described in Section 10.1, the DM DNS information SHOULD be 1028 coherent with the IP plane. The TTL of the Distribution Master name 1029 SHOULD be adjusted appropriately prior to changing the IP address. 1031 Some DNS infrastructure uses the IP address to designate the 1032 secondary, in which case, other mechanisms must be found. The reason 1033 for using IP addresses instead of names is generally to reach an 1034 internal interface that is not designated by a FQDN, and to avoid 1035 potential bootstrap problems. Such scenarios are considered as out 1036 of scope in the case of home networks. 1038 11. Operational considerations for Offline/Disconnected resolution 1040 This section is non-normative. It provides suggestions on 1041 operational consideration. TBD. 1043 12. provisioning of the Homenet Naming Authority (HNA) 1045 This document does not deal with how the HNA is provisioned with a 1046 trusted relationship to the Distribution Master for the forward zone. 1047 Provisioning of the relationship with an ISP-connection specific 1048 Distribution Master for reverse zones is dealt with in 1049 [I-D.ietf-homenet-naming-architecture-dhc-options] 1051 This section details what needs to be provisioned into the HNA and 1052 serves as a requirements statement for mechanisms. 1054 13. Privacy Considerations 1056 Outsourcing the DNS Authoritative service from the HNA to a third 1057 party raises a few privacy related concerns. 1059 The Public Homenet Zone contains a full description of the services 1060 hosted in the network. These services may not be expected to be 1061 publicly shared although their names remain accessible through the 1062 Internet. Even though DNS makes information public, the DNS does not 1063 expect to make the complete list of services public. In fact, making 1064 information public still requires the key (or FQDN) of each service 1065 to be known by the resolver in order to retrieve information about 1066 the services. More specifically, making mywebsite.example.com public 1067 in the DNS, is not sufficient to make resolvers aware of the 1068 existence web site. However, an attacker may walk the reverse DNS 1069 zone, or use other reconnaissance techniques to learn this 1070 information as described in [RFC7707]. 1072 In order to prevent the complete Public Homenet Zone being published 1073 on the Internet, AXFR queries SHOULD be blocked on the Public 1074 Authoritative Server(s). Similarly, to avoid zone-walking NSEC3 1075 [RFC5155] SHOULD be preferred over NSEC [RFC4034]. When the Public 1076 Homenet Zone is outsourced, the end user should be aware that it 1077 provides a complete description of the services available on the home 1078 network. More specifically, names usually provides a clear 1079 indication of the service and possibly even the device type, and as 1080 the Public Homenet Zone contains the IP addresses associated with the 1081 service, they also limit the scope of the scan space. 1083 In addition to the Public Homenet Zone, the third party can also 1084 monitor the traffic associated with the Public Homenet Zone. This 1085 traffic may provide an indication of the services an end user 1086 accesses, plus how and when they use these services. Although, 1087 caching may obfuscate this information inside the home network, it is 1088 likely that outside your home network this information will not be 1089 cached. 1091 14. Security Considerations 1093 The Homenet Naming Architecture described in this document solves 1094 exposing the HNA's DNS service as a DoS attack vector. 1096 14.1. HNA DM channels 1098 The HNA DM channels are specified to include their own security 1099 mechanisms that are designed to provide the minimum attacke surface, 1100 and to authenticate transactions where necessary. 1102 Note that in the case of the Reverse Homenet Zone, the data is less 1103 subject to attacks than in the Public Homenet Zone. In addition, the 1104 HNA and the DM MAY belong to the same administrative domain, i.e. the 1105 ISP. More specifically, the WAN interface is located in the ISP 1106 network. As a result, if provisioned using DHCPv6, the security 1107 credential may not even transit in the home network. On the other 1108 hand, if the HNA is not hosted at the border of the home network, the 1109 credential may rely on the security associated to DHCPv6. Even if 1110 HNA and DM are in the same administrative domain it is strongly 1111 RECOMMENDED to use a secure channel. 1113 14.2. Names are less secure than IP addresses 1115 This document describes how an end user can make their services and 1116 devices from his home network reachable on the Internet by using 1117 names rather than IP addresses. This exposes the home network to 1118 attackers, since names are expected to include less entropy than IP 1119 addresses. In fact, with IP addresses, the Interface Identifier is 1120 64 bits long leading to up to 2^64 possibilities for a given 1121 subnetwork. This is not to mention that the subnet prefix is also of 1122 64 bits long, thus providing up to 2^64 possibilities. On the other 1123 hand, names used either for the home network domain or for the 1124 devices present less entropy (livebox, router, printer, nicolas, 1125 jennifer, ...) and thus potentially exposes the devices to dictionary 1126 attacks. 1128 14.3. Names are less volatile than IP addresses 1130 IP addresses may be used to locate a device, a host or a service. 1131 However, home networks are not expected to be assigned a time 1132 invariant prefix by ISPs. As a result, observing IP addresses only 1133 provides some ephemeral information about who is accessing the 1134 service. On the other hand, names are not expected to be as volatile 1135 as IP addresses. As a result, logging names over time may be more 1136 valuable than logging IP addresses, especially to profile an end 1137 user's characteristics. 1139 PTR provides a way to bind an IP address to a name. In that sense, 1140 responding to PTR DNS queries may affect the end user's privacy. For 1141 that reason end users may choose not to respond to PTR DNS queries 1142 and MAY instead return a NXDOMAIN response. 1144 14.4. DNS Reflection Attacks 1146 An attacker performs a reflection attack when it sends traffic to one 1147 or more intermediary nodes (reflectors), that in turn send back 1148 response traffic to the victim. Motivations for using an 1149 intermediary node might be anonymity of the attacker, as well as 1150 amplification of the traffic. Typically, when the intermediary node 1151 is a DNSSEC server, the attacker sends a DNSSEC query and the victim 1152 is likely to receive a DNSSEC response. This section analyzes how 1153 the different components may be involved as a reflector in a 1154 reflection attack. Section 14.5 considers the Hidden Primary, 1155 Section 14.6 the Synchronization Server, and Section 14.7 the Public 1156 Authoritative Server(s). 1158 14.5. Reflection Attack involving the Hidden Primary 1160 With the specified architecture, the Hidden Primary is only expected 1161 to receive DNS queries of type SOA, AXFR or IXFR. This section 1162 analyzes how these DNS queries may be used by an attacker to perform 1163 a reflection attack. 1165 DNS queries of type AXFR and IXFR use TCP and as such are less 1166 subject to reflection attacks. This makes SOA queries the only 1167 remaining practical vector of attacks for reflection attacks, based 1168 on UDP. 1170 SOA queries are not associated with a large amplification factor 1171 compared to queries of type "ANY" or to query of non existing FQDNs. 1172 This reduces the probability a DNS query of type SOA will be involved 1173 in a DDoS attack. 1175 SOA queries are expected to follow a very specific pattern, which 1176 makes rate limiting techniques an efficient way to limit such 1177 attacks, and associated impact on the naming service of the home 1178 network. 1180 Motivations for such a flood might be a reflection attack, but could 1181 also be a resource exhaustion attack performed against the Hidden 1182 Primary. The Hidden Primary only expects to exchange traffic with 1183 the DM, that is its associated secondary. Even though secondary 1184 servers may be renumbered as mentioned in Section 10, the Hidden 1185 Primary is likely to perform a DNSSEC resolution and find out the 1186 associated secondary's IP addresses in use. As a result, the Hidden 1187 Primary is likely to limit the origin of its incoming traffic based 1188 on the origin IP address. 1190 With filtering rules based on IP address, SOA flooding attacks are 1191 limited to forged packets with the IP address of the secondary 1192 server. In other words, the only victims are the Hidden Primary 1193 itself or the secondary. There is a need for the Hidden Primary to 1194 limit that flood to limit the impact of the reflection attack on the 1195 secondary, and to limit the resource needed to carry on the traffic 1196 by the HNA hosting the Hidden Primary. On the other hand, mitigation 1197 should be performed appropriately, so as to limit the impact on the 1198 legitimate SOA sent by the secondary. 1200 The main reason for the DM sending a SOA query is to update the SOA 1201 RRset after the TTL expires, to check the serial number upon the 1202 receipt of a NOTIFY query from the Hidden Primary, or to re-send the 1203 SOA request when the response has not been received. When a flood of 1204 SOA queries is received by the Hidden Primary, the Hidden Primary may 1205 assume it is involved in an attack. 1207 There are few legitimate time slots when the secondary is expected to 1208 send a SOA query. Suppose T_NOTIFY is the time a NOTIFY is sent by 1209 the Hidden Primary, T_SOA the last time the SOA has been queried, TTL 1210 the TTL associated to the SOA, and T_REFRESH the refresh time defined 1211 in the SOA RRset. The specific time SOA queries are expected can be 1212 for example T_NOTIFY, T_SOA + 2/3 TTL, T_SOA + TTL, T_SOA + 1213 T_REFRESH., and. Outside a few minutes following these specific time 1214 slots, the probability that the HNA discards a legitimate SOA query 1215 is very low. Within these time slots, the probability the secondary 1216 may have its legitimate query rejected is higher. If a legitimate 1217 SOA is discarded, the secondary will re-send SOA query every "retry 1218 time" second until "expire time" seconds occurs, where "retry time" 1219 and "expire time" have been defined in the SOA. 1221 As a result, it is RECOMMENDED to set rate limiting policies to 1222 protect HNA resources. If a flood lasts more than the expired time 1223 defined by the SOA, it is RECOMMENDED to re-initiate a 1224 synchronization between the Hidden Primary and the secondaries. 1226 14.6. Reflection Attacks involving the DM 1228 The DM acts as a secondary coupled with the Hidden Primary. The 1229 secondary expects to receive NOTIFY query, SOA responses, AXFR and 1230 IXFR responses from the Hidden Primary. 1232 Sending a NOTIFY query to the secondary generates a NOTIFY response 1233 as well as initiating an SOA query exchange from the secondary to the 1234 Hidden Primary. As mentioned in [RFC1996], this is a known "benign 1235 denial of service attack". As a result, the DM SHOULD enforce rate 1236 limiting on sending SOA queries and NOTIFY responses to the Hidden 1237 Primary. Most likely, when the secondary is flooded with valid and 1238 signed NOTIFY queries, it is under a replay attack which is discussed 1239 in Section 14.9. The key thing here is that the secondary is likely 1240 to be designed to be able to process much more traffic than the 1241 Hidden Primary hosted on a HNA. 1243 This paragraph details how the secondary may limit the NOTIFY 1244 queries. Because the Hidden Primary may be renumbered, the secondary 1245 SHOULD NOT perform permanent IP filtering based on IP addresses. In 1246 addition, a given secondary may be shared among multiple Hidden 1247 Primaries which make filtering rules based on IP harder to set. The 1248 time at which a NOTIFY is sent by the Hidden Primary is not 1249 predictable. However, a flood of NOTIFY messages may be easily 1250 detected, as a NOTIFY originated from a given Homenet Zone is 1251 expected to have a very limited number of unique source IP addresses, 1252 even when renumbering is occurring. As a result, the secondary, MAY 1253 rate limit incoming NOTIFY queries. 1255 On the Hidden Primary side, it is recommended that the Hidden Primary 1256 sends a NOTIFY as long as the zone has not been updated by the 1257 secondary. Multiple SOA queries may indicate the secondary is under 1258 attack. 1260 14.7. Reflection Attacks involving the Public Authoritative Servers 1262 Reflection attacks involving the Public Authoritative Server(s) are 1263 similar to attacks on any Outsourcing Infrastructure. This is not 1264 specific to the architecture described in this document, and thus are 1265 considered as out of scope. 1267 In fact, one motivation of the architecture described in this 1268 document is to expose the Public Authoritative Server(s) to attacks 1269 instead of the HNA, as it is believed that the Public Authoritative 1270 Server(s) will be better able to defend itself. 1272 14.8. Flooding Attack 1274 The purpose of flooding attacks is mostly resource exhaustion, where 1275 the resource can be bandwidth, memory, or CPU for example. 1277 One goal of the architecture described in this document is to limit 1278 the surface of attack on the HNA. This is done by outsourcing the 1279 DNS service to the Public Authoritative Server(s). By doing so, the 1280 HNA limits its DNS interactions between the Hidden Primary and the 1281 DM. This limits the number of entities the HNA interacts with as 1282 well as the scope of DNS exchanges - NOTIFY, SOA, AXFR, IXFR. 1284 The use of an authenticated channel with SIG(0) or TSIG between the 1285 HNA and the DM, enables detection of illegitimate DNS queries, so 1286 appropriate action may be taken - like dropping the queries. If 1287 signatures are validated, then most likely, the HNA is under a replay 1288 attack, as detailed in Section 14.9 1290 In order to limit the resource required for authentication, it is 1291 recommended to use TSIG that uses symmetric cryptography over SIG(0) 1292 that uses asymmetric cryptography. 1294 14.9. Replay Attack 1296 Replay attacks consist of an attacker either resending or delaying a 1297 legitimate message that has been sent by an authorized user or 1298 process. As the Hidden Primary and the DM use an authenticated 1299 channel, replay attacks are mostly expected to use forged DNS queries 1300 in order to provide valid traffic. 1302 From the perspective of an attacker, using a correctly authenticated 1303 DNS query may not be detected as an attack and thus may generate a 1304 response. Generating and sending a response consumes more resources 1305 than either dropping the query by the defender, or generating the 1306 query by the attacker, and thus could be used for resource exhaustion 1307 attacks. In addition, as the authentication is performed at the DNS 1308 layer, the source IP address could be impersonated in order to 1309 perform a reflection attack. 1311 Section 14.4 details how to mitigate reflection attacks and 1312 Section 14.8 details how to mitigate resource exhaustion. Both 1313 sections assume a context of DoS with a flood of DNS queries. This 1314 section suggests a way to limit the attack surface of replay attacks. 1316 As SIG(0) and TSIG use inception and expiration time, the time frame 1317 for replay attack is limited. SIG(0) and TSIG recommends a fudge 1318 value of 5 minutes. This value has been set as a compromise between 1319 possibly loose time synchronization between devices and the valid 1320 lifetime of the message. As a result, better time synchronization 1321 policies could reduce the time window of the attack. 1323 []() 1334 15. IANA Considerations 1336 This document has no actions for IANA. 1338 16. Acknowledgment 1340 The authors wish to thank Philippe Lemordant for its contributions on 1341 the early versions of the draft; Ole Troan for pointing out issues 1342 with the IPv6 routed home concept and placing the scope of this 1343 document in a wider picture; Mark Townsley for encouragement and 1344 injecting a healthy debate on the merits of the idea; Ulrik de Bie 1345 for providing alternative solutions; Paul Mockapetris, Christian 1346 Jacquenet, Francis Dupont and Ludovic Eschard for their remarks on 1347 HNA and low power devices; Olafur Gudmundsson for clarifying DNSSEC 1348 capabilities of small devices; Simon Kelley for its feedback as 1349 dnsmasq implementer; Andrew Sullivan, Mark Andrew, Ted Lemon, Mikael 1350 Abrahamson, Michael Richardson and Ray Bellis for their feedback on 1351 handling different views as well as clarifying the impact of 1352 outsourcing the zone signing operation outside the HNA; Mark Andrew 1353 and Peter Koch for clarifying the renumbering. 1355 17. References 1357 17.1. Normative References 1359 [RFC1033] Lottor, M., "Domain Administrators Operations Guide", 1360 RFC 1033, DOI 10.17487/RFC1033, November 1987, 1361 . 1363 [RFC1034] Mockapetris, P., "Domain names - concepts and facilities", 1364 STD 13, RFC 1034, DOI 10.17487/RFC1034, November 1987, 1365 . 1367 [RFC1035] Mockapetris, P., "Domain names - implementation and 1368 specification", STD 13, RFC 1035, DOI 10.17487/RFC1035, 1369 November 1987, . 1371 [RFC1995] Ohta, M., "Incremental Zone Transfer in DNS", RFC 1995, 1372 DOI 10.17487/RFC1995, August 1996, 1373 . 1375 [RFC1996] Vixie, P., "A Mechanism for Prompt Notification of Zone 1376 Changes (DNS NOTIFY)", RFC 1996, DOI 10.17487/RFC1996, 1377 August 1996, . 1379 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1380 Requirement Levels", BCP 14, RFC 2119, 1381 DOI 10.17487/RFC2119, March 1997, 1382 . 1384 [RFC2136] Vixie, P., Ed., Thomson, S., Rekhter, Y., and J. Bound, 1385 "Dynamic Updates in the Domain Name System (DNS UPDATE)", 1386 RFC 2136, DOI 10.17487/RFC2136, April 1997, 1387 . 1389 [RFC2142] Crocker, D., "Mailbox Names for Common Services, Roles and 1390 Functions", RFC 2142, DOI 10.17487/RFC2142, May 1997, 1391 . 1393 [RFC2181] Elz, R. and R. Bush, "Clarifications to the DNS 1394 Specification", RFC 2181, DOI 10.17487/RFC2181, July 1997, 1395 . 1397 [RFC2308] Andrews, M., "Negative Caching of DNS Queries (DNS 1398 NCACHE)", RFC 2308, DOI 10.17487/RFC2308, March 1998, 1399 . 1401 [RFC2845] Vixie, P., Gudmundsson, O., Eastlake 3rd, D., and B. 1402 Wellington, "Secret Key Transaction Authentication for DNS 1403 (TSIG)", RFC 2845, DOI 10.17487/RFC2845, May 2000, 1404 . 1406 [RFC2931] Eastlake 3rd, D., "DNS Request and Transaction Signatures 1407 ( SIG(0)s )", RFC 2931, DOI 10.17487/RFC2931, September 1408 2000, . 1410 [RFC4034] Arends, R., Austein, R., Larson, M., Massey, D., and S. 1411 Rose, "Resource Records for the DNS Security Extensions", 1412 RFC 4034, DOI 10.17487/RFC4034, March 2005, 1413 . 1415 [RFC4192] Baker, F., Lear, E., and R. Droms, "Procedures for 1416 Renumbering an IPv6 Network without a Flag Day", RFC 4192, 1417 DOI 10.17487/RFC4192, September 2005, 1418 . 1420 [RFC4301] Kent, S. and K. Seo, "Security Architecture for the 1421 Internet Protocol", RFC 4301, DOI 10.17487/RFC4301, 1422 December 2005, . 1424 [RFC4555] Eronen, P., "IKEv2 Mobility and Multihoming Protocol 1425 (MOBIKE)", RFC 4555, DOI 10.17487/RFC4555, June 2006, 1426 . 1428 [RFC4960] Stewart, R., Ed., "Stream Control Transmission Protocol", 1429 RFC 4960, DOI 10.17487/RFC4960, September 2007, 1430 . 1432 [RFC5155] Laurie, B., Sisson, G., Arends, R., and D. Blacka, "DNS 1433 Security (DNSSEC) Hashed Authenticated Denial of 1434 Existence", RFC 5155, DOI 10.17487/RFC5155, March 2008, 1435 . 1437 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 1438 (TLS) Protocol Version 1.2", RFC 5246, 1439 DOI 10.17487/RFC5246, August 2008, 1440 . 1442 [RFC5936] Lewis, E. and A. Hoenes, Ed., "DNS Zone Transfer Protocol 1443 (AXFR)", RFC 5936, DOI 10.17487/RFC5936, June 2010, 1444 . 1446 [RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer 1447 Security Version 1.2", RFC 6347, DOI 10.17487/RFC6347, 1448 January 2012, . 1450 [RFC6644] Evans, D., Droms, R., and S. Jiang, "Rebind Capability in 1451 DHCPv6 Reconfigure Messages", RFC 6644, 1452 DOI 10.17487/RFC6644, July 2012, 1453 . 1455 [RFC6672] Rose, S. and W. Wijngaards, "DNAME Redirection in the 1456 DNS", RFC 6672, DOI 10.17487/RFC6672, June 2012, 1457 . 1459 [RFC6762] Cheshire, S. and M. Krochmal, "Multicast DNS", RFC 6762, 1460 DOI 10.17487/RFC6762, February 2013, 1461 . 1463 [RFC6763] Cheshire, S. and M. Krochmal, "DNS-Based Service 1464 Discovery", RFC 6763, DOI 10.17487/RFC6763, February 2013, 1465 . 1467 [RFC7010] Liu, B., Jiang, S., Carpenter, B., Venaas, S., and W. 1468 George, "IPv6 Site Renumbering Gap Analysis", RFC 7010, 1469 DOI 10.17487/RFC7010, September 2013, 1470 . 1472 [RFC7296] Kaufman, C., Hoffman, P., Nir, Y., Eronen, P., and T. 1473 Kivinen, "Internet Key Exchange Protocol Version 2 1474 (IKEv2)", STD 79, RFC 7296, DOI 10.17487/RFC7296, October 1475 2014, . 1477 [RFC7344] Kumari, W., Gudmundsson, O., and G. Barwood, "Automating 1478 DNSSEC Delegation Trust Maintenance", RFC 7344, 1479 DOI 10.17487/RFC7344, September 2014, 1480 . 1482 [RFC7368] Chown, T., Ed., Arkko, J., Brandt, A., Troan, O., and J. 1483 Weil, "IPv6 Home Networking Architecture Principles", 1484 RFC 7368, DOI 10.17487/RFC7368, October 2014, 1485 . 1487 [RFC7558] Lynn, K., Cheshire, S., Blanchet, M., and D. Migault, 1488 "Requirements for Scalable DNS-Based Service Discovery 1489 (DNS-SD) / Multicast DNS (mDNS) Extensions", RFC 7558, 1490 DOI 10.17487/RFC7558, July 2015, 1491 . 1493 [RFC7707] Gont, F. and T. Chown, "Network Reconnaissance in IPv6 1494 Networks", RFC 7707, DOI 10.17487/RFC7707, March 2016, 1495 . 1497 [RFC7788] Stenberg, M., Barth, S., and P. Pfister, "Home Networking 1498 Control Protocol", RFC 7788, DOI 10.17487/RFC7788, April 1499 2016, . 1501 [RFC7858] Hu, Z., Zhu, L., Heidemann, J., Mankin, A., Wessels, D., 1502 and P. Hoffman, "Specification for DNS over Transport 1503 Layer Security (TLS)", RFC 7858, DOI 10.17487/RFC7858, May 1504 2016, . 1506 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 1507 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 1508 May 2017, . 1510 [RFC8375] Pfister, P. and T. Lemon, "Special-Use Domain 1511 'home.arpa.'", RFC 8375, DOI 10.17487/RFC8375, May 2018, 1512 . 1514 [RFC8415] Mrugalski, T., Siodelski, M., Volz, B., Yourtchenko, A., 1515 Richardson, M., Jiang, S., Lemon, T., and T. Winters, 1516 "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)", 1517 RFC 8415, DOI 10.17487/RFC8415, November 2018, 1518 . 1520 17.2. Informative References 1522 [I-D.howard-dnsop-ip6rdns] 1523 Howard, L., "Reverse DNS in IPv6 for Internet Service 1524 Providers", draft-howard-dnsop-ip6rdns-00 (work in 1525 progress), June 2014. 1527 [I-D.ietf-homenet-naming-architecture-dhc-options] 1528 Migault, D., Mrugalski, T., Griffiths, C., Weber, R., and 1529 W. Cloetens, "DHCPv6 Options for Homenet Naming 1530 Architecture", draft-ietf-homenet-naming-architecture-dhc- 1531 options-06 (work in progress), June 2018. 1533 [I-D.ietf-homenet-simple-naming] 1534 Lemon, T., Migault, D., and S. Cheshire, "Homenet Naming 1535 and Service Discovery Architecture", draft-ietf-homenet- 1536 simple-naming-03 (work in progress), October 2018. 1538 [I-D.sury-dnsext-cname-dname] 1539 Sury, O., "CNAME+DNAME Name Redirection", draft-sury- 1540 dnsext-cname-dname-00 (work in progress), April 2010. 1542 Appendix A. Envisioned deployment scenarios 1544 A number of deployment have been envisionned, this section aims at 1545 providing a brief description. The use cases are not limitatives and 1546 this section is not normative. 1548 A.1. CPE Vendor 1550 A specific vendor with specific relations with a registrar or a 1551 registry may sell a CPE that is provisioned with provisioned domain 1552 name. Such domain name does not need to be necessary human readable. 1554 One possible way is that the vendor also provisions the HNA with a 1555 private and public keys as well as a certificate. Note that these 1556 keys are not expected to be used for DNSSEC signing. Instead these 1557 keys are solely used by the HNA to proceed to the authentication. 1558 Normally the keys should be necessary and sufficient to proceed to 1559 the authentication. The reason to combine the domain name and the 1560 key is that outsourcing infrastructure are likely handle names better 1561 than keys and that domain names might be used as a login which 1562 enables the key to be regenerated. 1564 When the home network owner plugs the CPE at home, the relation 1565 between HNA and DM is expected to work out-of-the-box. 1567 A.2. Agnostic CPE 1569 An CPE that is not preconfigured may also take advanatge to the 1570 protocol defined in this document but some configuration steps will 1571 be needed. 1573 1. The owner of the home network buys a domain name to a registrar, 1574 and as such creates an account on that registrar 1576 2. Either the registrar is also providing the outsourcing 1577 infrastructure or the home network needs to create a specific 1578 account on the outsourcing infrastructure. * If the outsourcing 1579 provider is the registrar, the outsourcing has by design a proof 1580 of ownership of the domain name by the homenet owner. In this 1581 case, it is expected the infrastructure provides the necessary 1582 parameters to the home network owner to configure the HNA. A 1583 good way to provide the parameters would be the home network be 1584 able to copy/paste a JSON object. What matters at that point is 1585 the outsourcing infrastructure being able to generate 1586 authentication credentials for the HNA to authenticate itself to 1587 the outsourcing infrastructure. This obviously requires the home 1588 network to provide the public key gnerated by the HNA in a CSR. 1590 o If the outsourcing infrastructure is not the registrar, then the 1591 proof of ownership needs to be established using protocols like 1592 ACME for example that will end in the generation of a certificate. 1593 ACME is used here to the purpose of automating the generation of 1594 the certificate, the CA may be a specific CA or the outsourcing 1595 infrastructure. With that being done, the outsourcing 1596 infrastructure has a roof of ownership and can proceed as above. 1598 Appendix B. Example: Homenet Zone 1600 This section is not normative and intends to illustrate how the HNA 1601 builds the Homenet Zone. 1603 As depicted in Figure 1, the Public Homenet Zone is hosted on the 1604 Public Authoritative Server(s), whereas the Homenet Zone is hosted on 1605 the HNA. This section considers that the HNA builds the zone that 1606 will be effectively published on the Public Authoritative Server(s). 1607 In other words "Homenet to Public Zone transformation" is the 1608 identity also commonly designated as "no operation" (NOP). 1610 In that case, the Homenet Zone should configure its Name Server RRset 1611 (NS) and Start of Authority (SOA) with the values associated with the 1612 Public Authoritative Server(s). This is illustrated in Figure 2. 1613 public.primary.example.net is the FQDN of the Public Authoritative 1614 Server(s), and IP1, IP2, IP3, IP4 are the associated IP addresses. 1615 Then the HNA should add the additional new nodes that enter the home 1616 network, remove those that should be removed, and sign the Homenet 1617 Zone. 1619 $ORIGIN example.com 1620 $TTL 1h 1622 @ IN SOA public.primary.example.net 1623 hostmaster.example.com. ( 1624 2013120710 ; serial number of this zone file 1625 1d ; secondary refresh 1626 2h ; secondary retry time in case of a problem 1627 4w ; secondary expiration time 1628 1h ; maximum caching time in case of failed 1629 ; lookups 1630 ) 1632 @ NS public.authoritative.servers.example.net 1634 public.primary.example.net A @IP1 1635 public.primary.example.net A @IP2 1636 public.primary.example.net AAAA @IP3 1637 public.primary.example.net AAAA @IP4 1639 Figure 2: Homenet Zone 1641 The SOA RRset is defined in [RFC1033], [RFC1035] and [RFC2308]. This 1642 SOA is specific, as it is used for the synchronization between the 1643 Hidden Primary and the DM and published on the DNS Public 1644 Authoritative Server(s).. 1646 o MNAME: indicates the primary. In our case the zone is published 1647 on the Public Authoritative Server(s), and its name MUST be 1648 included. If multiple Public Authoritative Server(s) are 1649 involved, one of them MUST be chosen. More specifically, the HNA 1650 MUST NOT include the name of the Hidden Primary. 1652 o RNAME: indicates the email address to reach the administrator. 1653 [RFC2142] recommends using hostmaster@domain and replacing the '@' 1654 sign by '.'. 1656 o REFRESH and RETRY: indicate respectively in seconds how often 1657 secondaries need to check the primary, and the time between two 1658 refresh when a refresh has failed. Default values indicated by 1659 [RFC1033] are 3600 (1 hour) for refresh and 600 (10 minutes) for 1660 retry. This value might be too long for highly dynamic content. 1661 However, the Public Authoritative Server(s) and the HNA are 1662 expected to implement NOTIFY [RFC1996]. So whilst shorter refresh 1663 timers might increase the bandwidth usage for secondaries hosting 1664 large number of zones, it will have little practical impact on the 1665 elapsed time required to achieve synchronization between the 1666 Outsourcing Infrastructure and the Hidden Master. As a result, 1667 the default values are acceptable. 1669 o EXPIRE: is the upper limit data SHOULD be kept in absence of 1670 refresh. The default value indicated by [RFC1033] is 3600000 1671 (approx. 42 days). In home network architectures, the HNA 1672 provides both the DNS synchronization and the access to the home 1673 network. This device may be plugged and unplugged by the end user 1674 without notification, thus we recommend a long expiry timer. 1676 o MINIMUM: indicates the minimum TTL. The default value indicated 1677 by [RFC1033] is 86400 (1 day). For home network, this value MAY 1678 be reduced, and 3600 (1 hour) seems more appropriate. 1680 <> 1696 Appendix C. Example: HNA necessary parameters for outsourcing 1698 This section specifies the various parameters required by the HNA to 1699 configure the naming architecture of this document. This section is 1700 informational, and is intended to clarify the information handled by 1701 the HNA and the various settings to be done. 1703 DM may be configured with the following parameters. These parameters 1704 are necessary to establish a secure channel between the HNA and the 1705 DM as well as to specify the DNS zone that is in the scope of the 1706 communication: 1708 o DM: The associated FQDNs or IP addresses of the DM. IP addresses 1709 are optional and the FQDN is sufficient. To secure the binding 1710 name and IP addresses, a DNSSEC exchange is required. Otherwise, 1711 the IP addresses should be entered manually. 1713 o Authentication Method: How the HNA authenticates itself to the DM. 1715 o Authentication data: Associated Data. PSK only requires a single 1716 argument. If other authentication mechanisms based on 1717 certificates are used, then HNA private keys, certificates and 1718 certification authority should be specified. 1720 o Public Authoritative Server(s): The FQDN or IP addresses of the 1721 Public Authoritative Server(s). It MAY correspond to the data 1722 that will be set in the NS RRsets and SOA of the Homenet Zone. IP 1723 addresses are optional and the FQDN is sufficient. To secure the 1724 binding between name and IP addresses, a DNSSEC exchange is 1725 required. Otherwise, the IP addresses should be entered manually. 1727 o Registered Homenet Domain: The domain name used to establish the 1728 secure channel. This name is used by the DM and the HNA for the 1729 primary / secondary configuration as well as to index the NOTIFY 1730 queries of the HNA when the HNA has been renumbered. 1732 Setting the Homenet Zone requires the following information. 1734 o Registered Homenet Domain: The Domain Name of the zone. Multiple 1735 Registered Homenet Domains may be provided. This will generate 1736 the creation of multiple Public Homenet Zones. 1738 o Public Authoritative Server(s): The Public Authoritative Server(s) 1739 associated with the Registered Homenet Domain. Multiple Public 1740 Authoritative Server(s) may be provided. 1742 Two possible methods of providing the required information would be: 1744 JSON for forward zones should be standardized in a similar way to 1745 zone file layout in RFC1035 1747 DHCP for reverse zones needs a separate draft 1749 Authors' Addresses 1751 Daniel Migault 1752 Ericsson 1753 8275 Trans Canada Route 1754 Saint Laurent, QC 4S 0B6 1755 Canada 1757 EMail: daniel.migault@ericsson.com 1758 Ralf Weber 1759 Nominum 1760 2000 Seaport Blvd 1761 Redwood City 94063 1762 US 1764 EMail: ralf.weber@nominum.com 1766 Michael Richardson 1767 Sandelman Software Works 1768 470 Dawson Avenue 1769 Ottawa, ON K1Z 5V7 1770 Canada 1772 EMail: mcr+ietf@sandelman.ca 1774 Ray Hunter 1775 Globis Consulting BV 1776 Weegschaalstraat 3 1777 Eindhoven 5632CW 1778 NL 1780 EMail: v6ops@globis.net 1782 Chris Griffiths 1784 EMail: cgriffiths@gmail.com 1786 Wouter Cloetens 1787 SoftAtHome 1788 vaartdijk 3 701 1789 Wijgmaal 3018 1790 BE 1792 EMail: wouter.cloetens@softathome.com