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