idnits 2.17.1 draft-ietf-homenet-naming-architecture-dhc-options-05.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 (October 27, 2017) is 2374 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) ** Obsolete normative reference: RFC 2845 (Obsoleted by RFC 8945) ** Obsolete normative reference: RFC 3315 (Obsoleted by RFC 8415) ** Obsolete normative reference: RFC 5246 (Obsoleted by RFC 8446) ** Obsolete normative reference: RFC 6347 (Obsoleted by RFC 9147) == Outdated reference: A later version (-27) exists of draft-ietf-homenet-front-end-naming-delegation-05 Summary: 4 errors (**), 0 flaws (~~), 2 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 HOMENET D. Migault (Ed) 3 Internet-Draft Ericsson 4 Intended status: Standards Track T. Mrugalski 5 Expires: April 30, 2018 ISC 6 C. Griffiths 8 R. Weber 9 Nominum 10 W. Cloetens 11 SoftAtHome 12 October 27, 2017 14 DHCPv6 Options for Homenet Naming Architecture 15 draft-ietf-homenet-naming-architecture-dhc-options-05 17 Abstract 19 The Homenet Naming Authority (HNA) is the designated device in charge 20 of outsourcing the service to a third party, which requires setting 21 up an architecture. 23 Such settings may be inappropriate for most end users. This document 24 defines DHCPv6 options so any agnostic HNA can automatically proceed 25 to the appropriate configuration and outsource the authoritative 26 naming service for the home network. In most cases, the outsourcing 27 mechanism is transparent for the end user. 29 Status of This Memo 31 This Internet-Draft is submitted in full conformance with the 32 provisions of BCP 78 and BCP 79. 34 Internet-Drafts are working documents of the Internet Engineering 35 Task Force (IETF). Note that other groups may also distribute 36 working documents as Internet-Drafts. The list of current Internet- 37 Drafts is at https://datatracker.ietf.org/drafts/current/. 39 Internet-Drafts are draft documents valid for a maximum of six months 40 and may be updated, replaced, or obsoleted by other documents at any 41 time. It is inappropriate to use Internet-Drafts as reference 42 material or to cite them other than as "work in progress." 44 This Internet-Draft will expire on April 30, 2018. 46 Internet-DrafDHCPv6 Options for Homenet Naming Architecture October 2017 48 Copyright Notice 50 Copyright (c) 2017 IETF Trust and the persons identified as the 51 document authors. All rights reserved. 53 This document is subject to BCP 78 and the IETF Trust's Legal 54 Provisions Relating to IETF Documents 55 (https://trustee.ietf.org/license-info) in effect on the date of 56 publication of this document. Please review these documents 57 carefully, as they describe your rights and restrictions with respect 58 to this document. Code Components extracted from this document must 59 include Simplified BSD License text as described in Section 4.e of 60 the Trust Legal Provisions and are provided without warranty as 61 described in the Simplified BSD License. 63 Table of Contents 65 1. Requirements notation . . . . . . . . . . . . . . . . . . . . 3 66 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 67 3. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 68 4. Protocol Overview . . . . . . . . . . . . . . . . . . . . . . 6 69 4.1. Architecture and DHCPv6 Options Overview . . . . . . . . 6 70 4.2. Mechanisms Securing DNS Transactions . . . . . . . . . . 9 71 4.3. Primary / Secondary Synchronization versus DNS Update . . 10 72 5. HNA Configuration . . . . . . . . . . . . . . . . . . . . . . 11 73 5.1. HNA Primary / Secondary Synchronization Configurations . 11 74 5.1.1. HNA / Synchronization Server . . . . . . . . . . . . 11 75 5.1.2. HNA / Reverse Synchronization Server . . . . . . . . 11 76 5.2. HNA DNS Data Handling and Update Policies . . . . . . . . 12 77 5.2.1. Homenet Zone Template . . . . . . . . . . . . . . . . 12 78 5.2.2. DNS (Reverse) Homenet Zone . . . . . . . . . . . . . 12 79 6. Payload Description . . . . . . . . . . . . . . . . . . . . . 13 80 6.1. Supported Authentication Methods Field . . . . . . . . . 13 81 6.2. Update Field . . . . . . . . . . . . . . . . . . . . . . 14 82 6.3. Client Public Key Option . . . . . . . . . . . . . . . . 14 83 6.4. Zone Template Option . . . . . . . . . . . . . . . . . . 14 84 6.5. Synchronization Server Option . . . . . . . . . . . . . . 15 85 6.6. Reverse Synchronization Server Option . . . . . . . . . . 16 86 7. DHCP Behavior . . . . . . . . . . . . . . . . . . . . . . . . 17 87 7.1. DHCPv6 Server Behavior . . . . . . . . . . . . . . . . . 17 88 7.2. DHCPv6 Client Behavior . . . . . . . . . . . . . . . . . 18 89 7.3. DHCPv6 Relay Agent Behavior . . . . . . . . . . . . . . . 18 90 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18 91 9. Security Considerations . . . . . . . . . . . . . . . . . . . 19 92 9.1. DNSSEC is recommended to authenticate DNS hosted data . . 19 93 9.2. Channel between the HNA and ISP DHCP Server MUST be 94 secured . . . . . . . . . . . . . . . . . . . . . . . . . 19 95 9.3. HNAs are sensitive to DoS . . . . . . . . . . . . . . . . 19 97 Internet-DrafDHCPv6 Options for Homenet Naming Architecture October 2017 99 10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 19 100 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 19 101 11.1. Normative References . . . . . . . . . . . . . . . . . . 20 102 11.2. Informational References . . . . . . . . . . . . . . . . 21 103 Appendix A. Scenarios and impact on the End User . . . . . . . . 22 104 A.1. Base Scenario . . . . . . . . . . . . . . . . . . . . . . 22 105 A.2. Third Party Registered Homenet Domain . . . . . . . . . . 23 106 A.3. Third Party DNS Infrastructure . . . . . . . . . . . . . 23 107 A.4. Multiple ISPs . . . . . . . . . . . . . . . . . . . . . . 25 108 Appendix B. Document Change Log . . . . . . . . . . . . . . . . 26 109 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 27 111 1. Requirements notation 113 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 114 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 115 document are to be interpreted as described in [RFC2119]. 117 2. Terminology 119 The reader is expected to be familiar with 120 [I-D.ietf-homenet-front-end-naming-delegation] and its terminology 121 section. This section defines terms that have not been defined in 122 [I-D.ietf-homenet-front-end-naming-delegation]: 124 - Client Public Key: designates a public key generated by the HNA. 125 This key is used as an authentication credential for the HNA. 127 - Homenet Zone Template: The template used as a basis to generate 128 the Homenet Zone. 130 - DNS Template Server: The DNS server that hosts the Homenet Zone 131 Template. 133 - Homenet Reverse Zone: The reverse zone file associated to the 134 Homenet Zone. 136 3. Introduction 138 HNAs are usually constrained devices with reduced network and CPU 139 capacities. As such, a HNA hosting on the Internet the authoritative 140 naming service for its home network may become vulnerable to resource 141 exhaustion attacks. Outsourcing the authoritative service to a third 142 party avoids exposing the HNA to such attacks. This third party can 143 be the ISP or any other independent third party. 145 Outsourcing the authoritative naming service to a third party 146 requires setting up an architecture designated in this document as 148 Internet-DrafDHCPv6 Options for Homenet Naming Architecture October 2017 150 the Outsourcing Infrastructure. These settings may be inappropriate 151 for most end users that do not have the sufficient knowledge. To 152 address this issue, this document proposes DHCPv6 options so any 153 agnostic HNA can automatically set the Outsourcing Infrastructure. 154 In most cases, these DHCPv6 options are sufficient and do not require 155 any additional interaction from the end user, thus achieving a zero- 156 config settings. In some other cases, the end user is expected to 157 perform some limited manual configuration. 159 When the HNA is plugged, the DHCPv6 options described in the document 160 enable: 162 - 1. To build the Homenet Zone: Building the Homenet Zone requires 163 filling the zone with appropriated bindings such as bindings 164 between the names and the IP addresses of the different devices 165 of the home networks. How the HNA is aware of these binding is 166 out of scope of the document. They may be provided, for 167 example, by the DHCPv6 server hosted on the HNA. On the other 168 hand, building the Homenet Zone also requires configuration 169 parameters like the name of the Registered Domain Name 170 associated to the home network or the Public Authoritative 171 Server(s) the Homenet Zone is outsourced to. These 172 configuration parameters are stored in the Homenet Zone 173 Template. This document describes the Zone Template Option 174 which carries the FQDN associated to the Homenet Zone Template. 175 In order to retrieve the Homenet Zone Template, the HNA sends a 176 query of type AXFR [RFC1034], [RFC5936]. 178 - 2. To upload the Homenet Zone to the Synchronization Server, in 179 charge of publishing the Homenet Zone on the Public 180 Authoritative Server(s). This document describes the 181 Synchronization Server Option that provides the FQDN of the 182 appropriated server. Note that, the document does not consider 183 whether the Homenet Zone is signed or not, and if signed, which 184 entity is responsible to sign it. Such questions are out of 185 the scope of the current document. 187 - 3. To upload the Homenet Reverse Zone to the Reverse 188 Synchronization Server in charge of publishing the Homenet 189 Reverse Zone on the Reverse Public Authoritative Server(s). 190 This document describes the Reverse Synchronization Server 191 Option that provides the FQDN of the appropriated server. 192 Similarly to item 2., we do not consider in this document if 193 the Homenet Reverse Zone is signed or not, and if signed who 194 signs it. 196 - 4. To provide authentication credential (a public key) to the DHCP 197 Server: Information stored in the Homenet Zone Template, the 199 Internet-DrafDHCPv6 Options for Homenet Naming Architecture October 2017 201 Homenet Zone and Homenet Reverse Zone belongs to the HNA, and 202 only the HNA should be able to update or upload these zones. 203 To authenticate the HNA, this document defines the Client 204 Public Key Option. This option is sent by the HNA to the 205 DHCPv6 server and provides the Client Public Key the HNA uses 206 to authenticate itself. This document does not describe 207 mechanisms used to transmit the Client Public Key from the 208 DHCPv6 server to the appropriate entities. If the DHCPv6 209 server is not able to provide the Client Public Key to the 210 appropriated entities, then the end user is likely to provide 211 manually the Client Public Key to these entities. This 212 document illustrates two scenarios: one where the DHCPv6 server 213 is responsible for distributing the Client Public Key to the 214 Synchronization Servers and Reverse Synchronization Server. In 215 the other scenarios, the Client Public Key is distributed out 216 of band. 218 The DHCPv6 options described in this document make possible to 219 configure an Outsourcing Infrastructure with no or little 220 configurations from the end user. A zero-config setting is achieved 221 if the the link between the HNA and the DHCPv6 server and the link 222 between the DHCPv6 server and the various DNS servers (Homenet Zone 223 Server, the Reverse Synchronization Server, Synchronization Server) 224 are trusted. For example, one way to provide a thrustworhy 225 connection between the HNA and the DHCPv6 server is defined in 226 [I-D.ietf-dhc-sedhcpv6]. When both links are trusted, the HNA is 227 able to provide its authentication credentials (a Client Public Key) 228 to the DHCPv6 server, that in turn forwards it to the various DNS 229 servers. With the authentication credentials on the DNS servers, the 230 HNA is able to securely update. 232 If the DHCPv6 server cannot provide the Client Public Key to one of 233 these servers (most likely the Synchronization Server) and the HNA 234 needs to interact with the server, then, the end user is expected to 235 provide the HNA's Client Public Key to these servers (the Reverse 236 Synchronization Server or the Synchronization Server) either manually 237 or using other mechanisms. Such mechanisms are outside the scope of 238 this document. In that case, the authentication credentials need to 239 be provided every time the key is modified. Appendix A provides more 240 details on how different scenarios impact the end users. 242 The remaining of this document is structured as follows. Section 4 243 provides an overview of the DHCPv6 options as well as the expected 244 interactions between the HNA and the various involved entities. This 245 section also provides an overview of available mechanisms to secure 246 DNS transactions and update DNS data. Section 5 describes how the 247 HNA may securely synchronize and update DNS data. Section 6 248 describes the payload of the DHCPv6 options and Section 7 details how 250 Internet-DrafDHCPv6 Options for Homenet Naming Architecture October 2017 252 DHCPv6 client, server and relay agent behave. Section 8 lists the 253 new parameters to be registered at the IANA, Section 9 provides 254 security considerations. Finally, Appendix A describes how the HNA 255 may behave and be configured regarding various scenarios. 257 4. Protocol Overview 259 This section provides an overview of the HNA's interactions with the 260 Outsourcing Infrastructure in Section 4.1, and so the necessary for 261 its setting. In this document, the configuration is provided via 262 DHCPv6 options. Once configured, the HNA is expected to be able to 263 update and publish DNS data on the different components of the 264 Outsourcing Infrastructure. As a result authenticating and updating 265 mechanisms play an important role in the specification. Section 4.2 266 provides an overview of the different authentication methods and 267 Section 4.3 provides an overview of the different update mechanisms 268 considered to update the DNS data. 270 4.1. Architecture and DHCPv6 Options Overview 272 This section illustrates how a HNA receives the necessary information 273 via DHCPv6 options to outsource its authoritative naming service on 274 the Outsourcing Infrastructure. For the sake of simplicity, this 275 section assumes that the DHCPv6 server is able to communicate to the 276 various DNS servers and to provide them the public key associated 277 with the HNA. Once each server got the public key, the HNA can 278 proceed to transactions in an authenticated and secure way. 280 This scenario has been chosen as it is believed to be the most 281 popular scenario. This document does not ignore that scenarios where 282 the DHCP Server does not have privileged relations with the 283 Synchronization Server must be considered. These cases are discussed 284 latter in Appendix A. Such scenario does not necessarily require 285 configuration for the end user and can also be zero-config. 287 The scenario is represented in Figure 1. 289 - 1: The HNA provides its Client Public Key to the DHCP Server using 290 a Client Public Key Option (OPTION_PUBLIC_KEY) and includes the 291 following option codes in its its Option Request Option (ORO): 292 Zone Template Option (OPTION_DNS_ZONE_TEMPLATE), the 293 Synchronization Server Option (OPTION_SYNC_SERVER) and the 294 Reverse Synchronization Server Option 295 (OPTION_REVERSE_SYNC_SERVER). 297 - 2: The DHCP Server makes the Client Public Key available to the 298 DNS servers, so the HNA can secure its DNS transactions. How 299 the Client Public Key is transmitted to the various DNS servers 301 Internet-DrafDHCPv6 Options for Homenet Naming Architecture October 2017 303 is out of scope of this document. Note that the Client Public 304 Key alone is not sufficient to perform the authentication and 305 the key should be, for example, associated with an identifier, 306 or the concerned domain name. How the binding is performed is 307 out of scope of the document. It can be a centralized database 308 or various bindings may be sent to the different servers. 309 Figure 1 represents the specific case where the DHCP Server 310 forwards the set (Client Public Key, Zone Template FQDN) to the 311 DNS Template Server, the set (Client Public Key, IPv6 subnet) 312 to the Reverse Synchronization Server and the set (Client 313 Public Key, Registered Homenet Domain) to the Synchronization 314 Server. 316 - 3: The DHCP Server responds to the HNA with the requested DHCPv6 317 options, i.e. the Client Public Key Option (OPTION_PUBLIC_KEY), 318 Zone Template Option OPTION_DNS_ZONE_TEMPLATE, Synchronization 319 Server Option (OPTION_SYNC_SERVER), Reverse Synchronization 320 Server Option (OPTION_REVERSE_SYNC_SERVER). Note that this 321 step may be performed in parallel to step 2, or even before. 322 In other words, there is no requirements that step 3 is 323 conducted after step 2. 325 - 4: Upon receiving the Zone Template Option 326 (OPTION_DNS_ZONE_TEMPLATE), the HNA performs an AXFR DNS query 327 for the Zone Template FQDN. The exchange is authenticated 328 according to the authentication methods defined in the 329 Supported Authentication Methods field of the DHCP option. 330 Once the HNA has retrieved the DNS Zone Template, the HNA can 331 build the Homenet Zone and the Homenet Reverse Zone. 332 Eventually the HNA signs these zones. 334 - 5: Once the Homenet Reverse Zone has been set, the HNA uploads the 335 zone to the Reverse Synchronization Server. The Reverse 336 Synchronization Server Option (OPTION_REVERSE_SYNC_SERVER) 337 provides the Reverse Synchronization Server FQDN as well as the 338 upload method, and the Supported Authentication Methods 339 protocol to secure the upload. 341 - 6: Once the Homenet Zone has been set, the HNA uploads the zone to 342 the Synchronization Server. The Synchronization Server Option 343 (OPTION_SYNC_SERVER) provides the Synchronization Server FQDN 344 as well as the upload method and the authentication method to 345 secure the upload. 347 Internet-DrafDHCPv6 Options for Homenet Naming Architecture October 2017 349 +---------------------+ 350 | DHCPv6 Server | 351 +---------------------+ 352 ^ ^ ^ 353 | | | 354 1.| |3. |2. 355 | | | 356 v v | 357 +------+ | +--------------------------------+ 358 | | 4. +--->| DNS Template Server | 359 | |<---------->| | 360 | | | +--------------------------------+ 361 | HNA | | 362 | | | +--------------------------------+ 363 | | 5./6. +--->| Reverse Synchronization | 364 | |<---------->| Server | 365 | | | +--------------------------------+ 366 | | | 367 | | | +--------------------------------+ 368 +------+ +--->| Synchronization Server | 369 | | 370 +--------------------------------+ 372 Figure 1: Protocol Overview 374 As described above, the HNA is likely to interact with various DNS 375 content. More specifically, the HNA is likely to update the: 377 - Homenet Zone Template: if the configuration of the zone may be 378 changed. This may include additional Public Authoritative 379 Server(s), a different Registered Homenet Domain as the one 380 initially proposed, or a redirection to another domain. 382 - Homenet Reverse Zone: every time a new device is connected or 383 dis-connected. 385 - Homenet Zone: every time a new device is connected, dis- 386 connected. 388 Step 2 and step 3 should be considered as independent steps and could 389 be re-ordered. In fact, the DHCPv6 server does not have to wait for 390 a confirmation from the DNS servers the Client Public Key has been 391 properly received, and is operational by the DNS servers. The DHCP 392 Server is expected to reply upon receiving the Client Public Key 393 Option. The reply to the message with a Client Public Key Option 394 from the DHCP Server is interpreted by the DHCPv6 client as a 395 confirmation of the reception of the option by the DHCP Server only. 396 It does not indicate whether the server had processed the option or 398 Internet-DrafDHCPv6 Options for Homenet Naming Architecture October 2017 400 not. Debugging configurations errors or transmission error with one 401 of the DNS servers is let to the HNA and thus is outside of the scope 402 of the DHCPv6. First, it is unlikely a DNS server can validate that 403 the Client Public Key will be operational for the HNA, as multiple 404 causes of errors could occur. For example, the Client Public Key may 405 have been changed during the transmission or by the DHCP Server, or 406 the DNS server may be misconfigured. Second, the number of error 407 codes would be too complex. In addition to multiple causes of 408 errors, multiple architectures and multiple DNS servers may be 409 involved. Third, this may cause significant DHCP Server performance 410 degradation. 412 In fact, the HNA performs these updates in a secure manner. There 413 are multiple ways to secure a DNS transaction and this document 414 considers two mechanisms: nsupdate and primary/secondary 415 synchronization. Section 4.2 describes the authentication method 416 that may be use to secure the DNS transactions of the HNA. The 417 appropriate authentication methods may, for example, be chosen 418 according to the level of confidentiality or the level of 419 authentication requested by the HNA transactions. Section 4.3 420 positions the nsupdate and primary/secondary synchronization 421 mechanisms. The update appropriate update mechanism may depend on 422 the for example on the update frequency or the size of the DNS data 423 to update. 425 4.2. Mechanisms Securing DNS Transactions 427 Multiple protocols like IPsec [RFC4301] or TLS / DTLS [RFC5246] / 428 [RFC6347] may be used to secure DNS transactions between the HNA and 429 the DNS servers. This document limits its scope to authentication 430 method that have been designed specifically for DNS. This includes 431 DNSSEC [RFC4033], [RFC4034], [RFC4035] that authenticates and 432 provides integrity protection of DNS data, TSIG [RFC2845], [RFC2930] 433 that use a shared secret to secure a transaction between two end 434 points and SIG(0) [RFC2931] authenticates the DNS packet exchanged. 436 The key issue with TSIG is that a shared secret must be negotiated 437 between the HNA and the server. On the other hand, TSIG performs 438 symmetric cryptography which is light in comparison with asymmetric 439 cryptography used by SIG(0). As a result, over large zone transfer, 440 TSIG may be preferred to SIG(0). 442 This document does not provide means to distribute shared secret for 443 example using a specific DHCPv6 option. The only assumption made is 444 that the HNA generates or is assigned a public key. 446 As a result, when the document specifies the transaction is secured 447 with TSIG, it means that either the HNA and the DNS server have been 449 Internet-DrafDHCPv6 Options for Homenet Naming Architecture October 2017 451 manually configured with a shared secret, or the shared secret has 452 been negotiated using TKEY [RFC2930], and the TKEY exchanged are 453 secured with SIG(0). 455 Exchanges with the DNS Template Server to retrieve the Homenet Zone 456 Template may be protected by SIG(0), TSIG or DNSSEC. When DNSSEC is 457 used, it means the DNS Template Server only provides integrity 458 protection, and does not necessarily prevent someone else to query 459 the Homenet Zone Template. In addition, DNSSEC is only a way to 460 protect the AXFR queries transaction, in other words, DNSSEC cannot 461 be used to secure updates. If DNSSEC is used to provide integrity 462 protection for the AXFR response, the HNA should proceed to the 463 DNSSEC signature checks. If signature check fails, it MUST reject 464 the response. If the signature check succeeds, the HNA removes all 465 DNSSEC related RRsets (DNSKEY, RRSIG, NSEC* ...) before building the 466 Homenet Zone. In fact, these DNSSEC related fields are associated to 467 the Homenet Zone Template and not the Homenet Zone. 469 Any update exchange should use SIG(0) or TSIG to authenticate the 470 exchange. 472 4.3. Primary / Secondary Synchronization versus DNS Update 474 As updates only concern DNS zones, this document only considers DNS 475 update mechanisms such as DNS update [RFC2136] [RFC3007] or a 476 primary / secondary synchronization. 478 The Homenet Zone Template SHOULD be updated with DNS update as it 479 contains static configuration data that is not expected to evolve 480 over time. 482 The Homenet Reverse Zone and the Homenet Zone can be updated either 483 with DNS update or using a primary / secondary synchronization. As 484 these zones may be large, with frequent updates, we recommend to use 485 the primary / secondary architecture as described in 486 [I-D.ietf-homenet-front-end-naming-delegation]. The primary / 487 secondary mechanism is preferred as it better scales and avoids DoS 488 attacks: First the primary notifies the secondary the zone must be 489 updated, and leaves the secondary to proceed to the update when 490 possible. Then, the NOTIFY message sent by the primary is a small 491 packet that is less likely to load the secondary. At last, the AXFR 492 query performed by the secondary is a small packet sent over TCP 493 (section 4.2 [RFC5936]) which makes unlikely the secondary to perform 494 reflection attacks with a forged NOTIFY. On the other hand, DNS 495 updates can use UDP, packets require more processing than a NOTIFY, 496 and they do not provide the server the opportunity to postpone the 497 update. 499 Internet-DrafDHCPv6 Options for Homenet Naming Architecture October 2017 501 5. HNA Configuration 503 5.1. HNA Primary / Secondary Synchronization Configurations 505 The primary / secondary architecture is described in 506 [I-D.ietf-homenet-front-end-naming-delegation]. The HNA hosts a 507 Hidden Primary that synchronizes with a Synchronization Server or the 508 Reverse Synchronization Server. 510 When the HNA is plugged its IP address may be unknown to the 511 secondary. The section details how the HNA or primary communicates 512 the necessary information to set up the secondary. 514 In order to set the primary / secondary configuration, both primary 515 and secondaries must agree on 1) the zone to be synchronized, 2) the 516 IP address and ports used by both primary and secondary. 518 5.1.1. HNA / Synchronization Server 520 The HNA is aware of the zone to be synchronized by reading the 521 Registered Homenet Domain in the Homenet Zone Template provided by 522 the Zone Template Option (OPTION_DNS_ZONE_TEMPLATE). The IP address 523 of the secondary is provided by the Synchronization Server Option 524 (OPTION_SYNC_SERVER). 526 The Synchronization Server has been configured with the Registered 527 Homenet Domain and the Client Public Key that identifies the HNA. 528 The only missing information is the IP address of the HNA. This IP 529 address is provided by the HNA by sending a NOTIFY [RFC1996]. 531 When the HNA has built its Homenet Zone, it sends a NOTIFY message to 532 the Synchronization Servers. Upon receiving the NOTIFY message, the 533 secondary reads the Registered Homenet Domain and checks the NOTIFY 534 is sent by the authorized primary. This can be done using the shared 535 secret (TSIG) or the public key (SIG(0)). Once the NOTIFY has been 536 authenticated, the Synchronization Servers might consider the source 537 IP address of the NOTIFY query to configure the primaries attributes. 539 5.1.2. HNA / Reverse Synchronization Server 541 The HNA is aware of the zone to be synchronized by looking at its 542 assigned prefix. The IP address of the secondary is provided by the 543 Reverse Synchronization Server Option (OPTION_REVERSE_SYNC_SERVER). 545 Configuration of the secondary is performed as illustrated in 546 Section 5.1.1. 548 Internet-DrafDHCPv6 Options for Homenet Naming Architecture October 2017 550 5.2. HNA DNS Data Handling and Update Policies 552 5.2.1. Homenet Zone Template 554 The Homenet Zone Template contains at least the related fields of the 555 Public Authoritative Server(s) as well as the Homenet Registered 556 Domain, that is SOA, and NS fields. This template might be generated 557 automatically by the owner of the DHCP Server. For example, an ISP 558 might provide a default Homenet Registered Domain as well as default 559 Public Authoritative Server(s). This default settings should provide 560 the HNA the necessary pieces of information to set the homenet naming 561 architecture. 563 If the Homenet Zone Template is not subject to modifications or 564 updates, the owner of the template might only use DNSSEC to enable 565 integrity check. 567 On the other hand, the Homenet Zone Template might also be subject to 568 modification by the HNA. The advantage of using the standard DNS 569 zone format is that standard DNS update mechanism can be used to 570 perform updates. These updates might be accepted or rejected by the 571 owner of the Homenet Zone Template. Policies that defines what is 572 accepted or rejected is out of scope of this document. However, this 573 document assumes the Registered Homenet Domain is used as an index by 574 the Synchronization Server, and SIG(0), TSIG are used to authenticate 575 the HNA. As a result, the Registered Homenet Domain should not be 576 modified unless the Synchronization Server can handle with it. 578 5.2.2. DNS (Reverse) Homenet Zone 580 The Homenet Zone might be generated from the Homenet Zone Template. 581 How the Homenet Zone is generated is out of scope of this document. 582 In some cases, the Homenet Zone might be the exact copy of the 583 Homenet Zone Template. In other cases, it might be generated from 584 the Homenet Zone Template with additional RRsets. In some other 585 cases, the Homenet Zone might be generated without considering the 586 Homenet Zone Template, but only considering specific configuration 587 rules. 589 In the current document the HNA only sets a single zone that is 590 associated with one single Homenet Registered Domain. The domain 591 might be assigned by the owner of the Homenet Zone Template. This 592 constraint does not prevent the HNA to use multiple domain names. 593 How additional domains are considered is out of scope of this 594 document. One way to handle these additional zones is to configure 595 static redirections to the Homenet Zone using CNAME [RFC2181], 596 [RFC1034], DNAME [RFC6672] or CNAME+DNAME 597 [I-D.sury-dnsext-cname-dname]. 599 Internet-DrafDHCPv6 Options for Homenet Naming Architecture October 2017 601 6. Payload Description 603 This section details the payload of the DHCPv6 options. A few DHCPv6 604 options are used to advertise a server the HNA may be expected to 605 interact with. Interaction may require to define update and 606 authentication methods. Update fields are shared by multiple DHCPv6 607 options and are described in separate sections. Section 6.1 608 describes the Supported Authentication Method field, Section 6.2 609 describes the Update field, the remaining Section 6.3, Section 6.4, 610 Section 6.5, Section 6.6 describe the DHCPv6 options. 612 6.1. Supported Authentication Methods Field 614 The Supported Authentication Methods field of the DHCPv6 option 615 represented in Figure 2 indicates the authentication method supported 616 by the DNS server. One of these mechanism MUST be chosen by the HNA 617 in order to perform a transaction with the DNS server. See 618 Section 4.2 for more details. 620 0 1 621 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 622 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 623 | Supported Auth. Methods | 624 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 626 Figure 2: Supported Authentication Methods Filed 628 - DNS (Bit 0): indicates, when set to 1, that DNS without any 629 security extension is supported. 631 - DNSSEC (Bit 1): indicates, when set to 1, that DNSSEC provides 632 integrity protection. This can only be used for read 633 operations like retrieving the Homenet Zone Template. 635 - SIG(0) (Bit 2): indicates, when set to 1, that transaction 636 protected by SIG(0) are supported. 638 - TSIG (Bit 3): indicates, when set to 1, that transaction using 639 TSIG is supported. Note that if a shared secret has not been 640 previously negotiated between the two party, it should be 641 negotiated using TKEY. The TKEY exchanges MUST be protected 642 with SIG(0) even though SIG(0) is not supported. 644 - Remaining Bits (Bit 4-15): MUST be set to 0 by the DHCP Server 645 and MUST be ignored by the DHCPv6 client. 647 A Supported Authentication Methods field with all bits set to zero 648 indicates the operation is not permitted. The Supported 650 Internet-DrafDHCPv6 Options for Homenet Naming Architecture October 2017 652 Authentication Methods field may be set to zero when updates 653 operations are not permitted for the DNS Homenet Template. In any 654 other case this is an error. 656 6.2. Update Field 658 The Update Field of the DHCPv6 option is represented in Figure 3. It 659 indicates the update mechanism supported by the DNS server. See 660 Section 4.3 for more details. 662 0 663 0 1 2 3 4 5 6 7 664 +-+-+-+-+-+-+-+-+ 665 | Update | 666 +-+-+-+-+-+-+-+-+ 668 Figure 3: Update Field 670 - Primary / Secondary (Bit 0): indicates, when set to 1, that DNS 671 Server supports data synchronization using a Primary / 672 Secondary mechanism. 674 - DNS Update (Bit 1): indicates, when set to 1, that DNS Server 675 supports data synchronization using DNS Updates. 677 - Remaining Bits (Bit 2-7): MUST be set to 0 by the DHCPv6 server 678 and MUST be ignored by the DHCPv6 client. 680 6.3. Client Public Key Option 682 The Client Public Key Option (OPTION_PUBLIC_KEY) indicates the Client 683 Public Key that is used to authenticate the HNA. This option is 684 defined in [I-D.ietf-dhc-sedhcpv6]. 686 6.4. Zone Template Option 688 The Zone Template Option (OPTION_DNS_ZONE_TEMPLATE) Option indicates 689 the HNA how to retrieve the Homenet Zone Template. It provides a 690 FQDN the HNA SHOULD query with a DNS query of type AXFR as well as 691 the authentication methods associated to the AXFR query or the 692 nsupdate queries. Homenet Zone Template update, if permitted MUST 693 use the DNS Update mechanism. 695 Internet-DrafDHCPv6 Options for Homenet Naming Architecture October 2017 697 0 1 2 3 698 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 699 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 700 | OPTION_DNS_ZONE_TEMPLATE | option-len | 701 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 702 | Supp. Auth. Methods (axfr) | Supp. Auth. Methods (update) | 703 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 704 | | 705 / Zone Template FQDN / 706 | | 707 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 709 Figure 4: Zone Template Option 711 - option-code: (16 bits): OPTION_DNS_ZONE_TEMPLATE, the option code 712 for the Zone Template Option (TBD1). 714 - option-len (16 bits): length in octets of the option-data field as 715 described in [RFC3315]. 717 - Supported Authentication Methods(axfr) (16 bits): defines which 718 authentication methods are supported by the DNS server. This 719 field concerns the AXFR and consultation queries, not the 720 update queries. See Section 6.1 for more details. 722 - Supported Authentication Methods (16 bits): defines which 723 authentication methods are supported by the DNS server. This 724 field concerns the update. See Section 6.1 for more details. 726 - Zone Template FQDN FQDN (variable): the FQDN of the DNS server 727 hosting the Homenet Zone Template. 729 6.5. Synchronization Server Option 731 The Synchronization Server Option (OPTION_SYNC_SERVER) provides 732 information necessary for the HNA to upload the Homenet Zone to the 733 Synchronization Server. Finally, the option provides the 734 authentication methods that are available to perform the upload. The 735 upload is performed via a DNS primary / secondary architecture or DNS 736 updates. 738 Internet-DrafDHCPv6 Options for Homenet Naming Architecture October 2017 740 0 1 2 3 741 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 742 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 743 | OPTION_SYNC_SERVER | option-len | 744 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 745 | Supported Auth. Methods | Update | Server / 746 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 747 / Port | | 748 +-+-+-+-+-+-+-+-+ | 749 | | 750 / Synchronization Server FQDN / 751 | | 752 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 754 Figure 5: Synchronization Server Option 756 - option-code (16 bits): OPTION_SYNC_SERVER, the option code for the 757 Synchronization Server Option (TBD2). 759 - option-len (16 bits): length in octets of the option-data field as 760 described in [RFC3315]. 762 - Supported Authentication Methods (16 bits): defines which 763 authentication methods are supported by the DNS server. See 764 Section 6.1 for more details. 766 - Update (8 bits): defines which update mechanisms are supported by 767 the DNS server. See Section 4.3 for more details. 769 - Server Port (16 bits): defines the port the Synchronization Server 770 is listening. When multiple transport layers may be used, a 771 single and unique Server Port value applies to all the 772 transport layers. In the case of DNS for example, Server Port 773 value considers DNS exchanges using UDP and TCP. 775 - Synchronization Server FQDN (variable): the FQDN of the 776 Synchronization Server. 778 6.6. Reverse Synchronization Server Option 780 The Reverse Synchronization Server Option 781 (OPTION_REVERSE_SYNC_SERVER) provides information necessary for the 782 HNA to upload the Homenet Zone to the Synchronization Server. The 783 option provides the authentication methods that are available to 784 perform the upload. The upload is performed via a DNS primary / 785 secondary architecture or DNS updates. 787 Internet-DrafDHCPv6 Options for Homenet Naming Architecture October 2017 789 0 1 2 3 790 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 791 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 792 | OPTION_REVERSE_SYNC_SERVER | option-len | 793 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 794 | Supported Auth. Methods | Update | Server / 795 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 796 / Port | | 797 +-+-+-+-+-+-+-+-+-+ | 798 | | 799 / Reverse Synchronization Server FQDN / 800 | | 801 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 803 Figure 6: Reverse Synchronization Server Option 805 - option-code (16 bits): OPTION_REVERSE_SYNC_SERVER, the option code 806 for the Reverse Synchronization Server Option (TBD3). 808 - option-len (16 bits): length in octets of the option-data field as 809 described in [RFC3315]. 811 - Supported Authentication Methods (16 bits): defines which 812 authentication methods are supported by the DNS server. See 813 Section 6.1 for more details. 815 - Update (8 bits): defines which update mechanisms are supported by 816 the DNS server. See Section 4.3 for more details. 818 - Server Port (16 bits): defines the port the Synchronization Server 819 is listening. 821 - Reverse Synchronization Server FQDN (variable): The FQDN of the 822 Reverse Synchronization Server. 824 7. DHCP Behavior 826 7.1. DHCPv6 Server Behavior 828 Sections 17.2.2 and 18.2 of [RFC3315] govern server operation in 829 regards to option assignment. As a convenience to the reader, we 830 mention here that the server will send option foo only if configured 831 with specific values for foo and if the client requested it. In 832 particular, when configured the DHCP Server sends the Zone Template 833 Option, Synchronization Server Option, Reverse Synchronization Server 834 Option when requested by the DHCPv6 client by including necessary 835 option codes in its ORO. 837 Internet-DrafDHCPv6 Options for Homenet Naming Architecture October 2017 839 The DHCP Server may receive a Client Public Key Option 840 (OPTION_PUBLIC_KEY) from the HNA. Upon receipt of this DHCPv6 841 option, the DHCP Server SHOULD acknowledge the reception of the 842 Client Public Key Option as described in Section 4.1 and communicate 843 this credential to the available DNS Servers like the DNS Template 844 Server, the Synchronization Server and the Reverse Synchronization 845 Server, unless not configured to do so. 847 A HNA may update its Client Public Key by sending a new value in the 848 Client Public Key Option (OPTION_PUBLIC_KEY) as this document assumes 849 the link between the HNA and the DHCP Server is considered 850 authenticated and trusted. The server SHOULD process received Client 851 Public Key Option sent by the client (see step 2 in Section 4.1), 852 unless not configured to do so. 854 7.2. DHCPv6 Client Behavior 856 The DHCPv6 client SHOULD send a Client Public Key Option 857 (OPTION_PUBLIC_KEY) to the DHCP Server. This Client Public Key 858 authenticates the HNA. 860 The DHCPv6 client sends a ORO with the necessary option codes: Zone 861 Template Option, Synchronization Server Option and Reverse 862 Synchronization Server Option. 864 Upon receiving a DHCP option described in this document in the Reply 865 message, the HNA SHOULD retrieve or update DNS zones using the 866 associated Supported Authentication Methods and update protocols, as 867 described in Section 5. 869 7.3. DHCPv6 Relay Agent Behavior 871 There are no additional requirements for the DHCP Relay agents. 873 8. IANA Considerations 875 The DHCP options detailed in this document is: 877 - OPTION_DNS_ZONE_TEMPLATE: TBD1 879 - OPTION_SYNC_SERVER: TBD2 881 - OPTION_REVERSE_SYNC_SERVER: TBD3 883 Internet-DrafDHCPv6 Options for Homenet Naming Architecture October 2017 885 9. Security Considerations 887 9.1. DNSSEC is recommended to authenticate DNS hosted data 889 It is recommended that the (Reverse) Homenet Zone is signed with 890 DNSSEC. The zone may be signed by the HNA or by a third party. We 891 recommend the zone to be signed by the HNA, and that the signed zone 892 is uploaded. 894 9.2. Channel between the HNA and ISP DHCP Server MUST be secured 896 The channel MUST be secured because the HNA provides authentication 897 credentials. Unsecured channel may result in HNA impersonation 898 attacks. 900 The document considers that the channel between the HNA and the ISP 901 DHCP Server is trusted. More specifically, the HNA is authenticated 902 and the exchanged messages are protected. The current document does 903 not specify how to secure the channel. [RFC3315] proposes a DHCP 904 authentication and message exchange protection, [RFC4301], [RFC7296] 905 propose to secure the channel at the IP layer. 907 9.3. HNAs are sensitive to DoS 909 HNA have not been designed for handling heavy load. The HNA are 910 exposed on the Internet, and their IP address is publicly published 911 on the Internet via the DNS. This makes the Home Network sensitive 912 to Deny of Service Attacks. The resulting outsourcing architecture 913 is described in [I-D.ietf-homenet-front-end-naming-delegation]. This 914 document shows how the outsourcing architecture can be automatically 915 set. 917 10. Acknowledgments 919 We would like to thank Marcin Siodelski and Bernie Volz for their 920 comments on the design of the DHCPv6 options. We would also like to 921 thank Mark Andrews, Andrew Sullivan and Lorenzo Colliti for their 922 remarks on the architecture design. The designed solution has been 923 largely been inspired by Mark Andrews's document 924 [I-D.andrews-dnsop-pd-reverse] as well as discussions with Mark. We 925 also thank Ray Hunter for its reviews, its comments and for 926 suggesting an appropriated terminology. 928 11. References 929 Internet-DrafDHCPv6 Options for Homenet Naming Architecture October 2017 931 11.1. Normative References 933 [RFC1034] Mockapetris, P., "Domain names - concepts and facilities", 934 STD 13, RFC 1034, DOI 10.17487/RFC1034, November 1987, 935 . 937 [RFC1996] Vixie, P., "A Mechanism for Prompt Notification of Zone 938 Changes (DNS NOTIFY)", RFC 1996, DOI 10.17487/RFC1996, 939 August 1996, . 941 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 942 Requirement Levels", BCP 14, RFC 2119, 943 DOI 10.17487/RFC2119, March 1997, 944 . 946 [RFC2136] Vixie, P., Ed., Thomson, S., Rekhter, Y., and J. Bound, 947 "Dynamic Updates in the Domain Name System (DNS UPDATE)", 948 RFC 2136, DOI 10.17487/RFC2136, April 1997, 949 . 951 [RFC2181] Elz, R. and R. Bush, "Clarifications to the DNS 952 Specification", RFC 2181, DOI 10.17487/RFC2181, July 1997, 953 . 955 [RFC2845] Vixie, P., Gudmundsson, O., Eastlake 3rd, D., and B. 956 Wellington, "Secret Key Transaction Authentication for DNS 957 (TSIG)", RFC 2845, DOI 10.17487/RFC2845, May 2000, 958 . 960 [RFC2930] Eastlake 3rd, D., "Secret Key Establishment for DNS (TKEY 961 RR)", RFC 2930, DOI 10.17487/RFC2930, September 2000, 962 . 964 [RFC2931] Eastlake 3rd, D., "DNS Request and Transaction Signatures 965 ( SIG(0)s )", RFC 2931, DOI 10.17487/RFC2931, September 966 2000, . 968 [RFC3007] Wellington, B., "Secure Domain Name System (DNS) Dynamic 969 Update", RFC 3007, DOI 10.17487/RFC3007, November 2000, 970 . 972 [RFC3315] Droms, R., Ed., Bound, J., Volz, B., Lemon, T., Perkins, 973 C., and M. Carney, "Dynamic Host Configuration Protocol 974 for IPv6 (DHCPv6)", RFC 3315, DOI 10.17487/RFC3315, July 975 2003, . 977 Internet-DrafDHCPv6 Options for Homenet Naming Architecture October 2017 979 [RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S. 980 Rose, "DNS Security Introduction and Requirements", 981 RFC 4033, DOI 10.17487/RFC4033, March 2005, 982 . 984 [RFC4034] Arends, R., Austein, R., Larson, M., Massey, D., and S. 985 Rose, "Resource Records for the DNS Security Extensions", 986 RFC 4034, DOI 10.17487/RFC4034, March 2005, 987 . 989 [RFC4035] Arends, R., Austein, R., Larson, M., Massey, D., and S. 990 Rose, "Protocol Modifications for the DNS Security 991 Extensions", RFC 4035, DOI 10.17487/RFC4035, March 2005, 992 . 994 [RFC4301] Kent, S. and K. Seo, "Security Architecture for the 995 Internet Protocol", RFC 4301, DOI 10.17487/RFC4301, 996 December 2005, . 998 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 999 (TLS) Protocol Version 1.2", RFC 5246, 1000 DOI 10.17487/RFC5246, August 2008, 1001 . 1003 [RFC5936] Lewis, E. and A. Hoenes, Ed., "DNS Zone Transfer Protocol 1004 (AXFR)", RFC 5936, DOI 10.17487/RFC5936, June 2010, 1005 . 1007 [RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer 1008 Security Version 1.2", RFC 6347, DOI 10.17487/RFC6347, 1009 January 2012, . 1011 [RFC6672] Rose, S. and W. Wijngaards, "DNAME Redirection in the 1012 DNS", RFC 6672, DOI 10.17487/RFC6672, June 2012, 1013 . 1015 [RFC7296] Kaufman, C., Hoffman, P., Nir, Y., Eronen, P., and T. 1016 Kivinen, "Internet Key Exchange Protocol Version 2 1017 (IKEv2)", STD 79, RFC 7296, DOI 10.17487/RFC7296, October 1018 2014, . 1020 11.2. Informational References 1022 [I-D.andrews-dnsop-pd-reverse] 1023 Andrews, M., "Automated Delegation of IP6.ARPA reverse 1024 zones with Prefix Delegation", draft-andrews-dnsop-pd- 1025 reverse-02 (work in progress), November 2013. 1027 Internet-DrafDHCPv6 Options for Homenet Naming Architecture October 2017 1029 [I-D.ietf-dhc-sedhcpv6] 1030 Li, L., Jiang, S., Cui, Y., Jinmei, T., Lemon, T., and D. 1031 Zhang, "Secure DHCPv6", draft-ietf-dhc-sedhcpv6-21 (work 1032 in progress), February 2017. 1034 [I-D.ietf-homenet-front-end-naming-delegation] 1035 Migault, D., Weber, R., Hunter, R., Griffiths, C., and W. 1036 Cloetens, "Outsourcing Home Network Authoritative Naming 1037 Service", draft-ietf-homenet-front-end-naming- 1038 delegation-05 (work in progress), August 2016. 1040 [I-D.sury-dnsext-cname-dname] 1041 Sury, O., "CNAME+DNAME Name Redirection", draft-sury- 1042 dnsext-cname-dname-00 (work in progress), April 2010. 1044 Appendix A. Scenarios and impact on the End User 1046 This section details various scenarios and discuss their impact on 1047 the end user. 1049 A.1. Base Scenario 1051 The base scenario is the one described in Section 4. It is typically 1052 the one of an ISP that manages the DHCP Server, and all DNS servers. 1054 The end user subscribes to the ISP (foo), and at subscription time 1055 registers for example.foo as its Registered Homenet Domain 1056 example.foo. Since the ISP knows the Registered Homenet Domain and 1057 the Public Authoritative Server(s) the ISP is able to build the 1058 Homenet Zone Template. 1060 The ISP manages the DNS Template Server, so it is able to load the 1061 Homenet Zone Template on the DNS Template Server. 1063 When the HNA is plugged (at least the first time), it provides its 1064 Client Public Key to the DHCP Server. In this scenario, the DHCP 1065 Server and the DNS Servers are managed by the ISP so the DHCP Server 1066 can provide authentication credentials of the HNA to enable secure 1067 authenticated transaction between the HNA and these DNS servers. 1068 More specifically, credentials are provided to: 1070 - Synchronization Server 1072 - Reverse Synchronization Server 1074 - DNS Template Server 1076 Internet-DrafDHCPv6 Options for Homenet Naming Architecture October 2017 1078 The HNA can update the zone using DNS update or a primary / secondary 1079 configuration in a secure way. 1081 The main advantage of this scenario is that the naming architecture 1082 is configured automatically and transparently for the end user. 1084 The drawbacks are that the end user uses a Registered Homenet Domain 1085 managed by the ISP and that it relies on the ISP naming 1086 infrastructure. 1088 A.2. Third Party Registered Homenet Domain 1090 This section considers the case when the end user wants its home 1091 network to use example.com as a Registered Homenet Domain instead of 1092 example.foo that has been assigned by the ISP. We also suppose that 1093 example.com is not managed by the ISP. 1095 This can also be achieved without any configuration. When the end 1096 user buys the domain name example.com, it may request to redirect the 1097 name example.com to example.foo using static redirection with CNAME 1098 [RFC2181], [RFC1034], DNAME [RFC6672] or CNAME+DNAME 1099 [I-D.sury-dnsext-cname-dname]. 1101 This configuration is performed once when the domain name example.com 1102 is registered. The only information the end user needs to know is 1103 the domain name assigned by the ISP. Once this configuration is done 1104 no additional configuration is needed anymore. More specifically, 1105 the HNA may be changed, the zone can be updated as in Appendix A.1 1106 without any additional configuration from the end user. 1108 The main advantage of this scenario is that the end user benefits 1109 from the Zero Configuration of the Base Scenario Appendix A.1. Then, 1110 the end user is able to register for its home network an unlimited 1111 number of domain names provided by an unlimited number of different 1112 third party providers. 1114 The drawback of this scenario may be that the end user still rely on 1115 the ISP naming infrastructure. Note that the only case this may be 1116 inconvenient is when the DNS Servers provided by the ISPs results in 1117 high latency. 1119 A.3. Third Party DNS Infrastructure 1121 This scenario considers that the end user uses example.com as a 1122 Registered Homenet Domain, and does not want to rely on the 1123 authoritative servers provided by the ISP. 1125 Internet-DrafDHCPv6 Options for Homenet Naming Architecture October 2017 1127 In this section we limit the outsourcing to the Synchronization 1128 Server and Public Authoritative Server(s) to a third party. All 1129 other DNS Servers DNS Template Server, Reverse Public Authoritative 1130 Server(s) and Reverse Synchronization Server remain managed by the 1131 ISP. The reason we consider that Reverse Public Authoritative 1132 Server(s) and Reverse Synchronization Server remains managed by the 1133 ISP are that the prefix is managed by the ISP, so outsourcing these 1134 resources requires some redirection agreement with the ISP. More 1135 specifically the ISP will need to configure the redirection on one of 1136 its Reverse DNS Servers. That said, outsourcing these resources is 1137 similar as outsourcing Synchronization Server and Public 1138 Authoritative Server(s) to a third party. Similarly, the DNS 1139 Template Server can be easily outsourced as detailed in this section 1141 Outsourcing Synchronization Server and Public Authoritative Server(s) 1142 requires: 1144 - 1) Updating the Homenet Zone Template: this can be easily done as 1145 detailed in Section 4.3 as the DNS Template Server is still 1146 managed by the ISP. Such modification can be performed once by 1147 any HNA. Once this modification has been performed, the HNA 1148 can be changed, the Client Public Key of the HNA may be 1149 changed, this does not need to be done another time. One can 1150 imagine a GUI on the HNA asking the end user to fill the field 1151 with Registered Homenet Domain, optionally Public Authoritative 1152 Server(s), with a button "Configure Homenet Zone Template". 1154 - 2) Updating the DHCP Server Information. In fact the Reverse 1155 Synchronization Server returned by the ISP is modified. One 1156 can imagine a GUI interface that enables the end user to modify 1157 its profile parameters. Again, this configuration update is 1158 done once-for-ever. 1160 - 3) Upload the authentication credential of the HNA, that is the 1161 Client Public Key of the HNA, to the third party. Unless we 1162 use specific mechanisms, like communication between the DHCP 1163 Server and the third party, or a specific token that is plugged 1164 into the HNA, this operation is likely to be performed every 1165 time the HNA is changed, and every time the Client Public Key 1166 generated by the HNA is changed. 1168 The main advantage of this scenario is that the DNS infrastructure is 1169 completely outsourced to the third party. Most likely the Client 1170 Public Key that authenticate the HNA need to be configured for every 1171 HNA. Configuration is expected to be HNA live-long. 1173 Internet-DrafDHCPv6 Options for Homenet Naming Architecture October 2017 1175 A.4. Multiple ISPs 1177 This scenario considers a HNA connected to multiple ISPs. 1179 Firstly, suppose the HNA has been configured with the based scenarios 1180 exposed in Appendix A.1. The HNA has multiple interfaces, one for 1181 each ISP, and each of these interface is configured using DHCP. The 1182 HNA sends to each ISP its Client Public Key Option as well as a 1183 request for a Zone Template Option, a Synchronization Server Option 1184 and a Reverse Synchronization Server Option. Each ISP provides the 1185 requested DHCP options, with different values. Note that this 1186 scenario assumes, the home network has a different Registered Homenet 1187 Domain for each ISP as it is managed by the ISP. On the other hand, 1188 the HNA Client Public Key may be shared between the HNA and the 1189 multiple ISPs. The HNA builds the associate DNS(SEC) Homenet Zone, 1190 and proceeds to the various settings as described in Appendix A.1. 1192 The protocol and DHCPv6 options described in this document are fully 1193 compatible with a HNA connected to multiple ISPs with multiple 1194 Registered Homenet Domains. However, the HNA should be able to 1195 handle different Registered Homenet Domains. This is an 1196 implementation issue which is outside the scope of the current 1197 document. More specifically, multiple Registered Homenet Domains 1198 leads to multiple DNS(SEC) Homenet Zones. A basic implementation may 1199 erase the DNS(SEC) Homenet Zone that exists when it receives DHCPv6 1200 options, and rebuild everything from scratch. This will work for an 1201 initial configuration but comes with a few drawbacks. First, updates 1202 to the DNS(SEC) Homenet Zone may only push to one of the multiple 1203 Registered Homenet Domain, the latest Registered Homenet Domain that 1204 has been set, and this is most likely expected to be almost randomly 1205 chosen as it may depend on the latency on each ISP network at the 1206 boot time. As a results, this leads to unsynchronized Registered 1207 Homenet Domains. Secondly, if the HNA handles in some ways 1208 resolution, only the latest Registered Homenet Domain set may be able 1209 to provide naming resolution in case of network disruption. 1211 Secondly, suppose the HNA is connected to multiple ISP with a single 1212 Registered Homenet Domain. In this case, the one party is chosen to 1213 host the Registered Homenet Domain. This entity may be one of the 1214 ISP or a third party. Note that having multiple ISPs can be 1215 motivated for bandwidth aggregation, or connectivity fail-over. In 1216 the case of connectivity fail-over, the fail-over concerns the access 1217 network and a failure of the access network may not impact the core 1218 network where the Synchronization Server and Public Authoritative 1219 Primaries are hosted. In that sense, choosing one of the ISP even in 1220 a scenario of multiple ISPs may make sense. However, for sake of 1221 simplicity, this scenario assumes that a third party has be chosen to 1222 host the Registered Homenet Domain. The DNS settings for each ISP is 1224 Internet-DrafDHCPv6 Options for Homenet Naming Architecture October 2017 1226 described in Appendix A.2 and Appendix A.3. With the configuration 1227 described in Appendix A.2, the HNA is expect to be able to handle 1228 multiple Homenet Registered Domain, as the third party redirect to 1229 one of the ISPs Servers. With the configuration described in 1230 Appendix A.3, DNS zone are hosted and maintained by the third party. 1231 A single DNS(SEC) Homenet Zone is built and maintained by the HNA. 1232 This latter configuration is likely to match most HNA 1233 implementations. 1235 The protocol and DHCPv6 options described in this document are fully 1236 compatible with a HNA connected to multiple ISPs. To configure or 1237 not and how to configure the HNA depends on the HNA facilities. 1238 Appendix A.1 and Appendix A.2 require the HNA to handle multiple 1239 Registered Homenet Domain, whereas Appendix A.3 does not have such 1240 requirement. 1242 Appendix B. Document Change Log 1244 [RFC Editor: This section is to be removed before publication] 1246 -05: changing Master to Primary, Slave to Secondary 1248 -04: Working Version Major modifications are: 1250 - Re-structuring the draft: description and comparison of update and 1251 authentication methods have been integrated into the Overview 1252 section. a Configuration section has been created to describe 1253 both configuration and corresponding behavior of the HNA. 1255 - Adding Ports parameters: Server Set can configure a port. The 1256 Port Server parameter have been added in the DHCPv6 option 1257 payloads because middle boxes may not be configured to let port 1258 53 packets and it may also be useful to split servers among 1259 different ports, assigning each end user a different port. 1261 - Multiple ISP scenario: In order to address comments, the multiple 1262 ISPs scenario has been described to explicitly show that the 1263 protocol and DHCPv6 options do not prevent a HNA connected to 1264 multiple independent ISPs. 1266 -03: Working Version Major modifications are: 1268 - Redesigning options/scope: according to feed backs received from 1269 the IETF89 presentation in the dhc WG. 1271 - Redesigning architecture: according to feed backs received from 1272 the IETF89 presentation in the homenet WG, discussion with Mark 1273 and Lorenzo. 1275 Internet-DrafDHCPv6 Options for Homenet Naming Architecture October 2017 1277 -02: Working Version Major modifications are: 1279 - Redesigning options/scope: As suggested by Bernie Volz 1281 -01: Working Version Major modifications are: 1283 - Remove the DNS Zone file construction: As suggested by Bernie Volz 1285 - DHCPv6 Client behavior: Following options guide lines 1287 - DHCPv6 Server behavior: Following options guide lines 1289 -00: version published in the homenet WG. Major modifications are: 1291 - Reformatting of DHCPv6 options: Following options guide lines 1293 - DHCPv6 Client behavior: Following options guide lines 1295 - DHCPv6 Server behavior: Following options guide lines 1297 -00: First version published in dhc WG. 1299 Authors' Addresses 1301 Daniel Migault 1302 Ericsson 1303 8400 boulevard Decarie 1304 Montreal, QC H4P 2N2 1305 Canada 1307 Email: daniel.migault@ericsson.com 1309 Tomek Mrugalski 1310 Internet Systems Consortium, Inc. 1311 950 Charter Street 1312 Redwood City, CA 94063 1313 USA 1315 Email: tomasz.mrugalski@gmail.com 1316 URI: http://www.isc.org 1318 Chris Griffiths 1320 Email: cgriffiths@gmail.com 1322 Internet-DrafDHCPv6 Options for Homenet Naming Architecture October 2017 1324 Ralf Weber 1325 Nominum 1326 2000 Seaport Blvd #400 1327 Redwood City, CA 94063 1328 US 1330 Email: ralf.weber@nominum.com 1331 URI: http://www.nominum.com 1333 Wouter Cloetens 1334 SoftAtHome 1335 vaartdijk 3 701 1336 3018 Wijgmaal 1337 Belgium 1339 Email: wouter.cloetens@softathome.com