idnits 2.17.1 draft-ietf-homenet-naming-architecture-dhc-options-02.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 (May 19, 2015) is 3258 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-02 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: November 20, 2015 SoftAtHome 6 C. Griffiths 7 Dyn 8 R. Weber 9 Nominum 10 May 19, 2015 12 DHCP Options for Homenet Naming Architecture 13 draft-ietf-homenet-naming-architecture-dhc-options-02.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 November 20, 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. Primary / Secondary Synchronization versus DNS Update . . 11 74 5. CPE Configuration . . . . . . . . . . . . . . . . . . . . . . 11 75 5.1. CPE Primary / Secondary 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 . . . . . . . . . . . . . . . . 16 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 primary / secondary architecture. The 139 Public 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 Primary(ies): 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 primary 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 159 secondary and the CPE acts as primary. The CPE sends 160 information so the DNSSEC zone can be set and served. 162 - Reverse Public Authoritative Primary(ies): 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 primary 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 secondary and the CPE acts as primary. 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 Primary(ies) 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 Primary(ies). 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 Primary(ies). 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 Primary(ies), 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 primary/secondary synchronization). Which security mechanism to use 406 to 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 primary/secondary synchronization 415 mechanisms. 417 4.2. Mechanisms Securing DNS Transactions 419 Multiple protocols like IPsec [RFC4301] or TLS / DTLS [RFC5246] / 420 [RFC6347] may be used to secure DNS transactions between the CPE and 421 the DNS servers. This document restricts the scope of security 422 protocols to those that have been designed specifically for DNS. 423 This includes DNSSEC [RFC4033], [RFC4034], [RFC4035] that 424 authenticates and provides integrity protection of DNS data, TSIG 425 [RFC2845], [RFC2930] that use a shared secret to secure a transaction 426 between two end points and SIG(0) [RFC2931] authenticates the DNS 427 packet exchanged. 429 The key issue with TSIG is that a shared secret must be negotiated 430 between the CPE and the server. On the other hand, TSIG performs 431 symmetric cryptography which is light in comparison with asymmetric 432 cryptography used by SIG(0). As a result, over large zone transfer, 433 TSIG may be preferred to SIG(0). 435 This document does not provides means to distribute shared secret for 436 example using a specific DHCP Option. The only assumption made is 437 that the CPE generates or is assigned a public key. 439 As a result, when the document specifies the transaction is secured 440 with TSIG, it means that either the CPE and the DNS Server have been 441 manually configured with a shared secret, or the shared secret has 442 been negotiated using TKEY [RFC2930], and the TKEY exchanged are 443 secured with SIG(0). 445 Exchange with the DNS Template Server to retrieve the DNS Homenet 446 Zone Template may be protected by SIG(0), TSIG or DNSSEC. When 447 DNSSEC is used, it means the DNS Template Server only provides 448 integrity protection, and does not necessarily prevents someone else 449 to query the DNS Homenet Zone Template. In addition, DNSSEC is only 450 a way to protect the AXFR queries transaction, in other words, DNSSEC 451 cannot be used to secure updates. If DNSSEC is used to provide 452 integrity protection for the AXFR response, the CPE should proceed to 453 the DNSSEC signature checks. If signature check fails, it MUST 454 reject the response. If the signature check succeeds, the CPE 455 removes all DNSSEC related RRsets (DNSKEY, RRSIG, NSEC* ...) before 456 building the DNS Homenet Zone. In fact, these DNSSEC related fields 457 are associated to the DNS Homenet Zone Template and not the DNS 458 Homenet Zone. 460 Any update exchange should use SIG(0) or TSIG to authenticate the 461 exchange. 463 4.3. Primary / Secondary Synchronization versus DNS Update 465 As updates only concern DNS zones, this document only considers DNS 466 update mechanisms such as DNS update [RFC2136] [RFC3007] or a 467 primary / secondary synchronization. 469 The DNS Homenet Zone Template can only be updated with DNS update. 470 The reason is that the DNS Homenet Zone Template contains static 471 configuration data that is not expected to evolve over time. 473 The DNS Homenet Reverse Zone and the DNS Homenet Zone can be updated 474 either with DNS update or using a primary / secondary 475 synchronization. As these zones may be large, with frequent updates, 476 we recommend to use the primary / secondary architecture as described 477 in [I-D.ietf-homenet-front-end-naming-delegation]. The primary / 478 secondary mechanism is preferred as it better scales and avoids DoS 479 attacks: First the primary notifies the secondary the zone must be 480 updated, and leaves the secondary to proceed to the update when 481 possible. Then, the NOTIFY message sent by the primary is a small 482 packet that is less likely to load the secondary. At last, the AXFR 483 query performed by the secondary is a small packet sent over TCP 484 (section 4.2 [RFC5936]) which makes unlikely the secondary to perform 485 reflection attacks with a forged NOTIFY. On the other hand, DNS 486 updates can use UDP, packets require more processing then a NOTIFY, 487 and they do not provide the server the opportunity to post-pone the 488 update. 490 5. CPE Configuration 492 5.1. CPE Primary / Secondary Synchronization Configurations 494 The primary / secondary architecture is described in 495 [I-D.ietf-homenet-front-end-naming-delegation]. The CPE is 496 configured as a primary whereas the DNS Server is configured as a 497 secondary. The DNS Server represents the Public Authoritative Name 498 Server Set or the Reverse Public Authoritative Name Server Set. 500 When the CPE is plugged its IP address may be unknown to the 501 secondary. The section details how the CPE or primary communicate 502 the necessary information to set up the secondary. 504 In order to set the primary / secondary configuration, both primary 505 and secondaries must agree on 1) the zone to be synchronized, 2) the 506 IP address and ports used by both primary and secondary. 508 5.1.1. CPE / Public Authoritative Name Server Set 510 The CPE knows the zone to be synchronized by reading the Registered 511 Homenet Domain in the DNS Homenet Zone Template provided by the DHCP 512 Zone Template Option (OPTION_DNS_ZONE_TEMPLATE). The IP address of 513 the secondary is provided by the DHCP Public Authoritative Name 514 Server Set Option (OPTION_NAME_SERVER_SET). 516 The Public Authoritative Name Server Set has been configured with the 517 Registered Homenet Domain and the Public Key that identifies the CPE. 518 The only thing missing is the IP address of the CPE. This IP address 519 is provided by the CPE by sending a NOTIFY [RFC1996]. 521 When the CPE has built its DNS Homenet Zone, it sends a NOTIFY 522 message to the Public Authoritative Name Server Sets. Upon receiving 523 the NOTIFY message, the secondary reads the Registered Homenet Domain 524 and checks the NOTIFY is sent by the authorized primary. This can be 525 done using the shared secret (TSIG) or the public key (SIG(0)). Once 526 the NOTIFY has been authenticated, the Public Authoritative Name 527 Server Sets might consider the source IP address of the NOTIFY query 528 to configure the primaries attributes. 530 5.1.2. CPE / Reverse Public Authoritative Name Server Set 532 The CPE knows the zone to be synchronized by looking at its assigned 533 prefix. The IP address of the secondary is provided by the DHCP 534 Reverse Public Authoritative Name Server Set Option 535 (OPTION_REVERSE_NAME_SERVER_SET). 537 Configuration of the secondary is performed as illustrated in 538 Section 5.1.1. 540 5.2. CPE DNS Data Handling and Update Policies 542 5.2.1. DNS Homenet Zone Template 544 The DNS Homenet Zone Template contains at least the related fields of 545 the Public Authoritative Primary(ies) as well as the Homenet 546 Registered Domain, that is SOA, and NS fields. This template might 547 be generated automatically by the owner of the DHCP Server. For 548 example, an ISP might provide a default Homenet Registered Domain as 549 well as default Public Authoritative Primary(ies). This default 550 settings should provide the CPE the necessary pieces of information 551 to set the homenet naming architecture. 553 If the DNS Homenet Zone Template is not subject to modifications or 554 updates, the owner of the template might only use DNSSEC to enable 555 integrity check. 557 The DNS Homenet Zone Template might be subject to modification by the 558 CPE. The advantage of using the standard DNS zone format is that 559 standard DNS update mechanism can be used to perform updates. These 560 updates might be accepted or rejected by the owner of the DNS Homenet 561 Zone Template. Policies that defines what is accepted or rejected is 562 out of scope of this document. However, in this document we assume 563 the Registered Homenet Domain is used as an index by the Public 564 Authoritative Name Server Set, and SIG(0), TSIG are used to 565 authenticate the CPE. As a result, the Registered Homenet Domain 566 should not be modified unless the Public Authoritative Name Server 567 Set can handle with it. 569 5.2.2. DNS (Reverse) Homenet Zone 571 The DNS Homenet Zone might be generated from the DNS Homenet Zone 572 Template. How the DNS Homenet Zone is generated is out of scope of 573 this document. In some cases, the DNS Homenet Zone might be the 574 exact copy of the DNS Homenet Zone Template. In other cases, it 575 might be generated from the DNS Homenet Zone Template with additional 576 RRsets. In some other cases, the DNS Homenet Zone might be generated 577 without considering the DNS Homenet Zone Template, but only 578 considering specific configuration rules. 580 In the current document the CPE only sets a single zone that is 581 associated with one single Homenet Registered Domain. The domain 582 might be assigned by the owner of the DNS Homenet Zone Template. 583 This constrain does not prevent the CPE to use multiple domain names. 584 How additional domains are considered is out of scope of this 585 document. One way to handle these additional zones is to configure 586 static redirections to the DNS Homenet Zone using CNAME [RFC2181], 587 [RFC1034], DNAME [RFC6672] or CNAME+DNAME 588 [I-D.sury-dnsext-cname-dname]. 590 6. Payload Description 592 This section details the payload of the DHCP Options. A few DHCP 593 Options are used to advertise a server the CPE may be expect to 594 interact with. Interaction may require to define how the update is 595 expected to be performed as well as how the communication is secured. 596 Security and Update are shared by multiple DHCP Options and are 597 described in separate sections. Section 6.1 describes the security 598 field, Section 6.2 describes the update fields, the remaining 599 sections Section 6.3, Section 6.4, Section 6.5, Section 6.6 describe 600 the DHCP Options. 602 6.1. Security Field 604 The Security Field of the DHCP Option is represented in Figure 2. It 605 indicates the security mechanism supported by the DNS Server. One of 606 these mechanism MUST be chosen by the CPE in order to perform a 607 transaction with the DNS server. See Section 4.2 for more details. 609 0 1 610 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 611 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 612 | Security | 613 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 615 Figure 2: Security Field 617 - DNS (Bit 0): indicates, when set to 1, that DNS without any 618 security extension is supported. 620 - DNSSEC (Bit 1): indicates, when set to 1, that DNSSEC provides 621 integrity protection. This can only be used for read 622 operations like retrieving the DNS Homenet Zone Template. 624 - SIG(0) (Bit 2): indicates, when set to 1, that transaction 625 protected by SIG(0) are supported. 627 - TSIG (Bit 3): indicates, when set to 1, that transaction using 628 TSIG is supported. Note that if a shared secret has not been 629 previously negotiated between the two party, it should be 630 negotiated using TKEY. The TKEY exchanges MUST be protected 631 with SIG(0) even though SIG(0) is not supported. 633 - Remaining Bits (Bit 4-15): MUST be set to 0 by the DHCP Server 634 and ignored by the DHCP Client. 636 A Security field with all bits set to zero indicates the operation is 637 not permitted. The Security field may be set to zero when updates 638 operations are not permitted for the DNS Homenet Template. In any 639 other case this is an error. 641 6.2. Update Field 643 The Update Field of the DHCP Option is represented in Figure 3. It 644 indicates the update mechanism supported by the DNS server. See 645 Section 4.3 for more details. 647 0 648 0 1 2 3 4 5 6 7 649 +-+-+-+-+-+-+-+-+ 650 | Update | 651 +-+-+-+-+-+-+-+-+ 653 Figure 3: Update Field 655 - Primary / Secondary (Bit 0): indicates, when set to 1, that DNS 656 Server supports data synchronization using a Primary / 657 Secondary mechanism. 659 - DNS Update (Bit 1): indicates, when set to 1, that DNS Server 660 supports data synchronization using DNS Updates. 662 - Remaining Bits (Bit 2-7): MUST be set to 0 by the DHCP Server and 663 ignored by the DHCP Client. 665 6.3. DHCP Public Key Option 667 The DHCP Public Key Option (OPTION_PUBLIC_KEY) indicates the Public 668 Key that is used to authenticate the CPE. 670 0 1 2 3 671 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 672 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 673 | OPTION_PUBLIC_KEY | option-len | 674 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 675 | | 676 / Public Key Data / 677 | | 678 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 680 Figure 4: DHCP Public Key Option 682 - OPTION_PUBLIC_KEY (variable): the option code for the DHCP Public 683 Key Option. 685 - option-len (16 bits): length in octets of the option-data field as 686 described in [RFC3315]. 688 - Public Key Data: contains the Public Key. The format is the DNSKEY 689 RDATA format as defined in [RFC4034]. 691 6.4. DHCP Zone Template Option 693 The DHCP Zone Template Option (OPTION_DNS_ZONE_TEMPLATE) Option 694 indicates the CPE how to retrieve the DNS Homenet Zone Template. It 695 provides a FQDN the CPE SHOULD query with a DNS query of type AXFR. 696 The option also specifies which security protocols are available on 697 the authoritative server. DNS Homenet Zone Template update, if 698 permitted MUST use the DNS Update mechanism. 700 0 1 2 3 701 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 702 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 703 | OPTION_DNS_ZONE_TEMPLATE | option-len | 704 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 705 | Security (axfr) | Security | 706 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 707 | | 708 / Zone Template FQDN / 709 | | 710 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 712 Figure 5: DHCP Zone Template Option 714 - OPTION_DNS_ZONE_TEMPLATE (variable): the option code for the DHCP 715 Zone Template Option. 717 - option-len (16 bits): length in octets of the option-data field as 718 described in [RFC3315]. 720 - Security (axfr) (16 bits): defines which security protocols are 721 supported by the DNS server. This field concerns the AXFR and 722 consultation queries, not the update queries. See Section 6.1 723 for more details. 725 - Security (16 bits): defines which security protocols are supported 726 by the DNS server. This field concerns the update. See 727 Section 6.1 for more details. 729 - Zone Template FQDN FQDN (variable): the FQDN of the DNS server 730 hosting the DNS Homenet Zone Template. 732 6.5. DHCP Public Authoritative Name Server Set Option 734 The DHCP Public Authoritative Name Server Set Option 735 (OPTION_NAME_SERVER_SET) provides information so the CPE can upload 736 the DNS Homenet Zone to the Public Authoritative Name Server Set. 737 Finally, the option provides the security mechanisms that are 738 available to perform the upload. The upload is performed via a DNS 739 primary / secondary architecture or DNS updates. 741 0 1 2 3 742 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 743 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 744 | OPTION_NAME_SERVER_SET | option-len | 745 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 746 | Security | Update | Server / 747 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 748 / Port | | 749 +-+-+-+-+-+-+-+-+-+ | 750 | | 751 / Public Authoritative Name Server Set FQDN / 752 | | 753 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 755 Figure 6: DHCP Public Authoritative Name Server Set Option 757 - OPTION_NAME_SERVER_SET (16 bits): the option code for the DHCP 758 Public Authoritative Name Server Set Option. 760 - option-len (16 bits): length in octets of the option-data field as 761 described in [RFC3315]. 763 - Security (16 bits): defines which security protocols are supported 764 by the DNS server. See Section 6.1 for more details. 766 - Update (8 bits): defines which update mechanisms are supported by 767 the DNS server. See Section 4.3 for more details. 769 - Server Port (16 bits): defines the port the Public Authoritative 770 Name Server Set is listening. 772 - Public Authoritative Name Server Set FQDN (variable): the FQDN of 773 the Public Authoritative Name Server Set. 775 6.6. DHCP Reverse Public Authoritative Name Server Set Option 777 The DHCP Reverse Public Authoritative Name Server Set Option 778 (OPTION_REVERSE_NAME_SERVER_SET) provides information so the CPE can 779 upload the DNS Homenet Zone to the Public Authoritative Name Server 780 Set. The option provides the security mechanisms that are available 781 to perform the upload. The upload is performed via a DNS primary / 782 secondary architecture or DNS updates. 784 0 1 2 3 785 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 786 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 787 | OPTION_REVERSE_NAME_SERVER_SET| option-len | 788 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 789 | Security | Update | Server / 790 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 791 / Port | | 792 +-+-+-+-+-+-+-+-+-+ | 793 | | 794 / Reverse Public Authoritative Name Server Set FQDN / 795 | | 796 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 798 Figure 7: DHCP Reverse Public Authoritative Name Server Set Option 800 - OPTION_REVERSE_NAME_SERVER_SET (16 bits): the option code for the 801 DHCP Reverse Public Authoritative Name Server Set Option. 803 - option-len (16 bits): length in octets of the option-data field as 804 described in [RFC3315]. 806 - Security (16 bits): defines which security protocols are supported 807 by the DNS server. See Section 6.1 for more details. 809 - Update (8 bits): defines which update mechanisms are supported by 810 the DNS server. See Section 4.3 for more details. 812 - Server Port (16 bits): defines the port the Public Authoritative 813 Name Server Set is listening. 815 - Reverse Public Authoritative Name Server Set FQDN (variable): The 816 FQDN of the Reverse Public Authoritative Name Server Set. 818 7. DHCP Behavior 820 7.1. DHCPv6 Server Behavior 822 The DHCP Server sends the DHCP Zone Template Option 823 (OPTION_DNS_ZONE_TEMPLATE), DHCP Public Authoritative Name Server Set 824 Option (OPTION_NAME_SERVER_SET), DHCP Reverse Public Authoritative 825 Name Server Set Option (OPTION_REVERSE_NAME_SERVER_SET) upon request 826 by the DHCP Client. 828 The DHCP Server MAY receive a DHCP Public Key Option 829 (OPTION_PUBLIC_KEY) from the CPE. Upon receipt of this DHCP Option, 830 the DHCP Sever is expect to communicate this credential to the 831 available DNS Servers like the DNS Template Server, the Public 832 Authoritative Name Server Set and the Reverse Public Authoritative 833 Name Server Set. 835 7.2. DHCPv6 Client Behavior 837 The DHCP Client MAY send a DHCP Public Key Option (OPTION_PUBLIC_KEY) 838 to the DHCP Server. This Public Key authenticates the CPE. 840 The DHCP Client sends a DHCP Option Request Option (ORO) with the 841 necessary DHCP options. 843 A CPE SHOULD only send the an ORO request for DHCP Options it needs 844 or for information that needs to be up-to-date. 846 Upon receiving a DHCP option described in this document, the CPE 847 SHOULD retrieve or update DNS zones using the associated security and 848 update protocols. 850 7.3. DHCPv6 Relay Behavior 852 DHCP Relay behavior are not modified by this document. 854 8. IANA Considerations 856 The DHCP options detailed in this document is: 858 - OPTION_DNS_ZONE_TEMPLATE: TBD 860 - OPTION_NAME_SERVER_SET: TBD 862 - OPTION_REVERSE_NAME_SERVER_SET: TBD 864 - OPTION_PUBLIC_KEY: TBD 866 9. Security Considerations 868 9.1. DNSSEC is recommended to authenticate DNS hosted data 870 It is recommended that the (Reverse) DNS Homenet Zone is signed with 871 DNSSEC. The zone may be signed by the CPE or by a third party. We 872 recommend the zone to be signed by the CPE, and that the signed zone 873 is uploaded. 875 9.2. Channel between the CPE and ISP DHCP Server MUST be secured 877 The document considers that the channel between the CPE and the ISP 878 DHCP Server is trusted. More specifically, the CPE is authenticated 879 and the exchanged messages are protected. The current document does 880 not specify how to secure the channel. [RFC3315] proposes a DHCP 881 authentication and message exchange protection, [RFC4301], [RFC7296] 882 propose to secure the channel at the IP layer. 884 In fact, the channel MUST be secured because the CPE provides 885 authentication credentials. Unsecured channel may result in CPE 886 impersonation attacks. 888 9.3. CPEs are sensitive to DoS 890 CPE have not been designed for handling heavy load. The CPE are 891 exposed on the Internet, and their IP address is publicly published 892 on the Internet via the DNS. This makes the Home Network sensitive 893 to Deny of Service Attacks. The resulting outsourcing architecture 894 is described in [I-D.ietf-homenet-front-end-naming-delegation]. This 895 document shows how the outsourcing architecture can be automatically 896 set. 898 10. Acknowledgment 900 We would like to thank Tomasz Mrugalski, Marcin Siodelski and Bernie 901 Volz for their comments on the design of the DHCP Options. We would 902 also like to thank Mark Andrews, Andrew Sullivan and Lorenzo Colliti 903 for their remarks on the architecture design. The designed solution 904 has been largely been inspired by Mark Andrews's document 905 [I-D.andrews-dnsop-pd-reverse] as well as discussions with Mark. 907 11. References 909 11.1. Normative References 911 [RFC1034] Mockapetris, P., "Domain names - concepts and facilities", 912 STD 13, RFC 1034, November 1987. 914 [RFC1996] Vixie, P., "A Mechanism for Prompt Notification of Zone 915 Changes (DNS NOTIFY)", RFC 1996, August 1996. 917 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 918 Requirement Levels", BCP 14, RFC 2119, March 1997. 920 [RFC2136] Vixie, P., Thomson, S., Rekhter, Y., and J. Bound, 921 "Dynamic Updates in the Domain Name System (DNS UPDATE)", 922 RFC 2136, April 1997. 924 [RFC2181] Elz, R. and R. Bush, "Clarifications to the DNS 925 Specification", RFC 2181, July 1997. 927 [RFC2845] Vixie, P., Gudmundsson, O., Eastlake, D., and B. 928 Wellington, "Secret Key Transaction Authentication for DNS 929 (TSIG)", RFC 2845, May 2000. 931 [RFC2930] Eastlake, D., "Secret Key Establishment for DNS (TKEY 932 RR)", RFC 2930, September 2000. 934 [RFC2931] Eastlake, D., "DNS Request and Transaction Signatures ( 935 SIG(0)s)", RFC 2931, September 2000. 937 [RFC3007] Wellington, B., "Secure Domain Name System (DNS) Dynamic 938 Update", RFC 3007, November 2000. 940 [RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., 941 and M. Carney, "Dynamic Host Configuration Protocol for 942 IPv6 (DHCPv6)", RFC 3315, July 2003. 944 [RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S. 945 Rose, "DNS Security Introduction and Requirements", RFC 946 4033, March 2005. 948 [RFC4034] Arends, R., Austein, R., Larson, M., Massey, D., and S. 949 Rose, "Resource Records for the DNS Security Extensions", 950 RFC 4034, March 2005. 952 [RFC4035] Arends, R., Austein, R., Larson, M., Massey, D., and S. 953 Rose, "Protocol Modifications for the DNS Security 954 Extensions", RFC 4035, March 2005. 956 [RFC4301] Kent, S. and K. Seo, "Security Architecture for the 957 Internet Protocol", RFC 4301, December 2005. 959 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 960 (TLS) Protocol Version 1.2", RFC 5246, August 2008. 962 [RFC5936] Lewis, E. and A. Hoenes, "DNS Zone Transfer Protocol 963 (AXFR)", RFC 5936, June 2010. 965 [RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer 966 Security Version 1.2", RFC 6347, January 2012. 968 [RFC6672] Rose, S. and W. Wijngaards, "DNAME Redirection in the 969 DNS", RFC 6672, June 2012. 971 [RFC7296] Kaufman, C., Hoffman, P., Nir, Y., Eronen, P., and T. 972 Kivinen, "Internet Key Exchange Protocol Version 2 973 (IKEv2)", STD 79, RFC 7296, October 2014. 975 11.2. Informational References 977 [I-D.andrews-dnsop-pd-reverse] 978 Andrews, M., "Automated Delegation of IP6.ARPA reverse 979 zones with Prefix Delegation", draft-andrews-dnsop-pd- 980 reverse-02 (work in progress), November 2013. 982 [I-D.ietf-homenet-front-end-naming-delegation] 983 Migault, D., Cloetens, W., Griffiths, C., and R. Weber, 984 "Outsourcing Home Network Authoritative Naming Service", 985 draft-ietf-homenet-front-end-naming-delegation-02 (work in 986 progress), May 2015. 988 [I-D.sury-dnsext-cname-dname] 989 Sury, O., "CNAME+DNAME Name Redirection", draft-sury- 990 dnsext-cname-dname-00 (work in progress), April 2010. 992 Appendix A. Scenarios and impact on the End User 994 This section details various scenarios and discuss their impact on 995 the end user. 997 A.1. Base Scenario 999 The base scenario is the one described in Section 4. It is typically 1000 the one of an ISP that manages the DHCP Server, and all DNS servers. 1002 The end user subscribes to the ISP (foo), and at subscription time 1003 registers for example.foo as its Registered Homenet Domain 1004 example.foo. Since the ISP knows the Registered Homenet Domain and 1005 the Public Authoritative Primary(ies) the ISP is able to build the 1006 DNS Homenet Zone Template. 1008 The ISP manages the DNS Template Server, so it is able to load the 1009 DNS Homenet Zone Template on the DNS Template Server. 1011 When the CPE is plugged (at least the first time), it provides its 1012 Public Key to the DHCP Server. In this scenario, the DHCP Server and 1013 the DNS Servers are managed by the ISP so the DHCP Server can provide 1014 authentication credentials of the CPE to enable secure authenticated 1015 transaction between the CPE and these DNS servers. More 1016 specifically, credentials are provided to: 1018 - Public Authoritative Name Server Set 1020 - Reverse Public Authoritative Name Server Set 1022 - DNS Template Server 1023 The CPE can update the zone using DNS update or a primary / secondary 1024 configuration in a secure way. 1026 The main advantage of this scenario is that the naming architecture 1027 is configured automatically and transparently for the end user. 1029 The drawbacks are that the end user uses a Registered Homenet Domain 1030 managed by the ISP and that it relies on the ISP naming 1031 infrastructure. 1033 A.2. Third Party Registered Homenet Domain 1035 This section considers the case when the end user wants its home 1036 network to use example.com as a Registered Homenet Domain instead of 1037 example.foo that has been assigned by the ISP. We also suppose that 1038 example.com is not managed by the ISP. 1040 This can also be achieved without any configuration. When the end 1041 user buys the domain name example.com, it may request to redirect the 1042 name example.com to example.foo using static redirection with CNAME 1043 [RFC2181], [RFC1034], DNAME [RFC6672] or CNAME+DNAME 1044 [I-D.sury-dnsext-cname-dname]. 1046 This configuration is performed once when the domain name example.com 1047 is registered. The only information the end user needs to know is 1048 the domain name assigned by the ISP. Once this configuration is done 1049 no additional configuration is needed anymore. More specifically, 1050 the CPE may be changed, the zone can be updated as in Appendix A.1 1051 without any additional configuration from the end user. 1053 The main advantage of this scenario is that the end user benefits 1054 from the Zero Configuration of the Base Scenario Appendix A.1. Then, 1055 the end user is able to register for its home network an unlimited 1056 number of domain names provided by an unlimited number of different 1057 third party providers. 1059 The drawback of this scenario may be that the end user still rely on 1060 the ISP naming infrastructure. Note that the only case this may be 1061 inconvenient is when the DNS Servers provided by the ISPs results in 1062 high latency. 1064 A.3. Third Party DNS Infrastructure 1066 This scenario considers that the end user uses example.com as a 1067 Registered Homenet Domain, and does not want to rely on the 1068 authoritative servers provided by the ISP. 1070 In this section we limit the outsourcing to the Public Authoritative 1071 Name Server Set and Public Authoritative Primary(ies) to a third 1072 party. All other DNS Servers DNS Template Server, Reverse Public 1073 Authoritative Primary(ies) and Reverse Public Authoritative Name 1074 Server Set remain managed by the ISP. The reason we consider that 1075 Reverse Public Authoritative Primary(ies) and Reverse Public 1076 Authoritative Name Server Set remains managed by the ISP are that the 1077 prefix is managed by the ISP, so outsourcing these resources requires 1078 some redirection agreement with the ISP. More specifically the ISP 1079 will need to configure the redirection on one of its Reverse DNS 1080 Servers. That said, outsourcing these resources is similar as 1081 outsourcing Public Authoritative Name Server Set and Public 1082 Authoritative Primary(ies) to a third party. Similarly, the DNS 1083 Template Server can be easily outsourced as detailed in this section 1085 Outsourcing Public Authoritative Name Server Set and Public 1086 Authoritative Primary(ies) requires: 1088 - 1) Updating the DNS Homenet Zone Template: this can be easily done 1089 as detailed in Section 4.3 as the DNS Template Server is still 1090 managed by the ISP. Such modification can be performed once by 1091 any CPE. Once this modification has been performed, the CPE 1092 can be changed, the Public Key of the CPE may be changed, this 1093 does not need to be done another time. One can imagine a GUI 1094 on the CPE asking the end user to fill the field with 1095 Registered Homenet Domain, optionally Public Authoritative 1096 Primary(ies), with a button "Configure DNS Homenet Zone 1097 Template". 1099 - 2) Updating the DHCP Server Information. In fact the Reverse 1100 Public Authoritative Name Server Set returned by the ISP is 1101 modified. One can imagine a GUI interface that enables the end 1102 user to modify its profile parameters. Again, this 1103 configuration update is done once-for-ever. 1105 - 3) Upload the authentication credential of the CPE, that is the 1106 Public Key of the CPE, to the third party. Unless we use 1107 specific mechanisms, like communication between the DHCP Server 1108 and the third party, or a specific token that is plugged into 1109 the CPE, this operation is likely to be performed every time 1110 the CPE is changed, and every time the Public Key generated by 1111 the CPE is changed. 1113 The main advantage of this scenario is that the DNS infrastructure is 1114 completely outsourced to the third party. Most likely the Public Key 1115 that authenticate the CPE need to be configured for every CPE. 1116 Configuration is expected to be CPE live-long. 1118 A.4. Multiple ISPs 1120 This scenario considers a CPE connected to multiple ISPs. 1122 Firstly, suppose the CPE has been configured with the based scenarios 1123 exposed in Appendix A.1. The CPE has multiple interfaces, one for 1124 each ISP, and each of these interface is configured using DHCP. The 1125 CPE sends to each ISP its DHCP Public Key Option as well as a request 1126 for a DHCP Zone Template Option, a DHCP Public Authoritative Name 1127 Server Set Option and a DHCP Reverse Public Authoritative Name Server 1128 Set Option. Each ISP provides the requested DHCP options, with 1129 different values. Note that this scenario assumes, the home network 1130 has a different Registered Homenet Domain for each ISP as it is 1131 managed by the ISP. On the other hand, the CPE Public Key may be 1132 shared between the CPE and the multiple ISPs. The CPE builds the 1133 associate DNS(SEC) Homenet Zone, and proceeds to the various settings 1134 as described in Appendix A.1. 1136 The protocol and DHCP Options described in this document are fully 1137 compatible with a CPE connected to multiple ISPs with multiple 1138 Registered Homenet Domains. However, the CPE should be able to 1139 handle different Registered Homenet Domains. This is an 1140 implementation issue which is outside the scope of the current 1141 document. More specifically, multiple Registered Homenet Domains 1142 leads to multiple DNS(SEC) Homenet Zones. A basic implementation may 1143 erase the DNS(SEC) Homenet Zone that exists when it receives DHCP 1144 Options, and rebuild everything from scratch. This will work for an 1145 initial configuration but comes with a few drawbacks. First, updates 1146 to the DNS(SEC) Homenet Zone may only push to one of the multiple 1147 Registered Homenet Domain, the latest Registered Homenet Domain that 1148 has been set, and this is most likely expected to be almost randomly 1149 chosen as it may depend on the latency on each ISP network at the 1150 boot time. As a results, this leads to unsynchronized Registered 1151 Homenet Domains. Secondly, if the CPE handles in some ways 1152 resolution, only the latest Registered Homenet Domain set may be able 1153 to provide naming resolution in case of network disruption. 1155 Secondly, suppose the CPE is connected to multiple ISP with a single 1156 Registered Homenet Domain. In this case, the one party is chosen to 1157 host the Registered Homenet Domain. This entity may be one of the 1158 ISP or a third party. Note that having multiple ISPs can be 1159 motivated for bandwidth aggregation, or connectivity fail-over. In 1160 the case of connectivity fail-over, the fail-over concerns the access 1161 network and a failure of the access network may not impact the core 1162 network where the Public Authoritative Name Server Set and Public 1163 Authoritative Primaries are hosted. In that sense, choosing one of 1164 the ISP even in a scenario of multiple ISPs may make sense. However, 1165 for sake of simplicity, this scenario assumes that a third party has 1166 be chosen to host the Registered Homenet Domain. The DNS settings 1167 for each ISP is described in Appendix A.2 and Appendix A.3. With the 1168 configuration described in Appendix A.2, the CPE is expect to be able 1169 to handle multiple Homenet Registered Domain, as the third party 1170 redirect to one of the ISPs Servers. With the configuration 1171 described in Appendix A.3, DNS zone are hosted and maintained by the 1172 third party. A single DNS(SEC) Homenet Zone is built and maintained 1173 by the CPE. This latter configuration is likely to match most CPE 1174 implementations. 1176 The protocol and DHCP Options described in this document are fully 1177 compatible with a CPE connected to multiple ISPs. To configure or 1178 not and how to configure the CPE depends on the CPE facilities. 1179 Appendix A.1 and Appendix A.2 require the CPE to handle multiple 1180 Registered Homenet Domain, whereas Appendix A.3 does not have such 1181 requirement. 1183 Appendix B. Document Change Log 1185 [RFC Editor: This section is to be removed before publication] 1187 -05: changing Master to Primary, Slave to Secondary 1189 -04: Working Version Major modifications are: 1191 - Re-structuring the draft: description and comparison of update and 1192 security mechanisms have been intergrated into the Overview 1193 section. a Configuration section has been created to describe 1194 both configuration and corresponding behavior of the CPE. 1196 - Adding Ports parameters: Server Set can configure a port. The 1197 Port Server parameter have been added in the DHCP Option 1198 payloads because middle boxes may not be configured to let port 1199 53 packets and it may also be useful to split servers among 1200 different ports, assigning each end user a different port. 1202 - Multiple ISP scenario: In order to address comments, the multiple 1203 ISPs scenario has been described to explicitly show that the 1204 protocol and DHCP Options do not prevent a CPE connected to 1205 multiple independent ISPs. 1207 -03: Working Version Major modifications are: 1209 - Redesigning options/scope: according to feed backs received from 1210 the IETF89 presentation in the dhc WG. 1212 - Redesigning architecture: according to feed backs received from 1213 the IETF89 presentation in the homenet WG, discussion with Mark 1214 and Lorenzo. 1216 -02: Working Version Major modifications are: 1218 - Redesigning options/scope: As suggested by Bernie Volz 1220 -01: Working Version Major modifications are: 1222 - Remove the DNS Zone file construction: As suggested by Bernie Volz 1224 - DHCPv6 Client behavior: Following options guide lines 1226 - DHCPv6 Server behavior: Following options guide lines 1228 -00: version published in the homenet WG. Major modifications are: 1230 - Reformatting of DHCP Options: Following options guide lines 1232 - DHCPv6 Client behavior: Following options guide lines 1234 - DHCPv6 Server behavior: Following options guide lines 1236 -00: First version published in dhc WG. 1238 Authors' Addresses 1240 Daniel Migault 1241 Ericsson 1242 8400 boulevard Decarie 1243 Montreal, QC H4P 2N2 1244 Canada 1246 Email: daniel.migault@ericsson.com 1248 Wouter Cloetens 1249 SoftAtHome 1250 vaartdijk 3 701 1251 3018 Wijgmaal 1252 Belgium 1254 Email: wouter.cloetens@softathome.com 1255 Chris Griffiths 1256 Dyn 1257 150 Dow Street 1258 Manchester, NH 03101 1259 US 1261 Email: cgriffiths@dyn.com 1262 URI: http://dyn.com 1264 Ralf Weber 1265 Nominum 1266 2000 Seaport Blvd #400 1267 Redwood City, CA 94063 1268 US 1270 Email: ralf.weber@nominum.com 1271 URI: http://www.nominum.com