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