idnits 2.17.1 draft-mglt-dhc-public-authoritative-server-option-00.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 : ---------------------------------------------------------------------------- ** The abstract seems to contain references ([I-D.mglt-homenet-front-end-naming-delegation]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (July 05, 2013) is 3942 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 3315 (Obsoleted by RFC 8415) ** Obsolete normative reference: RFC 5996 (Obsoleted by RFC 7296) == Outdated reference: A later version (-04) exists of draft-mglt-homenet-front-end-naming-delegation-01 Summary: 3 errors (**), 0 flaws (~~), 2 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 DHC D. Migault (Ed) 3 Internet-Draft Francetelecom - Orange 4 Intended status: Standards Track W. Cloetens 5 Expires: January 06, 2014 SoftAtHome 6 C. Griffiths 7 Dyn 8 R. Weber 9 Nominum 10 July 05, 2013 12 DHCP DNS Public Authoritative Server Option 13 draft-mglt-dhc-public-authoritative-server-option-00.txt 15 Abstract 17 The home network naming architecture as described in 18 [I-D.mglt-homenet-front-end-naming-delegation] requires a complex 19 naming configuration on the CPE. This configuration MAY not be 20 handled easily by the average end user. Furthermore, such 21 misconfiguration MAY result in making home network unreachable. 23 This document proposes a DHCP option that provides the CPE all 24 necessary parameters to set up the home network naming architecture. 26 First, this DHCP option provides automatic configuration and avoids 27 most end users' misconfigurations. Most average end users may not 28 require specific configuration, and their ISP default configuration 29 MAY fully address their needs. In that case, the naming homenet 30 architecture configuration will be completely transparent to the end 31 users. Then, saving naming configuration outside the CPE, makes it 32 resilient to change of CPE or CPE upgrades. Such configuration may 33 also be configured by the end user, via the customer area of their 34 ISP. 36 Status of This Memo 38 This Internet-Draft is submitted in full conformance with the 39 provisions of BCP 78 and BCP 79. 41 Internet-Drafts are working documents of the Internet Engineering 42 Task Force (IETF). Note that other groups may also distribute 43 working documents as Internet-Drafts. The list of current Internet- 44 Drafts is at http://datatracker.ietf.org/drafts/current/. 46 Internet-Drafts are draft documents valid for a maximum of six months 47 and may be updated, replaced, or obsoleted by other documents at any 48 time. It is inappropriate to use Internet-Drafts as reference 49 material or to cite them other than as "work in progress." 51 This Internet-Draft will expire on January 06, 2014. 53 Copyright Notice 55 Copyright (c) 2013 IETF Trust and the persons identified as the 56 document authors. All rights reserved. 58 This document is subject to BCP 78 and the IETF Trust's Legal 59 Provisions Relating to IETF Documents 60 (http://trustee.ietf.org/license-info) in effect on the date of 61 publication of this document. Please review these documents 62 carefully, as they describe your rights and restrictions with respect 63 to this document. Code Components extracted from this document must 64 include Simplified BSD License text as described in Section 4.e of 65 the Trust Legal Provisions and are provided without warranty as 66 described in the Simplified BSD License. 68 Table of Contents 70 1. Requirements notation . . . . . . . . . . . . . . . . . . . . 3 71 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 72 3. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4 73 4. Protocol Overview . . . . . . . . . . . . . . . . . . . . . . 5 74 5. Payload Description . . . . . . . . . . . . . . . . . . . . . 7 75 5.1. DNS Public Authoritative Server Option . . . . . . . . . 7 76 5.2. registered-domain-list . . . . . . . . . . . . . . . . . 8 77 5.3. master-list payload . . . . . . . . . . . . . . . . . . . 8 78 5.4. secure-channel-list payload . . . . . . . . . . . . . . . 8 79 6. Exchange Details . . . . . . . . . . . . . . . . . . . . . . 10 80 6.1. DHCPv6 Server . . . . . . . . . . . . . . . . . . . . . . 10 81 6.2. CPE . . . . . . . . . . . . . . . . . . . . . . . . . . . 10 82 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 83 8. Security Considerations . . . . . . . . . . . . . . . . . . . 11 84 8.1. DNSSEC is recommended to authenticate DNS hosted data . . 11 85 8.2. Channel between the CPE and ISP DHCP Server MUST be 86 secured . . . . . . . . . . . . . . . . . . . . . . . . . 12 87 8.3. CPEs are sensitive to DoS . . . . . . . . . . . . . . . . 12 88 9. Acknowledgment . . . . . . . . . . . . . . . . . . . . . . . 12 89 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 12 90 10.1. Normative References . . . . . . . . . . . . . . . . . . 12 91 10.2. Informational References . . . . . . . . . . . . . . . . 13 92 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 13 94 1. Requirements notation 96 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 97 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 98 document are to be interpreted as described in [RFC2119]. 100 2. Terminology 102 - Customer Premises Equipment: (CPE) is the router providing 103 connectivity to the home network. It is configured and managed 104 by the end user. In this document, the CPE MAY also hosts 105 services such as DHCPv6. This device MAY be provided by the 106 ISP. 108 - Registered Homenet Domain: is the Domain Name associated to the 109 home network. 111 - DNS Homenet Zone: is the DNS zone associated to the home network. 112 This zone is set by the CPE and essentially contains the 113 bindings between names and IP addresses of the nodes of the 114 home network. In this document, the CPE does neither perform 115 any DNSSEC management operations such as zone signing nor 116 provide an authoritative service for the zone. Both are 117 delegated to the Public Authoritative Server. The CPE 118 synchronizes the DNS Homenet Zone with the Public Authoritative 119 Server via a hidden master / slave architecture. The Public 120 Authoritative Server MAY use specific servers for the 121 synchronization of the DNS Homenet Zone: the Public 122 Authoritative Name Server Set. 124 - Public Authoritative Server: performs DNSSEC management 125 operations as well as provides the authoritative service for 126 the zone. In this document, the Public Authoritative Server 127 synchronizes the DNS Homenet Zone with the CPE via a hidden 128 master / slave architecture. The Public Authoritative Server 129 acts as a slave and MAY use specific servers called Public 130 Authoritative Name Server Set. Once the Public Authoritative 131 Server synchronizes the DNS Homenet Zone, it signs the zone and 132 generates the DNSSEC Public Zone. Then the Public 133 Authoritative Server hosts the zone as an authoritative server 134 on the Public Authoritative Master(s). 136 - DNSSEC Public Zone: corresponds to the signed version of the DNS 137 Homenet Zone. It is hosted by the Public Authoritative Server, 138 which is authoritative for this zone, and is reachable on the 139 Public Authoritative Master(s). 141 - Public Authoritative Master(s): are the visible name server 142 hosting the DNSSEC Public Zone. End users' resolutions for the 143 Homenet Domain are sent to this server, and this server is a 144 master for the zone. 146 - Public Authoritative Name Server Set: is the server the CPE 147 synchronizes the DNS Homenet Zone. It is configured as a slave 148 and the CPE acts as master. The CPE sends information so the 149 DNSSEC zone can be set and served. 151 3. Introduction 153 With IPv6, nodes inside the home network are expected to be globally 154 reachable. CPEs are already providing connectivity to the home 155 network, and most of the time already assigns IP addresses to the 156 nodes of the home network using for example DHCPv6. 158 This makes CPE good candidate for defining the DNS zone file of the 159 home network. However, CPEs have not been designed to handle heavy 160 traffic, nor heavy operations. As a consequence, CPE SHOULD neither 161 host the authoritative naming service of the home network, nor handle 162 DNSSEC operations such as zone signing. In addition, CPE are usually 163 managed by end users, and the average end user is most likely not 164 mastering DNSSEC to administrate its DNSSEC zone. As a result, CPE 165 SHOULD outsource both the naming authoritative service and its DNSSEC 166 management operations to a third party. This architecture, 167 designated as the homenet naming architecture is described in 168 [I-D.mglt-homenet-front-end-naming-delegation], and the third party 169 is designated as the Public Authoritative Servers. 171 The home network naming architecture defines how the CPE and the 172 Public Authoritative Servers interact together, so to leverage some 173 of the issues related to the CPE, and the DNSSEC understanding of the 174 average end user. Even though most of the DNSSEC issues are 175 outsourced to the Public Authoritative Servers, setting the homenet 176 naming architecture still requires some configurations. 178 Configuration is fine as it provides the opportunity for advanced end 179 users to make the naming architecture fit their specific needs. 180 However most of the end users do not want to configure the homenet 181 naming architecture. In most cases, the end users wants to subscribe 182 and plug its CPE. The CPE is expected to be configured to set 183 automatically and transparently the appropriated home network naming 184 architecture. 186 Using DHCP options to provide the necessary parameters for setting 187 the homenet naming architecture provides multiple advantages. 188 Firstly, it makes the network configuration independent of the CPE. 190 Any new plugged CPE configures itself according to the provided 191 configuration parameters. Secondly, it saves the configuration 192 outside the CPE, which prevents re-configuring the CPE when it is 193 replaced or reset. Finally ISPs are likely to propose a default 194 homenet naming architecture that may address most of the end users 195 needs. For these end users, no configuration will be performed at 196 any time. This avoids unnecessary configurations or misconfiguration 197 that could result in isolating the home network. For more advanced 198 end users, the configuration MAY be provided also via the web GUI of 199 the ISP's customer area for example. This configuration MAY enable 200 third party Public Authoritative Servers. By doing so, these end 201 users will also benefit from CPE-indepedent configuration and 202 configuration backup. 204 This document considers the architecture described in 205 [I-D.mglt-homenet-front-end-naming-delegation]. The DNS(SEC) zone 206 related to the home network is configured and set by the CPE and 207 hosted on a Public Authoritative Server. 208 [I-D.mglt-homenet-front-end-naming-delegation] describes how the 209 synchronization between the CPE and the Public Authoritative Server 210 is performed. This document describes the DNS Public Authoritative 211 Server DHCP option (DNS_PUBLIC_AUTHORITATIVE_SERVER) that provides 212 the necessary parameters to the CPE to set the architecture described 213 in [I-D.mglt-homenet-front-end-naming-delegation]. 215 Section 4 presents an overview of the DNS Public Authoritative Server 216 DHCP option (DNS_PUBLIC_AUTHORITATIVE_SERVER) and Section 5 describes 217 the format of this option and Section 6 details the exchange between 218 the CPE and the DHCPv6 Server. 220 This document assumes the reader is familiar with 221 [I-D.mglt-homenet-front-end-naming-delegation]. 223 This document assumes that the communication between the CPE and the 224 ISP DHCP Server is protected. This document does not specify which 225 mechanism should be used. [RFC3315] proposes a DHCP authentication 226 and message exchange protection, [RFC4301], [RFC5996] proposes to 227 secure the channel at the IP layer. 229 This document only deals with IPv6 IP addresses and DHCPv6 [RFC3315]. 230 When we mention DHCP, it MUST be understood as DHCPv6. 232 4. Protocol Overview 234 The CPE requests the necessary parameters to set its home network 235 naming configuration to the DHCP server. The DHCP server MAY be, for 236 example, the one of its ISP, that already provides the IPv6 prefix to 237 the CPE. 239 The CPE sends an Option Request DHCP Option (ORO) [RFC3315] for the 240 DHCP DNS Public Authoritative Server Option 241 (DNS_PUBLIC_AUTHORITATIVE_SERVER) 243 If available, the DHCP server sends back one or more DHCP DNS Public 244 Authoritative Server Option (DNS_PUBLIC_AUTHORITATIVE_SERVER), 245 depending if the end user has registered to one or multiple Public 246 Authoritative Servers. 248 A CPE MAY be associated to one or multiple Registered Homenet Domain 249 and one or multiple Public Authoritative Servers. The CPE builds a 250 zone for each Registered Homenet Domain. These zones are uploaded / 251 synchronized with their associated Public Authoritative Servers. 252 Note that synchronization is performed through master / slave 253 configuration of the DNS servers, thus Public Authoritative Servers 254 are configured to host specific Registered Homenet Domains. On the 255 other hand, a given Homenet Zone MAY be hosted by multiple Public 256 Authoritative Servers. The CPE MUST build properly the DNS Homenet 257 Zone and synchronize properly the hidden master and slaves for the 258 synchronizations. 260 In order to configure properly the DNS Homenet Zone, the CPE SHOULD 261 collect the list of Registered Homenet Domain and their associated 262 Public Authoritative Servers. For each Registered Homenet Domain, 263 the CPE lists the Public Authoritative Servers FQDN and set them as 264 authoritative Name Server (RRset NS) for the zone. The CPE MAY also 265 add in the DNS Homenet Zone their IP addresses (RRsets A or AAAA). 266 This FQDN and IP addresses associated are designated as the Public 267 Authoritative Master(s). 269 Note that how the CPE manage the multiple DNS Homenet Zones is 270 implementation dependent. It MAY synchronize all DNS Homenet Zone 271 with the Public Authoritative Servers, or use zone redirection 272 mechanisms like like CNAME [RFC2181], [RFC1034], DNAME [RFC6672] or 273 CNAME+DNAME [I-D.sury-dnsext-cname-dname]. In the first case, any 274 update requires to update all zone, whereas redirection MAY require 275 only updating a single DNS Homenet Zone. 277 In order to synchronize the DNS Homenet Zone with a Public 278 Authoritative Server, the CPE needs to know how to establish a secure 279 channel with the Public Authoritative Server. The Public 280 Authoritative Server MAY have dedicated servers working as slave to 281 synchronize the DNS Homenet Zone with the CPE. These servers are 282 called Public Authoritative Name Server Set. In addition to these 283 servers, the CPE MUST know which security protocol can be used to 284 secure the channel as well as the security credential. In this 285 document, we only considered Pre-Shared Key (PSK). 287 As a result, the DHCP DNS Public Authoritative Server Option 288 (DNS_PUBLIC_AUTHORITATIVE_SERVER) carries: 290 - Registered Homenet Domain List: the list of Registered Homenet 291 Domain the Public Authoritative Server hosts. 293 - Master : the Public Authoritative Master(s), that is to say the 294 FQDNs provided in the NS RRsets of the Homenet Zones associated 295 to each of the Registered Homenet Domains. IP addresses are 296 derived by the CPE thanks to a DNS(SEC) resolutions. 298 - Secure Channel: the Public Authoritative Name Server Set , that is 299 the FQDN the CPE MUST securely synchronize its DNS Homenet Zone 300 with. This field MUST also specify, the security protocol as 301 well as the security material. 303 5. Payload Description 305 5.1. DNS Public Authoritative Server Option 307 The DHCP DNS Public Authoritative Server Option is constituted of 308 three ordered sub payloads: the registered-domain-list, the master- 309 list and the secure-channel-list payload. 311 0 1 2 3 312 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 313 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 314 |OPTION_DNS_PUBLIC_AUTH_SERVER | option-len | 315 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 316 | registered-domain-list-len | master-list-len | 317 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 318 | secure-channel-list-len | | 319 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + 320 | | 321 / registered-domain-list / 322 | | 323 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 324 | | 325 / master-list / 326 | | 327 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 328 | | 329 / secure-channel-list / 330 | | 331 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 333 - option-code: OPTION_DNS_PUBLIC_AUTH_SERVER 334 - option-len: length of the OPTION_DNS_PUBLIC_AUTH_SERVER field, the 335 option-code and the option-message in octets. 337 - registered-domain-list-len: Length in octets of the list of 338 Registered Homenet Domains field. 340 - master-list-len: Length in octets of the list of the master-list 341 field. 343 - secure-channel-list-len: Length in octets of the Secure Channels 344 field. 346 - registered-domain-list: The list of Registered Homenet Domains. 348 - master-list: The list of Public Authoritative Master(s). 350 - secure-channel-list: The list of Secure Channels 352 5.2. registered-domain-list 354 The registered-domain-list contains a list of fqdn payloads. The 355 fqdn payload is as described below: 357 0 1 2 3 358 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 359 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 360 | fqdn | option-len | 361 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-| 362 | | 363 | fqdn-value | 364 | | 365 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 367 - payload-code: fqdn 369 - option-len: length of the fqdn field, the payload-code and the 370 payload-message in octets. 372 - fqdn-value: fqdn value as specified in [RFC1035] 374 5.3. master-list payload 376 The master-list payload contains a list of fqdn payloads. The fqdn 377 payload is defined in Section 5.2. 379 5.4. secure-channel-list payload 380 The registered-domain-list contains a list of secure-channel 381 payloads. The secure-channel payload is described below. 383 0 1 2 3 384 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 385 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 386 | secure-channel | option-len | 387 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 388 | sec-protocol | sec-cred-type | security-credential-len | 389 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 390 | name-server-set-len | | 391 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ / 392 | | 393 / security-credential (PSK) / 394 | | 395 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 396 / name-server-set | 397 | | 398 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 400 - payload-code: secure-channel-list. Although not necessary, since 401 payloads are ordered, we provide this code to ease 402 implementation and future options. 404 - option-len: Length of the delegated-naming-action-list field, the 405 status-code and the status-message in octets. 407 - sec-protocol: the protocol that secures the exchanges between the 408 CPE and the Public Authoritative Server. Possible protocols 409 are NONE, TSIG, IPSEC. 411 - sec-cred-type: the type of credential used between the CPE and the 412 Public Authoritative Server. The current document considers 413 only PSK that can be used with any of the sec-protocol. 415 - security-credential-len: length of the delegated-naming-action- 416 list field, the sec-cred-type and the security-credential-len 417 in octets. 419 - security-credential: the security credential. In this document, 420 the security credential is of type PSK. 422 - name-server-set-len: length of the name-server-set field and the 423 name-server-set-len in octets. 425 - name-server-set: Public Authoritative Name Server Set encoded as 426 specified in [RFC1035]. Only the FQDN representation is 427 considered in this document. 429 6. Exchange Details 431 This section details the DHCPv6 exchange between the DHCPv6 server 432 and the CPE. 434 6.1. DHCPv6 Server 436 The DHCPv6 server MUST NOT send a DHCP DNS Public Authoritative 437 Server Option (DNS_PUBLIC_AUTHORITATIVE_SERVER) if not requested by 438 the CPE through the DHCP Option Request Option (ORO). 440 In the remaining of this section we suppose the DHCPv6 Server has 441 received a DHCP Option Request Option (ORO) from the CPE for a DHCP 442 DNS Public Authoritative Server Option 443 (DNS_PUBLIC_AUTHORITATIVE_SERVER). 445 If the DHCPv6 Server does not understand the DHCP DNS Public 446 Authoritative Server Option, it ignores the Option as specified in 447 [RFC3315]. 449 If the DHCPv6 has no specific configuration, it MUST return a DHCP 450 DNS Public Authoritative Server Option with the len registered- 451 domain-list-len, master-list-len and secure-channel-list-len set to 452 zero. This response is called the Zero Response and indicates that 453 there are not enough arguments to set the home network architecture. 455 The registered-domain-list is mandatory. If it does not exists, and 456 Zero Response MUST be sent. 458 A zero length for master-list indicates the CPE hosts the zone. In 459 this case, a zero length secure-channel-list is expected. 461 6.2. CPE 463 In this section we assume the CPE has sent a DHCP Option Request 464 Option (ORO) from the CPE for a DHCP DNS Public Authoritative Server 465 Option (DNS_PUBLIC_AUTHORITATIVE_SERVER). 467 An Zero Response indicates the DHCPv6 Server has not a specific 468 configuration for the CPE. 470 A response with an registered-domain-list set to zero MUST be 471 ignored. 473 A zero length for master-list indicates the CPE hosts the zone. A 474 non zero length secure-channel-list MUST be ignored. 476 7. IANA Considerations 478 The DHCP options detailed in this document is: 480 - OPTION_DNS_PUBLIC_AUTH_SERVER: TBD 482 The payload detailed in this document are: 484 - fqdn: TBD 486 - secure-channel: TBD 488 The security-protocol detailed in this document are: 490 - NONE: TBD 492 - TSIG: TBD 494 - IPSEC: TBD 496 The security-credential detailed in this document are: 498 - NONE: TBD 500 - PSK: TBD 502 8. Security Considerations 504 8.1. DNSSEC is recommended to authenticate DNS hosted data 506 The document describes how the Secure Delegation can be set between 507 the Delegating DNS Server and the Delegated DNS Server. 509 Deploying DNSSEC is recommended since in some cases the information 510 stored in the DNS is used by the ISP or an IT department to grant 511 access. For example some Servers may performed a PTR DNS query to 512 grant access based on host names. With the described Delegating 513 Naming Architecture, the ISP or the IT department MUST take into 514 consideration that the CPE is outside its area of control. As such, 515 with DNS, DNS responses may be forged, resulting in isolating a 516 Service, or not enabling a host to access a service. ISPs or IT 517 department may not base their access policies on PTR or any DNS 518 information. DNSSEC fulfills the DNS lack of trust, and we recommend 519 to deploy DNSSEC on CPEs. 521 8.2. Channel between the CPE and ISP DHCP Server MUST be secured 523 In the document we consider that the channel between the CPE and the 524 ISP DHCP Server is trusted. More specifically, we suppose the CPE is 525 authenticated and the exchanged messages are protected. The current 526 document does not specify how to secure the channel. [RFC3315] 527 proposes a DHCP authentication and message exchange protection, 528 [RFC4301], [RFC5996] propose to secure the channel at the IP layer. 530 In fact, the channel MUST be secured because the CPE provides 531 necessary information for the configuration of the Naming Delegation. 532 Unsecured channel may result in setting the Naming Delegation with an 533 non legitimate CPE. The non legitimate CPE would then be redirected 534 the DNS traffic that is intended for the legitimate CPE. This makes 535 the CPE sensitive to three types of attacks. The first one is the 536 Deny Of Service Attack, if for example DNS traffic for a lot of CPEs 537 are redirected to a single CPE. CPE are even more sensitive to this 538 attack since they have been designed for low traffic. The other type 539 of traffic is the DNS traffic hijacking. A malicious CPE may 540 redirect the DNS traffic of the legitimate CPE to one of its server. 541 In return, the DNS Servers would be able to provide DNS Responses and 542 redirect the End Users on malicious Servers. This is particularly 543 used in Pharming Attacks. A third attack may consists in isolating a 544 Home Network by misconfiguring the Naming Delegation for example to a 545 non-existing DNS Server, or with a bad DS value. 547 8.3. CPEs are sensitive to DoS 549 The Naming Delegation Architecture involves the CPE that hosts a DNS 550 Server for the Home Network. CPE have not been designed for handling 551 heavy load. The CPE are exposed on the Internet, and their IP 552 address is publicly published on the Internet via the DNS. This 553 makes the Home Network sensitive to Deny of Service Attacks. The 554 Naming Delegation Architecture described in this document does not 555 address this issue. The issue is addressed by 556 [I-D.mglt-homenet-front-end-naming-delegation]. 558 9. Acknowledgment 560 10. References 562 10.1. Normative References 564 [RFC1034] Mockapetris, P., "Domain names - concepts and facilities", 565 STD 13, RFC 1034, November 1987. 567 [RFC1035] Mockapetris, P., "Domain names - implementation and 568 specification", STD 13, RFC 1035, November 1987. 570 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 571 Requirement Levels", BCP 14, RFC 2119, March 1997. 573 [RFC2181] Elz, R. and R. Bush, "Clarifications to the DNS 574 Specification", RFC 2181, July 1997. 576 [RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., 577 and M. Carney, "Dynamic Host Configuration Protocol for 578 IPv6 (DHCPv6)", RFC 3315, July 2003. 580 [RFC4301] Kent, S. and K. Seo, "Security Architecture for the 581 Internet Protocol", RFC 4301, December 2005. 583 [RFC5996] Kaufman, C., Hoffman, P., Nir, Y., and P. Eronen, 584 "Internet Key Exchange Protocol Version 2 (IKEv2)", RFC 585 5996, September 2010. 587 [RFC6672] Rose, S. and W. Wijngaards, "DNAME Redirection in the 588 DNS", RFC 6672, June 2012. 590 10.2. Informational References 592 [I-D.mglt-homenet-front-end-naming-delegation] 593 Migault, D., Cloetens, W., Lemordant, P., and C. 594 Griffiths, "IPv6 Home Network Front End Naming 595 Delegation", draft-mglt-homenet-front-end-naming- 596 delegation-01 (work in progress), November 2012. 598 [I-D.sury-dnsext-cname-dname] 599 Sury, O., "CNAME+DNAME Name Redirection", draft-sury- 600 dnsext-cname-dname-00 (work in progress), April 2010. 602 Authors' Addresses 604 Daniel Migault 605 Francetelecom - Orange 606 38 rue du General Leclerc 607 92794 Issy-les-Moulineaux Cedex 9 608 France 610 Phone: +33 1 45 29 60 52 611 Email: mglt.ietf@gmail.com 612 Wouter Cloetens 613 SoftAtHome 614 vaartdijk 3 701 615 3018 Wijgmaal 616 Belgium 618 Email: wouter.cloetens@softathome.com 620 Chris Griffiths 621 Dyn 622 150 Dow Street 623 Manchester, NH 03101 624 US 626 Email: cgriffiths@dyn.com 627 URI: http://dyn.com 629 Ralf Weber 630 Nominum 631 2000 Seaport Blvd #400 632 Redwood City, CA 94063 633 US 635 Email: ralf.weber@nominum.com 636 URI: http://www.nominum.com