idnits 2.17.1 draft-ietf-homenet-naming-architecture-dhc-options-01.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 (February 17, 2015) is 3353 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-00 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 W. Cloetens 5 Expires: August 21, 2015 SoftAtHome 6 C. Griffiths 7 Dyn 8 R. Weber 9 Nominum 10 February 17, 2015 12 DHCP Options for Homenet Naming Architecture 13 draft-ietf-homenet-naming-architecture-dhc-options-01.txt 15 Abstract 17 CPEs are usually constraint devices with reduced network and CPU 18 capacities. As such, a CPE hosting on the Internet the authoritative 19 naming service for its home network may become vulnerable to resource 20 exhaustion attacks. One way to avoid exposing CPE is to outsource 21 the authoritative service to a third party. This third party can be 22 the ISP or any other independent third party. 24 Outsourcing the authoritative naming service to a third party 25 requires setting up an architecture which may be unappropriated for 26 most end users. To leverage this issue, this document proposes DHCP 27 Options so any agnostic CPE can automatically proceed to the 28 appropriated configuration and outsource the authoritative naming 29 service for the home network. This document shows that in most 30 cases, these DHCP Options make outsourcing to a third party (be it 31 the ISP or any ISP independent service provider) transparent for the 32 end user. 34 Status of This Memo 36 This Internet-Draft is submitted in full conformance with the 37 provisions of BCP 78 and BCP 79. 39 Internet-Drafts are working documents of the Internet Engineering 40 Task Force (IETF). Note that other groups may also distribute 41 working documents as Internet-Drafts. The list of current Internet- 42 Drafts is at http://datatracker.ietf.org/drafts/current/. 44 Internet-Drafts are draft documents valid for a maximum of six months 45 and may be updated, replaced, or obsoleted by other documents at any 46 time. It is inappropriate to use Internet-Drafts as reference 47 material or to cite them other than as "work in progress." 48 This Internet-Draft will expire on August 21, 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 . . . . . . . . . . . . . . . . . . . . . . . . 4 70 4. Protocol Overview . . . . . . . . . . . . . . . . . . . . . . 6 71 4.1. Architecture and DHCP Options Overview . . . . . . . . . 7 72 4.2. Mechanisms Securing DNS Transactions . . . . . . . . . . 10 73 4.3. Master / Slave Synchronization versus DNS Update . . . . 11 74 5. CPE Configuration . . . . . . . . . . . . . . . . . . . . . . 11 75 5.1. CPE Master / Slave Synchronization Configurations . . . . 11 76 5.1.1. CPE / Public Authoritative Name Server Set . . . . . 12 77 5.1.2. CPE / Reverse Public Authoritative Name Server Set . 12 78 5.2. CPE DNS Data Handling and Update Policies . . . . . . . . 12 79 5.2.1. DNS Homenet Zone Template . . . . . . . . . . . . . . 12 80 5.2.2. DNS (Reverse) Homenet Zone . . . . . . . . . . . . . 13 81 6. Payload Description . . . . . . . . . . . . . . . . . . . . . 13 82 6.1. Security Field . . . . . . . . . . . . . . . . . . . . . 14 83 6.2. Update Field . . . . . . . . . . . . . . . . . . . . . . 14 84 6.3. DHCP Public Key Option . . . . . . . . . . . . . . . . . 15 85 6.4. DHCP Zone Template Option . . . . . . . . . . . . . . . . 15 86 6.5. DHCP Public Authoritative Name Server Set Option . . . . 16 87 6.6. DHCP Reverse Public Authoritative Name Server Set Option 17 88 7. DHCP Behavior . . . . . . . . . . . . . . . . . . . . . . . . 18 89 7.1. DHCPv6 Server Behavior . . . . . . . . . . . . . . . . . 18 90 7.2. DHCPv6 Client Behavior . . . . . . . . . . . . . . . . . 19 91 7.3. DHCPv6 Relay Behavior . . . . . . . . . . . . . . . . . . 19 92 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19 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 . . . . . . . . . . . . . . . . 20 98 10. Acknowledgment . . . . . . . . . . . . . . . . . . . . . . . 20 99 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 20 100 11.1. Normative References . . . . . . . . . . . . . . . . . . 20 101 11.2. Informational References . . . . . . . . . . . . . . . . 22 102 Appendix A. Scenarios and impact on the End User . . . . . . . . 22 103 A.1. Base Scenario . . . . . . . . . . . . . . . . . . . . . . 22 104 A.2. Third Party Registered Homenet Domain . . . . . . . . . . 23 105 A.3. Third Party DNS Infrastructure . . . . . . . . . . . . . 23 106 A.4. Multiple ISPs . . . . . . . . . . . . . . . . . . . . . . 25 107 Appendix B. Document Change Log . . . . . . . . . . . . . . . . 26 108 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 27 110 1. Requirements notation 112 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 113 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 114 document are to be interpreted as described in [RFC2119]. 116 2. Terminology 118 - Customer Premises Equipment: (CPE) is the router providing 119 connectivity to the home network. It is configured and managed 120 by the end user. In this document, the CPE might also hosts 121 services such as DHCPv6. This device might be provided by the 122 ISP. 124 - Public Key: designates a public Key generated by the CPE. This 125 key is used as an authentication credential for the CPE. 127 - Registered Homenet Domain: is the Domain Name associated to the 128 home network. 130 - DNS Homenet Zone: is the DNS zone associated to the home network. 131 This zone is set by the CPE and essentially contains the 132 bindings between names and IP addresses of the nodes of the 133 home network. In this document, the CPE does neither perform 134 any DNSSEC management operations such as zone signing nor 135 provide an authoritative service for the zone. Both are 136 delegated to the Public Authoritative Server. The CPE 137 synchronizes the DNS Homenet Zone with the Public Authoritative 138 Server via a hidden master / slave architecture. The Public 139 Authoritative Server might use specific servers for the 140 synchronization of the DNS Homenet Zone: the Public 141 Authoritative Name Server Set. 143 - DNS Homenet Zone Template: The template used as a basis to 144 generate the DNS Homenet Zone. 146 - DNS Template Server: The DNS server that hosts the DNS Homenet 147 Zone Template. 149 - DNS Homenet Reverse Zone: The reverse zone file associated to the 150 DNS Homenet Zone. 152 - Public Authoritative Master(s): are the visible name server 153 hosting the DNS Homenet Zone. End users' resolutions for the 154 Homenet Domain are sent to this server, and this server is a 155 master for the zone. 157 - Public Authoritative Name Server Set: is the server the CPE 158 synchronizes the DNS Homenet Zone. It is configured as a slave 159 and the CPE acts as master. The CPE sends information so the 160 DNSSEC zone can be set and served. 162 - Reverse Public Authoritative Master(s): are the visible name 163 server hosting the DNS Homenet Reverse Zone. End users' 164 resolutions for the Homenet Domain are sent to this server, and 165 this server is a master for the zone. 167 - Reverse Public Authoritative Name Server Set: is the server the 168 CPE synchronizes the DNS Homenet Reverse Zone. It is 169 configured as a slave and the CPE acts as master. The CPE 170 sends information so the DNSSEC zone can be set and served. 172 3. Introduction 174 CPEs are usually constraint devices with reduced network and CPU 175 capacities. As such, a CPE hosting on the Internet the authoritative 176 naming service for its home network may become vulnerable to resource 177 exhaustion attacks. One way to avoid exposing CPE is to outsource 178 the authoritative service to a third party. This third party can be 179 the ISP or any other independent third party. 181 Outsourcing the authoritative naming service to a third party 182 requires setting up an architecture which may be unappropriated for 183 most end users. To leverage this issue, this document proposes DHCP 184 Options so any agnostic CPE can automatically proceed to the 185 appropriated configuration and outsource the authoritative naming 186 service for the home network. This document shows that in most 187 cases, these DHCP Options make outsourcing to a third party (be it 188 the ISP or any ISP independent service provider) transparent for the 189 end user. 191 When the CPE is plugged, the DHCP Options described in the document 192 enable the CPE: 194 - 1. To build the DNS Homenet Zone: Building the DNS Homenet Zone 195 requires filling the zone with appropriated bindings likes name 196 / IP addresses of the different devices in the home networks. 197 Such information can be provided for example by the DHCP Server 198 hosted on the CPE. On the other hand, it also requires 199 configuration parameters like the name of the Registered Domain 200 Name associated to the home network or the Public Authoritative 201 Master(s) the DNS Homenet Zone is outsourced to. These 202 configuration parameters are stored in the DNS Homenet Zone 203 Template. This document describes the DHCP Zone Template 204 Option. This option carries a DNS Homenet Zone Template FQDN. 205 In order to retrieve the DNS Homenet Zone Template, the CPE 206 sends a query of type AXFR [RFC1034] [RFC5936]for the DNS 207 Homenet Zone Template FQDN. 209 - 2. To upload the DNS(SEC) Homenet Zone to the appropriated server: 210 This server is designated as the Public Authoritative Name 211 Server Set. It is in charge of publishing the DNS(SEC) Homenet 212 Zone on the Public Authoritative Master(s). This document 213 describes the DHCP Public Authoritative Name Server Set Option 214 that provides the FQDN of the appropriated server. Note that, 215 in the document we do not consider whether the DNS(SEC) Homenet 216 Zone is signed or not and if signed who signs it. Such 217 questions are out of the scope of the current document. 219 - 3. To upload the DNS Homenet Reverse Zone to the appropriated 220 server: This server is designated as the Reverse Public 221 Authoritative Name Server Set. It is in charge of publishing 222 the DNS Homenet Reverse Zone on the Reverse Public 223 Authoritative Master(s). This document describes the DHCP 224 Reverse Public Authoritative Name Server Set Option that 225 provides the FQDN of the appropriated server. Similarly to 226 item 2., we do not consider in this document if the DNS Homenet 227 Reverse Zone is signed or not, and if signed who signs it. 229 - 4. To provide authentication credential (a public key) to the DHCP 230 Server: Information stored in the DNS Homenet Zone Template, 231 the DNS(SEC) Homenet Zone and DNS Homenet Reverse Zone belongs 232 to the CPE, and only the CPE should be able to update or upload 233 these zones. To authenticate the CPE, this document defines 234 the DHCP Public Key Option. This option is sent by the CPE to 235 the DHCP Server and provides the Public Key the CPE uses to 236 authenticate itself. The DHCP Server is then responsible to 237 provide the Public Key to the various DNS servers. 239 As a result, the DHCP Options described in this document enable an 240 agnostic CPE to outsource its naming infrastructure without any 241 configuration from the end user. The main reason no configuration is 242 required by the end user is that there are privileged links: first 243 between the CPE and the DHCP Server and then between the DHCP Server 244 and the various DNS servers (DNS Homenet Zone Server, the Reverse 245 Public Authoritative Name Server Set, Public Authoritative Name 246 Server Set). This enables the CPE to send its authentication 247 credentials (a Public Key) to the DHCP Server that in turn forward it 248 to the various DNS servers. With the authentication credential on 249 the DNS servers set, the CPE is able to update the various zones in a 250 secure way. 252 If the DHCP Server cannot provide the public key to one of these 253 servers (most likely the Public Authoritative Name Server Set) and 254 the CPE needs to interact with the server, then, the end user is 255 expected to provide the CPE's public key to these servers (the 256 Reverse Public Authoritative Name Server Set or the Public 257 Authoritative Name Server Set) either manually or using other 258 mechanisms. Such mechanisms are outside the scope of this document. 259 In that case, the authentication credentials need to be provided 260 every time the key is modified. Appendix A provides more details on 261 how different scenarios impact the end users. 263 The remaining of this document is as follows. Section 4 provides an 264 overview of the DHCP Options as well as the expected interactions 265 between the CPE and the various involved entities. This section also 266 provides an overview of available mechanisms to secure DNS 267 transactions and update DNS Data. Section 5 describes how the CPE 268 may securely synchronize and update DNS data. Section 6 describes 269 the payload of the DHCP Options and Section 7 details how DHCP Client 270 DHCP Server and DHCP Relay behave. Section 8 lists the new 271 parameters to be registered at the IANA, Section 9 provides security 272 considerations. Finally, Appendix A describes how the CPE may behave 273 and be configured regarding various scenarios. 275 4. Protocol Overview 277 This section provides an overview of the how the CPE is expect to 278 interact with various entities, as well as how the CPE is expected to 279 be configured via DHCP Options. Section 4.1 describes the entities 280 the CPE is expected to interact with. Interaction with each entities 281 is defined via DHCP Options that are expected to configure the CPE. 282 Once configured, the CPE is expected to be able to update some DNS 283 Data hosted by the different entities. As a result security and 284 updating mechanisms play an important role in the specification. 285 Section 4.2 provides an overview of the different security mechanisms 286 considered for securing the CPE transactions and Section 4.3 287 considers the different update mechanisms considered for the CPE to 288 update the DNS Data. 290 4.1. Architecture and DHCP Options Overview 292 This section illustrates how a CPE configures its naming 293 infrastructure to outsource its authoritative naming service. All 294 configurations and settings are performed using DHCP Options. This 295 section, for the sake of simplicity, assumes that the DHCP Server is 296 able to communicate to the various DNS servers and to provide them 297 the public key associated to the CPE. Once each server got the 298 public key, the CPE can proceed to updates in a authenticated and 299 secure way. 301 This scenario has been chosen as it is believed to be the most 302 popular scenario. This document does not ignore that scenarios where 303 the DHCP Server does not have privileged relations with the Public 304 Authoritative Name Server Set must be considered. These cases are 305 discussed latter in Appendix A. Such scenario does not necessarily 306 require configuration for the end user and can also be Zero Config. 308 The scenario is represented in Figure 1. 310 - 1: The CPE provides its Public Key to the DHCP Server using a DHCP 311 Public Key Option (OPTION_PUBLIC_KEY) and sends a DHCP Option 312 Request Option (ORO) for the DHCP Zone Template Option 313 (OPTION_DNS_ZONE_TEMPLATE), the DHCP Public Authoritative Name 314 Server Set Option (OPTION_NAME_SERVER_SET) and the DHCP Reverse 315 Public Authoritative Name Server Set Option 316 (OPTION_REVERSE_NAME_SERVER_SET). 318 - 2: The DHCP Server makes the Public Key available to the DNS 319 servers, so the CPE can secure its DNS transactions. Note that 320 the Public Key alone is not sufficient to perform the 321 authentication and the key should be, for example, associated 322 with an identifier, or the concerned domain name. How the 323 binding is performed is out of scope of the document. It can 324 be a centralized database or various bindings may be sent to 325 the different servers. Figure 1 represents the specific case 326 were the DHCP Server forwards the set (Public Key, Zone 327 Template FQDN) to the DNS Template Server, the set (Public Key, 328 IPv6 subnet) to the Reverse Public Authoritative Name Server 329 Set and the set (Public Key, Registered Homenet Domain) to the 330 Public Authoritative Name Server Set. 332 - 3.: The DHCP Server responds to the CPE with the requested DHCP 333 Options, i.e. the DHCP Public Key Option (OPTION_PUBLIC_KEY), 334 DHCP Zone Template Option OPTION_DNS_ZONE_TEMPLATE, DHCP Public 335 Authoritative Name Server Set Option (OPTION_NAME_SERVER_SET), 336 DHCP Reverse Public Authoritative Name Server Set Option 337 (OPTION_REVERSE_NAME_SERVER_SET). 339 - 4.: Upon receiving the DHCP Zone Template Option 340 (OPTION_DNS_ZONE_TEMPLATE), the CPE performs an AXFR DNS query 341 for the Zone Template FQDN. The exchange is secured according 342 to the security protocols defined in the Security field of the 343 DHCP option. Once the CPE has retrieved the DNS Zone Template, 344 the CPE can build the DNS Homenet Zone and the DNS Homenet 345 Reverse Zone. Eventually the CPE signs these zones. 347 - 5.: Once the DNS(SEC) Homenet Reverse Zone has been set, the CPE 348 uploads the zone to the Reverse Public Authoritative Name 349 Server Set. The DHCP Reverse Public Authoritative Name Server 350 Set Option (OPTION_REVERSE_NAME_SERVER_SET) provides the 351 Reverse Public Authoritative Name Server Set FQDN as well as 352 the upload method, and the security protocol to secure the 353 upload. 355 - 6.: Once the DNS(SEC) Homenet Zone has been set, the CPE uploads 356 the zone to the Public Authoritative Name Server Set. The DHCP 357 Public Authoritative Name Server Set Option 358 (OPTION_NAME_SERVER_SET) provides the Public Authoritative Name 359 Server Set FQDN as well as the upload method and the security 360 protocol to secure the upload. 362 +----------------------+ 363 | DHCP Server | 364 +----------------------+ 365 ^ ^ ^ 366 | | |2. 367 1.| |3. | 368 v v | 369 +------+ | +--------------------------------+ 370 | | 4. +--->| DNS Template Server | 371 | |<---------->| | 372 | | | +--------------------------------+ 373 | CPE | | 374 | | | +--------------------------------+ 375 | | 5./6. +--->| Reverse Public Authoritative | 376 | |<---------->| Name Server Set | 377 | | | +--------------------------------+ 378 -------| |-------|-------------------------------------- 379 | | | +--------------------------------+ 380 +------+ +--->| Public Authoritative | 381 | Name Server Set | 382 +--------------------------------+ 384 Figure 1: Protocol Overview 386 As described above, the CPE is likely to interact with various DNS 387 content. This section is focused on DNS Data the CPE is likely to 388 update. More specifically, the CPE is likely to update the: 390 - DNS Homenet Zone Template: may be updated by the CPE if the 391 configuration of the zone may be changed. This can include 392 additional Public Authoritative Master(s), a different 393 Registered Homenet Domain as the one initially proposed, or a 394 redirection to another domain. 396 - DNS Homenet Reverse Zone: may be updated every time a new device 397 is connected or dis-connected. 399 - DNS Homenet Zone: may be updated every time a new device is 400 connected, dis-connected. 402 In fact, the CPE must be able to perform these updates in a secure 403 manner. There are multiple ways to secure a DNS transaction and this 404 document considers two mechanisms to update a DNS Data (nsupdate and 405 master/slave synchronization). Which security mechanism to use to 406 secure a DNS transaction depends on the expected security 407 (authentication of the authoritative server, mutual authentication, 408 confidentiality...). The expected security may also depends on the 409 kind of transaction performed by the CPE. Section 4.2 describes the 410 different security mechanisms considered in the document as well as 411 their respective goals. Which mechanism to use to update the DNS 412 Data depends on the kind of update. Frequency of the update, size of 413 the DNS Data to update may be some useful criteria. Section 4.3 414 positions the nsupdate and master/slave synchronization mechanisms. 416 4.2. Mechanisms Securing DNS Transactions 418 Multiple protocols like IPsec [RFC4301] or TLS / DTLS [RFC5246] / 419 [RFC6347] may be used to secure DNS transactions between the CPE and 420 the DNS servers. This document restricts the scope of security 421 protocols to those that have been designed specifically for DNS. 422 This includes DNSSEC [RFC4033], [RFC4034], [RFC4035] that 423 authenticates and provides integrity protection of DNS data, TSIG 424 [RFC2845], [RFC2930] that use a shared secret to secure a transaction 425 between two end points and SIG(0) [RFC2931] authenticates the DNS 426 packet exchanged. 428 The key issue with TSIG is that a shared secret must be negotiated 429 between the CPE and the server. On the other hand, TSIG performs 430 symmetric cryptography which is light in comparison with asymmetric 431 cryptography used by SIG(0). As a result, over large zone transfer, 432 TSIG may be preferred to SIG(0). 434 This document does not provides means to distribute shared secret for 435 example using a specific DHCP Option. The only assumption made is 436 that the CPE generates or is assigned a public key. 438 As a result, when the document specifies the transaction is secured 439 with TSIG, it means that either the CPE and the DNS Server have been 440 manually configured with a shared secret, or the shared secret has 441 been negotiated using TKEY [RFC2930], and the TKEY exchanged are 442 secured with SIG(0). 444 Exchange with the DNS Template Server to retrieve the DNS Homenet 445 Zone Template may be protected by SIG(0), TSIG or DNSSEC. When 446 DNSSEC is used, it means the DNS Template Server only provides 447 integrity protection, and does not necessarily prevents someone else 448 to query the DNS Homenet Zone Template. In addition, DNSSEC is only 449 a way to protect the AXFR queries transaction, in other words, DNSSEC 450 cannot be used to secure updates. If DNSSEC is used to provide 451 integrity protection for the AXFR response, the CPE should proceed to 452 the DNSSEC signature checks. If signature check fails, it MUST 453 reject the response. If the signature check succeeds, the CPE 454 removes all DNSSEC related RRsets (DNSKEY, RRSIG, NSEC* ...) before 455 building the DNS Homenet Zone. In fact, these DNSSEC related fields 456 are associated to the DNS Homenet Zone Template and not the DNS 457 Homenet Zone. 459 Any update exchange should use SIG(0) or TSIG to authenticate the 460 exchange. 462 4.3. Master / Slave Synchronization versus DNS Update 464 As updates only concern DNS zones, this document only considers DNS 465 update mechanisms such as DNS update [RFC2136] [RFC3007] or a master 466 / slave synchronization. 468 The DNS Homenet Zone Template can only be updated with DNS update. 469 The reason is that the DNS Homenet Zone Template contains static 470 configuration data that is not expected to evolve over time. 472 The DNS Homenet Reverse Zone and the DNS Homenet Zone can be updated 473 either with DNS update or using a master / slave synchronization. As 474 these zones may be large, with frequent updates, we recommend to use 475 the master / slave architecture as described in 476 [I-D.ietf-homenet-front-end-naming-delegation]. The master / slave 477 mechanism is preferred as it better scales and avoids DoS attacks: 478 First the master notifies the slave the zone must be updated, and 479 leaves the slave to proceed to the update when possible. Then, the 480 NOTIFY message sent by the master is a small packet that is less 481 likely to load the slave. At last, the AXFR query performed by the 482 slave is a small packet sent over TCP (section 4.2 [RFC5936]) which 483 makes unlikely the slave to perform reflection attacks with a forged 484 NOTIFY. On the other hand, DNS updates can use UDP, packets require 485 more processing then a NOTIFY, and they do not provide the server the 486 opportunity to post-pone the update. 488 5. CPE Configuration 490 5.1. CPE Master / Slave Synchronization Configurations 492 The master / slave architecture is described in 493 [I-D.ietf-homenet-front-end-naming-delegation]. The CPE is 494 configured as a master whereas the DNS Server is configured as a 495 slave. The DNS Server represents the Public Authoritative Name 496 Server Set or the Reverse Public Authoritative Name Server Set. 498 When the CPE is plugged its IP address may be unknown to the slave. 499 The section details how the CPE or master communicate the necessary 500 information to set up the slave. 502 In order to set the master / slave configuration, both master and 503 slaves must agree on 1) the zone to be synchronized, 2) the IP 504 address and ports used by both master and slave. 506 5.1.1. CPE / Public Authoritative Name Server Set 508 The CPE knows the zone to be synchronized by reading the Registered 509 Homenet Domain in the DNS Homenet Zone Template provided by the DHCP 510 Zone Template Option (OPTION_DNS_ZONE_TEMPLATE). The IP address of 511 the slave is provided by the DHCP Public Authoritative Name Server 512 Set Option (OPTION_NAME_SERVER_SET). 514 The Public Authoritative Name Server Set has been configured with the 515 Registered Homenet Domain and the Public Key that identifies the CPE. 516 The only thing missing is the IP address of the CPE. This IP address 517 is provided by the CPE by sending a NOTIFY [RFC1996]. 519 When the CPE has built its DNS Homenet Zone, it sends a NOTIFY 520 message to the Public Authoritative Name Server Sets. Upon receiving 521 the NOTIFY message, the slave reads the Registered Homenet Domain and 522 checks the NOTIFY is sent by the authorized master. This can be done 523 using the shared secret (TSIG) or the public key (SIG(0)). Once the 524 NOTIFY has been authenticated, the Public Authoritative Name Server 525 Sets might consider the source IP address of the NOTIFY query to 526 configure the masters attributes. 528 5.1.2. CPE / Reverse Public Authoritative Name Server Set 530 The CPE knows the zone to be synchronized by looking at its assigned 531 prefix. The IP address of the slave is provided by the DHCP Reverse 532 Public Authoritative Name Server Set Option 533 (OPTION_REVERSE_NAME_SERVER_SET). 535 Configuration of the slave is performed as illustrated in 536 Section 5.1.1. 538 5.2. CPE DNS Data Handling and Update Policies 540 5.2.1. DNS Homenet Zone Template 542 The DNS Homenet Zone Template contains at least the related fields of 543 the Public Authoritative Master(s) as well as the Homenet Registered 544 Domain, that is SOA, and NS fields. This template might be generated 545 automatically by the owner of the DHCP Server. For example, an ISP 546 might provide a default Homenet Registered Domain as well as default 547 Public Authoritative Master(s). This default settings should provide 548 the CPE the necessary pieces of information to set the homenet naming 549 architecture. 551 If the DNS Homenet Zone Template is not subject to modifications or 552 updates, the owner of the template might only use DNSSEC to enable 553 integrity check. 555 The DNS Homenet Zone Template might be subject to modification by the 556 CPE. The advantage of using the standard DNS zone format is that 557 standard DNS update mechanism can be used to perform updates. These 558 updates might be accepted or rejected by the owner of the DNS Homenet 559 Zone Template. Policies that defines what is accepted or rejected is 560 out of scope of this document. However, in this document we assume 561 the Registered Homenet Domain is used as an index by the Public 562 Authoritative Name Server Set, and SIG(0), TSIG are used to 563 authenticate the CPE. As a result, the Registered Homenet Domain 564 should not be modified unless the Public Authoritative Name Server 565 Set can handle with it. 567 5.2.2. DNS (Reverse) Homenet Zone 569 The DNS Homenet Zone might be generated from the DNS Homenet Zone 570 Template. How the DNS Homenet Zone is generated is out of scope of 571 this document. In some cases, the DNS Homenet Zone might be the 572 exact copy of the DNS Homenet Zone Template. In other cases, it 573 might be generated from the DNS Homenet Zone Template with additional 574 RRsets. In some other cases, the DNS Homenet Zone might be generated 575 without considering the DNS Homenet Zone Template, but only 576 considering specific configuration rules. 578 In the current document the CPE only sets a single zone that is 579 associated with one single Homenet Registered Domain. The domain 580 might be assigned by the owner of the DNS Homenet Zone Template. 581 This constrain does not prevent the CPE to use multiple domain names. 582 How additional domains are considered is out of scope of this 583 document. One way to handle these additional zones is to configure 584 static redirections to the DNS Homenet Zone using CNAME [RFC2181], 585 [RFC1034], DNAME [RFC6672] or CNAME+DNAME 586 [I-D.sury-dnsext-cname-dname]. 588 6. Payload Description 590 This section details the payload of the DHCP Options. A few DHCP 591 Options are used to advertise a server the CPE may be expect to 592 interact with. Interaction may require to define how the update is 593 expected to be performed as well as how the communication is secured. 594 Security and Update are shared by multiple DHCP Options and are 595 described in separate sections. Section 6.1 describes the security 596 field, Section 6.2 describes the update fields, the remaining 597 sections Section 6.3, Section 6.4, Section 6.5, Section 6.6 describe 598 the DHCP Options. 600 6.1. Security Field 602 The Security Field of the DHCP Option is represented in Figure 2. It 603 indicates the security mechanism supported by the DNS Server. One of 604 these mechanism MUST be chosen by the CPE in order to perform a 605 transaction with the DNS server. See Section 4.2 for more details. 607 0 1 608 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 609 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 610 | Security | 611 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 613 Figure 2: Security Field 615 - DNS (Bit 0): indicates, when set to 1, that DNS without any 616 security extension is supported. 618 - DNSSEC (Bit 1): indicates, when set to 1, that DNSSEC provides 619 integrity protection. This can only be used for read 620 operations like retrieving the DNS Homenet Zone Template. 622 - SIG(0) (Bit 2): indicates, when set to 1, that transaction 623 protected by SIG(0) are supported. 625 - TSIG (Bit 3): indicates, when set to 1, that transaction using 626 TSIG is supported. Note that if a shared secret has not been 627 previously negotiated between the two party, it should be 628 negotiated using TKEY. The TKEY exchanges MUST be protected 629 with SIG(0) even though SIG(0) is not supported. 631 - Remaining Bits (Bit 4-15): MUST be set to 0 by the DHCP Server 632 and ignored by the DHCP Client. 634 A Security field with all bits set to zero indicates the operation is 635 not permitted. The Security field may be set to zero when updates 636 operations are not permitted for the DNS Homenet Template. In any 637 other case this is an error. 639 6.2. Update Field 641 The Update Field of the DHCP Option is represented in Figure 3. It 642 indicates the update mechanism supported by the DNS server. See 643 Section 4.3 for more details. 645 0 646 0 1 2 3 4 5 6 7 647 +-+-+-+-+-+-+-+-+ 648 | Update | 649 +-+-+-+-+-+-+-+-+ 651 Figure 3: Update Field 653 - Master / Slave (Bit 0): indicates, when set to 1, that DNS Server 654 supports data synchronization using a Master / Slave mechanism. 656 - DNS Update (Bit 1): indicates, when set to 1, that DNS Server 657 supports data synchronization using DNS Updates. 659 - Remaining Bits (Bit 2-7): MUST be set to 0 by the DHCP Server and 660 ignored by the DHCP Client. 662 6.3. DHCP Public Key Option 664 The DHCP Public Key Option (OPTION_PUBLIC_KEY) indicates the Public 665 Key that is used to authenticate the CPE. 667 0 1 2 3 668 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 669 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 670 | OPTION_PUBLIC_KEY | option-len | 671 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 672 | | 673 / Public Key Data / 674 | | 675 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 677 Figure 4: DHCP Public Key Option 679 - OPTION_PUBLIC_KEY (variable): the option code for the DHCP Public 680 Key Option. 682 - option-len (16 bits): length in octets of the option-data field as 683 described in [RFC3315]. 685 - Public Key Data: contains the Public Key. The format is the DNSKEY 686 RDATA format as defined in [RFC4034]. 688 6.4. DHCP Zone Template Option 690 The DHCP Zone Template Option (OPTION_DNS_ZONE_TEMPLATE) Option 691 indicates the CPE how to retrieve the DNS Homenet Zone Template. It 692 provides a FQDN the CPE SHOULD query with a DNS query of type AXFR. 694 The option also specifies which security protocols are available on 695 the authoritative server. DNS Homenet Zone Template update, if 696 permitted MUST use the DNS Update mechanism. 698 0 1 2 3 699 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 700 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 701 | OPTION_DNS_ZONE_TEMPLATE | option-len | 702 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 703 | Security (axfr) | Security | 704 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 705 | | 706 / Zone Template FQDN / 707 | | 708 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 710 Figure 5: DHCP Zone Template Option 712 - OPTION_DNS_ZONE_TEMPLATE (variable): the option code for the DHCP 713 Zone Template Option. 715 - option-len (16 bits): length in octets of the option-data field as 716 described in [RFC3315]. 718 - Security (axfr) (16 bits): defines which security protocols are 719 supported by the DNS server. This field concerns the AXFR and 720 consultation queries, not the update queries. See Section 6.1 721 for more details. 723 - Security (16 bits): defines which security protocols are supported 724 by the DNS server. This field concerns the update. See 725 Section 6.1 for more details. 727 - Zone Template FQDN FQDN (variable): the FQDN of the DNS server 728 hosting the DNS Homenet Zone Template. 730 6.5. DHCP Public Authoritative Name Server Set Option 732 The DHCP Public Authoritative Name Server Set Option 733 (OPTION_NAME_SERVER_SET) provides information so the CPE can upload 734 the DNS Homenet Zone to the Public Authoritative Name Server Set. 735 Finally, the option provides the security mechanisms that are 736 available to perform the upload. The upload is performed via a DNS 737 master / slave architecture or DNS updates. 739 0 1 2 3 740 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 741 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 742 | OPTION_NAME_SERVER_SET | option-len | 743 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 744 | Security | Update | Server / 745 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 746 / Port | | 747 +-+-+-+-+-+-+-+-+-+ | 748 | | 749 / Public Authoritative Name Server Set FQDN / 750 | | 751 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 753 Figure 6: DHCP Public Authoritative Name Server Set Option 755 - OPTION_NAME_SERVER_SET (16 bits): the option code for the DHCP 756 Public Authoritative Name Server Set Option. 758 - option-len (16 bits): length in octets of the option-data field as 759 described in [RFC3315]. 761 - Security (16 bits): defines which security protocols are supported 762 by the DNS server. See Section 6.1 for more details. 764 - Update (8 bits): defines which update mechanisms are supported by 765 the DNS server. See Section 4.3 for more details. 767 - Server Port (16 bits): defines the port the Public Authoritative 768 Name Server Set is listening. 770 - Public Authoritative Name Server Set FQDN (variable): the FQDN of 771 the Public Authoritative Name Server Set. 773 6.6. DHCP Reverse Public Authoritative Name Server Set Option 775 The DHCP Reverse Public Authoritative Name Server Set Option 776 (OPTION_REVERSE_NAME_SERVER_SET) provides information so the CPE can 777 upload the DNS Homenet Zone to the Public Authoritative Name Server 778 Set. The option provides the security mechanisms that are available 779 to perform the upload. The upload is performed via a DNS master / 780 slave architecture or DNS updates. 782 0 1 2 3 783 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 784 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 785 | OPTION_REVERSE_NAME_SERVER_SET| option-len | 786 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 787 | Security | Update | Server / 788 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 789 / Port | | 790 +-+-+-+-+-+-+-+-+-+ | 791 | | 792 / Reverse Public Authoritative Name Server Set FQDN / 793 | | 794 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 796 Figure 7: DHCP Reverse Public Authoritative Name Server Set Option 798 - OPTION_REVERSE_NAME_SERVER_SET (16 bits): the option code for the 799 DHCP Reverse Public Authoritative Name Server Set Option. 801 - option-len (16 bits): length in octets of the option-data field as 802 described in [RFC3315]. 804 - Security (16 bits): defines which security protocols are supported 805 by the DNS server. See Section 6.1 for more details. 807 - Update (8 bits): defines which update mechanisms are supported by 808 the DNS server. See Section 4.3 for more details. 810 - Server Port (16 bits): defines the port the Public Authoritative 811 Name Server Set is listening. 813 - Reverse Public Authoritative Name Server Set FQDN (variable): The 814 FQDN of the Reverse Public Authoritative Name Server Set. 816 7. DHCP Behavior 818 7.1. DHCPv6 Server Behavior 820 The DHCP Server sends the DHCP Zone Template Option 821 (OPTION_DNS_ZONE_TEMPLATE), DHCP Public Authoritative Name Server Set 822 Option (OPTION_NAME_SERVER_SET), DHCP Reverse Public Authoritative 823 Name Server Set Option (OPTION_REVERSE_NAME_SERVER_SET) upon request 824 by the DHCP Client. 826 The DHCP Server MAY receive a DHCP Public Key Option 827 (OPTION_PUBLIC_KEY) from the CPE. Upon receipt of this DHCP Option, 828 the DHCP Sever is expect to communicate this credential to the 829 available DNS Servers like the DNS Template Server, the Public 830 Authoritative Name Server Set and the Reverse Public Authoritative 831 Name Server Set. 833 7.2. DHCPv6 Client Behavior 835 The DHCP Client MAY send a DHCP Public Key Option (OPTION_PUBLIC_KEY) 836 to the DHCP Server. This Public Key authenticates the CPE. 838 The DHCP Client sends a DHCP Option Request Option (ORO) with the 839 necessary DHCP options. 841 A CPE SHOULD only send the an ORO request for DHCP Options it needs 842 or for information that needs to be up-to-date. 844 Upon receiving a DHCP option described in this document, the CPE 845 SHOULD retrieve or update DNS zones using the associated security and 846 update protocols. 848 7.3. DHCPv6 Relay Behavior 850 DHCP Relay behavior are not modified by this document. 852 8. IANA Considerations 854 The DHCP options detailed in this document is: 856 - OPTION_DNS_ZONE_TEMPLATE: TBD 858 - OPTION_NAME_SERVER_SET: TBD 860 - OPTION_REVERSE_NAME_SERVER_SET: TBD 862 - OPTION_PUBLIC_KEY: TBD 864 9. Security Considerations 866 9.1. DNSSEC is recommended to authenticate DNS hosted data 868 It is recommended that the (Reverse) DNS Homenet Zone is signed with 869 DNSSEC. The zone may be signed by the CPE or by a third party. We 870 recommend the zone to be signed by the CPE, and that the signed zone 871 is uploaded. 873 9.2. Channel between the CPE and ISP DHCP Server MUST be secured 875 The document considers that the channel between the CPE and the ISP 876 DHCP Server is trusted. More specifically, the CPE is authenticated 877 and the exchanged messages are protected. The current document does 878 not specify how to secure the channel. [RFC3315] proposes a DHCP 879 authentication and message exchange protection, [RFC4301], [RFC7296] 880 propose to secure the channel at the IP layer. 882 In fact, the channel MUST be secured because the CPE provides 883 authentication credentials. Unsecured channel may result in CPE 884 impersonation attacks. 886 9.3. CPEs are sensitive to DoS 888 CPE have not been designed for handling heavy load. The CPE are 889 exposed on the Internet, and their IP address is publicly published 890 on the Internet via the DNS. This makes the Home Network sensitive 891 to Deny of Service Attacks. The resulting outsourcing architecture 892 is described in [I-D.ietf-homenet-front-end-naming-delegation]. This 893 document shows how the outsourcing architecture can be automatically 894 set. 896 10. Acknowledgment 898 We would like to thank Tomasz Mrugalski, Marcin Siodelski and Bernie 899 Volz for their comments on the design of the DHCP Options. We would 900 also like to thank Mark Andrews, Andrew Sullivan and Lorenzo Colliti 901 for their remarks on the architecture design. The designed solution 902 has been largely been inspired by Mark Andrews's document 903 [I-D.andrews-dnsop-pd-reverse] as well as discussions with Mark. 905 11. References 907 11.1. Normative References 909 [RFC1034] Mockapetris, P., "Domain names - concepts and facilities", 910 STD 13, RFC 1034, November 1987. 912 [RFC1996] Vixie, P., "A Mechanism for Prompt Notification of Zone 913 Changes (DNS NOTIFY)", RFC 1996, August 1996. 915 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 916 Requirement Levels", BCP 14, RFC 2119, March 1997. 918 [RFC2136] Vixie, P., Thomson, S., Rekhter, Y., and J. Bound, 919 "Dynamic Updates in the Domain Name System (DNS UPDATE)", 920 RFC 2136, April 1997. 922 [RFC2181] Elz, R. and R. Bush, "Clarifications to the DNS 923 Specification", RFC 2181, July 1997. 925 [RFC2845] Vixie, P., Gudmundsson, O., Eastlake, D., and B. 926 Wellington, "Secret Key Transaction Authentication for DNS 927 (TSIG)", RFC 2845, May 2000. 929 [RFC2930] Eastlake, D., "Secret Key Establishment for DNS (TKEY 930 RR)", RFC 2930, September 2000. 932 [RFC2931] Eastlake, D., "DNS Request and Transaction Signatures ( 933 SIG(0)s)", RFC 2931, September 2000. 935 [RFC3007] Wellington, B., "Secure Domain Name System (DNS) Dynamic 936 Update", RFC 3007, November 2000. 938 [RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., 939 and M. Carney, "Dynamic Host Configuration Protocol for 940 IPv6 (DHCPv6)", RFC 3315, July 2003. 942 [RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S. 943 Rose, "DNS Security Introduction and Requirements", RFC 944 4033, March 2005. 946 [RFC4034] Arends, R., Austein, R., Larson, M., Massey, D., and S. 947 Rose, "Resource Records for the DNS Security Extensions", 948 RFC 4034, March 2005. 950 [RFC4035] Arends, R., Austein, R., Larson, M., Massey, D., and S. 951 Rose, "Protocol Modifications for the DNS Security 952 Extensions", RFC 4035, March 2005. 954 [RFC4301] Kent, S. and K. Seo, "Security Architecture for the 955 Internet Protocol", RFC 4301, December 2005. 957 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 958 (TLS) Protocol Version 1.2", RFC 5246, August 2008. 960 [RFC5936] Lewis, E. and A. Hoenes, "DNS Zone Transfer Protocol 961 (AXFR)", RFC 5936, June 2010. 963 [RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer 964 Security Version 1.2", RFC 6347, January 2012. 966 [RFC6672] Rose, S. and W. Wijngaards, "DNAME Redirection in the 967 DNS", RFC 6672, June 2012. 969 [RFC7296] Kaufman, C., Hoffman, P., Nir, Y., Eronen, P., and T. 970 Kivinen, "Internet Key Exchange Protocol Version 2 971 (IKEv2)", STD 79, RFC 7296, October 2014. 973 11.2. Informational References 975 [I-D.andrews-dnsop-pd-reverse] 976 Andrews, M., "Automated Delegation of IP6.ARPA reverse 977 zones with Prefix Delegation", draft-andrews-dnsop-pd- 978 reverse-02 (work in progress), November 2013. 980 [I-D.ietf-homenet-front-end-naming-delegation] 981 Migault, D., Cloetens, W., Griffiths, C., and R. Weber, 982 "Outsourcing Home Network Authoritative Naming Service", 983 draft-ietf-homenet-front-end-naming-delegation-00 (work in 984 progress), September 2014. 986 [I-D.sury-dnsext-cname-dname] 987 Sury, O., "CNAME+DNAME Name Redirection", draft-sury- 988 dnsext-cname-dname-00 (work in progress), April 2010. 990 Appendix A. Scenarios and impact on the End User 992 This section details various scenarios and discuss their impact on 993 the end user. 995 A.1. Base Scenario 997 The base scenario is the one described in Section 4. It is typically 998 the one of an ISP that manages the DHCP Server, and all DNS servers. 1000 The end user subscribes to the ISP (foo), and at subscription time 1001 registers for example.foo as its Registered Homenet Domain 1002 example.foo. Since the ISP knows the Registered Homenet Domain and 1003 the Public Authoritative Master(s) the ISP is able to build the DNS 1004 Homenet Zone Template. 1006 The ISP manages the DNS Template Server, so it is able to load the 1007 DNS Homenet Zone Template on the DNS Template Server. 1009 When the CPE is plugged (at least the first time), it provides its 1010 Public Key to the DHCP Server. In this scenario, the DHCP Server and 1011 the DNS Servers are managed by the ISP so the DHCP Server can provide 1012 authentication credentials of the CPE to enable secure authenticated 1013 transaction between the CPE and these DNS servers. More 1014 specifically, credentials are provided to: 1016 - Public Authoritative Name Server Set 1018 - Reverse Public Authoritative Name Server Set 1020 - DNS Template Server 1021 The CPE can update the zone using DNS update or a master / slave 1022 configuration in a secure way. 1024 The main advantage of this scenario is that the naming architecture 1025 is configured automatically and transparently for the end user. 1027 The drawbacks are that the end user uses a Registered Homenet Domain 1028 managed by the ISP and that it relies on the ISP naming 1029 infrastructure. 1031 A.2. Third Party Registered Homenet Domain 1033 This section considers the case when the end user wants its home 1034 network to use example.com as a Registered Homenet Domain instead of 1035 example.foo that has been assigned by the ISP. We also suppose that 1036 example.com is not managed by the ISP. 1038 This can also be achieved without any configuration. When the end 1039 user buys the domain name example.com, it may request to redirect the 1040 name example.com to example.foo using static redirection with CNAME 1041 [RFC2181], [RFC1034], DNAME [RFC6672] or CNAME+DNAME 1042 [I-D.sury-dnsext-cname-dname]. 1044 This configuration is performed once when the domain name example.com 1045 is registered. The only information the end user needs to know is 1046 the domain name assigned by the ISP. Once this configuration is done 1047 no additional configuration is needed anymore. More specifically, 1048 the CPE may be changed, the zone can be updated as in Appendix A.1 1049 without any additional configuration from the end user. 1051 The main advantage of this scenario is that the end user benefits 1052 from the Zero Configuration of the Base Scenario Appendix A.1. Then, 1053 the end user is able to register for its home network an unlimited 1054 number of domain names provided by an unlimited number of different 1055 third party providers. 1057 The drawback of this scenario may be that the end user still rely on 1058 the ISP naming infrastructure. Note that the only case this may be 1059 inconvenient is when the DNS Servers provided by the ISPs results in 1060 high latency. 1062 A.3. Third Party DNS Infrastructure 1064 This scenario considers that the end user uses example.com as a 1065 Registered Homenet Domain, and does not want to rely on the 1066 authoritative servers provided by the ISP. 1068 In this section we limit the outsourcing to the Public Authoritative 1069 Name Server Set and Public Authoritative Master(s) to a third party. 1070 All other DNS Servers DNS Template Server, Reverse Public 1071 Authoritative Master(s) and Reverse Public Authoritative Name Server 1072 Set remain managed by the ISP. The reason we consider that Reverse 1073 Public Authoritative Masters(s) and Reverse Public Authoritative Name 1074 Server Set remains managed by the ISP are that the prefix is managed 1075 by the ISP, so outsourcing these resources requires some redirection 1076 agreement with the ISP. More specifically the ISP will need to 1077 configure the redirection on one of its Reverse DNS Servers. That 1078 said, outsourcing these resources is similar as outsourcing Public 1079 Authoritative Name Server Set and Public Authoritative Master(s) to a 1080 third party. Similarly, the DNS Template Server can be easily 1081 outsourced as detailed in this section 1083 Outsourcing Public Authoritative Name Server Set and Public 1084 Authoritative Master(s) requires: 1086 - 1) Updating the DNS Homenet Zone Template: this can be easily done 1087 as detailed in Section 4.3 as the DNS Template Server is still 1088 managed by the ISP. Such modification can be performed once by 1089 any CPE. Once this modification has been performed, the CPE 1090 can be changed, the Public Key of the CPE may be changed, this 1091 does not need to be done another time. One can imagine a GUI 1092 on the CPE asking the end user to fill the field with 1093 Registered Homenet Domain, optionally Public Authoritative 1094 Master(s), with a button "Configure DNS Homenet Zone Template". 1096 - 2) Updating the DHCP Server Information. In fact the Reverse 1097 Public Authoritative Name Server Set returned by the ISP is 1098 modified. One can imagine a GUI interface that enables the end 1099 user to modify its profile parameters. Again, this 1100 configuration update is done once-for-ever. 1102 - 3) Upload the authentication credential of the CPE, that is the 1103 Public Key of the CPE, to the third party. Unless we use 1104 specific mechanisms, like communication between the DHCP Server 1105 and the third party, or a specific token that is plugged into 1106 the CPE, this operation is likely to be performed every time 1107 the CPE is changed, and every time the Public Key generated by 1108 the CPE is changed. 1110 The main advantage of this scenario is that the DNS infrastructure is 1111 completely outsourced to the third party. Most likely the Public Key 1112 that authenticate the CPE need to be configured for every CPE. 1113 Configuration is expected to be CPE live-long. 1115 A.4. Multiple ISPs 1117 This scenario considers a CPE connected to multiple ISPs. 1119 Firstly, suppose the CPE has been configured with the based scenarios 1120 exposed in Appendix A.1. The CPE has multiple interfaces, one for 1121 each ISP, and each of these interface is configured using DHCP. The 1122 CPE sends to each ISP its DHCP Public Key Option as well as a request 1123 for a DHCP Zone Template Option, a DHCP Public Authoritative Name 1124 Server Set Option and a DHCP Reverse Public Authoritative Name Server 1125 Set Option. Each ISP provides the requested DHCP options, with 1126 different values. Note that this scenario assumes, the home network 1127 has a different Registered Homenet Domain for each ISP as it is 1128 managed by the ISP. On the other hand, the CPE Public Key may be 1129 shared between the CPE and the multiple ISPs. The CPE builds the 1130 associate DNS(SEC) Homenet Zone, and proceeds to the various settings 1131 as described in Appendix A.1. 1133 The protocol and DHCP Options described in this document are fully 1134 compatible with a CPE connected to multiple ISPs with multiple 1135 Registered Homenet Domains. However, the CPE should be able to 1136 handle different Registered Homenet Domains. This is an 1137 implementation issue which is outside the scope of the current 1138 document. More specifically, multiple Registered Homenet Domains 1139 leads to multiple DNS(SEC) Homenet Zones. A basic implementation may 1140 erase the DNS(SEC) Homenet Zone that exists when it receives DHCP 1141 Options, and rebuild everything from scratch. This will work for an 1142 initial configuration but comes with a few drawbacks. First, updates 1143 to the DNS(SEC) Homenet Zone may only push to one of the multiple 1144 Registered Homenet Domain, the latest Registered Homenet Domain that 1145 has been set, and this is most likely expected to be almost randomly 1146 chosen as it may depend on the latency on each ISP network at the 1147 boot time. As a results, this leads to unsynchronized Registered 1148 Homenet Domains. Secondly, if the CPE handles in some ways 1149 resolution, only the latest Registered Homenet Domain set may be able 1150 to provide naming resolution in case of network disruption. 1152 Secondly, suppose the CPE is connected to multiple ISP with a single 1153 Registered Homenet Domain. In this case, the one party is chosen to 1154 host the Registered Homenet Domain. This entity may be one of the 1155 ISP or a third party. Note that having multiple ISPs can be 1156 motivated for bandwidth aggregation, or connectivity fail-over. In 1157 the case of connectivity fail-over, the fail-over concerns the access 1158 network and a failure of the access network may not impact the core 1159 network where the Public Authoritative Name Server Set and Public 1160 Masters are hosted. In that sense, choosing one of the ISP even in a 1161 scenario of multiple ISPs may make sense. However, for sake of 1162 simplicity, this scenario assumes that a third party has be chosen to 1163 host the Registered Homenet Domain. The DNS settings for each ISP is 1164 described in Appendix A.2 and Appendix A.3. With the configuration 1165 described in Appendix A.2, the CPE is expect to be able to handle 1166 multiple Homenet Registered Domain, as the third party redirect to 1167 one of the ISPs Servers. With the configuration described in 1168 Appendix A.3, DNS zone are hosted and maintained by the third party. 1169 A single DNS(SEC) Homenet Zone is built and maintained by the CPE. 1170 This latter configuration is likely to match most CPE 1171 implementations. 1173 The protocol and DHCP Options described in this document are fully 1174 compatible with a CPE connected to multiple ISPs. To configure or 1175 not and how to configure the CPE depends on the CPE facilities. 1176 Appendix A.1 and Appendix A.2 require the CPE to handle multiple 1177 Registered Homenet Domain, whereas Appendix A.3 does not have such 1178 requirement. 1180 Appendix B. Document Change Log 1182 [RFC Editor: This section is to be removed before publication] 1184 -04: Working Version Major modifications are: 1186 - Re-structuring the draft: description and comparison of update and 1187 security mechanisms have been intergrated into the Overview 1188 section. a Configuration section has been created to describe 1189 both configuration and corresponding behavior of the CPE. 1191 - Adding Ports parameters: Server Set can configure a port. The 1192 Port Server parameter have been added in the DHCP Option 1193 payloads because middle boxes may not be configured to let port 1194 53 packets and it may also be useful to split servers among 1195 different ports, assigning each end user a different port. 1197 - Multiple ISP scenario: In order to address comments, the multiple 1198 ISPs scenario has been described to explicitly show that the 1199 protocol and DHCP Options do not prevent a CPE connected to 1200 multiple independent ISPs. 1202 -03: Working Version Major modifications are: 1204 - Redesigning options/scope: according to feed backs received from 1205 the IETF89 presentation in the dhc WG. 1207 - Redesigning architecture: according to feed backs received from 1208 the IETF89 presentation in the homenet WG, discussion with Mark 1209 and Lorenzo. 1211 -02: Working Version Major modifications are: 1213 - Redesigning options/scope: As suggested by Bernie Volz 1215 -01: Working Version Major modifications are: 1217 - Remove the DNS Zone file construction: As suggested by Bernie Volz 1219 - DHCPv6 Client behavior: Following options guide lines 1221 - DHCPv6 Server behavior: Following options guide lines 1223 -00: version published in the homenet WG. Major modifications are: 1225 - Reformatting of DHCP Options: Following options guide lines 1227 - DHCPv6 Client behavior: Following options guide lines 1229 - DHCPv6 Server behavior: Following options guide lines 1231 -00: First version published in dhc WG. 1233 Authors' Addresses 1235 Daniel Migault 1236 Ericsson 1237 8400 boulevard Decarie 1238 Montreal, QC H4P 2N2 1239 Canada 1241 Email: mglt.ietf@gmail.com 1243 Wouter Cloetens 1244 SoftAtHome 1245 vaartdijk 3 701 1246 3018 Wijgmaal 1247 Belgium 1249 Email: wouter.cloetens@softathome.com 1250 Chris Griffiths 1251 Dyn 1252 150 Dow Street 1253 Manchester, NH 03101 1254 US 1256 Email: cgriffiths@dyn.com 1257 URI: http://dyn.com 1259 Ralf Weber 1260 Nominum 1261 2000 Seaport Blvd #400 1262 Redwood City, CA 94063 1263 US 1265 Email: ralf.weber@nominum.com 1266 URI: http://www.nominum.com