idnits 2.17.1 draft-ietf-homenet-front-end-naming-delegation-03.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, 2015) is 3214 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 4960 (Obsoleted by RFC 9260) ** Obsolete normative reference: RFC 5246 (Obsoleted by RFC 8446) ** Obsolete normative reference: RFC 6347 (Obsoleted by RFC 9147) == Outdated reference: A later version (-24) exists of draft-ietf-homenet-naming-architecture-dhc-options-02 == Outdated reference: A later version (-08) exists of draft-ietf-opsec-ipv6-host-scanning-07 Summary: 4 errors (**), 0 flaws (~~), 3 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 HOMENET D. Migault (Ed) 3 Internet-Draft Ericsson 4 Intended status: Standards Track R. Weber 5 Expires: January 3, 2016 Nominum 6 R. Hunter 7 Globis Consulting BV 8 C. Griffiths 10 W. Cloetens 11 SoftAtHome 12 July 2, 2015 14 Outsourcing Home Network Authoritative Naming Service 15 draft-ietf-homenet-front-end-naming-delegation-03.txt 17 Abstract 19 RFC7368 'IPv6 Home Networking Architecture Principles' section 3.7 20 describes architecture principles related to naming and service 21 discovery in residential home networks. 23 Customer Edge Routers and other Customer Premises Equipment (CPEs) 24 are designed to provide IP connectivity to home networks. Most CPEs 25 assign IP addresses to the nodes of the home network which makes them 26 good candidates for hosting the naming service. IPv6 provides global 27 connectivity, and nodes from the home network will be reachable from 28 the global Internet. As a result, the naming service is expected to 29 be exposed on the Internet. 31 However, CPEs have not been designed to host such a naming service 32 exposed on the Internet. Running a naming service visible on the 33 Internet may expose the CPEs to resource exhaustion and other 34 attacks, which could make the home network unreachable, and most 35 probably would also affect the internal communications of the home 36 network. 38 In addition, regular end users may not understand, or possess the 39 necessary skills to be able to perform, DNSSEC management and 40 configuration. Misconfiguration may also result in naming service 41 disruption, thus these end users may prefer to rely on third party 42 name service providers. 44 This document describes a homenet naming architecture, where the CPEs 45 manage the DNS zones associated with its own home network, and 46 outsource elements of the naming service (possibly including DNSSEC 47 management) to a third party running on the Internet. 49 Status of This Memo 51 This Internet-Draft is submitted in full conformance with the 52 provisions of BCP 78 and BCP 79. 54 Internet-Drafts are working documents of the Internet Engineering 55 Task Force (IETF). Note that other groups may also distribute 56 working documents as Internet-Drafts. The list of current Internet- 57 Drafts is at http://datatracker.ietf.org/drafts/current/. 59 Internet-Drafts are draft documents valid for a maximum of six months 60 and may be updated, replaced, or obsoleted by other documents at any 61 time. It is inappropriate to use Internet-Drafts as reference 62 material or to cite them other than as "work in progress." 64 This Internet-Draft will expire on January 3, 2016. 66 Copyright Notice 68 Copyright (c) 2015 IETF Trust and the persons identified as the 69 document authors. All rights reserved. 71 This document is subject to BCP 78 and the IETF Trust's Legal 72 Provisions Relating to IETF Documents 73 (http://trustee.ietf.org/license-info) in effect on the date of 74 publication of this document. Please review these documents 75 carefully, as they describe your rights and restrictions with respect 76 to this document. Code Components extracted from this document must 77 include Simplified BSD License text as described in Section 4.e of 78 the Trust Legal Provisions and are provided without warranty as 79 described in the Simplified BSD License. 81 Table of Contents 83 1. Requirements notation . . . . . . . . . . . . . . . . . . . . 3 84 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 85 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 86 4. Architecture Description . . . . . . . . . . . . . . . . . . 6 87 4.1. Architecture Overview . . . . . . . . . . . . . . . . . . 6 88 4.2. Example: Homenet Zone . . . . . . . . . . . . . . . . . . 8 89 4.3. Example: CPE necessary parameters for outsourcing . . . . 10 90 5. Synchronization between CPE and the Synchronization Server . 11 91 5.1. Synchronization with a Hidden Primary . . . . . . . . . . 11 92 5.2. Securing Synchronization . . . . . . . . . . . . . . . . 12 93 5.3. CPE Security Policies . . . . . . . . . . . . . . . . . . 13 94 6. DNSSEC compliant Homenet Architecture . . . . . . . . . . . . 14 95 6.1. Zone Signing . . . . . . . . . . . . . . . . . . . . . . 14 96 6.2. Secure Delegation . . . . . . . . . . . . . . . . . . . . 16 98 7. Handling Different Views . . . . . . . . . . . . . . . . . . 16 99 7.1. Misleading Reasons for Local Scope DNS Zone . . . . . . . 17 100 7.2. Consequences . . . . . . . . . . . . . . . . . . . . . . 17 101 7.3. Guidance and Recommendations . . . . . . . . . . . . . . 18 102 8. Homenet Reverse Zone . . . . . . . . . . . . . . . . . . . . 19 103 9. Renumbering . . . . . . . . . . . . . . . . . . . . . . . . . 19 104 9.1. Hidden Primary . . . . . . . . . . . . . . . . . . . . . 19 105 9.2. Synchronization Server . . . . . . . . . . . . . . . . . 21 106 10. Privacy Considerations . . . . . . . . . . . . . . . . . . . 21 107 11. Security Considerations . . . . . . . . . . . . . . . . . . . 22 108 11.1. Names are less secure than IP addresses . . . . . . . . 22 109 11.2. Names are less volatile than IP addresses . . . . . . . 23 110 11.3. DNS Reflection Attacks . . . . . . . . . . . . . . . . . 23 111 11.3.1. Reflection Attack involving the Hidden Primary . . . 23 112 11.3.2. Reflection Attacks involving the Synchronization 113 Server . . . . . . . . . . . . . . . . . . . . . . . 25 114 11.3.3. Reflection Attacks involving the Public 115 Authoritative Servers . . . . . . . . . . . . . . . 25 116 11.4. Flooding Attack . . . . . . . . . . . . . . . . . . . . 26 117 11.5. Replay Attack . . . . . . . . . . . . . . . . . . . . . 26 118 12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 27 119 13. Acknowledgment . . . . . . . . . . . . . . . . . . . . . . . 27 120 14. References . . . . . . . . . . . . . . . . . . . . . . . . . 27 121 14.1. Normative References . . . . . . . . . . . . . . . . . . 27 122 14.2. Informational References . . . . . . . . . . . . . . . . 29 123 Appendix A. Document Change Log . . . . . . . . . . . . . . . . 30 124 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 32 126 1. Requirements notation 128 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 129 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 130 document are to be interpreted as described in [RFC2119]. 132 2. Introduction 134 IPv6 provides global end to end IP reachability. End users prefer to 135 use names instead of long and complex IPv6 addresses when accessing 136 services hosted in the home network. 138 Customer Edge Routers and other Customer Premises Equipment (CPEs) 139 are already providing IPv6 connectivity to the home network, and 140 generally provide IPv6 addresses or prefixes to the nodes of the home 141 network. This makes CPEs good candidates to manage the binding 142 between names and IP addresses of nodes. In addition, [RFC7368] 143 recommends that home networks be resilient to connectivity disruption 144 from the ISP. This could be achieved by a dedicated device inside 145 the home network that builds the Homenet Zone, thus providing 146 bindings between names and IP addresses. All this makes the CPE the 147 natural candidate for populating the Homenet zone. 149 CPEs are usually low powered devices designed for the home network, 150 but not for terminating heavy traffic. As a result, hosting an 151 authoritative DNS service on the Internet may expose the home network 152 to resource exhaustion and other attacks. This may isolate the home 153 network from the Internet and also impact the services hosted by the 154 CPEs, thus affecting overall home network communication. 156 In order to avoid resource exhaustion and other attacks, this 157 document describes an architecture that outsources the authoritative 158 naming service of the home network. More specifically, the Homenet 159 Zone built by the CPE is outsourced to an Outsourcing Infrastructure. 160 The Outsourcing Infrastructure publishes the corresponding Public 161 Homenet Zone on the Internet. Section 4.1 describes the 162 architecture. In order to keep the Public Homenet Zone up-to-date 163 Section 5 describes how the Homenet Zone and the Public Homenet Zone 164 can be synchronized. The proposed architecture aims at deploying 165 DNSSEC, and the Public Homenet Zone is expected to be signed with a 166 secure delegation. The zone signing and secure delegation may be 167 performed either by the CPE or by the Outsourcing Infrastructure. 168 Section 6 discusses these two alternatives. Section 7 discusses the 169 consequences of publishing multiple representations of the same zone 170 also commonly designated as views. This section provides guidance to 171 limit the risks associated with multiple views. Section 8 discusses 172 management of the reverse zone. Section 9 discusses how renumbering 173 should be handled. Finally, Section 10 and Section 11 respectively 174 discuss privacy and security considerations when outsourcing the 175 Homenet Zone. 177 3. Terminology 179 - Customer Premises Equipment: (CPE) is the router providing 180 connectivity to the home network. It might be configured and 181 managed by the end user. In this document, the CPE might also 182 host services such as DHCPv6. This device might be provided by 183 the ISP. 185 - Registered Homenet Domain: is the Domain Name associated to the 186 home network. 188 - Homenet Zone: is the DNS zone associated with the home network. 189 It is designated by its Registered Homenet Domain. This zone 190 is built by the CPE and contains the bindings between names and 191 IP addresses of the nodes in the home network. The CPE 192 synchronizes the Homenet Zone with the Synchronization Server 193 via a hidden primary / secondary architecture. The Outsourcing 194 Infrastructure may process the Homenet Zone - for example 195 providing DNSSEC signing - to generate the Public Homenet Zone. 196 This Public Homenet Zone is then transmitted to the Public 197 Authoritative Server(s) that publish it on the Internet. 199 - Public Homenet Zone: is the public version of the Homenet Zone. 200 It is expected to be signed with DNSSEC. It is hosted by the 201 Public Authoritative Server(s), which are authoritative for 202 this zone. The Public Homenet Zone and the Homenet Zone might 203 be different. For example some names might not become 204 reachable from the Internet, and thus not be hosted in the 205 Public Homenet Zone. Another example of difference may also 206 occur when the Public Homenet Zone is signed whereas the 207 Homenet Zone is not signed. 209 - Outsourcing Infrastructure: is the combination of the 210 Synchronization Server and the Public Authoritative Server(s). 212 - Public Authoritative Servers: are the authoritative name servers 213 hosting the Public Homenet Zone. Name resolution requests for 214 the Homenet Domain are sent to these servers. For resiliency 215 the Public Homenet Zone SHOULD be hosted on multiple servers. 217 - Synchronization Server: is the server with which the CPE 218 synchronizes the Homenet Zone. The Synchronization Server is 219 configured as a secondary and the CPE acts as primary. There 220 MAY be multiple Synchronization Servers, but the text assumes a 221 single server. In addition, the text assumes the 222 Synchronization Server is a separate entity. This is not a 223 requirement, and when the CPE signs the zone, the 224 synchronization function might also be operated by the Public 225 Authoritative Servers. 227 - Homenet Reverse Zone: The reverse zone file associated with the 228 Homenet Zone. 230 - Reverse Public Authoritative Servers: are the authoritative name 231 server(s) hosting the Public Homenet Reverse Zone. Queries for 232 reverse resolution of the Homenet Domain are sent to this 233 server. Similarly to Public Authoritative Servers, for 234 resiliency, the Homenet Reverse Zone SHOULD be hosted on 235 multiple servers. 237 - Reverse Synchronization Server: is the server with which the CPE 238 synchronizes the Homenet Reverse Zone. It is configured as a 239 secondary and the CPE acts as primary. There MAY be multiple 240 Reverse Synchronization Servers, but the text assumes a single 241 server. In addition, the text assumes the Reverse 242 Synchronization Server is a separate entity. This is not a 243 requirement, and when the CPE signs the zone, the 244 synchronization function might also be operated by the Reverse 245 Public Authoritative Servers. 247 - Hidden Primary: designates the primary server of the CPE, that 248 synchronizes the Homenet Zone with the Synchronization Server. 249 A primary / secondary architecture is used between the CPE and 250 the Synchronization Server. The hidden primary is not expected 251 to serve end user queries for the Homenet Zone as a regular 252 primary server would. The hidden primary is only known to its 253 associated Synchronization Server. 255 4. Architecture Description 257 This section describes the architecture for outsourcing the 258 authoritative naming service from the CPE to the Outsourcing 259 Infrastructure. Section 4.1 describes the architecture, Section 4.2 260 and Section 4.3 illustrates this architecture and shows how the 261 Homenet Zone should be built by the CPE. It also lists the necessary 262 parameters the CPE needs to be able to outsource the authoritative 263 naming service. These two sections are informational and non- 264 normative. 266 4.1. Architecture Overview 268 Figure 1 provides an overview of the architecture. 270 The home network is designated by the Registered Homenet Domain Name 271 -- example.com in Figure 1. The CPE builds the Homenet Zone 272 associated with the home network. How the Homenet Zone is built is 273 out of the scope of this document. The CPE may host or interact with 274 multiple services to determine name-to-address mappings, such as a 275 web GUI, DHCP [RFC6644] or mDNS [RFC6762]. These services may 276 coexist and may be used to populate the Homenet Zone. This document 277 assumes the Homenet Zone has been populated with domain names that 278 are intended to be publicly published and that are publicly 279 reachable. More specifically, names associated with services or 280 devices that are not expected to be reachable from outside the home 281 network or names bound to non-globally reachable IP addresses MUST 282 NOT be part of the Homenet Zone. 284 Once the Homenet Zone has been built, the CPE does not host an 285 authoritative naming service, but instead outsources it to the 286 Outsourcing Infrastructure. The Outsourcing Infrastructure takes the 287 Homenet Zone as an input and publishes the Public Homenet Zone. If 288 the CPE does not sign the Homenet Zone, the Outsourcing 289 Infrastructure may instead sign it on behalf of the CPE. Figure 1 290 provides a more detailed description of the Outsourcing 291 Infrastructure, but overall, it is expected that the CPE provides the 292 Homenet Zone. Then the Public Homenet Zone is derived from the 293 Homenet Zone and published on the Internet. 295 As a result, DNS queries from the DNS resolvers on the Internet are 296 answered by the Outsourcing Infrastructure and do not reach the CPE. 297 Figure 1 illustrates the case of the resolution of node1.example.com. 299 home network +-------------------+ Internet 300 | | 301 | CPE | 302 | | +-----------------------+ 303 +-------+ |+-----------------+| | Public Authoritative | 304 | | || Homenet Zone || | Server(s) | 305 | node1 | || || |+---------------------+| 306 | | || || || Public Homenet Zone || 307 +-------+ || Homenet Domain ||=========|| || 308 || Name || ^ || (example.com) || 309 node1.\ || (example.com) || | |+---------------------+| 310 example.com |+-----------------+| | +-----------------------+ 311 +-------------------+ | ^ | 312 Synchronization | | 313 | | 314 DNSSEC resolution for node1.example.com | v 315 +-----------------------+ 316 | | 317 | DNSSEC Resolver | 318 | | 319 +-----------------------+ 321 Figure 1: Homenet Naming Architecture Description 323 The Outsourcing Infrastructure is described in Figure 2. The 324 Synchronization Server receives the Homenet Zone as an input. The 325 received zone may be transformed to output the Public Homenet Zone. 326 Various operations may be performed here, however this document only 327 considers zone signing as a potential operation. This should occur 328 only when the CPE outsources this operation to the Synchronization 329 Server. On the other hand, if the CPE signs the Homenet Zone itself, 330 the zone would be collected by the Synchronization Server and 331 directly transferred to the Public Authoritative Server(s). These 332 policies are discussed and detailed in Section 6 and Section 7. 334 Internet 336 +------------------------------------------------------+ 337 | Outsourcing Infrastructure | 338 +------------------------------------------------------+ 340 +----------------------+ +----------------------+ 341 | | | | 342 | Synchronization | | Public Authoritative | 343 | Server | | Server(s) | 344 | | | | 345 | +------------------+ | X |+--------------------+| 346 | | Homenet Zone | | ^ || Public Homenet Zone|| 347 =========>| | | | || || 348 ^ | | | | | || || 349 | | | (example.com) | | | || (example.com) || 350 | | +------------------+ | | |+--------------------+| 351 | +----------------------+ | +----------------------+ 352 | Homenet to Public Zone 353 Synchronization transformation 354 from the CPE 356 Figure 2: Outsourcing Infrastructure Description 358 4.2. Example: Homenet Zone 360 This section is not normative and intends to illustrate how the CPE 361 builds the Homenet Zone. 363 As depicted in Figure 1 and Figure 2, the Public Homenet Zone is 364 hosted on the Public Authoritative Server(s), whereas the Homenet 365 Zone is hosted on the CPE. Motivations for keeping these two zones 366 identical are detailed in Section 7, and this section considers that 367 the CPE builds the zone that will be effectively published on the 368 Public Authoritative Server(s). In other words "Homenet to Public 369 Zone transformation" is the identity also commonly designated as "no 370 operation" (NOP). 372 In that case, the Homenet Zone should configure its Name Server RRset 373 (NS) and Start of Authority (SOA) with the values associated with the 374 Public Authoritative Server(s). This is illustrated in Figure 3. 375 public.primary.example.net is the FQDN of the Public Authoritative 376 Server(s), and IP1, IP2, IP3, IP4 are the associated IP addresses. 377 Then the CPE should add the additional new nodes that enter the home 378 network, remove those that should be removed, and sign the Homenet 379 Zone. 381 $ORIGIN example.com 382 $TTL 1h 384 @ IN SOA public.primary.example.net 385 hostmaster.example.com. ( 386 2013120710 ; serial number of this zone file 387 1d ; secondary refresh 388 2h ; secondary retry time in case of a problem 389 4w ; secondary expiration time 390 1h ; maximum caching time in case of failed 391 ; lookups 392 ) 394 @ NS public.authoritative.servers.example.net 396 public.primary.example.net A @IP1 397 public.primary.example.net A @IP2 398 public.primary.example.net AAAA @IP3 399 public.primary.example.net AAAA @IP4 401 Figure 3: Homenet Zone 403 The SOA RRset is defined in [RFC1033], [RFC1035] and [RFC2308]. This 404 SOA is specific, as it is used for the synchronization between the 405 Hidden Primary and the Synchronization Server and published on the 406 DNS Public Authoritative Server(s).. 408 - MNAME: indicates the primary. In our case the zone is published 409 on the Public Authoritative Server(s), and its name MUST be 410 included. If multiple Public Authoritative Server(s) are 411 involved, one of them MUST be chosen. More specifically, the 412 CPE MUST NOT include the name of the Hidden Primary. 414 - RNAME: indicates the email address to reach the administrator. 415 [RFC2142] recommends using hostmaster@domain and replacing the 416 '@' sign by '.'. 418 - REFRESH and RETRY: indicate respectively in seconds how often 419 secondaries need to check the primary, and the time between two 420 refresh when a refresh has failed. Default values indicated by 421 [RFC1033] are 3600 (1 hour) for refresh and 600 (10 minutes) 422 for retry. This value might be too long for highly dynamic 423 content. However, the Public Authoritative Server(s) and the 424 CPE are expected to implement NOTIFY [RFC1996]. So whilst 425 shorter refresh timers might increase the bandwidth usage for 426 secondaries hosting large number of zones, it will have little 427 practical impact on the elapsed time required to achieve 428 synchronization between the Outsourcing Infrastructure and the 429 Hidden Master. As a result, the default values are acceptable. 431 EXPIRE: is the upper limit data SHOULD be kept in absence of 432 refresh. The default value indicated by [RFC1033] is 3600000 433 (approx. 42 days). In home network architectures, the CPE 434 provides both the DNS synchronization and the access to the 435 home network. This device may be plugged and unplugged by the 436 end user without notification, thus we recommend a long expiry 437 timer. 439 MINIMUM: indicates the minimum TTL. The default value indicated by 440 [RFC1033] is 86400 (1 day). For home network, this value MAY 441 be reduced, and 3600 (1 hour) seems more appropriate. 443 4.3. Example: CPE necessary parameters for outsourcing 445 This section specifies the various parameters required by the CPE to 446 configure the naming architecture of this document. This section is 447 informational, and is intended to clarify the information handled by 448 the CPE and the various settings to be done. 450 Synchronization Server may be configured with the following 451 parameters. These parameters are necessary to establish a secure 452 channel between the CPE and the Synchronization Server as well as to 453 specify the DNS zone that is in the scope of the communication: 455 - Synchronization Server: The associated FQDNs or IP addresses of 456 the Synchronization Server. IP addresses are optional and the 457 FQDN is sufficient. To secure the binding name and IP 458 addresses, a DNSSEC exchange is required. Otherwise, the IP 459 addresses should be entered manually. 461 - Authentication Method: How the CPE authenticates itself to the 462 Synchronization Server. This MAY depend on the implementation 463 but this should cover at least IPsec, DTLS and TSIG 465 - Authentication data: Associated Data. PSK only requires a single 466 argument. If other authentication mechanisms based on 467 certificates are used, then CPE private keys, certificates and 468 certification authority should be specified. 470 - Public Authoritative Server(s): The FQDN or IP addresses of the 471 Public Authoritative Server(s). It MAY correspond to the data 472 that will be set in the NS RRsets and SOA of the Homenet Zone. 473 IP addresses are optional and the FQDN is sufficient. To 474 secure the binding between name and IP addresses, a DNSSEC 475 exchange is required. Otherwise, the IP addresses should be 476 entered manually. 478 - Registered Homenet Domain: The domain name used to establish the 479 secure channel. This name is used by the Synchronization 480 Server and the CPE for the primary / secondary configuration as 481 well as to index the NOTIFY queries of the CPE when the CPE has 482 been renumbered. 484 Setting the Homenet Zone requires the following information. 486 - Registered Homenet Domain: The Domain Name of the zone. Multiple 487 Registered Homenet Domains may be provided. This will generate 488 the creation of multiple Public Homenet Zones. 490 - Public Authoritative Server(s): The Public Authoritative 491 Server(s) associated with the Registered Homenet Domain. 492 Multiple Public Authoritative Server(s) may be provided. 494 5. Synchronization between CPE and the Synchronization Server 496 The Homenet Reverse Zone and the Homenet Zone MAY be updated either 497 with DNS UPDATE [RFC2136] or using a primary / secondary 498 synchronization. The primary / secondary mechanism is preferred as 499 it scales better and avoids DoS attacks: First the primary notifies 500 the secondary that the zone must be updated and leaves the secondary 501 to proceed with the update when possible. Then, a NOTIFY message is 502 sent by the primary, which is a small packet that is less likely to 503 load the secondary. Finally, the AXFR query performed by the 504 secondary is a small packet sent over TCP (section 4.2 [RFC5936]), 505 which mitigates reflection attacks using a forged NOTIFY. On the 506 other hand, DNS UPDATE (which can be transported over UDP), requires 507 more processing than a NOTIFY, and does not allow the server to 508 perform asynchronous updates. 510 This document RECOMMENDS use of a primary / secondary mechanism 511 instead of the use of DNS UPDATE. This section details the primary / 512 secondary mechanism. 514 5.1. Synchronization with a Hidden Primary 516 Uploading and dynamically updating the zone file on the 517 Synchronization Server can be seen as zone provisioning between the 518 CPE (Hidden Primary) and the Synchronization Server (Secondary 519 Server). This can be handled either in band or out of band. 521 The Synchronization Server is configured as a secondary for the 522 Homenet Domain Name. This secondary configuration has been 523 previously agreed between the end user and the provider of the 524 Synchronization Server. In order to set the primary / secondary 525 architecture, the CPE acts as a Hidden Primary Server, which is a 526 regular authoritative DNS Server listening on the WAN interface. 528 The Hidden Primary Server SHOULD accept SOA [RFC1033], AXFR 529 [RFC1034], and IXFR [RFC1995] queries from its configured secondary 530 DNS server(s). The Hidden Primary Server SHOULD send NOTIFY messages 531 [RFC1996] in order to update Public DNS server zones as updates 532 occur. Because, the Homenet Zones are likely to be small, the CPE 533 MUST implement AXFR and SHOULD implement IXFR. 535 Hidden Primary Server differs from a regular authoritative server for 536 the home network by: 538 - Interface Binding: the Hidden Primary Server listens on the WAN 539 Interface, whereas a regular authoritative server for the home 540 network would listen on the home network interface. 542 - Limited exchanges: the purpose of the Hidden Primary Server is to 543 synchronize with the Synchronization Server, not to serve any 544 zones to end users. As a result, exchanges are performed with 545 specific nodes (the Synchronization Server). Further, exchange 546 types are limited. The only legitimate exchanges are: NOTIFY 547 initiated by the Hidden Primary and IXFR or AXFR exchanges 548 initiated by the Synchronization Server. On the other hand, 549 regular authoritative servers would respond to any hosts, and 550 any DNS query would be processed. The CPE SHOULD filter IXFR/ 551 AXFR traffic and drop traffic not initiated by the 552 Synchronization Server. The CPE MUST listen for DNS on TCP and 553 UDP and MUST at least allow SOA lookups of the Homenet Zone. 555 5.2. Securing Synchronization 557 Exchange between the Synchronization Server and the CPE MUST be 558 secured, at least for integrity protection and for authentication. 560 TSIG [RFC2845] or SIG(0) [RFC2931] MAY be used to secure the DNS 561 communications between the CPE and the Synchronization Server. TSIG 562 uses a symmetric key which can be managed by TKEY [RFC2930]. 563 Management of the key involved in SIG(0) is performed through zone 564 updates. How keys are rolled over with SIG(0) is out-of-scope of 565 this document. The advantage of these mechanisms is that they are 566 only associated with the DNS application. Not relying on shared 567 libraries eases testing and integration. On the other hand, using 568 TSIG, TKEY or SIG(0) requires these mechanisms to be implemented on 569 the CPE, which adds code and complexity. Another disadvantage is 570 that TKEY does not provide authentication mechanisms. 572 Protocols like TLS [RFC5246] / DTLS [RFC6347] MAY be used to secure 573 the transactions between the Synchronization Server and the CPE. The 574 advantage of TLS/DTLS is that this technology is widely deployed, and 575 most of the devices already embed TLS/DTLS libraries, possibly also 576 taking advantage of hardware acceleration. Further, TLS/DTLS 577 provides authentication facilities and can use certificates to 578 authenticate the Synchronization Server and the CPE. On the other 579 hand, using TLS/DTLS requires implementing DNS exchanges over TLS/ 580 DTLS, as well as a new service port. This document therefore does 581 NOT RECOMMEND this option. 583 IPsec [RFC4301] IKEv2 [RFC7296] MAY also be used to secure 584 transactions between the CPE and the Synchronization Server. 585 Similarly to TLS/DTLS, most CPEs already embed an IPsec stack, and 586 IKEv2 supports multiple authentication mechanisms via the EAP 587 framework. In addition, IPsec can be used to protect DNS exchanges 588 between the CPE and the Synchronization Server without any 589 modifications of the DNS server or client. DNS integration over 590 IPsec only requires an additional security policy in the Security 591 Policy Database (SPD). One disadvantage of IPsec is that NATs and 592 firewall traversal may be problematic. However, in our case, the CPE 593 is connected to the Internet, and IPsec communication between the CPE 594 and the Synchronization Server should not be impacted by middle 595 boxes. 597 How the PSK can be used by any of the TSIG, TLS/DTLS or IPsec 598 protocols: Authentication based on certificates implies a mutual 599 authentication and thus requires the CPE to manage a private key, a 600 public key, or certificates, as well as Certificate Authorities. 601 This adds complexity to the configuration especially on the CPE side. 602 For this reason, we RECOMMEND that the CPE MAY use PSK or certificate 603 base authentication, and that the Synchronization Server MUST support 604 PSK and certificate based authentication. 606 Note also that authentication of message exchanges between the CPE 607 and the Synchronization Server SHOULD NOT use the external IP address 608 of the CPE to index the appropriate keys. As detailed in Section 9, 609 the IP addresses of the Synchronization Server and the Hidden Primary 610 are subject to change, for example while the network is being 611 renumbered. This means that the necessary keys to authenticate 612 transaction SHOULD NOT be indexed using the IP address, and SHOULD be 613 resilient to IP address changes. 615 5.3. CPE Security Policies 617 This section details security policies related to the Hidden Primary 618 / Secondary synchronization. 620 The Hidden Primary, as described in this document SHOULD drop any 621 queries from the home network. This could be implemented via port 622 binding and/or firewall rules. The precise mechanism deployed is out 623 of scope of this document. 625 The Hidden Primary SHOULD drop any DNS queries arriving on the WAN 626 interface that are not issued from the Synchronization Server. 628 The Hidden Primary SHOULD drop any outgoing packets other than DNS 629 NOTIFY query, SOA response, IXFR response or AXFR responses. 631 The Hidden Primary SHOULD drop any incoming packets other than DNS 632 NOTIFY response, SOA query, IXFR query or AXFR query. 634 The Hidden Primary SHOULD drop any non protected IXFR or AXFR 635 exchange,depending on how the synchronization is secured. 637 6. DNSSEC compliant Homenet Architecture 639 [RFC7368] in Section 3.7.3 recommends DNSSEC to be deployed on both 640 the authoritative server and the resolver. The resolver side is out 641 of scope of this document, and only the authoritative part of the 642 server is considered. 644 Deploying DNSSEC requires signing the zone and configuring a secure 645 delegation. As described in Section 4.1, signing can be performed 646 either by the CPE or by the Outsourcing Infrastructure. Section 6.1 647 details the implications of these two alternatives. Similarly, the 648 secure delegation can be performed by the CPE or by the Outsourcing 649 Infrastructure. Section 6.2 discusses these two alternatives. 651 6.1. Zone Signing 653 This section discusses the pros and cons when zone signing is 654 performed by the CPE or by the Outsourcing Infrastructure. It is 655 RECOMMENDED that the CPE signs the zone unless there is a strong 656 argument against this, such as a CPE that is not capable of signing 657 the zone. In that case zone signing MAY be performed by the 658 Outsourcing Infrastructure on behalf of the CPE. 660 Reasons for signing the zone by the CPE are: 662 - 1: Keeping the Homenet Zone and the Public Homenet Zone equal to 663 securely optimize DNS resolution. As the Public Zone is signed 664 with DNSSEC, RRsets are authenticated, and thus DNS responses 665 can be validated even though they are not provided by the 666 authoritative server. This provides the CPE the ability to 667 respond on behalf of the Public Authoritative Server(s). This 668 could be useful for example if, in the future, the CPE 669 announces to the home network that the CPE can act as a local 670 authoritative primary or equivalent for the Homenet Zone. 671 Currently the CPE is not expected to receive authoritative DNS 672 queries, as its IP address is not mentioned in the Public 673 Homenet Zone. On the other hand most CPEs host a resolving 674 function, and could be configured to perform a local lookup to 675 the Homenet Zone instead of initiating a DNS exchange with the 676 Public Authoritative Server(s). Note that outsourcing the zone 677 signing operation means that all DNSSEC queries SHOULD be 678 cached to perform a local lookup, otherwise a resolution with 679 the Public Authoritative Server(s) would be performed. 681 - 2: Keeping the Homenet Zone and the Public Homenet Zone equal to 682 securely address the connectivity disruption independence 683 detailed in [RFC7368] section 4.4.1 and 3.7.5. As local 684 lookups are possible in case of network disruption, 685 communications within the home network can still rely on the 686 DNSSEC service. Note that outsourcing the zone signing 687 operation does not address connectivity disruption independence 688 with DNSSEC. Instead local lookup would provide DNS as opposed 689 to DNSSEC responses provided by the Public Authoritative 690 Server(s). 692 - 3: Keeping the Homenet Zone and the Public Homenet Zone equal to 693 guarantee coherence between DNS responses. Using a unique zone 694 is one way to guarantee uniqueness of the responses among 695 servers and places. Issues generated by different views are 696 discussed in more details in Section 7. 698 - 2: Privacy and Integrity of the DNSSEC Homenet Zone are better 699 guaranteed. When the Zone is signed by the CPE, it makes 700 modification of the DNS data -- for example for flow 701 redirection -- impossible. As a result, signing the Homenet 702 Zone by the CPE provides better protection for end user 703 privacy. 705 Reasons for signing the zone by the Outsourcing Infrastructure are: 707 - 1: The CPE may not be capable of signing the zone, most likely 708 because its firmware does not support this function. However 709 this reason is expected to become less and less valid over 710 time. 712 - 2: Outsourcing DNSSEC management operations. Management 713 operations involve key roll-over, which can be performed 714 automatically by the CPE and transparently for the end user. 716 Avoiding DNSSEC management is mostly motivated by bad software 717 implementations. 719 - 3: Reducing the impact of CPE replacement on the Public Homenet 720 Zone. Unless the CPE private keys can be extracted and stored 721 off-device, CPE hardware replacement will result in an 722 emergency key roll-over. This can be mitigated by using 723 relatively small TTLs. 725 - 4: Reducing configuration impact on the end user. Unless there 726 are zero configuration mechanisms in place to provide 727 credentials between the new CPE and the Synchronization Server, 728 authentication associations between the CPE and the 729 Synchronization Server would need to be re-configured. As CPE 730 replacement is not expected to happen regularly, end users may 731 not be at ease with such configuration settings. However, 732 mechanisms as described in 733 [I-D.ietf-homenet-naming-architecture-dhc-options] use DHCP 734 Options to outsource the configuration and avoid this issue. 736 - 5: The Outsourcing Infrastructure is more likely to handle private 737 keys more securely than the CPE. However, having all private 738 keys in one place may also nullify that benefit. 740 6.2. Secure Delegation 742 Secure delegation is achieved only if the DS RRset is properly set in 743 the parent zone. Secure delegation can be performed by the CPE or 744 the Outsourcing Infrastructures (that is the Synchronization Server 745 or the Public Authoritative Server(s)). 747 The DS RRset can be updated manually with nsupdate for example. This 748 requires the CPE or the Outsourcing Infrastructure to be 749 authenticated by the DNS server hosting the parent of the Public 750 Homenet Zone. Such a trust channel between the CPE and the parent 751 DNS server may be hard to maintain with CPEs, and thus may be easier 752 to establish with the Outsourcing Infrastructure. In fact, the 753 Public Authoritative Server(s) may use Automating DNSSEC Delegation 754 Trust Maintenance [RFC7344]. 756 7. Handling Different Views 758 The Homenet Zone provides information about the home network. Some 759 users may be tempted to have provide responses dependent on the 760 origin of the DNS query. More specifically, some users may be 761 tempted to provide a different view for DNS queries originating from 762 the home network and for DNS queries coming from the Internet. Each 763 view could then be associated with a dedicated Homenet Zone. Note 764 that this document does not specify how DNS queries originating from 765 the home network are addressed to the Homenet Zone. This could be 766 done via hosting the DNS resolver on the CPE for example. 768 This section is not normative. Section 7.1 details why some nodes 769 may only be reachable from the home network and not from the global 770 Internet. Section 7.2 briefly describes the consequences of having 771 distinct views such as a "home network view" and an "Internet view". 772 Finally, Section 7.3 provides guidance on how to resolve names that 773 are only significant in the home network, without creating different 774 views. 776 7.1. Misleading Reasons for Local Scope DNS Zone 778 The motivation for supporting different views is to provide different 779 answers dependent on the origin of the DNS query, for reasons such 780 as: 782 - 1: An end user may want to have services not published on the 783 Internet. Services like the CPE administration interface that 784 provides the GUI to administer your CPE might not seem 785 advisable to publish on the Internet. Similarly, services like 786 the mapper that registers the devices of your home network may 787 also not be desirable to be published on the Internet. In both 788 cases, these services should only be known or used by the 789 network administrator. To restrict the access of such 790 services, the home network administrator may choose to publish 791 these pieces of information only within the home network, where 792 it might be assumed that the users are more trusted than on the 793 Internet. Even though this assumption may not be valid, at 794 least this may reduce the surface of any attack. 796 - 2: Services within the home network may be reachable using non 797 global IP addresses. IPv4 and NAT may be one reason. On the 798 other hand IPv6 may favor link-local or site-local IP 799 addresses. These IP addresses are not significant outside the 800 boundaries of the home network. As a result, they MAY be 801 published in the home network view, and SHOULD NOT be published 802 in the Public Homenet Zone. 804 7.2. Consequences 806 Enabling different views leads to a non-coherent naming system. 807 Depending on where resolution is performed, some services will not be 808 available. This may be especially inconvenient with devices with 809 multiple interfaces that are attached both to the Internet via a 810 3G/4G interface and to the home network via a WLAN interface. 811 Devices may also cache the results of name resolution, and these 812 cached entries may no longer be valid if a mobile device moves 813 between a homenet connection and an internet connection e.g. a device 814 temporarily loses wifi signal and switches to 3G. 816 Regarding local-scope IP addresses, such devices may end up with poor 817 connectivity. Suppose, for example, that DNS resolution is performed 818 via the WLAN interface attached to the CPE, and the response provides 819 local-scope IP addresses, but the communication is initiated on the 820 3G/4G interface. Communications with local-scope addresses will be 821 unreachable on the Internet, thus aborting the communication. The 822 same situation occurs if a device is flip / flopping between various 823 WLAN networks. 825 Regarding DNSSEC, if the CPE does not sign the Homenet Zone and 826 outsources the signing process, the two views are different, because 827 one is protected with DNSSEC whereas the other is not. Devices with 828 multiple interfaces will have difficulty securing the naming 829 resolution, as responses originating from the home network may not be 830 signed. 832 For devices with all its interfaces attached to a single 833 administrative domain, that is to say the home network, or the 834 Internet. Incoherence between DNS responses may still also occur if 835 the device is able to perform DNS resolutions both using the DNS 836 resolving server of the home network, or one of the ISP. DNS 837 resolution performed via the CPE or the ISP resolver may be different 838 than those performed over the Internet. 840 7.3. Guidance and Recommendations 842 As documented in Section 7.2, it is RECOMMENDED to avoid different 843 views. If network administrators choose to implement multiple views, 844 impacts on devices' resolution SHOULD be evaluated. 846 As a consequence, the Homenet Zone is expected to be an exact copy of 847 the Public Homenet Zone. As a result, services that are not expected 848 to be published on the Internet SHOULD NOT be part of the Homenet 849 Zone, local-scope addresses SHOULD NOT be part of the Homenet Zone, 850 and when possible, the CPE SHOULD sign the Homenet Zone. 852 The Homenet Zone is expected to host public information only. It is 853 not the scope of the DNS service to define local home network 854 boundaries. Instead, local scope information is expected to be 855 provided to the home network using local scope naming services. mDNS 856 [RFC6762] DNS-SD [RFC6763] are two examples of these services. 857 Currently mDNS is limited to a single link network. However, future 858 protocols are expected to leverage this constraint as pointed out in 859 [I-D.ietf-dnssd-requirements]. 861 8. Homenet Reverse Zone 863 This section is focused on the Homenet Reverse Zone. 865 Firstly, all considerations for the Homenet Zone apply to the Homenet 866 Reverse Zone. The main difference between the Homenet Reverse Zone 867 and the Homenet Zone is that the parent zone of the Homenet Reverse 868 Zone is most likely managed by the ISP. As the ISP also provides the 869 IP prefix to the CPE, it may be able to authenticate the CPE using 870 mechanisms outside the scope of this document e.g. the physical 871 attachment point to the ISP network. If the Reverse Synchronization 872 Server is managed by the ISP, credentials to authenticate the CPE for 873 the zone synchronization may be set automatically and transparently 874 to the end user. [I-D.ietf-homenet-naming-architecture-dhc-options] 875 describes how automatic configuration may be performed. 877 With IPv6, the domain space for IP addresses is so large that reverse 878 zone may be confronted with scalability issues. How the reverse zone 879 is generated is out of scope of this document. 880 [I-D.howard-dnsop-ip6rdns] provides guidance on how to address 881 scalability issues. 883 9. Renumbering 885 This section details how renumbering is handled by the Hidden Primary 886 server or the Synchronization Server. Both types of renumbering are 887 discussed i.e. "make-before-break" and "break-before-make". 889 In the make-before-break renumbering scenario, the new prefix is 890 advertised, the network is configured to prepare the transition to 891 the new prefix. During a period of time, the two prefixes old and 892 new coexist, before the old prefix is completely removed. In the 893 break-before-make renumbering scenario, the new prefix is advertised 894 making the old prefix obsolete. 896 Renumbering has been extensively described in [RFC4192] and analyzed 897 in [RFC7010] and the reader is expected to be familiar with them 898 before reading this section. 900 9.1. Hidden Primary 902 In a renumbering scenario, the Hidden Primary is informed it is being 903 renumbered. In most cases, this occurs because the whole home 904 network is being renumbered. As a result, the Homenet Zone will also 905 be updated. Although the new and old IP addresses may be stored in 906 the Homenet Zone, we recommend that only the newly reachable IP 907 addresses be published. 909 To avoid reachability disruption, IP connectivity information 910 provided by the DNS SHOULD be coherent with the IP plane. In our 911 case, this means the old IP address SHOULD NOT be provided via the 912 DNS when it is not reachable anymore. Let for example TTL be the TTL 913 associated with a RRset of the Homenet Zone, it may be cached for TTL 914 seconds. Let T_NEW be the time the new IP address replaces the old 915 IP address in the Homenet Zone, and T_OLD_UNREACHABLE the time the 916 old IP is not reachable anymore. In the case of the make-before- 917 break, seamless reachability is provided as long as T_OLD_UNREACHABLE 918 - T_NEW > 2 * TTL. If this is not satisfied, then devices associated 919 with the old IP address in the home network may become unreachable 920 for 2 * TTL - (T_OLD_UNREACHABLE - T_NEW). In the case of a break- 921 before-make, T_OLD_UNREACHABLE = T_NEW, and the device may become 922 unreachable up to 2 * TTL. 924 Once the Homenet Zone file has been updated on the Hidden Primary, 925 the Hidden Primary needs to inform the Outsourcing Infrastructure 926 that the Homenet Zone has been updated and that the IP address to use 927 to retrieve the updated zone has also been updated. Both 928 notifications are performed using regular DNS exchanges. Mechanisms 929 to update an IP address provided by lower layers with protocols like 930 SCTP [RFC4960], MOBIKE [RFC4555] are not considered in this document. 932 The Hidden Primary SHOULD inform the Synchronization Server that the 933 Homenet Zone has been updated by sending a NOTIFY payload with the 934 new IP address. In addition, this NOTIFY payload SHOULD be 935 authenticated using SIG(0) or TSIG. When the Synchronization Server 936 receives the NOTIFY payload, it MUST authenticate it. Note that the 937 cryptographic key used for the authentication SHOULD be indexed by 938 the Registered Homenet Domain contained in the NOTIFY payload as well 939 as the RRSIG. In other words, the IP address SHOULD NOT be used as 940 an index. If authentication succeeds, the Synchronization Server 941 MUST also notice the IP address has been modified and perform a 942 reachability check before updating its primary configuration. The 943 routability check MAY performed by sending a SOA request to the 944 Hidden Primary using the source IP address of the NOTIFY. This 945 exchange is also secured, and if an authenticated response is 946 received from the Hidden Primary with the new IP address, the 947 Synchronization Server SHOULD update its configuration file and 948 retrieve the Homenet Zone using an AXFR or a IXFR exchange. 950 Note that the primary reason for providing the IP address is that the 951 Hidden Primary is not publicly announced in the DNS. If the Hidden 952 Primary were publicly announced in the DNS, then the IP address 953 update could have been performed using the DNS as described in 954 Section 9.2. 956 9.2. Synchronization Server 958 Renumbering of the Synchronization Server results in the 959 Synchronization Server changing its IP address. The Synchronization 960 Server is a secondary, so its renumbering does not impact the Homenet 961 Zone. In fact, exchanges to the Synchronization Server are 962 restricted to the Homenet Zone synchronization. In our case, the 963 Hidden Primary MUST be able to send NOTIFY payloads to the 964 Synchronization Server. 966 If the Synchronization Server is configured in the Hidden Primary 967 configuration file using a FQDN, then the update of the IP address is 968 performed by DNS. More specifically, before sending the NOTIFY, the 969 Hidden Primary performs a DNS resolution to retrieve the IP address 970 of the secondary. 972 As described in Section 9.1, the Synchronization Server DNS 973 information SHOULD be coherent with the IP plane. Let TTL be the TTL 974 associated with the Synchronization Server FQDN, T_NEW the time the 975 new IP address replaces the old one and T_OLD_UNREACHABLE the time 976 the Synchronization Server is not reachable anymore with its old IP 977 address. Seamless reachability is provided as long as 978 T_OLD_UNREACHABLE - T_NEW > 2 * TTL. If this condition is not met, 979 the Synchronization Server may be unreachable during 2 * TTL - 980 (T_OLD_UNREACHABLE - T_NEW). In the case of a break-before-make, 981 T_OLD_UNREACHABLE = T_NEW, and it may become unreachable up to 2 * 982 TTL. 984 Some DNS infrastructure uses the IP address to designate the 985 secondary, in which case, other mechanisms must be found. The reason 986 for using IP addresses instead of names is generally to reach an 987 internal interface that is not designated by a FQDN, and to avoid 988 potential bootstrap problems. Such scenarios are considered as out 989 of scope in the case of home networks. 991 10. Privacy Considerations 993 Outsourcing the DNS Authoritative service from the CPE to a third 994 party raises a few privacy related concerns. 996 The Homenet Zone contains a full description of the services hosted 997 in the network. These services may not be expected to be publicly 998 shared although their names remain accessible through the Internet. 999 Even though DNS makes information public, the DNS does not expect to 1000 make the complete list of services public. In fact, making 1001 information public still requires the key (or FQDN) of each service 1002 to be known by the resolver in order to retrieve information about 1003 the services. More specifically, making mywebsite.example.com public 1004 in the DNS, is not sufficient to make resolvers aware of the 1005 existence web site. However, an attacker may walk the reverse DNS 1006 zone, or use other reconnaissance techniques to learn this 1007 information as described in [I-D.ietf-opsec-ipv6-host-scanning]. 1009 In order to prevent the complete Homenet Zone being published on the 1010 Internet, AXFR queries SHOULD be blocked on the Public Authoritative 1011 Server(s). Similarly, to avoid zone-walking NSEC3 [RFC5155] SHOULD 1012 be preferred over NSEC [RFC4034]. 1014 When the Homenet Zone is outsourced, the end user should be aware 1015 that it provides a complete description of the services available on 1016 the home network. More specifically, names usually provides a clear 1017 indication of the service and possibly even the device type, and as 1018 the Homenet Zone contains the IP addresses associated with the 1019 service, they also limit the scope of the scan space. 1021 In addition to the Homenet Zone, the third party can also monitor the 1022 traffic associated with the Homenet Zone. This traffic may provide 1023 an indication of the services an end user accesses, plus how and when 1024 they use these services. Although, caching may obfuscate this 1025 information inside the home network, it is likely that outside your 1026 home network this information will not be cached. 1028 11. Security Considerations 1030 The Homenet Naming Architecture described in this document solves 1031 exposing the CPE's DNS service as a DoS attack vector. 1033 11.1. Names are less secure than IP addresses 1035 This document describes how an end user can make their services and 1036 devices from his home network reachable on the Internet by using 1037 names rather than IP addresses. This exposes the home network to 1038 attackers, since names are expected to include less entropy than IP 1039 addresses. In fact, with IP addresses, the Interface Identifier is 1040 64 bits long leading to up to 2^64 possibilities for a given 1041 subnetwork. This is not to mention that the subnet prefix is also of 1042 64 bits long, thus providing up to 2^64 possibilities. On the other 1043 hand, names used either for the home network domain or for the 1044 devices present less entropy (livebox, router, printer, nicolas, 1045 jennifer, ...) and thus potentially exposes the devices to dictionary 1046 attacks. 1048 11.2. Names are less volatile than IP addresses 1050 IP addresses may be used to locate a device, a host or a service. 1051 However, home networks are not expected to be assigned a time 1052 invariant prefix by ISPs. As a result, observing IP addresses only 1053 provides some ephemeral information about who is accessing the 1054 service. On the other hand, names are not expected to be as volatile 1055 as IP addresses. As a result, logging names over time may be more 1056 valuable than logging IP addresses, especially to profile an end 1057 user's characteristics. 1059 PTR provides a way to bind an IP address to a name. In that sense, 1060 responding to PTR DNS queries may affect the end user's privacy. For 1061 that reason end users may choose not to respond to PTR DNS queries 1062 and MAY instead return a NXDOMAIN response. 1064 11.3. DNS Reflection Attacks 1066 An attacker performs a reflection attack when it sends traffic to one 1067 or more intermediary nodes (reflectors), that in turn send back 1068 response traffic to the victim. Motivations for using an 1069 intermediary node might be anonymity of the attacker, as well as 1070 amplification of the traffic. Typically, when the intermediary node 1071 is a DNSSEC server, the attacker sends a DNSSEC query and the victim 1072 is likely to receive a DNSSEC response. This section analyzes how 1073 the different components may be involved as a reflector in a 1074 reflection attack. Section 11.3.1 considers the Hidden Primary, 1075 Section 11.3.2 the Synchronization Server, and Section 11.3.3 the 1076 Public Authoritative Server(s). 1078 11.3.1. Reflection Attack involving the Hidden Primary 1080 With the specified architecture, the Hidden Primary is only expected 1081 to receive DNS queries of type SOA, AXFR or IXFR. This section 1082 analyzes how these DNS queries may be used by an attacker to perform 1083 a reflection attack. 1085 DNS queries of type AXFR and IXFR use TCP and as such are less 1086 subject to reflection attacks. This makes SOA queries the only 1087 remaining practical vector of attacks for reflection attacks, based 1088 on UDP. 1090 SOA queries are not associated with a large amplification factor 1091 compared to queries of type "ANY" or to query of non existing FQDNs. 1092 This reduces the probability a DNS query of type SOA will be involved 1093 in a DDoS attack. 1095 SOA queries are expected to follow a very specific pattern, which 1096 makes rate limiting techniques an efficient way to limit such 1097 attacks, and associated impact on the naming service of the home 1098 network. 1100 Motivations for such a flood might be a reflection attack, but could 1101 also be a resource exhaustion attack performed against the Hidden 1102 Primary. The Hidden Primary only expects to exchange traffic with 1103 the Synchronization Server, that is its associated secondary. Even 1104 though secondary servers may be renumbered as mentioned in Section 9, 1105 the Hidden Primary is likely to perform a DNSSEC resolution and find 1106 out the associated secondary's IP addresses in use. As a result, the 1107 Hidden Primary is likely to limit the origin of its incoming traffic 1108 based on the origin IP address. 1110 With filtering rules based on IP address, SOA flooding attacks are 1111 limited to forged packets with the IP address of the secondary 1112 server. In other words, the only victims are the Hidden Primary 1113 itself or the secondary. There is a need for the Hidden Primary to 1114 limit that flood to limit the impact of the reflection attack on the 1115 secondary, and to limit the resource needed to carry on the traffic 1116 by the CPE hosting the Hidden Primary. On the other hand, mitigation 1117 should be performed appropriately, so as to limit the impact on the 1118 legitimate SOA sent by the secondary. 1120 The main reason for the Synchronization Server sending a SOA query is 1121 to update the SOA RRset after the TTL expires, to check the serial 1122 number upon the receipt of a NOTIFY query from the Hidden Primary, or 1123 to re-send the SOA request when the response has not been received. 1124 When a flood of SOA queries is received by the Hidden Primary, the 1125 Hidden Primary may assume it is involved in an attack. 1127 There are few legitimate time slots when the secondary is expected to 1128 send a SOA query. Suppose T_NOTIFY is the time a NOTIFY is sent by 1129 the Hidden Primary, T_SOA the last time the SOA has been queried, TTL 1130 the TTL associated to the SOA, and T_REFRESH the refresh time defined 1131 in the SOA RRset. The specific time SOA queries are expected can be 1132 for example T_NOTIFY, T_SOA + 2/3 TTL, T_SOA + TTL, T_SOA + 1133 T_REFRESH., and. Outside a few minutes following these specific time 1134 slots, the probability that the CPE discards a legitimate SOA query 1135 is very low. Within these time slots, the probability the secondary 1136 may have its legitimate query rejected is higher. If a legitimate 1137 SOA is discarded, the secondary will re-send SOA query every "retry 1138 time" second until "expire time" seconds occurs, where "retry time" 1139 and "expire time" have been defined in the SOA. 1141 As a result, it is RECOMMENDED to set rate limiting policies to 1142 protect CPE resources. If a flood lasts more than the expired time 1143 defined by the SOA, it is RECOMMENDED to re-initiate a 1144 synchronization between the Hidden Primary and the secondaries. 1146 11.3.2. Reflection Attacks involving the Synchronization Server 1148 The Synchronization Server acts as a secondary coupled with the 1149 Hidden Primary. The secondary expects to receive NOTIFY query, SOA 1150 responses, AXFR and IXFR responses from the Hidden Primary. 1152 Sending a NOTIFY query to the secondary generates a NOTIFY response 1153 as well as initiating an SOA query exchange from the secondary to the 1154 Hidden Primary. As mentioned in [RFC1996], this is a known "benign 1155 denial of service attack". As a result, the Synchronization Server 1156 SHOULD enforce rate limiting on sending SOA queries and NOTIFY 1157 responses to the Hidden Primary. Most likely, when the secondary is 1158 flooded with valid and signed NOTIFY queries, it is under a replay 1159 attack which is discussed in Section 11.5. The key thing here is 1160 that the secondary is likely to be designed to be able to process 1161 much more traffic than the Hidden Primary hosted on a CPE. 1163 This paragraph details how the secondary may limit the NOTIFY 1164 queries. Because the Hidden Primary may be renumbered, the secondary 1165 SHOULD NOT perform permanent IP filtering based on IP addresses. In 1166 addition, a given secondary may be shared among multiple Hidden 1167 Primaries which make filtering rules based on IP harder to set. The 1168 time at which a NOTIFY is sent by the Hidden Primary is not 1169 predictable. However, a flood of NOTIFY messages may be easily 1170 detected, as a NOTIFY originated from a given Homenet Zone is 1171 expected to have a very limited number of unique source IP addresses, 1172 even when renumbering is occurring. As a result, the secondary, MAY 1173 rate limit incoming NOTIFY queries. 1175 On the Hidden Primary side, it is recommended that the Hidden Primary 1176 sends a NOTIFY as long as the zone has not been updated by the 1177 secondary. Multiple SOA queries may indicate the secondary is under 1178 attack. 1180 11.3.3. Reflection Attacks involving the Public Authoritative Servers 1182 Reflection attacks involving the Public Authoritative Server(s) are 1183 similar to attacks on any Outsourcing Infrastructure. This is not 1184 specific to the architecture described in this document, and thus are 1185 considered as out of scope. 1187 In fact, one motivation of the architecture described in this 1188 document is to expose the Public Authoritative Server(s) to attacks 1189 instead of the CPE, as it is believed that the Public Authoritative 1190 Server(s) will be better able to defend itself. 1192 11.4. Flooding Attack 1194 The purpose of flooding attacks is mostly resource exhaustion, where 1195 the resource can be bandwidth, memory, or CPU for example. 1197 One goal of the architecture described in this document is to limit 1198 the surface of attack on the CPE. This is done by outsourcing the 1199 DNS service to the Public Authoritative Server(s). By doing so, the 1200 CPE limits its DNS interactions between the Hidden Primary and the 1201 Synchronization Server. This limits the number of entities the CPE 1202 interacts with as well as the scope of DNS exchanges - NOTIFY, SOA, 1203 AXFR, IXFR. 1205 The use of an authenticated channel with SIG(0) or TSIG between the 1206 CPE and the Synchronization Server, enables detection of illegitimate 1207 DNS queries, so appropriate action may be taken - like dropping the 1208 queries. If signatures are validated, then most likely, the CPE is 1209 under a replay attack, as detailed in Section 11.5 1211 In order to limit the resource required for authentication, it is 1212 recommended to use TSIG that uses symmetric cryptography over SIG(0) 1213 that uses asymmetric cryptography. 1215 11.5. Replay Attack 1217 Replay attacks consist of an attacker either resending or delaying a 1218 legitimate message that has been sent by an authorized user or 1219 process. As the Hidden Primary and the Synchronization Server use an 1220 authenticated channel, replay attacks are mostly expected to use 1221 forged DNS queries in order to provide valid traffic. 1223 From the perspective of an attacker, using a correctly authenticated 1224 DNS query may not be detected as an attack and thus may generate a 1225 response. Generating and sending a response consumes more resources 1226 than either dropping the query by the defender, or generating the 1227 query by the attacker, and thus could be used for resource exhaustion 1228 attacks. In addition, as the authentication is performed at the DNS 1229 layer, the source IP address could be impersonated in order to 1230 perform a reflection attack. 1232 Section 11.3 details how to mitigate reflection attacks and 1233 Section 11.4 details how to mitigate resource exhaustion. Both 1234 sections assume a context of DoS with a flood of DNS queries. This 1235 section suggests a way to limit the attack surface of replay attacks. 1237 As SIG(0) and TSIG use inception and expiration time, the time frame 1238 for replay attack is limited. SIG(0) and TSIG recommends a fudge 1239 value of 5 minutes. This value has been set as a compromise between 1240 possibly loose time synchronization between devices and the valid 1241 lifetime of the message. As a result, better time synchronization 1242 policies could reduce the time window of the attack. 1244 12. IANA Considerations 1246 This document has no actions for IANA. 1248 13. Acknowledgment 1250 The authors wish to thank Philippe Lemordant for its contributions on 1251 the early versions of the draft; Ole Troan for pointing out issues 1252 with the IPv6 routed home concept and placing the scope of this 1253 document in a wider picture; Mark Townsley for encouragement and 1254 injecting a healthy debate on the merits of the idea; Ulrik de Bie 1255 for providing alternative solutions; Paul Mockapetris, Christian 1256 Jacquenet, Francis Dupont and Ludovic Eschard for their remarks on 1257 CPE and low power devices; Olafur Gudmundsson for clarifying DNSSEC 1258 capabilities of small devices; Simon Kelley for its feedback as 1259 dnsmasq implementer; Andrew Sullivan, Mark Andrew, Ted Lemon, Mikael 1260 Abrahamson, Michael Richardson and Ray Bellis for their feedback on 1261 handling different views as well as clarifying the impact of 1262 outsourcing the zone signing operation outside the CPE; Mark Andrew 1263 and Peter Koch for clarifying the renumbering. 1265 14. References 1267 14.1. Normative References 1269 [RFC1034] Mockapetris, P., "Domain names - concepts and facilities", 1270 STD 13, RFC 1034, November 1987. 1272 [RFC1035] Mockapetris, P., "Domain names - implementation and 1273 specification", STD 13, RFC 1035, November 1987. 1275 [RFC1995] Ohta, M., "Incremental Zone Transfer in DNS", RFC 1995, 1276 August 1996. 1278 [RFC1996] Vixie, P., "A Mechanism for Prompt Notification of Zone 1279 Changes (DNS NOTIFY)", RFC 1996, August 1996. 1281 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1282 Requirement Levels", BCP 14, RFC 2119, March 1997. 1284 [RFC2136] Vixie, P., Thomson, S., Rekhter, Y., and J. Bound, 1285 "Dynamic Updates in the Domain Name System (DNS UPDATE)", 1286 RFC 2136, April 1997. 1288 [RFC2142] Crocker, D., "MAILBOX NAMES FOR COMMON SERVICES, ROLES AND 1289 FUNCTIONS", RFC 2142, May 1997. 1291 [RFC2308] Andrews, M., "Negative Caching of DNS Queries (DNS 1292 NCACHE)", RFC 2308, March 1998. 1294 [RFC2845] Vixie, P., Gudmundsson, O., Eastlake, D., and B. 1295 Wellington, "Secret Key Transaction Authentication for DNS 1296 (TSIG)", RFC 2845, May 2000. 1298 [RFC2930] Eastlake, D., "Secret Key Establishment for DNS (TKEY 1299 RR)", RFC 2930, September 2000. 1301 [RFC2931] Eastlake, D., "DNS Request and Transaction Signatures ( 1302 SIG(0)s )", RFC 2931, September 2000. 1304 [RFC4034] Arends, R., Austein, R., Larson, M., Massey, D., and S. 1305 Rose, "Resource Records for the DNS Security Extensions", 1306 RFC 4034, March 2005. 1308 [RFC4301] Kent, S. and K. Seo, "Security Architecture for the 1309 Internet Protocol", RFC 4301, December 2005. 1311 [RFC4555] Eronen, P., "IKEv2 Mobility and Multihoming Protocol 1312 (MOBIKE)", RFC 4555, June 2006. 1314 [RFC4960] Stewart, R., "Stream Control Transmission Protocol", RFC 1315 4960, September 2007. 1317 [RFC5155] Laurie, B., Sisson, G., Arends, R., and D. Blacka, "DNS 1318 Security (DNSSEC) Hashed Authenticated Denial of 1319 Existence", RFC 5155, March 2008. 1321 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 1322 (TLS) Protocol Version 1.2", RFC 5246, August 2008. 1324 [RFC5936] Lewis, E. and A. Hoenes, "DNS Zone Transfer Protocol 1325 (AXFR)", RFC 5936, June 2010. 1327 [RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer 1328 Security Version 1.2", RFC 6347, January 2012. 1330 [RFC6644] Evans, D., Droms, R., and S. Jiang, "Rebind Capability in 1331 DHCPv6 Reconfigure Messages", RFC 6644, July 2012. 1333 [RFC6762] Cheshire, S. and M. Krochmal, "Multicast DNS", RFC 6762, 1334 February 2013. 1336 [RFC6763] Cheshire, S. and M. Krochmal, "DNS-Based Service 1337 Discovery", RFC 6763, February 2013. 1339 [RFC7296] Kaufman, C., Hoffman, P., Nir, Y., Eronen, P., and T. 1340 Kivinen, "Internet Key Exchange Protocol Version 2 1341 (IKEv2)", STD 79, RFC 7296, October 2014. 1343 14.2. Informational References 1345 [I-D.howard-dnsop-ip6rdns] 1346 Howard, L., "Reverse DNS in IPv6 for Internet Service 1347 Providers", draft-howard-dnsop-ip6rdns-00 (work in 1348 progress), June 2014. 1350 [I-D.ietf-dnssd-requirements] 1351 Lynn, K., Cheshire, S., Blanchet, M., and D. Migault, 1352 "Requirements for Scalable DNS-SD/mDNS Extensions", draft- 1353 ietf-dnssd-requirements-06 (work in progress), March 2015. 1355 [I-D.ietf-homenet-naming-architecture-dhc-options] 1356 Migault, D., Cloetens, W., Griffiths, C., and R. Weber, 1357 "DHCP Options for Homenet Naming Architecture", draft- 1358 ietf-homenet-naming-architecture-dhc-options-02 (work in 1359 progress), May 2015. 1361 [I-D.ietf-opsec-ipv6-host-scanning] 1362 Gont, F. and T. Chown, "Network Reconnaissance in IPv6 1363 Networks", draft-ietf-opsec-ipv6-host-scanning-07 (work in 1364 progress), April 2015. 1366 [RFC1033] Lottor, M., "Domain administrators operations guide", RFC 1367 1033, November 1987. 1369 [RFC4192] Baker, F., Lear, E., and R. Droms, "Procedures for 1370 Renumbering an IPv6 Network without a Flag Day", RFC 4192, 1371 September 2005. 1373 [RFC7010] Liu, B., Jiang, S., Carpenter, B., Venaas, S., and W. 1374 George, "IPv6 Site Renumbering Gap Analysis", RFC 7010, 1375 September 2013. 1377 [RFC7344] Kumari, W., Gudmundsson, O., and G. Barwood, "Automating 1378 DNSSEC Delegation Trust Maintenance", RFC 7344, September 1379 2014. 1381 [RFC7368] Chown, T., Arkko, J., Brandt, A., Troan, O., and J. Weil, 1382 "IPv6 Home Networking Architecture Principles", RFC 7368, 1383 October 2014. 1385 Appendix A. Document Change Log 1387 [RFC Editor: This section is to be removed before publication] 1389 -07: 1391 Ray Hunter is added as a co-author. 1393 -06: 1395 Ray Hunter is added in acknowledgment. 1397 Adding Renumbering section with comments from Dallas meeting 1399 Replacing Master / Primary - Slave / Secondary 1401 Security Consideration has been updated with Reflection attacks, 1402 flooding attacks, and replay attacks. 1404 -05: 1406 *Clarifying on handling different views: 1408 - 1: How the CPE may be involved in the resolution and responds 1409 without necessarily requesting the Public Authoritative 1410 Server(s) (and eventually the Hidden Primary) 1412 - 2: How to handle local scope resolution that is link-local, site- 1413 local and NAT IP addresses as well as Private domain names that 1414 the administrator does not want to publish outside the home 1415 network. 1417 Adding a Privacy Considerations Section 1419 Clarification on pro/cons outsourcing zone-signing 1421 Documenting how to handle reverse zones 1423 Adding reference to RFC 2308 1425 -04: 1427 *Clarifications on zone signing 1429 *Rewording 1431 *Adding section on different views 1432 *architecture clarifications 1434 -03: 1436 *Simon's comments taken into consideration 1438 *Adding SOA, PTR considerations 1440 *Removing DNSSEC performance paragraphs on low power devices 1442 *Adding SIG(0) as a mechanism for authenticating the servers 1444 *Goals clarification: the architecture described in the document 1) 1445 does not describe new protocols, and 2) can be adapted to specific 1446 cases for advance users. 1448 -02: 1450 *remove interfaces: "Public Authoritative Server Naming Interface" is 1451 replaced by "Public Authoritative Server(s)y(ies)". "Public 1452 Authoritative Server Management Interface" is replaced by 1453 "Synchronization Server". 1455 -01.3: 1457 *remove the authoritative / resolver services of the CPE. 1458 Implementation dependent 1460 *remove interactions with mdns and dhcp. Implementation dependent. 1462 *remove considerations on low powered devices 1464 *remove position toward homenet arch 1466 *remove problem statement section 1468 -01.2: 1470 * add a CPE description to show that the architecture can fit CPEs 1472 * specification of the architecture for very low powered devices. 1474 * integrate mDNS and DHCP interactions with the Homenet Naming 1475 Architecture. 1477 * Restructuring the draft. 1) We start from the homenet-arch draft to 1478 derive a Naming Architecture, then 2) we show why CPE need mechanisms 1479 that do not expose them to the Internet, 3) we describe the 1480 mechanisms. 1482 * I remove the terminology and expose it in the figures A and B. 1484 * remove the Front End Homenet Naming Architecture to Homenet Naming 1486 -01: 1488 * Added C. Griffiths as co-author. 1490 * Updated section 5.4 and other sections of draft to update section 1491 on Hidden Primary / Slave functions with CPE as Hidden Primary/ 1492 Homenet Server. 1494 * For next version, address functions of MDNS within Homenet Lan and 1495 publishing details northbound via Hidden Primary. 1497 -00: First version published. 1499 Authors' Addresses 1501 Daniel Migault 1502 Ericsson 1503 8400 Boulevard Decarie 1504 Montreal, QC H4P 2N2 1505 Canada 1507 Phone: +1 (514) 452-2160 1508 Email: daniel.migault@ericsson.com 1510 Ralf Weber 1511 Nominum 1512 2000 Seaport Blvd #400 1513 Redwood City, CA 94063 1514 US 1516 Email: ralf.weber@nominum.com 1517 URI: http://www.nominum.com 1518 Ray Hunter 1519 Globis Consulting BV 1520 Weegschaalstraat 3 1521 5632CW Eindhoven 1522 The Netherlands 1524 Email: v6ops@globis.net 1525 URI: http://www.globis.net 1527 Chris Griffiths 1529 Email: cgriffiths@gmail.com 1531 Wouter Cloetens 1532 SoftAtHome 1533 vaartdijk 3 701 1534 3018 Wijgmaal 1535 Belgium 1537 Email: wouter.cloetens@softathome.com