idnits 2.17.1 draft-mglt-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 (July 2, 2014) is 3586 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 5996 (Obsoleted by RFC 7296) ** Obsolete normative reference: RFC 6347 (Obsoleted by RFC 9147) == Outdated reference: A later version (-04) exists of draft-mglt-homenet-front-end-naming-delegation-03 Summary: 5 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 Orange 4 Intended status: Standards Track W. Cloetens 5 Expires: January 3, 2015 SoftAtHome 6 C. Griffiths 7 Dyn 8 R. Weber 9 Nominum 10 July 2, 2014 12 DHCP Options for Homenet Naming Architecture 13 draft-mglt-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 January 3, 2015. 50 Copyright Notice 52 Copyright (c) 2014 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 5. Securing the exchanges . . . . . . . . . . . . . . . . . . . 8 72 6. DNS Zones Update Mechanisms . . . . . . . . . . . . . . . . . 9 73 6.1. Data subjected to update . . . . . . . . . . . . . . . . 9 74 6.2. Master / Slave Synchronization versus DNS Update . . . . 9 75 6.3. Setting Master / Slave Synchronization . . . . . . . . . 10 76 6.4. Master / Slave Synchronization: CPE / Public 77 Authoritative Name Server Set . . . . . . . . . . . . . . 10 78 6.5. Master / Slave Synchronization: CPE / Reverse Public 79 Authoritative Name Server Set . . . . . . . . . . . . . . 11 80 7. DNS Zone Update Data . . . . . . . . . . . . . . . . . . . . 11 81 7.1. DNS Homenet Zone Template . . . . . . . . . . . . . . . . 11 82 7.2. DNS Homenet Zone . . . . . . . . . . . . . . . . . . . . 12 83 8. Payload Description . . . . . . . . . . . . . . . . . . . . . 12 84 8.1. Security Field . . . . . . . . . . . . . . . . . . . . . 12 85 8.2. Update Field . . . . . . . . . . . . . . . . . . . . . . 13 86 8.3. DHCP Public Key Option . . . . . . . . . . . . . . . . . 14 87 8.4. DHCP Zone Template Option . . . . . . . . . . . . . . . . 14 88 8.5. DHCP Public Authoritative Name Server Set Option . . . . 15 89 8.6. DHCP Reverse Public Authoritative Name Server Set Option 16 90 9. DHCP Behavior . . . . . . . . . . . . . . . . . . . . . . . . 17 91 9.1. DHCPv6 Server Behavior . . . . . . . . . . . . . . . . . 17 92 9.2. DHCPv6 Client Behavior . . . . . . . . . . . . . . . . . 17 93 9.3. DHCPv6 Relay Behavior . . . . . . . . . . . . . . . . . . 17 94 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17 95 11. Security Considerations . . . . . . . . . . . . . . . . . . . 18 96 11.1. DNSSEC is recommended to authenticate DNS hosted data . 18 97 11.2. Channel between the CPE and ISP DHCP Server MUST be 98 secured . . . . . . . . . . . . . . . . . . . . . . . . 18 99 11.3. CPEs are sensitive to DoS . . . . . . . . . . . . . . . 18 100 12. Acknowledgment . . . . . . . . . . . . . . . . . . . . . . . 18 101 13. References . . . . . . . . . . . . . . . . . . . . . . . . . 18 102 13.1. Normative References . . . . . . . . . . . . . . . . . . 18 103 13.2. Informational References . . . . . . . . . . . . . . . . 20 104 Appendix A. Scenarios and impact on the End User . . . . . . . . 20 105 A.1. Base Scenario . . . . . . . . . . . . . . . . . . . . . . 20 106 A.2. Third Party Registered Homenet Domain . . . . . . . . . . 21 107 A.3. Third Party DNS Infrastructure . . . . . . . . . . . . . 22 108 Appendix B. Document Change Log . . . . . . . . . . . . . . . . 23 109 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 24 111 1. Requirements notation 113 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 114 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 115 document are to be interpreted as described in [RFC2119]. 117 2. Terminology 119 - Customer Premises Equipment: (CPE) is the router providing 120 connectivity to the home network. It is configured and managed 121 by the end user. In this document, the CPE might also hosts 122 services such as DHCPv6. This device might be provided by the 123 ISP. 125 - Public Key: designates a public Key generated by the CPE. This 126 key is used as an authentication credential for the CPE. 128 - Registered Homenet Domain: is the Domain Name associated to the 129 home network. 131 - DNS Homenet Zone: is the DNS zone associated to the home network. 132 This zone is set by the CPE and essentially contains the 133 bindings between names and IP addresses of the nodes of the 134 home network. In this document, the CPE does neither perform 135 any DNSSEC management operations such as zone signing nor 136 provide an authoritative service for the zone. Both are 137 delegated to the Public Authoritative Server. The CPE 138 synchronizes the DNS Homenet Zone with the Public Authoritative 139 Server via a hidden master / slave architecture. The Public 140 Authoritative Server might use specific servers for the 141 synchronization of the DNS Homenet Zone: the Public 142 Authoritative Name Server Set. 144 - DNS Homenet Zone Template: The template used as a basis to 145 generate the DNS Homenet Zone. 147 - DNS Template Server: The DNS server that hosts the DNS Homenet 148 Zone Template. 150 - DNS Homenet Reverse Zone: The reverse zone file associated to the 151 DNS Homenet Zone. 153 - Public Authoritative Master(s): are the visible name server 154 hosting the DNS Homenet Zone. End users' resolutions for the 155 Homenet Domain are sent to this server, and this server is a 156 master for the zone. 158 - Public Authoritative Name Server Set: is the server the CPE 159 synchronizes the DNS Homenet Zone. It is configured as a slave 160 and the CPE acts as master. The CPE sends information so the 161 DNSSEC zone can be set and served. 163 - Reverse Public Authoritative Master(s): are the visible name 164 server hosting the DNS Homenet Reverse Zone. End users' 165 resolutions for the Homenet Domain are sent to this server, and 166 this server is a master for the zone. 168 - Reverse Public Authoritative Name Server Set: is the server the 169 CPE synchronizes the DNS Homenet Reverse Zone. It is 170 configured as a slave and the CPE acts as master. The CPE 171 sends information so the DNSSEC zone can be set and served. 173 3. Introduction 175 CPEs are usually constraint devices with reduced network and CPU 176 capacities. As such, a CPE hosting on the Internet the authoritative 177 naming service for its home network may become vulnerable to resource 178 exhaustion attacks. One way to avoid exposing CPE is to outsource 179 the authoritative service to a third party. This third party can be 180 the ISP or any other independent third party. 182 Outsourcing the authoritative naming service to a third party 183 requires setting up an architecture which may be unappropriated for 184 most end users. To leverage this issue, this document proposes DHCP 185 Options so any agnostic CPE can automatically proceed to the 186 appropriated configuration and outsource the authoritative naming 187 service for the home network. This document shows that in most 188 cases, these DHCP Options make outsourcing to a third party (be it 189 the ISP or any ISP independent service provider) transparent for the 190 end user. 192 When the CPE is plugged, the DHCP Options described in the document 193 enable the CPE: 195 - 1. To build the DNS Homenet Zone: Building the DNS Homenet Zone 196 requires filling the zone with appropriated bindings likes name 197 / IP addresses of the different devices in the home networks. 198 Such information can be provided for example by the DHCP Server 199 hosted on the CPE. On the other hand, it also requires 200 configuration parameters like the name of the Registered Domain 201 Name associated to the home network or the Public Authoritative 202 Master(s) the DNS Homenet Zone is outsourced to. These 203 configuration parameters are stored in the DNS Homenet Zone 204 Template. This document describes the DHCP Zone Template 205 Option. This option carries a DNS Homenet Zone Template FQDN. 206 In order to retrieve the DNS Homenet Zone Template, the CPE 207 sends a query of type AXFR [RFC1034] [RFC5936]for the DNS 208 Homenet Zone Template FQDN. 210 - 2. To upload the DNS(SEC) Homenet Zone to the appropriated server: 211 This server is designated as the Public Authoritative Name 212 Server Set. It is in charge of publishing the DNS(SEC) Homenet 213 Zone on the Public Authoritative Master(s). This document 214 describes the DHCP Public Authoritative Name Server Set Option 215 that provides the FQDN of the appropriated server. Note that, 216 in the document we do not consider whether the DNS(SEC) Homenet 217 Zone is signed or not and if signed who signs it. Such 218 questions are out of the scope of the current document. 220 - 3. To upload the DNS Homenet Reverse Zone to the appropriated 221 server: This server is designated as the Reverse Public 222 Authoritative Name Server Set. It is in charge of publishing 223 the DNS Homenet Reverse Zone on the Reverse Public 224 Authoritative Master(s). This document describes the DHCP 225 Reverse Public Authoritative Name Server Set Option that 226 provides the FQDN of the appropriated server. Similarly to 227 item 2., we do not consider in this document if the DNS Homenet 228 Reverse Zone is signed or not, and if signed who signs it. 230 - 4. To provide authentication credential (a public key) to the DHCP 231 Server: Information stored in the DNS Homenet Zone Template, 232 the DNS(SEC) Homenet Zone and DNS Homenet Reverse Zone belongs 233 to the CPE, and only the CPE should be able to update or upload 234 these zones. To authenticate the CPE, this document defines 235 the DHCP Public Key Option. This option is sent by the CPE to 236 the DHCP Server and provides the Public Key the CPE uses to 237 authenticate itself. The DHCP Server is then responsible to 238 provide the Public Key to the various DNS servers. 240 As a result, the DHCP Options described in this document enable an 241 agnostic CPE to outsource its naming infrastructure without any 242 configuration from the end user. The main reason no configuration is 243 required by the end user is that there are privilege links first 244 between the CPE and the DHCP Server and then between the DHCP Server 245 and the various DNS servers (DNS Homenet Zone Server, the Reverse 246 Public Authoritative Name Server Set, Public Authoritative Name 247 Server Set). This enables the CPE to send its authentication 248 credentials (a Public Key) to the DHCP Server that in turn forward it 249 to the various DNS servers. With the authentication credential on 250 the DNS servers set, the CPE is able to update the various zones in a 251 secure way. 253 If the DHCP Server cannot provide the public key to one of these 254 servers (most likely the Public Authoritative Name Server Set) and 255 the CPE needs to interact with the server, then, the end user is 256 expected to provide it manually or using other mechanisms. Such 257 mechanisms are outside the scope of this document. In that case, the 258 authentication credentials need to be provided every time the key is 259 modified. Appendix A provides more details on how different 260 scenarios impact the end users. 262 4. Protocol Overview 264 This section illustrates how a CPE configures its naming 265 infrastructure to outsource its authoritative naming service. All 266 configurations and settings are performed using DHCP Options. In 267 this section, for the sake of simplicity, we consider that the DHCP 268 Server is able to communicate to the various DNS servers and provide 269 them them the public key associated to the CPE. Once each server got 270 the credentials, the CPE can proceed to updates in a authenticated 271 and secure way. 273 This scenario has been chosen as it is believed to be the most 274 popular scenario. This document does not ignore that scenarios where 275 the DHCP Server does not have privilege relations with the Public 276 Authoritative Name Server Set must be considered. These cases are 277 discussed latter in Appendix A. Such scenario does not necessarily 278 require configuration for the end user and can also be Zero Config. 280 The scenario is represented in Figure 1. 282 - 1: The CPE provides its Public Key to the DHCP Server using a DHCP 283 Public Key Option (OPTION_PUBLIC_KEY) and sends a DHCP Option 284 Request Option (ORO) for the DHCP Zone Template Option 285 (OPTION_DNS_ZONE_TEMPLATE), the DHCP Public Authoritative Name 286 Server Set Option (OPTION_NAME_SERVER_SET) and the DHCP Reverse 287 Public Authoritative Name Server Set Option 288 (OPTION_REVERSE_NAME_SERVER_SET). 290 - 2: The DHCP Server makes the Public Key available to the DNS 291 servers, so the CPE can secure its DNS transactions. Note that 292 the Public Key alone is not sufficient to perform the 293 authentication and the key should be, for example, associated 294 with an identifier, or the concerned domain name. How the 295 binding is performed is out of scope of the document. It can 296 be a centralized database or various bindings may be sent to 297 the different servers. Figure 1 represents the specific case 298 were the DHCP Server forwards the set (Public Key, Zone 299 Template FQDN) to the DNS Template Server, the set (Public Key, 300 IPv6 subnet) to the Reverse Public Authoritative Name Server 301 Set and the set (Public Key, Registered Homenet Domain) to the 302 Public Authoritative Name Server Set. 304 - 3.: The DHCP Server responds to the CPE with the requested DHCP 305 Options, i.e. the DHCP Public Key Option (OPTION_PUBLIC_KEY), 306 DHCP Zone Template Option OPTION_DNS_ZONE_TEMPLATE, DHCP Public 307 Authoritative Name Server Set Option (OPTION_NAME_SERVER_SET), 308 DHCP Reverse Public Authoritative Name Server Set Option 309 (OPTION_REVERSE_NAME_SERVER_SET). 311 - 4.: Upon receiving the DHCP Zone Template Option 312 (OPTION_DNS_ZONE_TEMPLATE), the CPE performs an AXFR DNS query 313 for the Zone Template FQDN. The exchange is secured according 314 to the security protocols defined in the Security field of the 315 DHCP option. Once the CPE has retrieved the DNS Zone Template, 316 the CPE can build the DNS Homenet Zone and the DNS Homenet 317 Reverse Zone. Eventually the CPE signs these zones. 319 - 5.: Once the DNS(SEC) Homenet Reverse Zone has been set, the CPE 320 uploads the zone to the Reverse Public Authoritative Name 321 Server Set. The DHCP Reverse Public Authoritative Name Server 322 Set Option (OPTION_REVERSE_NAME_SERVER_SET) provides the 323 Reverse Public Authoritative Name Server Set FQDN as well as 324 the upload method, and the security protocol to secure the 325 upload. 327 - 6.: Once the DNS(SEC) Homenet Zone has been set, the CPE uploads 328 the zone to the Public Authoritative Name Server Set. The DHCP 329 Public Authoritative Name Server Set Option 330 (OPTION_NAME_SERVER_SET) provides the Public Authoritative Name 331 Server Set FQDN as well as the upload method and the security 332 protocol to secure the upload. 334 +----------------------+ 335 | DHCP Server | 336 +----------------------+ 337 ^ ^ ^ 338 | | |2. 339 1.| |3. | 340 v v | 341 +------+ | +--------------------------------+ 342 | | 4. +--->| DNS Template Server | 343 | |<---------->| | 344 | | | +--------------------------------+ 345 | CPE | | 346 | | | +--------------------------------+ 347 | | 5. +--->| Reverse Public Authoritative | 348 | |<---------->| Name Server Set | 349 | | | +--------------------------------+ 350 -------| |-------|-------------------------------------- 351 | | | +--------------------------------+ 352 +------+ +--->| Public Authoritative | 353 | Name Server Set | 354 +--------------------------------+ 356 Figure 1: Protocol Overview 358 5. Securing the exchanges 360 Multiple protocols like IPsec [RFC4301] or TLS / DTLS [RFC5246] / 361 [RFC6347] may be used to secure DNS transactions between the CPE and 362 the DNS servers. This document restricts the scope of security 363 protocols to those that have been designed specifically for DNS. 364 This includes DNSSEC [RFC4033], [RFC4034], [RFC4035] that 365 authenticates and provides integrity protection of DNS data, TSIG 366 [RFC2845], [RFC2930] that use a shared secret to secure a transaction 367 between two end points and SIG(0) [RFC2931] authenticates the DNS 368 packet exchanged. 370 The key issue with TSIG is that a shared secret must be negotiated 371 between the CPE and the server. On the other end, TSIG performs 372 symmetric cryptography which is light in comparison with asymmetric 373 cryptography used by SIG(0). As a result, over large zone transfer, 374 TSIG may be preferred to SIG(0). 376 This document does not provides means to distribute shared secret for 377 example using a specific DHCP Option. The only assumption made is 378 that the CPE generates or is assigned a public key. 380 As a result, when the document specifies the transaction is secured 381 with TSIG, it means that either the CPE and the DNS Server have been 382 manually configured with a shared secret, or the shared secret has 383 been negotiated using TKEY [RFC2930], and the TKEY exchanged are 384 secured with SIG(0). 386 Exchange with the DNS Template Server to retrieve the DNS Homenet 387 Zone Template may be protected by SIG(0), TSIG or DNSSEC. When 388 DNSSEC is used, it means the DNS Template Server only provides 389 integrity protection, and does not necessarily prevents someone else 390 to query the DNS Homenet Zone Template. In addition, DNSSEC is only 391 a way to protect the communication of AXFR queries, in other words, 392 DNSSEC cannot be used to secure updates. If DNSSEC is used to 393 provide integrity protection for the AXFR response, the CPE should 394 proceed to the DNSSEC signature checks. If signature check fails, it 395 MUST reject the response. If the signature check succeeds, the CPE 396 removes all DNSSEC related RRsets (DNSKEY, RRSIG, NSEC* ...) before 397 building the DNS Homenet Zone. In fact, these DNSSEC related fields 398 as associated to the DNS Homenet Zone Template and not the DNS 399 Homenet Zone. 401 Any update exchange should use SIG(0) or TSIG to authenticate the 402 exchange. 404 6. DNS Zones Update Mechanisms 406 6.1. Data subjected to update 408 The CPE is likely to update various DNS contents: 410 - DNS Homenet Zone Template: may be updated by the CPE if the 411 configuration of the zone may be changed. This can include 412 additional Public Authoritative Master(s), a different 413 Registered Homenet Domain as the one initially proposed, or a 414 redirection to another domain. 416 - DNS Homenet Reverse Zone: may be updated every time a new device 417 is connected or dis-connected. 419 - DNS Homenet Zone: may be updated every time a new device is 420 connected, dis-connected. 422 6.2. Master / Slave Synchronization versus DNS Update 424 As updates only concern DNS zones, this document only considers DNS 425 update mechanisms such as DNS update [RFC2136] [RFC3007] or a master 426 / slave synchronization. 428 The DNS Homenet Zone Template can only be updated with DNS update. 429 The reason is that the DNS Homenet Zone Template contains static 430 configuration data that is not expected to evolve over time. 432 The DNS Homenet Reverse Zone and the DNS Homenet Zone can be updated 433 either with DNS update or using a master / slave synchronization. As 434 these zones may be large, with frequent updates, we recommend to use 435 the master / slave architecture as described in 436 [I-D.mglt-homenet-front-end-naming-delegation]. The master / slave 437 mechanism is preferred as it better scales and avoids DoS attacks: 438 First the master notifies the slave the zone must be updated, and 439 leaves the slave to proceed to the update when possible. Then, the 440 NOTIFY message sent by the master is a small packet that is less 441 likely to load the slave. At last, the AXFR query performed by the 442 slave is a small packet sent over TCP (section 4.2 [RFC5936]) which 443 makes unlikely the slave to perform reflection attacks with a forged 444 NOTIFY. On the other hand, DNS updates can use UDP, packets require 445 more processing then a NOTIFY, and they do not provide the server the 446 opportunity to post-pone the update. 448 6.3. Setting Master / Slave Synchronization 450 The master / slave architecture is described in 451 [I-D.mglt-homenet-front-end-naming-delegation]. The CPE is 452 configured as a master whereas the DNS Server is configured as a 453 slave. The DNS Server represents the Public Authoritative Name 454 Server Set or the Reverse Public Authoritative Name Server Set. 456 When the CPE is plugged its IP address may be unknown to the slave. 457 The section details how the CPE or master communicate the necessary 458 information to set up the slave. 460 In order to set the master / slave configuration, both master and 461 slaves must agree on 1) the zone to be synchronized, 2) the IP 462 address used by both master and slave. In this document we assume 463 that synchronization is performed on both side on port 53. 465 [QUESTION Do we have to consider different port of port 53 is fine. 466 I guess it is fine.] 468 6.4. Master / Slave Synchronization: CPE / Public Authoritative Name 469 Server Set 471 The CPE knows the zone to be synchronized by reading the Registered 472 Homenet Domain in the DNS Homenet Zone Template provided by the DHCP 473 Zone Template Option (OPTION_DNS_ZONE_TEMPLATE). The IP address of 474 the slave is provided by the DHCP Public Authoritative Name Server 475 Set Option (OPTION_NAME_SERVER_SET). 477 The Public Authoritative Name Server Set has been configured with the 478 Registered Homenet Domain and the Public Key that identifies the CPE. 479 The only thing missing is the IP address of the CPE. This IP address 480 is provided by the CPE by sending a NOTIFY [RFC1996]. 482 When the CPE has built its DNS Homenet Zone, it sends a NOTIFY 483 message to the Public Authoritative Name Server Sets. Upon receiving 484 the NOTIFY message, the slave reads the Registered Homenet Domain and 485 checks the NOTIFY is sent by the authorized master. This can be done 486 using the shared secret (TSIG) or the public key (SIG(0)). Once the 487 NOTIFY has been authenticated, the Public Authoritative Name Server 488 Sets might consider the source IP address of the NOTIFY query to 489 configure the masters attributes. 491 6.5. Master / Slave Synchronization: CPE / Reverse Public Authoritative 492 Name Server Set 494 The CPE knows the zone to be synchronized by looking at its assigned 495 prefix. The IP address of the slave is provided by the DHCP Reverse 496 Public Authoritative Name Server Set Option 497 (OPTION_REVERSE_NAME_SERVER_SET). 499 Configuration of the slave is performed as illustrated in 500 Section 6.4. 502 7. DNS Zone Update Data 504 7.1. DNS Homenet Zone Template 506 The DNS Homenet Zone Template contains at least the related fields of 507 the Public Authoritative Master(s) as well as the Homenet Registered 508 Domain, that is SOA, and NS fields. This template might be generated 509 automatically by the owner of the DHCP Server. For example, an ISP 510 might provide a default Homenet Registered Domain as well as default 511 Public Authoritative Master(s). This default settings should provide 512 the CPE the necessary pieces of information to set the homenet naming 513 architecture. 515 If the DNS Homenet Zone Template is not subject to modifications or 516 updates, the owner of the template might only use DNSSEC to enable 517 integrity check. 519 The DNS Homenet Zone Template might be subject to modification by the 520 CPE. The advantage of using the standard DNS zone format is that 521 standard DNS update mechanism can be used to perform updates. These 522 updates might be accepted or rejected by the owner of the DNS Homenet 523 Zone Template. Policies that defines what is accepted or rejected is 524 out of scope of this document. However, in this document we assume 525 the Registered Homenet Domain is used as an index by the Public 526 Authoritative Name Server Set, and SIG(0), TSIG are used to 527 authenticate the CPE. As a result, the Registered Homenet Domain 528 should not be modified unless the Public Authoritative Name Server 529 Set can handle with it. 531 7.2. DNS Homenet Zone 533 The DNS Homenet Zone might be generated from the DNS Homenet Zone 534 Template. How the DNS Homenet Zone is generated is out of scope of 535 this document. In some cases, the DNS Homenet Zone might be the 536 exact copy of the DNS Homenet Zone Template. In other cases, it 537 might be generated from the DNS Homenet Zone Template with additional 538 RRsets. In some other cases, the DNS Homenet Zone might be generated 539 without considering the DNS Homenet Zone Template, but only 540 considering specific configuration rules. 542 In the current document the CPE only sets a single zone that is 543 associated with one single Homenet Registered Domain. The domain 544 might be assigned by the owner of the DNS Homenet Zone Template. 545 This constrain does not prevent the CPE to use multiple domain names. 546 How additional domains are considered is out of scope of this 547 document. One way to handle these additional zones is to configure 548 static redirections to the DNS Homenet Zone using CNAME [RFC2181], 549 [RFC1034], DNAME [RFC6672] or CNAME+DNAME 550 [I-D.sury-dnsext-cname-dname]. 552 8. Payload Description 554 8.1. Security Field 556 The Security Field of the DHCP Option is represented in Figure 2. It 557 indicates the security mechanism supported by the DNS Server. One of 558 these mechanism MUST be chosen by the CPE in order to perform a 559 transaction with the DNS server. See Section 5 for more details. 561 0 1 562 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 563 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 564 | Security | 565 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 567 Figure 2: Security Field 569 - DNS (Bit 0): indicates, when set to 1, that DNS without any 570 security extension is supported. 572 - DNSSEC (Bit 1): indicates, when set to 1, that DNSSEC provides 573 integrity protection. This can only be used for read 574 operations like retrieving the DNS Homenet Zone Template. 576 - SIG(0) (Bit 2): indicates, when set to 1, that transaction 577 protected by SIG(0) are supported. 579 - TSIG (Bit 3): indicates, when set to 1, that transaction using 580 TSIG is supported. Note that if a shared secret has not been 581 previously negotiated between the two party, it should be 582 negotiated using TKEY. The TKEY exchanges MUST be protected 583 with SIG(0) even though SIG(0) is not supported. 585 - Remaining Bits (Bit 4-15): MUST be set to 0 by the DHCP Server 586 and ignored by the DHCP Client. 588 A Security field with all bits set to zero indicates the operation is 589 not permitted. The Security field may be set to zero when updates 590 operations are not permitted for the DNS Homenet Template. In any 591 other case this is an error. 593 8.2. Update Field 595 The Update Field of the DHCP Option is represented in Figure 3. It 596 indicates the update mechanism supported by the DNS server. See 597 Section 6 for more details. 599 0 600 0 1 2 3 4 5 6 7 601 +-+-+-+-+-+-+-+-+ 602 | Update | 603 +-+-+-+-+-+-+-+-+ 605 Figure 3: Update Field 607 - Master / Slave (Bit 0): indicates, when set to 1, that DNS Server 608 supports data synchronization using a Master / Slave mechanism. 610 - DNS Update (Bit 1): indicates, when set to 1, that DNS Server 611 supports data synchronization using DNS Updates. 613 - Remaining Bits (Bit 2-7): MUST be set to 0 by the DHCP Server and 614 ignored by the DHCP Client. 616 8.3. DHCP Public Key Option 618 The DHCP Public Key Option (OPTION_PUBLIC_KEY) indicates the Public 619 Key that is used to authenticate the CPE. 621 0 1 2 3 622 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 623 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 624 | OPTION_PUBLIC_KEY | option-len | 625 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 626 | | 627 / Public Key Data / 628 | | 629 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 631 Figure 4: DHCP Public Key Option 633 - OPTION_PUBLIC_KEY (variable): the option code for the DHCP Public 634 Key Option. 636 - option-len (16 bits): length in octets of the option-data field as 637 described in [RFC3315]. 639 - Public Key Data: contains the Public Key. The format is the DNSKEY 640 RDATA format as defined in [RFC4034]. 642 8.4. DHCP Zone Template Option 644 The DHCP Zone Template Option (OPTION_DNS_ZONE_TEMPLATE) Option 645 indicates the CPE how to retrieve the DNS Homenet Zone Template. It 646 provides a FQDN the CPE SHOULD query with a DNS query of type AXFR. 647 The option also specifies which security protocols are available on 648 the authoritative server. DNS Homenet Zone Template update, if 649 permitted MUST use the DNS Update mechanism. 651 0 1 2 3 652 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 653 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 654 | OPTION_DNS_ZONE_TEMPLATE | option-len | 655 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 656 | Security (axfr) | Security | 657 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 658 | | 659 / Zone Template FQDN / 660 | | 661 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 663 Figure 5: DHCP Zone Template Option 665 - OPTION_DNS_ZONE_TEMPLATE (variable): the option code for the DHCP 666 Zone Template Option. 668 - option-len (16 bits): length in octets of the option-data field as 669 described in [RFC3315]. 671 - Security (axfr) (16 bits): defines which security protocols are 672 supported by the DNS server. This field concerns the AXFR and 673 consultation queries, not the update queries. See Section 8.1 674 for more details. 676 - Security (16 bits): defines which security protocols are supported 677 by the DNS server. This field concerns the update. See 678 Section 8.1 for more details. 680 - Zone Template FQDN FQDN (variable): the FQDN of the DNS server 681 hosting the DNS Homenet Zone Template. 683 8.5. DHCP Public Authoritative Name Server Set Option 685 The DHCP Public Authoritative Name Server Set Option 686 (OPTION_NAME_SERVER_SET) provides information so the CPE can upload 687 the DNS Homenet Zone to the Public Authoritative Name Server Set. 688 Finally, the option provides the security mechanisms that are 689 available to perform the upload. The upload is performed via a DNS 690 master / slave architecture or DNS updates. 692 0 1 2 3 693 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 694 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 695 | OPTION_NAME_SERVER_SET | option-len | 696 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 697 | Security | Update | | 698 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 699 | | 700 / Public Authoritative Name Server Set FQDN / 701 | | 702 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 704 Figure 6: DHCP Public Authoritative Name Server Set Option 706 - OPTION_NAME_SERVER_SET (16 bits): the option code for the DHCP 707 Public Authoritative Name Server Set Option. 709 - option-len (16 bits): length in octets of the option-data field as 710 described in [RFC3315]. 712 - Security (16 bits): defines which security protocols are supported 713 by the DNS server. See Section 8.1 for more details. 715 - Update (8 bits): defines which update mechanisms are supported by 716 the DNS server. See Section 6 for more details. 718 - Public Authoritative Name Server Set FQDN (variable): the FQDN of 719 the Public Authoritative Name Server Set. 721 8.6. DHCP Reverse Public Authoritative Name Server Set Option 723 The DHCP Reverse Public Authoritative Name Server Set Option 724 (OPTION_REVERSE_NAME_SERVER_SET) provides information so the CPE can 725 upload the DNS Homenet Zone to the Public Authoritative Name Server 726 Set. The option provides the security mechanisms that are available 727 to perform the upload. The upload is performed via a DNS master / 728 slave architecture or DNS updates. 730 0 1 2 3 731 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 732 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 733 | OPTION_REVERSE_NAME_SERVER_SET| option-len | 734 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 735 | Security | Update | | 736 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 737 | | 738 / Reverse Public Authoritative Name Server Set FQDN / 739 | | 740 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 742 Figure 7: DHCP Reverse Public Authoritative Name Server Set Option 744 - OPTION_REVERSE_NAME_SERVER_SET (16 bits): the option code for the 745 DHCP Reverse Public Authoritative Name Server Set Option. 747 - option-len (16 bits): length in octets of the option-data field as 748 described in [RFC3315]. 750 - Security (16 bits): defines which security protocols are supported 751 by the DNS server. See Section 8.1 for more details. 753 - Update (8 bits): defines which update mechanisms are supported by 754 the DNS server. See Section 6 for more details. 756 - Reverse Public Authoritative Name Server Set FQDN (variable): The 757 FQDN of the Reverse Public Authoritative Name Server Set. 759 9. DHCP Behavior 761 9.1. DHCPv6 Server Behavior 763 The DHCP Server sends the DHCP Zone Template Option 764 (OPTION_DNS_ZONE_TEMPLATE), DHCP Public Authoritative Name Server Set 765 Option (OPTION_NAME_SERVER_SET), DHCP Reverse Public Authoritative 766 Name Server Set Option (OPTION_REVERSE_NAME_SERVER_SET) upon request 767 by the DHCP Client. 769 The DHCP Server MAY receive a DHCP Public Key Option 770 (OPTION_PUBLIC_KEY) from the CPE. Upon receipt of this DHCP Option, 771 the DHCP Sever is expect to communicate this credential to the 772 available DNS Servers like the DNS Template Server, the Public 773 Authoritative Name Server Set and the Reverse Public Authoritative 774 Name Server Set. 776 9.2. DHCPv6 Client Behavior 778 The DHCP Client MAY send a DHCP Public Key Option (OPTION_PUBLIC_KEY) 779 to the DHCP Server. This Public Key authenticates the CPE. 781 The DHCP Client sends a DHCP Option Request Option (ORO) with the 782 necessary DHCP options. 784 A CPE SHOULD only send the an ORO request for DHCP Options it needs 785 or for information that needs to be up-to-date. 787 Upon receiving a DHCP option described in this document, the CPE 788 SHOULD retrieve or update DNS zones using the associated security and 789 update protocols. 791 9.3. DHCPv6 Relay Behavior 793 DHCP Relay behavior are not modified by this document. 795 10. IANA Considerations 797 The DHCP options detailed in this document is: 799 - OPTION_DNS_ZONE_TEMPLATE: TBD 801 - OPTION_NAME_SERVER_SET: TBD 803 - OPTION_REVERSE_NAME_SERVER_SET: TBD 805 - OPTION_PUBLIC_KEY: TBD 807 11. Security Considerations 809 11.1. DNSSEC is recommended to authenticate DNS hosted data 811 It is recommended that the (Reverse) DNS Homenet Zone is signed with 812 DNSSEC. The zone may be signed by the CPE or by a third party. We 813 recommend the zone to be signed by the CPE, and that the signed zone 814 is uploaded. 816 11.2. Channel between the CPE and ISP DHCP Server MUST be secured 818 The document considers that the channel between the CPE and the ISP 819 DHCP Server is trusted. More specifically, the CPE is authenticated 820 and the exchanged messages are protected. The current document does 821 not specify how to secure the channel. [RFC3315] proposes a DHCP 822 authentication and message exchange protection, [RFC4301], [RFC5996] 823 propose to secure the channel at the IP layer. 825 In fact, the channel MUST be secured because the CPE provides 826 authentication credentials. Unsecured channel may result in CPE 827 impersonation attacks. 829 11.3. CPEs are sensitive to DoS 831 CPE have not been designed for handling heavy load. The CPE are 832 exposed on the Internet, and their IP address is publicly published 833 on the Internet via the DNS. This makes the Home Network sensitive 834 to Deny of Service Attacks. The resulting outsourcing architecture 835 is described in [I-D.mglt-homenet-front-end-naming-delegation]. This 836 document shows how the outsourcing architecture can be automatically 837 set. 839 12. Acknowledgment 841 We would like to thank Tomasz Mrugalski, Marcin Siodelski and Bernie 842 Volz for their comments on the design of the DHCP Options. We would 843 also like to thank Mark Andrews, Andrew Sullivan and Lorenzo Colliti 844 for their remarks on the architecture design. The designed solution 845 has been largely been inspired by Mark Andrews's document 846 [I-D.andrews-dnsop-pd-reverse] as well as discussions with Mark. 848 13. References 850 13.1. Normative References 852 [RFC1034] Mockapetris, P., "Domain names - concepts and facilities", 853 STD 13, RFC 1034, November 1987. 855 [RFC1996] Vixie, P., "A Mechanism for Prompt Notification of Zone 856 Changes (DNS NOTIFY)", RFC 1996, August 1996. 858 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 859 Requirement Levels", BCP 14, RFC 2119, March 1997. 861 [RFC2136] Vixie, P., Thomson, S., Rekhter, Y., and J. Bound, 862 "Dynamic Updates in the Domain Name System (DNS UPDATE)", 863 RFC 2136, April 1997. 865 [RFC2181] Elz, R. and R. Bush, "Clarifications to the DNS 866 Specification", RFC 2181, July 1997. 868 [RFC2845] Vixie, P., Gudmundsson, O., Eastlake, D., and B. 869 Wellington, "Secret Key Transaction Authentication for DNS 870 (TSIG)", RFC 2845, May 2000. 872 [RFC2930] Eastlake, D., "Secret Key Establishment for DNS (TKEY 873 RR)", RFC 2930, September 2000. 875 [RFC2931] Eastlake, D., "DNS Request and Transaction Signatures ( 876 SIG(0)s)", RFC 2931, September 2000. 878 [RFC3007] Wellington, B., "Secure Domain Name System (DNS) Dynamic 879 Update", RFC 3007, November 2000. 881 [RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., 882 and M. Carney, "Dynamic Host Configuration Protocol for 883 IPv6 (DHCPv6)", RFC 3315, July 2003. 885 [RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S. 886 Rose, "DNS Security Introduction and Requirements", RFC 887 4033, March 2005. 889 [RFC4034] Arends, R., Austein, R., Larson, M., Massey, D., and S. 890 Rose, "Resource Records for the DNS Security Extensions", 891 RFC 4034, March 2005. 893 [RFC4035] Arends, R., Austein, R., Larson, M., Massey, D., and S. 894 Rose, "Protocol Modifications for the DNS Security 895 Extensions", RFC 4035, March 2005. 897 [RFC4301] Kent, S. and K. Seo, "Security Architecture for the 898 Internet Protocol", RFC 4301, December 2005. 900 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 901 (TLS) Protocol Version 1.2", RFC 5246, August 2008. 903 [RFC5936] Lewis, E. and A. Hoenes, "DNS Zone Transfer Protocol 904 (AXFR)", RFC 5936, June 2010. 906 [RFC5996] Kaufman, C., Hoffman, P., Nir, Y., and P. Eronen, 907 "Internet Key Exchange Protocol Version 2 (IKEv2)", RFC 908 5996, September 2010. 910 [RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer 911 Security Version 1.2", RFC 6347, January 2012. 913 [RFC6672] Rose, S. and W. Wijngaards, "DNAME Redirection in the 914 DNS", RFC 6672, June 2012. 916 13.2. Informational References 918 [I-D.andrews-dnsop-pd-reverse] 919 Andrews, M., "Automated Delegation of IP6.ARPA reverse 920 zones with Prefix Delegation", draft-andrews-dnsop-pd- 921 reverse-02 (work in progress), November 2013. 923 [I-D.mglt-homenet-front-end-naming-delegation] 924 Migault, D., Cloetens, W., Griffiths, C., and R. Weber, 925 "IPv6 Home Network Naming Delegation", draft-mglt-homenet- 926 front-end-naming-delegation-03 (work in progress), October 927 2013. 929 [I-D.sury-dnsext-cname-dname] 930 Sury, O., "CNAME+DNAME Name Redirection", draft-sury- 931 dnsext-cname-dname-00 (work in progress), April 2010. 933 Appendix A. Scenarios and impact on the End User 935 This section details various scenarios and discuss their impact on 936 the end user. 938 A.1. Base Scenario 940 The base scenario is the one described in Section 4. It is typically 941 the one of an ISP that manages the DHCP Server, and all DNS servers. 943 The end user subscribes to the ISP (foo), and at subscription time 944 registers for example.foo as its Registered Homenet Domain 945 example.foo. Since the ISP knows the Registered Homenet Domain and 946 the Public Authoritative Master(s) the ISP is able to build the DNS 947 Homenet Zone Template. 949 The ISP manages the DNS Template Server, so it is able to load the 950 DNS Homenet Zone Template on the DNS Template Server. 952 When the CPE is plugged (at least the first time), it provides its 953 Public Key to the DHCP Server. In this scenario, the DHCP Server and 954 the DNS Servers are managed by the ISP so the DHCP Server can provide 955 authentication credentials of the CPE to enable secure authenticated 956 transaction between the CPE and these DNS servers. More 957 specifically, credentials are provided to: 959 - Public Authoritative Name Server Set 961 - Reverse Public Authoritative Name Server Set 963 - DNS Template Server 965 The CPE can update the zone using DNS update or a master / slave 966 configuration in a secure way. 968 The main advantage of this scenario is that the naming architecture 969 is configured automatically and transparently for the end user. 971 The drawbacks are that the end user uses a Registered Homenet Domain 972 managed by the ISP and that it relies on the ISP naming 973 infrastructure. 975 A.2. Third Party Registered Homenet Domain 977 This section considers the case when the end user wants its home 978 network to use example.com as a Registered Homenet Domain instead of 979 example.foo that has been assigned by the ISP. We also suppose that 980 example.com is not managed by the ISP. 982 This can also be achieved without any configuration. When the end 983 user buys the domain name example.com, it may request to redirect the 984 name example.com to example.foo using static redirection with CNAME 985 [RFC2181], [RFC1034], DNAME [RFC6672] or CNAME+DNAME 986 [I-D.sury-dnsext-cname-dname]. 988 This configuration is performed once when the domain name example.com 989 is registered. The only information the end user needs to know is 990 the domain name assigned by the ISP. Once this configuration is done 991 no additional configuration is needed anymore. More specifically, 992 the CPE may be changed, the zone can be updated as in Appendix A.1 993 without any additional configuration from the end user. 995 The main advantage of this scenario is that the end user benefits 996 from the Zero Configuration of the Base Scenario Appendix A.1. Then, 997 the end user is able to register for its home network an unlimited 998 number of domain names provided by an unlimited number of different 999 third party providers. 1001 The drawback of this scenario may be that the end user still rely on 1002 the ISP naming infrastructure. Note that the only case this may be 1003 inconvenient is when the DNS Servers provided by the ISPs results in 1004 high latency. 1006 A.3. Third Party DNS Infrastructure 1008 This scenario considers that the end user uses example.com as a 1009 Registered Homenet Domain, and does not want to rely on the 1010 authoritative servers provided by the ISP. 1012 In this section we limit the outsourcing to the Public Authoritative 1013 Name Server Set and Public Authoritative Master(s) to a third party. 1014 All other DNS Servers DNS Template Server, Reverse Public 1015 Authoritative Master(s) and Reverse Public Authoritative Name Server 1016 Set remain managed by the ISP. The reason we consider that Reverse 1017 Public Authoritative Masters(s) and Reverse Public Authoritative Name 1018 Server Set remains managed by the ISP are that the prefix is managed 1019 by the ISP, so outsourcing these resources requires some redirection 1020 agreement with the ISP. More specifically the ISP will need to 1021 configure the redirection on one of its Reverse DNS Servers. That 1022 said, outsourcing these resources is similar as outsourcing Public 1023 Authoritative Name Server Set and Public Authoritative Master(s) to a 1024 third party. Similarly, the DNS Template Server can be easily 1025 outsourced as detailed in this section 1027 Outsourcing Public Authoritative Name Server Set and Public 1028 Authoritative Master(s) requires: 1030 - 1) Updating the DNS Homenet Zone Template: this can be easily done 1031 as detailed in Section 6 as the DNS Template Server is still 1032 managed by the ISP. Such modification can be performed once by 1033 any CPE. Once this modification has been performed, the CPE 1034 can be changed, the Public Key of the CPE may be changed, this 1035 does not need to be done another time. One can imagine a GUI 1036 on the CPE asking the end user to fill the field with 1037 Registered Homenet Domain, optionally Public Authoritative 1038 Master(s), with a button "Configure DNS Homenet Zone Template". 1040 - 2) Updating the DHCP Server Information. In fact the Reverse 1041 Public Authoritative Name Server Set returned by the ISP is 1042 modified. One can imagine a GUI interface that enables the end 1043 user to modify its profile parameters. Again, this 1044 configuration update is done once-for-ever. 1046 - 3) Upload the authentication credential of the CPE, that is the 1047 Public Key of the CPE, to the third party. Unless we use 1048 specific mechanisms, like communication between the DHCP Server 1049 and the third party, or a specific token that is plugged into 1050 the CPE, this operation is likely to be performed every time 1051 the CPE is changed, and every time the Public Key generated by 1052 the CPE is changed. 1054 The main advantage of this scenario is that the DNS infrastructure is 1055 completely outsourced to the third party. Most likely the Public Key 1056 that authenticate the CPE need to be configured for every CPE. 1057 Configuration is expected to be CPE live-long. 1059 Appendix B. Document Change Log 1061 [RFC Editor: This section is to be removed before publication] 1063 -03: Working Version Major modifications are: 1065 - Redesigning options/scope: according to feed backs received from 1066 the IETF89 presentation in the dhc WG. 1068 - Redesigning architecture: according to feed backs received from 1069 the IETF89 presentation in the homenet WG, discussion with Mark 1070 and Lorenzo. 1072 -02: Working Version Major modifications are: 1074 - Redesigning options/scope: As suggested by Bernie Volz 1076 -01: Working Version Major modifications are: 1078 - Remove the DNS Zone file construction: As suggested by Bernie Volz 1080 - DHCPv6 Client behavior: Following options guide lines 1082 - DHCPv6 Server behavior: Following options guide lines 1084 -00: version published in the homenet WG. Major modifications are: 1086 - Reformatting of DHCP Options: Following options guide lines 1088 - DHCPv6 Client behavior: Following options guide lines 1090 - DHCPv6 Server behavior: Following options guide lines 1092 -00: First version published in dhc WG. 1094 Authors' Addresses 1096 Daniel Migault 1097 Orange 1098 38 rue du General Leclerc 1099 92794 Issy-les-Moulineaux Cedex 9 1100 France 1102 Phone: +33 1 45 29 60 52 1103 Email: daniel.migault@orange.com 1105 Wouter Cloetens 1106 SoftAtHome 1107 vaartdijk 3 701 1108 3018 Wijgmaal 1109 Belgium 1111 Email: wouter.cloetens@softathome.com 1113 Chris Griffiths 1114 Dyn 1115 150 Dow Street 1116 Manchester, NH 03101 1117 US 1119 Email: cgriffiths@dyn.com 1120 URI: http://dyn.com 1122 Ralf Weber 1123 Nominum 1124 2000 Seaport Blvd #400 1125 Redwood City, CA 94063 1126 US 1128 Email: ralf.weber@nominum.com 1129 URI: http://www.nominum.com