idnits 2.17.1 draft-mglt-homenet-front-end-naming-delegation-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Line 301 has weird spacing: '... Domain t +-...' -- The document date (November 6, 2012) is 4188 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 5246 (Obsoleted by RFC 8446) ** Obsolete normative reference: RFC 5996 (Obsoleted by RFC 7296) ** Obsolete normative reference: RFC 6347 (Obsoleted by RFC 9147) 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 Francetelecom - Orange 4 Intended status: Standards Track W. Cloetens 5 Expires: May 10, 2013 SoftAtHome 6 P. Lemordant 7 Francetelecom - Orange 8 C. Griffiths 9 Comcast Cable Communications 10 November 6, 2012 12 IPv6 Home Network Front End Naming Delegation 13 draft-mglt-homenet-front-end-naming-delegation-01.txt 15 Abstract 17 CPEs are designed to provide IP connectivity to the Home Network. 18 Most of the CPEs are also providing the IP addresses of the nodes of 19 the Home Network. This makes CPEs good candidates for hosting the 20 Naming Service that would make devices reachable from the Home 21 Network but also from the Internet. 23 CPEs have not been designed to host a Naming Service reachable from 24 the Internet. This would expose the CPEs and the Home Network to 25 resource exhaustion which would result in making the Home Network 26 unreachable, and most probably would also affect the Home Network 27 inner communications. 29 This document describes an Front End Naming Architecture where the 30 CPEs manage the DNS(SEC) zone for its Home Network, and outsource the 31 zone to Public Server for resolution coming from the Internet. 33 The goal of the document is first to describe a Naming Architecture 34 that fulfills Home Network Naming requirements without exposing the 35 CPE to resource exhaustion. Then we intend the CPEs to be easily 36 configured by the End Users, and describe the necessary information 37 the End User is expect to provide to the CPE. 39 Status of this Memo 41 This Internet-Draft is submitted in full conformance with the 42 provisions of BCP 78 and BCP 79. 44 Internet-Drafts are working documents of the Internet Engineering 45 Task Force (IETF). Note that other groups may also distribute 46 working documents as Internet-Drafts. The list of current Internet- 47 Drafts is at http://datatracker.ietf.org/drafts/current/. 49 Internet-Drafts are draft documents valid for a maximum of six months 50 and may be updated, replaced, or obsoleted by other documents at any 51 time. It is inappropriate to use Internet-Drafts as reference 52 material or to cite them other than as "work in progress." 54 This Internet-Draft will expire on May 10, 2013. 56 Copyright Notice 58 Copyright (c) 2012 IETF Trust and the persons identified as the 59 document authors. All rights reserved. 61 This document is subject to BCP 78 and the IETF Trust's Legal 62 Provisions Relating to IETF Documents 63 (http://trustee.ietf.org/license-info) in effect on the date of 64 publication of this document. Please review these documents 65 carefully, as they describe your rights and restrictions with respect 66 to this document. Code Components extracted from this document must 67 include Simplified BSD License text as described in Section 4.e of 68 the Trust Legal Provisions and are provided without warranty as 69 described in the Simplified BSD License. 71 Table of Contents 73 1. Requirements notation . . . . . . . . . . . . . . . . . . . . 4 74 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 75 3. Front End Naming Architecture Requirements . . . . . . . . . . 5 76 4. Front End Naming Architecture Presentation . . . . . . . . . . 6 77 5. Front End Naming Architecture Description . . . . . . . . . . 8 78 5.1. Setting the Homenet Authoritative Server . . . . . . . . . 8 79 5.2. Setting the Homenet View . . . . . . . . . . . . . . . . . 8 80 5.3. Setting the Public View . . . . . . . . . . . . . . . . . 9 81 5.4. Synchronizing the Public View . . . . . . . . . . . . . . 9 82 5.5. Securing the Synchronization . . . . . . . . . . . . . . . 10 83 5.6. Setting the Homenet Resolution Server . . . . . . . . . . 11 84 5.7. Additional Views . . . . . . . . . . . . . . . . . . . . . 11 85 6. CPE's interface Recommendations . . . . . . . . . . . . . . . 11 86 7. Position toward Homenet Architecture . . . . . . . . . . . . . 12 87 8. Security Considerations . . . . . . . . . . . . . . . . . . . 13 88 8.1. Names are less secure than IP addresses . . . . . . . . . 13 89 8.2. Names are less volatile than IP addresses . . . . . . . . 13 90 8.3. DNSSEC is recommended to authenticate DNS hosted data . . 14 91 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 92 10. Acknowledgment . . . . . . . . . . . . . . . . . . . . . . . . 14 93 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 15 94 11.1. Normative References . . . . . . . . . . . . . . . . . . . 15 95 11.2. Informational References . . . . . . . . . . . . . . . . . 15 96 Appendix A. Document Change Log . . . . . . . . . . . . . . . . . 16 97 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 16 99 1. Requirements notation 101 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 102 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 103 document are to be interpreted as described in [RFC2119]. 105 2. Introduction 107 IPv6 provides global IP reachability to almost all nodes of the Home 108 Network even outside the Home Network. However End Users do not want 109 to access to the Services hosted in the Home Network with IPv6 110 addresses, but prefer to use names. 112 CPEs are already providing IPv6 connectivity to the Home Network and 113 generally provide IPv6 addresses or prefixes to the nodes of the Home 114 Network. This makes the CPEs a good candidate to manage binding 115 between names and IP addresses of the nodes. In other words, the CPE 116 is the natural candidate for setting the DNS(SEC) zone file. 118 CPEs are usually low powered devices designed for the Home Network, 119 but not for heavy traffic. CPEs can host the Naming Service for the 120 Home Network but should not be exposed on the Internet. This would 121 expose the CPE to resource exhaustion. As a consequence, it may 122 isolate the Home Network from the Internet and affects the services 123 hosted by the CPEs, thus affecting Home Network communications. As a 124 result, CPE SHOULD NOT host the Naming Service of the Home Network 125 for resolutions coming from the Internet. 127 In this document, we propose that the CPE sets the DNS(SEC) zone of 128 the Home Network. The CPE may generate different zones one for the 129 queries coming from the Home Network, and one for queries coming from 130 the Internet. We respectively call these Zones Homenet View and 131 Public View. The CPE hosts the Homenet View and responds to the 132 associated DNS(SEC) queries coming from the Home Network. For 133 queries coming from the Internet, the CPE outsources the Public View 134 to Public DNS(SEC) Servers that responds to the queries. 136 This document describes the Front End Naming Architecture where the 137 CPE hosts the Naming Service for the Home Network and outsources it 138 for queries from outside the Home Network. We especially insists on 139 the parameters the CPE requires to properly set up the Front End 140 Naming Architecture. 142 Section 3 describes the Front End Naming Architecture requirements. 143 Section 4 presents the different functional entities involved in the 144 Front End Naming Architecture. Section 5 details configuration of 145 the various functional entities as well as how they interact each 146 other.Section 6 is informative and sums up the different inputs the 147 CPE requires from the End User to set up the Front End Naming 148 Architecture. Section 7 positions the described architecture toward 149 the Home Network Architecture. Finally Section 8 provides security 150 considerations. 152 3. Front End Naming Architecture Requirements 154 This section lists and details goals and requirements of Front End 155 Naming Architecture. 157 - REQUIREMENT 1: DNS(SEC) queries for subdomain of the Homenet 158 Domain Name MUST be responded by the Public DNS(SEC) Servers 159 when issued from outside the Home Network. CPE could hardly 160 cope with heavy traffic coming from the Internet. To avoid 161 exposing the CPE to resource exhaustion, the Naming Service is 162 outsourced on the Public DNS(SEC) Servers for traffic coming 163 from the Internet. 165 - REQUIREMENT 2: The CPE MUST NOT, by default, accept any DNS(SEC) 166 queries from outside the Home Network. In some aspects, it 167 rewords the previous requirement. 169 - REQUIREMENT 3: The IP address of the CPE SHOULD NOT be publicly 170 published. This requirement avoids the DNS(SEC) queries 171 incidentally ends up on the CPE. 173 - REQUIREMENT 5: DNS(SEC) queries for subdomain of the Homenet 174 Domain Name MUST be responded by the CPE when issued from the 175 Home Network. To guarantee the Home Network independence in 176 case the Home Network has no connectivity on the Internet, the 177 CPE MUST respond to DNS(SEC) queries for subdomain of the 178 Homenet Domain Name coming from the Home Network. 180 - REQUIREMENT 6: The CPE MUST be able to update the Home Network 181 Zone hosted on the Public DNS(SEC) Servers. 183 - REQUIREMENT 7: The CPE SHOULD be able to provide different views. 184 At least the CPE should be able to handle a view for the Home 185 Network nodes and a view for the nodes outside the Home 186 Network. Home Network nodes that are not supposed to be 187 reachable from outside the Home Network are not expected to be 188 part of the latest view. 190 4. Front End Naming Architecture Presentation 192 This section describes the Front End Naming Architecture and defines 193 the notations used in this document. 195 - Home Network: designates all devices that are behind and managed 196 by the CPE. 198 - Internet: designates the network the CPE is attached to. 200 The CPE connects the Home Network to the Internet. Although the 201 different functional entities listed below MUST NOT necessarily be 202 hosted on the CPE, we assume in this document they are hosted on the 203 CPE: 205 - Homenet Resolving Server: is the DNS Resolver Server of the Home 206 Network. Typically its IP address is announced via DHCPv6. 207 Most of DNS(SEC) queries from nodes on the Home Network are 208 expected to be addressed to this Homenet Resolving Server. The 209 Homenet Resolving Server is expected to receive queries only 210 from the Home Network. 212 - Homenet Authoritative Server: is the Authoritative Server of the 213 Home Network. This server hosts bindings between FQDNs and IP 214 addresses. Unless cached, most of the DNS(SEC) queries sent 215 from the Home Network that concerns a node in the Home Network 216 are expected to be forwarded to this Homenet Authoritative 217 Server. More specifically DNS(SEC) resolutions sent from the 218 Home Network are expected to be sent to the Homenet Resolving 219 Server. The Homenet Resolver Server is a forwarder and 220 forwards to the Homenet Authoritative Server queries for domain 221 names or subdomain of the Homenet Domain Name. For other 222 resolutions, the Homenet Resolving Server proceeds to 223 traditional DNS(SEC) resolutions over the public DNS(SEC) 224 infrastructure. 226 - Homenet View: is the DNS(SEC) zone that contains all bindings 227 between FQDNs associated to the Homenet Domain Name and IP 228 addresses. The Home Network may have multiple views, but for 229 most Home Networks, a single Homenet View is expected. 230 Information of this Homenet View is only visible from the Home 231 Network. 233 - Public View: is the view that contains the bindings between FQDNs 234 and IP addresses. Unlike the Homenet View, the Public View is 235 expected to be publicly published. The Public View contains 236 information visible from the Internet. It is expected that the 237 Public View is constituted by a subset of the names of the 238 Homenet View. More specifically, devices that are not expected 239 to be reachable from the Internet should not be part of the 240 Public View. In some implementations, the Public View may be 241 equivalent to the the Homenet View. In this latter case Public 242 Views and Homenet Views will be represented by a single file. 244 - Master Public Server: is the part of the CPE that deals with the 245 Public view of the Home Network. The Master Public Server is 246 in charge of providing the Public View to the Public DNS(SEC) 247 Servers. It is not necessarily a DNS(SEC) server. However, in 248 this document we are using DNS mechanisms to synchronize the 249 Public View in the Public DNS(SEC) Servers and the Public View 250 on the CPE. 252 - WAN Interface: the CPE Interface on the Internet. 254 - Homenet Interfaces: the CPE Interfaces on the Home Network. 255 There might be a single or multiple interfaces. 257 The other involved entities are: 259 - Public DNS(SEC) Servers: are the servers on the Internet hosting 260 the Public View of the Home Network. 262 - Homenet Node: a Node of the Home Network 264 - Node: a Node located on the Internet. This Node is expected to 265 be in most of the cases a resolving server. 267 - Homenet Domain Name: The domain name associated to the Home 268 Network. There may be one or multiple domain names. 270 Figure 1 illustrates how a DNS(SEC) resolution is performed from a 271 Node in the Home Network or from a node on the Internet. 273 The Homenet Node sends a DNS(SEC) query to the Homenet Resolving 274 Server (1). When the Homenet Resolving Server receives the DNS(SEC) 275 it notices that query name is a subdomain of the Homenet Domain Name 276 (example.com), and forwards the query to the Homenet Authoritative 277 Server that hosts the Homenet View (2). The Homenet Authoritative 278 Server sends the response to the Homenet Resolving Server (3), which 279 finally sends the response to the Homenet Node (4). 281 For a node located on the Internet, the DNS(SEC) query is requesting 282 the Public DNS infrastructure (.com) which redirects the DNS(SEC) 283 query to the Public DNS(SEC) Servers (a). The Public DNS(SEC) Server 284 sends the response back to the Node (b). 286 +-------------------+ DNS(SEC) Query / Response: 287 | CPE | Q: video.example.com AAAA 288 +---------+ +-------------------+ R: video.example.com 289 | | Q (1) | Homenet Resolving |W AAAA IP6 290 | Homenet | ------>| Server .... |A Internet 291 | Node | <------| ...... | (2) |N +---------+ 292 | | R (4) | (3) ^ v | | | 293 +---------+ +-------------------+I | Node | 294 | Homenet Authorit. |n | | 295 H | Server |t | | 296 o |+-----------------+|e +---------+ 297 m || Homenet View ||r | ^ 298 e || | ||f. Q | |(b) 299 Home Network n || (.local) v | | Master/Slave (a) | | R 300 e |+-----------------+| Synchronization v | 301 Homenet Domain t +-------------------+ | +-------------------+ 302 Name: | Hidden Master | | | Public DNS(SEC) | 303 example.com I | Public Server | | | Servers | 304 n |+-----------------+| | |+-----------------+| 305 t || Public View || v || Public View || 306 e || ||==========|| || 307 r || (example.com) || || (example.com) || 308 f.|+-----------------+| |+-----------------+| 309 +-------------------+ +-------------------+ 311 Figure 1: Front End Naming Architecture Description 313 5. Front End Naming Architecture Description 315 This section provides a more detailed description of the Front End 316 Naming Architecture. More specifically it shows how the entities 317 described in Section 4 are organized to fulfill the requirements of 318 Section 3. 320 5.1. Setting the Homenet Authoritative Server 322 The Homenet Authoritative MUST be configured to reject any queries 323 coming from outside the Home Network, i.e. not from the Homenet 324 Interface. In other words, DNS queries related to the Homenet Domain 325 Names MUST never be received from the WAN Interface. 327 5.2. Setting the Homenet View 329 The Homenet Authoritative Server may be authoritative for multiple 330 Homenet Domain Names and each Homenet Domain Name may be associated 331 with multiple views. 333 The CPE is expected to be provided the various Homenet Domain Names 334 so it can properly generate the associated Homenet Zone files and the 335 appropriate DNS(SEC) settings. 337 5.3. Setting the Public View 339 The Public DNS(SEC) Servers MUST handle all DNS(SEC) queries related 340 to any Homenet Domain Names that are sent from outside the Home 341 Network. 343 The CPE MUST generate the Public View. In the case of multiple 344 Homenet Domain Names, multiple views MUST be generated, and in order 345 to fill properly the SOA and NS field, the CPE must be provided for 346 each Homenet Domain Name the corresponding Public DNS(SEC) name, and 347 IP addresses. 349 5.4. Synchronizing the Public View 351 Uploading and dynamically updating the zone file on the Public 352 Servers can be seen as zone provisioning between the CPE (Hidden 353 Master) and the Public Server (Slave Server). This can be handled 354 either in band or out of band. DNS dynamic update [RFC2136] may be 355 used. However, in this section we detail how to take advantage of 356 the DNS slave / master architecture to deploy updates to public 357 zones. 359 The Public DNS Server is configured as a slave for the Homenet Domain 360 Name. This slave configuration has been previously agreed between 361 the End User and the provider of the Public DNS Servers. The CPE is 362 hosting the Public Zone files associated to the various Homenet 363 Domain Names and associated views. Each of these files are 364 associated a Public Server. In order to set the master/ slave 365 architecture, the CPE acts as a Hidden Master Public Server, which is 366 a regular Authoritative DNS(SEC) Server listening on the WAN 367 interface. 369 The Hidden Master Public Server is only expected to initiate AXFR 370 [RFC1034], IXFR [RFC1995] transfers to configured slave DNS servers. 371 The Hidden Master Public Server should send NOTIFY messages [RFC1996] 372 in order to update Public DNS server zones as updates occur. 374 The CPE MUST be configured to send NOTIFY only when necessary. It is 375 recommended for example that it checks first the SOA on the Public 376 DNS Server before sending a NOTIFY. In other words, rebooting a CPE 377 SHOULD NOT systematically trigger a NOTIFY message. 379 Hidden Master Public Server differs from the Homenet Authoritative 380 Server by: 382 - Interface: the Homenet Authoritative Server listens on the 383 Homenet Interface whereas the Hidden Master Public Server 384 listen on the WAN Interface 386 - View: Homenet Authoritative Server hosts the names that are 387 available on the Home Network, whereas the Hidden Master Public 388 Server hosts the names that are publicly available. These two 389 zones may differ since some of the nodes may not be reached 390 from outside the Home Network. 392 - Traffic: Homenet Authoritative Server expects traffic from the 393 Home Network, whereas the Hidden Master Public Server only 394 accepts traffic from the Public Servers. 396 - Function: Homenet Authoritative Servers acts as an authoritative 397 DNS Server on the Home Network, whereas the Hidden Master 398 Public Server only synchronizes with the Public DNS Servers. 400 In this document, Master Public Server differs from the Homenet 401 Authoritative Server as different functions. Both functions may be 402 implemented by a single running instance of Authoritative Servers. 404 5.5. Securing the Synchronization 406 Exchange between the Public Servers and the CPE MUST be secured, at 407 least for integrity protection and for authentication. This is the 408 case whatever mechanism is used between the CPE and the Public 409 DNS(SEC) Servers. 411 TSIG [RFC2845] can be used to secure the DNS communications between 412 the CPE and the Public DNS(SEC) Servers. TKEY [RFC2931] can be used 413 for re-keying the key used for TSIG. Using TSIG and TKEY requires 414 that this mechanism is implemented on the DNS(SEC) Server's 415 implementation running on the CPE. One disadvantage is that TKEY 416 does not provides authentication mechanism, and the initial shared 417 secret must be set manually. 419 Protocols like TLS [RFC5246] / DTLS [RFC6347] can be used to secure 420 the transactions between the Public Servers and the CPE. Their use 421 would require the implementations to integrate TLS/DTLS as a security 422 layer. TLS/DTLS can use certificates to authenticate the Public 423 Server and the CPE. For example, the certificates can be hosted on a 424 dongle. 426 IPsec [RFC4301] IKEv2 [RFC5996] can also be used to secure the 427 transactions between the CPE and the Public Servers. IKEv2 provides 428 multiple authentications possibilities with its EAP framework. Then, 429 IPsec security does not require any changes of the DNS applications. 431 For these reasons, we recommend using IPsec. 433 5.6. Setting the Homenet Resolution Server 435 The Homenet Resolving Server MUST be configured as a DNS forwarder. 436 When a DNS(SEC) query coming from the Home Network concerns a Homenet 437 Domain Name or a Homenet Subdomain Name, the resolution MUST be 438 performed with the Homenet Authoritative Server. If the Home Network 439 has multiple Homenet Domain Names, multiple forwarding rules may be 440 applied. 442 To properly configure a basic configuration, the Homenet Resolving 443 Server needs to be informed of the Homenet Domain Names and 444 associated Homenet Authoritative Server. They may be one or multiple 445 associated Homenet Authoritative Servers. The same Authoritative 446 Naming Server may be used for multiple Homenet Domain Names. 448 5.7. Additional Views 450 In this document, we considered the Public and Homenet View. Each of 451 these Views may have additional views. 453 6. CPE's interface Recommendations 455 This section describes the various objects that are required to 456 properly set the Front End Naming Architecture. This section is 457 informational, and is intended to clarify the information handled by 458 the CPE and the various settings to be done. 460 A Public Server is defined with the following information: 462 - Public Server Name: The associated FQDN of the Public Server 464 - IP addresses: The list of IP addresses associated to the Public 465 Server. This list should not be provided by the End User. 466 Instead, it should be provided by performing a DNSSEC exchange. 467 If the Public Server Name DNS resolution cannot be performed 468 with DNSSEC, then it is recommended to provide this field. 469 This list of IP address is used to generate the Public View 470 with the proper values for SOA and NS and associated AAAA 471 fields. 473 - Public Server Management Name: The FQDN of the management 474 interface. This Management interface designated who the CPE is 475 synchronizing its Public View with. 477 - Public Server Management IP addresses: The list of IP addresses 478 associated to the Public Server Management Name. This field is 479 not expected to be filled by the End User, but to be derived 480 from the Public Server Management Name with a DNS(SEC) query. 482 - Authentication Method: How the CPE authenticates itself to the 483 Public Server. 485 - Authentication data: Associated Data. 487 To set a View one needs to have the following information: 489 - Homenet Domain Name: The Domain Name of the zone. 491 - Public Server Name (optional): The Server that are expected to 492 host the View. It is required both to field the SOA, NS and 493 associated AAAA as well as to define where the View has to be 494 uploaded. If the View is the Homenet View and the Homenet 495 Authoritative Server is hosted on the CPE, then, this 496 information is not required. 498 - Rules: Defines specific rules for deriving the View. Example of 499 rule s may be a list of FQDNs or IP addresses that MUST be 500 included or removed... 502 - DNSSEC Data: DNSSEC data required to generate the DNSSEC zone. 503 This can be the various DNSSEC Keys for example. 505 First the CPE MUST reject DNS queries received from the WAN 506 Interface. Then the CPE MUST list the Homenet Views and Public 507 Views. Homenet Views are those without the Public Server Name 508 specified and are loaded on the Homenet Authoritative Server. The 509 Homenet Resolving Server is configured as a forwarder for these 510 Views. Public Views are loaded on the Master Public Server, the 511 communications between the Master Public Server and the Public 512 Servers are secured, with an IPsec authenticated and encrypted 513 traffic flow for example. 515 7. Position toward Homenet Architecture 517 This section positions the Front End Naming Architecture toward the 518 Naming recommendation of [I-D.chown-homenet-arch]. 520 The Front End Naming Architecture has been designed to favor 521 unmanaged operations. Naming configuration is automatically 522 performed by the CPE. 524 The Front End Naming Architecture provides the End User a mean to 525 assign names to their devices and associate these names to an 526 Internet domain. With traditional naming configuration that sets an 527 "search" field for the resolvers, the Front End Naming Architecture 528 provides relative naming resolution. The search field is 529 configurable on the DHCPv6 Server hosted on the CPE. 531 Homenet devices can be attached in multiple local and Internet name 532 spaces. The Front End Naming Architecture works internally and 533 externally depending where the End User is. With Views, not all 534 devices are visible from the Internet. 536 The Front End Naming Architecture completely coexists with the 537 Internet name services. 539 With the Homenet View hosted on the CPE, Name resolution and service 540 discovery for reachable devices must continue to function if the 541 local network is disconnected from the global Internet. 543 8. Security Considerations 545 The Front End Naming Architecture described in this document solves 546 exposing the CPE's DNS service as a DoS attack vector. 548 8.1. Names are less secure than IP addresses 550 This document describes how an End User can make his services and 551 devices from his Home Network reachable on the Internet with Names 552 rather than IP addresses. This exposes the Home Network to attackers 553 since names are expected to provide less randomness than IP 554 addresses. The naming delegation protects the End User's privacy by 555 not providing the complete zone of the Home Network to the ISP. 556 However, using the DNS with names for the Home Network exposes the 557 Home Network and its components to dictionary attacks. In fact, with 558 IP addresses, the Interface Identifier is 64 bit length leading to 559 2^64 possibilities for a given subnetwork. This is not to mention 560 that the subnet prefix is also of 64 bit length, thus providing 561 another 2^64 possibilities. On the other hand, names used either for 562 the Home Network domain or for the devices present less randomness 563 (livebox, router, printer, nicolas, jennifer, ...) and thus exposes 564 the devices to dictionary attacks. 566 8.2. Names are less volatile than IP addresses 568 IP addresses may be used to locate a device, a host or a Service. 569 However, Home Networks are not expected to be assigned the same 570 Prefix over time. As a result observing IP addresses provides some 571 ephemeral information about who is accessing the service. On the 572 other hand, Names are not expected to be has volatile as IP 573 addresses. As a result, logging Names, over time, may be more 574 valuable that logging IP addresses, especially to profile End User's 575 characteristics. 577 PTR provides a way to bind an IP address to a Name. In that sense 578 responding to PTR DNS queries may affect the End User's Privacy. For 579 that reason we recommend that End Users may choose to respond or not 580 to PTR DNS queries and may return a NXDOMAIN response. 582 8.3. DNSSEC is recommended to authenticate DNS hosted data 584 The document describes how the Secure Delegation can be set between 585 the Delegating DNS Server and the Delegated DNS Server. 587 Deploying DNSSEC is recommended since in some cases the information 588 stored in the DNS is used by the ISP or an IT departments to grant 589 access. For example some Servers may performed a PTR DNS query to 590 grant access based on host names. With the described Delegating 591 Naming Architecture, the ISP or the IT department MUST take into 592 consideration that the CPE is outside its area of control. As such, 593 with DNS, DNS responses may be forged, resulting in isolating a 594 Service, or not enabling a host to access a service. ISPs or IT 595 department may not base their access policies on PTR or any DNS 596 information. DNSSEC fulfills the DNS lack of trust, and we recommend 597 to deploy DNSSEC on CPEs. 599 9. IANA Considerations 601 This document has no actions for IANA. 603 10. Acknowledgment 605 The authors wish to thank Ole Troan for pointing out issues with the 606 IPv6 routed home concept and placing the scope of this document in a 607 wider picture, Mark Townsley for encouragement and injecting a 608 healthy debate on the merits of the idea, Ulrik de Bie for providing 609 alternative solutions, Paul Mockapetris for pointing out issues of 610 the trustworthiness of a reverse lookup, and Christian Jacquenet for 611 seeing the value from a Service Provider point of view. 613 11. References 614 11.1. Normative References 616 [RFC1034] Mockapetris, P., "Domain names - concepts and facilities", 617 STD 13, RFC 1034, November 1987. 619 [RFC1995] Ohta, M., "Incremental Zone Transfer in DNS", RFC 1995, 620 August 1996. 622 [RFC1996] Vixie, P., "A Mechanism for Prompt Notification of Zone 623 Changes (DNS NOTIFY)", RFC 1996, August 1996. 625 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 626 Requirement Levels", BCP 14, RFC 2119, March 1997. 628 [RFC2136] Vixie, P., Thomson, S., Rekhter, Y., and J. Bound, 629 "Dynamic Updates in the Domain Name System (DNS UPDATE)", 630 RFC 2136, April 1997. 632 [RFC2845] Vixie, P., Gudmundsson, O., Eastlake, D., and B. 633 Wellington, "Secret Key Transaction Authentication for DNS 634 (TSIG)", RFC 2845, May 2000. 636 [RFC2931] Eastlake, D., "DNS Request and Transaction Signatures ( 637 SIG(0)s)", RFC 2931, September 2000. 639 [RFC4301] Kent, S. and K. Seo, "Security Architecture for the 640 Internet Protocol", RFC 4301, December 2005. 642 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 643 (TLS) Protocol Version 1.2", RFC 5246, August 2008. 645 [RFC5996] Kaufman, C., Hoffman, P., Nir, Y., and P. Eronen, 646 "Internet Key Exchange Protocol Version 2 (IKEv2)", 647 RFC 5996, September 2010. 649 [RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer 650 Security Version 1.2", RFC 6347, January 2012. 652 11.2. Informational References 654 [I-D.chown-homenet-arch] 655 Arkko, J., Chown, T., Weil, J., and O. Troan, "Home 656 Networking Architecture for IPv6", 657 draft-chown-homenet-arch-01 (work in progress), 658 October 2011. 660 Appendix A. Document Change Log 662 [RFC Editor: This section is to be removed before publication] 664 -01: 666 * Added C. Griffiths as co-author. 668 * Updated section 5.4 and other sections of draft to update section 669 on Hidden Master / Slave functions with CPE as Hidden Master/Homenet 670 Server. 672 * For next version, address functions of MDNS within Homenet Lan and 673 publishing details northbound via Hidden Master. 675 -00: First version published. 677 Authors' Addresses 679 Daniel Migault 680 Francetelecom - Orange 681 38 rue du General Leclerc 682 92794 Issy-les-Moulineaux Cedex 9 683 France 685 Phone: +33 1 45 29 60 52 686 Email: mglt.ietf@gmail.com 688 Wouter Cloetens 689 SoftAtHome 690 vaartdijk 3 701 691 3018 Wijgmaal 692 Belgium 694 Phone: 695 Email: wouter.cloetens@softathome.com 696 Philippe Lemordant 697 Francetelecom - Orange 698 2 avenue Pierre Marzin 699 22300 Lannion 700 France 702 Phone: +33 2 96 05 35 11 703 Email: philippe.lemordant@orange.com 705 Chris Griffiths 706 Comcast Cable Communications 707 One Comcast Center 708 Philadelphia, PA 19103 709 US 711 Phone: 712 Fax: 713 Email: chris_griffiths@cable.comcast.com 714 URI: http://www.comcast.com