idnits 2.17.1 draft-ietf-homenet-front-end-naming-delegation-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (May 4, 2015) is 3280 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-01 Summary: 4 errors (**), 0 flaws (~~), 2 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 HOMENET D. Migault (Ed) 3 Internet-Draft Ericsson 4 Intended status: Standards Track W. Cloetens 5 Expires: November 5, 2015 SoftAtHome 6 C. Griffiths 7 Dyn 8 R. Weber 9 Nominum 10 May 4, 2015 12 Outsourcing Home Network Authoritative Naming Service 13 draft-ietf-homenet-front-end-naming-delegation-02.txt 15 Abstract 17 CPEs are designed to provide IP connectivity to home networks. Most 18 CPEs assign IP addresses to the nodes of the home network which makes 19 it a good candidate for hosting the naming service. With IPv6, the 20 naming service makes nodes reachable from the home network as well as 21 from the Internet. 23 However, CPEs have not been designed to host such a naming service 24 exposed on the Internet. This may expose the CPEs to resource 25 exhaustion which would make the home network unreachable, and most 26 probably would also affect the home network inner communications. 28 In addition, DNSSEC management and configuration may not be well 29 understood or mastered by regular end users. Misconfiguration may 30 also result in naming service disruption, thus these end users may 31 prefer to rely on third party naming providers. 33 This document describes a homenet naming architecture where the CPEs 34 manage the DNS zone associated to its home network, and outsources 35 the naming service and eventually the DNSSEC management on the 36 Internet to a third party designated as the Public Authoritative 37 Servers. 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 November 5, 2015. 56 Copyright Notice 58 Copyright (c) 2015 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 . . . . . . . . . . . . . . . . . . . . 3 74 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 75 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 76 4. Architecture Description . . . . . . . . . . . . . . . . . . 5 77 4.1. Architecture Overview . . . . . . . . . . . . . . . . . . 6 78 4.2. Example: DNS(SEC) Homenet Zone . . . . . . . . . . . . . 8 79 4.3. Example: CPE necessary parameters for outsourcing . . . . 10 80 5. Synchronization between CPE and Public Authoritative Name 81 Server Sets . . . . . . . . . . . . . . . . . . . . . . . . . 11 82 5.1. Synchronization with a Hidden Primary . . . . . . . . . . 11 83 5.2. Securing Synchronization . . . . . . . . . . . . . . . . 12 84 5.3. CPE Security Policies . . . . . . . . . . . . . . . . . . 14 85 6. DNSSEC compliant Homenet Architecture . . . . . . . . . . . . 14 86 6.1. Zone Signing . . . . . . . . . . . . . . . . . . . . . . 14 87 6.2. Secure Delegation . . . . . . . . . . . . . . . . . . . . 16 88 7. Handling Different Views . . . . . . . . . . . . . . . . . . 16 89 7.1. Misleading Reasons for Local Scope DNS Zone . . . . . . . 17 90 7.2. Consequences . . . . . . . . . . . . . . . . . . . . . . 17 91 7.3. Guidance and Recommendations . . . . . . . . . . . . . . 18 92 8. Reverse Zone . . . . . . . . . . . . . . . . . . . . . . . . 18 93 9. Renumbering . . . . . . . . . . . . . . . . . . . . . . . . . 19 94 9.1. Hidden Primary . . . . . . . . . . . . . . . . . . . . . 19 95 9.2. Public Authoritative Name Server Set . . . . . . . . . . 21 96 10. Privacy Considerations . . . . . . . . . . . . . . . . . . . 21 97 11. Security Considerations . . . . . . . . . . . . . . . . . . . 22 98 11.1. Names are less secure than IP addresses . . . . . . . . 22 99 11.2. Names are less volatile than IP addresses . . . . . . . 23 100 11.3. DNS Reflection Attacks . . . . . . . . . . . . . . . . . 23 101 11.3.1. Reflection Attack involving the Hidden Primary . . . 23 102 11.3.2. Reflection Attacks involving the Public 103 Authoritative Name Server Set . . . . . . . . . . . 25 104 11.3.3. Reflection Attacks involving the Public 105 Authoritative Primary . . . . . . . . . . . . . . . 25 106 11.4. Flooding Attack . . . . . . . . . . . . . . . . . . . . 26 107 11.5. Replay Attack . . . . . . . . . . . . . . . . . . . . . 26 108 12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 27 109 13. Acknowledgment . . . . . . . . . . . . . . . . . . . . . . . 27 110 14. References . . . . . . . . . . . . . . . . . . . . . . . . . 27 111 14.1. Normative References . . . . . . . . . . . . . . . . . . 27 112 14.2. Informational References . . . . . . . . . . . . . . . . 29 113 Appendix A. Document Change Log . . . . . . . . . . . . . . . . 30 114 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 32 116 1. Requirements notation 118 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 119 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 120 document are to be interpreted as described in [RFC2119]. 122 2. Introduction 124 IPv6 provides global end to end IP reachability. To access services 125 hosted in the home network with IPv6 addresses, end users prefer to 126 use names instead of long and complex IPv6 addresses. 128 CPEs are already providing IPv6 connectivity to the home network and 129 generally provide IPv6 addresses or prefixes to the nodes of the home 130 network. This makes the CPEs a good candidate to manage binding 131 between names and IP addresses of the nodes. In addition, [RFC7368] 132 recommends that home networks be resilient to connectivity disruption 133 from the ISP. This requires that a dedicate device inside the home 134 network manage bindings between names and IP addresses of the nodes 135 and builds the DNS Homenet Zone. All this makes the CPE the natural 136 candidate for setting the DNS(SEC) zone file of the home network. 138 CPEs are usually low powered devices designed for the home network, 139 but not for heavy traffic. As a result, hosting an authoritative DNS 140 service on the Internet may expose the home network to resource 141 exhaustion, which may isolate the home network from the Internet and 142 affect the services hosted by the CPEs, thus affecting the overall 143 home network communications. 145 In order to avoid resource exhaustion, this document describes an 146 architecture that outsources the authoritative naming service of the 147 home network. More specifically, the DNS(SEC) Homenet Zone built by 148 the CPE is outsourced to Public Authoritative Servers. These servers 149 publish the corresponding DN(SEC) Public Zone on the Internet. 150 Section 4.1 describes the architecture. In order to keep the 151 DNS(SEC) Public Zone up-to-date Section 5 describes how the DNS(SEC) 152 Homenet Zone and the DN(SEC) Public Zone can be synchronized. The 153 proposed architecture aims at deploying DNSSEC and the DNS(SEC) 154 Public Zone is expected to be signed with a secure delegation. The 155 zone signing and secure delegation can be performed either by the CPE 156 or by the Public Authoritative Servers. Section 6 discusses these 157 two alternatives. Section 7 discusses multiple views aspects and 158 provide guidance to avoid them. Section 8 discusses the case of the 159 reverse zone. Section 9 discusses how renumbering should be handled. 160 Finally, Section 10 and Section 11 respectively discuss privacy and 161 security considerations when outsourcing the DNS Homenet Zone. 163 3. Terminology 165 - Customer Premises Equipment: (CPE) is the router providing 166 connectivity to the home network. It is configured and managed 167 by the end user. In this document, the CPE MAY also host 168 services such as DHCPv6. This device MAY be provided by the 169 ISP. 171 - Registered Homenet Domain: is the Domain Name associated to the 172 home network. 174 - DNS Homenet Zone: is the DNS zone associated to the home network. 175 This zone is set by the CPE and essentially contains the 176 bindings between names and IP addresses of the nodes of the 177 home network. In this document, the CPE does neither perform 178 any DNSSEC management operations such as zone signing nor 179 provide an authoritative service for the zone. Both are 180 delegated to the Public Authoritative Server. The CPE 181 synchronizes the DNS Homenet Zone with the Public Authoritative 182 Server via a hidden primary / secondary architecture. The 183 Public Authoritative Server MAY use specific servers for the 184 synchronization of the DNS Homenet Zone: the Public 185 Authoritative Name Server Set as public available name servers 186 for the Registered Homenet Domain. 188 - DNS Homenet Reverse Zone: The reverse zone file associated to the 189 DNS Homenet Zone. 191 - Public Authoritative Server: performs DNSSEC management 192 operations as well as provides the authoritative service for 193 the zone. In this document, the Public Authoritative Server 194 synchronizes the DNS Homenet Zone with the CPE via a hidden 195 primary / secondary architecture. The Public Authoritative 196 Server acts as a secondary and MAY use specific servers called 197 Public Authoritative Name Server Set. Once the Public 198 Authoritative Server synchronizes the DNS Homenet Zone, it 199 signs the zone and generates the DNSSEC Public Zone. Then the 200 Public Authoritative Server hosts the zone as an authoritative 201 server on the Public Authoritative Primary(ies). 203 - DNSSEC Public Zone: corresponds to the signed version of the DNS 204 Homenet Zone. It is hosted by the Public Authoritative Server, 205 which is authoritative for this zone, and is reachable on the 206 Public Authoritative Primary(ies). 208 - Public Authoritative Primary(ies): are the visible name server 209 hosting the DNSSEC Public Zone. End users' resolutions for the 210 Homenet Domain are sent to this server, and this server is a 211 primary for the zone. 213 - Public Authoritative Name Server Set: is the server the CPE 214 synchronizes the DNS Homenet Zone. It is configured as a 215 secondary and the CPE acts as primary. The CPE sends 216 information so the DNSSEC zone can be set and served. 218 - Reverse Public Authoritative Primary(ies): are the visible name 219 server hosting the DNS Homenet Reverse Zone. End users' 220 resolutions for the Homenet Domain are sent to this server, and 221 this server is a primary for the zone. 223 - Reverse Public Authoritative Name Server Set: is the server the 224 CPE synchronizes the DNS Homenet Reverse Zone. It is 225 configured as a secondary and the CPE acts as primary. The CPE 226 sends information so the DNSSEC zone can be set and served. 228 4. Architecture Description 230 This section describes the architecture for outsourcing the 231 authoritative naming service from the CPE to the Public Authoritative 232 Primary(ies). Section 4.1 describes the architecture, Section 4.2 233 and Section 4.3 illustrate this architecture and shows how the 234 DNS(SEC) Homenet Zone should be built by the CPE, as well as lists 235 the necessary parameters the CPE needs to outsource the authoritative 236 naming service. These two section are informational and non 237 normative. 239 4.1. Architecture Overview 241 Figure 1 provides an overview of the architecture. 243 The home network is designated by the Registered Homenet Domain Name 244 -- example.com in Figure 1. The CPE builds the DNS(SEC) Homenet Zone 245 associated to the home network. How the DNS(SEC) Homenet Zone is 246 built is out of the scope of this document. The CPE may host and 247 involve multiple services like a web GUI, DHCP [RFC6644] or mDNS 248 [RFC6762]. These services may coexist and may be used to populate 249 the DNS Homenet Zone. This document assumes the DNS(SEC) Homenet 250 Zone has been populated with domain names that are intended to be 251 publicly published and that are publicly reachable. More 252 specifically, names associated to services or devices that are not 253 expected to be reachable from outside the home network or names bound 254 to non globally reachable IP addresses MUST NOT be part of the 255 DNS(SEC) Homenet Zone. 257 Once the DNS(SEC) Homenet Zone has been built, the CPE does not host 258 the authoritative naming service for it, but instead outsources it to 259 the Public Authoritative Servers. The Public Authoritative Servers 260 take the DNS(SEC) Homenet as an input and publishes the DNS(SEC) 261 Public Zone. In fact the DNS(SEC) Homenet Zone and the DNS(SEC) 262 Public Zone have different names as they may be different. If the 263 CPE does not sign the DNS Homenet Zone, for example, the Public 264 Authoritative Servers may instead sign it on behalf of the CPE. 265 Figure 1 provides a more detailed description of the Public 266 Authoritative Servers, but overall, it is expected that the CPE 267 provides the DNS(SEC) Homenet Zone, the DNS(SEC) Public Zone is 268 derived from the DNS(SEC) Homenet Zone and published on the Internet. 270 As a result, DNS(SEC) queries from the DNS(SEC) Resolvers on the 271 Internet are answered by the Public Authoritative Server and do not 272 reach the CPE. Figure 1 illustrates the case of the resolution of 273 node1.example.com. 275 home network +-------------------+ Internet 276 | | 277 | CPE | 278 | | +----------------------+ 279 +-------+ |+-----------------+| | Public Authoritative | 280 | | || DNS(SEC) Homenet|| | Servers | 281 | node1 | || Zone || |+--------------------+| 282 | | || || ||DNS(SEC) Public Zone|| 283 +-------+ || Homenet Domain ||=========|| || 284 || Name || ^ || (example.com) || 285 node1.\ || (example.com) || | |+--------------------+| 286 example.com |+-----------------+| | +----------------------+ 287 +-------------------+ | ^ | 288 Synchronization | | 289 | | 290 DNSSEC resolution for node1.example.com | v 291 +----------------------+ 292 | | 293 | DNSSEC Resolver | 294 | | 295 +----------------------+ 297 Figure 1: Homenet Naming Architecture Description 299 The Public Authoritative Servers are described in Figure 2. The 300 Public Authoritative Name Server Set receives the DNS(SEC) Homenet 301 Zone as an input. The received zone may be transformed to output the 302 DNS(SEC) Public Zone. Various operations may be performed here, 303 however this document only considers zone signing as potential 304 operation. This could occur only when the CPE outsources this 305 operation to the Public Authoritative Name Server Set. On the other 306 hand, if the CPE signs the DNSSEC Homenet Zone itself, the zone it 307 collected by the Public Authoritative Name Server Set and directly 308 transferred to the Public Authoritative Primary. Implications of 309 such policy are detailed in Section 6 and Section 7. 311 Internet 313 +--------------------------------------------------------+ 314 | Public Authoritative Servers | 315 +--------------------------------------------------------+ 317 +----------------------+ +----------------------+ 318 | | | | 319 | Public Authoritative | | Public Authoritative | 320 | Name Server Set | | Primaries | 321 | | | | 322 | +------------------+ | X | +------------------+ | 323 | | DNS(SEC) Homenet | | ^ | | DNS(SEC) Public | | 324 =========>| | Zone | | | | | Zone | | 325 ^ | | | | | | | | | 326 | | | (example.com) | | | | | (example.com) | | 327 | | +------------------+ | | | +------------------+ | 328 | +----------------------+ | +----------------------+ 329 | Homenet to Public Zone 330 Synchronization transformation 331 from the CPE 333 Figure 2: Public Authoritative Servers Description 335 4.2. Example: DNS(SEC) Homenet Zone 337 This section is not normative and intends to illustrate how the CPE 338 builds the DNS(SEC) Homenet Zone. 340 As depicted in Figure 1 and Figure 2, the DNS(SEC) Public Zone is 341 hosted on the Public Authoritative Primaries, whereas the DNS(SEC) 342 Homenet Zone is hosted on the CPE. Motivations for keeping these two 343 zones identical are detailed in Section 7, and this section considers 344 that the CPE builds the zone that will be effectively published on 345 the Public Authoritative Primaries. In other words "Homenet to 346 Public Zone transformation" is the identity. 348 In that case, the DNS Homenet Zone should configure its Name Server 349 RRset (NS) and Start of Authority (SOA) with the ones associated to 350 the Public Authoritative Primaries. This is illustrated in Figure 3. 351 public.primary.example.net is the FQDN of the Public Authoritative 352 Primaries, and IP1, IP2, IP3, IP4 are the associated IP addresses. 353 Then the CPE should add the different new nodes that enter the home 354 network, remove those that should be removed and sign the DNS Homenet 355 Zone. 357 $ORIGIN example.com 358 $TTL 1h 360 @ IN SOA public.primary.example.net 361 hostmaster.example.com. ( 362 2013120710 ; serial number of this zone file 363 1d ; secondary refresh 364 2h ; secondary retry time in case of a problem 365 4w ; secondary expiration time 366 1h ; maximum caching time in case of failed 367 ; lookups 368 ) 370 @ NS public.authoritative.servers.example.net 372 public.primary.example.net A @IP1 373 public.primary.example.net A @IP2 374 public.primary.example.net AAAA @IP3 375 public.primary.example.net AAAA @IP4 377 Figure 3: DNS Homenet Zone 379 The SOA RRset is defined in [RFC1033], [RFC1035] and [RFC2308]. This 380 SOA is specific as it is used for the synchronization between the 381 Hidden Primary and the Public Authoritative Name Server Set and 382 published on the DNS Public Authoritative Primary. 384 - MNAME: indicates the primary. In our case the zone is published 385 on the Public Authoritative Primary, and its name MUST be 386 mentioned. If multiple Public Authoritative Primaries are 387 involved, one of them MUST be chosen. More specifically, the 388 CPE MUST NOT place the name of the Hidden Primary. 390 - RNAME: indicates the email address to reach the administrator. 391 [RFC2142] recommends to use hostmaster@domain and replacing the 392 '@' sign by '.'. 394 - REFRESH and RETRY: indicate respectively in seconds how often 395 secondaries need to check the primary and the time between two 396 refresh when a refresh has failed. Default value indicated by 397 [RFC1033] are 3600 (1 hour) for refresh and 600 (10 minutes) 398 for retry. This value MAY be long for highly dynamic content. 399 However, Public Authoritative Primaries and the CPE are 400 expected to implement NOTIFY [RFC1996]. Then short values MAY 401 increase the bandwidth usage for secondaries hosting large 402 number of zones. As a result, default values looks fine. 404 EXPIRE: is the upper limit data SHOULD be kept in absence of 405 refresh. Default value indicated by [RFC1033] is 3600000 about 406 42 days. In home network architectures, the CPE provides both 407 the DNS synchronization and the access to the home network. 408 This device MAY be plugged and unplugged by the end user 409 without notification, thus we recommend large period. 411 MINIMUM: indicates the minimum TTL. Default value indicated by 412 [RFC1033] is 86400 (1 day). For home network, this value MAY 413 be reduced, and 3600 (1 hour) seems more appropriated. 415 4.3. Example: CPE necessary parameters for outsourcing 417 This section specifies the various parameters required by the CPE to 418 configure the naming architecture of this document. This section is 419 informational, and is intended to clarify the information handled by 420 the CPE and the various settings to be done. 422 Public Authoritative Name Server Set may be defined with the 423 following parameters. These parameters are necessary to establish a 424 secure channel between the CPE and the Public Authoritative Name 425 Server Set: 427 - Public Authoritative Name Server Set: The associated FQDNs or IP 428 addresses of the Public Authoritative Server. IP addresses are 429 optional and the FQDN is sufficient. To secure the binding 430 name and IP addresses, a DNSSEC exchange is required. 431 Otherwise, the IP addresses should be entered manually. 433 - Authentication Method: How the CPE authenticates itself to the 434 Public Server. This MAY depend on the implementation but we 435 should consider at least IPsec, DTLS and TSIG 437 - Authentication data: Associated Data. PSK only requires a single 438 argument. If other authentication mechanisms based on 439 certificates are used, then, files for the CPE private keys, 440 certificates and certification authority should be specified. 442 - Public Authoritative Primary(ies): The FQDN or IP addresses of 443 the Public Authoritative Primary. It MAY correspond to the 444 data that will be set in the NS RRsets and SOA of the DNS 445 Homenet Zone. IP addresses are optional and the FQDN is 446 sufficient. To secure the binding name and IP addresses, a 447 DNSSEC exchange is required. Otherwise, the IP addresses 448 should be entered manually. 450 - Registered Homenet Domain: The domain name the Public 451 Authoritative is configured for DNS secondary, DNSSEC zone 452 signing and DNSSEC zone hosting. 454 Setting the DNS(SEC) Homenet Zone requires the following information. 456 - Registered Homenet Domain: The Domain Name of the zone. Multiple 457 Registered Homenet Domain may be provided. This will generate 458 the creation of multiple DNS Homenet Zones. 460 - Public Authoritative Primaries: The public authoritative servers 461 associated to the Registered Homenet Domain. Multiple public 462 authoritative server may be provided. 464 5. Synchronization between CPE and Public Authoritative Name Server 465 Sets 467 The DNS(SEC) Homenet Reverse Zone and the DNS Homenet Zone can be 468 updated either with DNS update [RFC2136] or using a primary / 469 secondary synchronization. The primary / secondary mechanism is 470 preferred as it better scales and avoids DoS attacks: First the 471 primary notifies the secondary the zone must be updated, and leaves 472 the secondary to proceed to the update when possible. Then, the 473 NOTIFY message sent by the primary is a small packet that is less 474 likely to load the secondary. At last, the AXFR query performed by 475 the secondary is a small packet sent over TCP (section 4.2 [RFC5936]) 476 which makes unlikely the secondary to perform reflection attacks with 477 a forged NOTIFY. On the other hand, DNS updates can use UDP, packets 478 require more processing then a NOTIFY, and they do not provide the 479 server the opportunity to post-pone the update. 481 This document recommends the use of a primary / secondary mechanism 482 instead of the use of nsupdates. This section details the primary / 483 secondary mechanism. 485 5.1. Synchronization with a Hidden Primary 487 Uploading and dynamically updating the zone file on the Public 488 Authoritative Name Server Set can be seen as zone provisioning 489 between the CPE (Hidden Primary) and the Public Authoritative Name 490 Server Set (Secondary Server). This can be handled either in band or 491 out of band. 493 The Public Authoritative Name Server Set is configured as a secondary 494 for the Homenet Domain Name. This secondary configuration has been 495 previously agreed between the end user and the provider of the Public 496 Authoritative Name Server Sets. In order to set the primary/ 497 secondary architecture, the CPE acts as a Hidden Primary Server, 498 which is a regular Authoritative DNS(SEC) Server listening on the WAN 499 interface. 501 The Hidden Primary Server is expected to accept SOA [RFC1033], AXFR 502 [RFC1034], and IXFR [RFC1995] queries from its configured secondary 503 DNS servers. The Hidden Primary Server SHOULD send NOTIFY messages 504 [RFC1996] in order to update Public DNS server zones as updates 505 occur. Because, DNS Homenet Zones are likely to be small, CPE MUST 506 implement AXFR and SHOULD implement IXFR. 508 Hidden Primary Server differs from a regular authoritative server for 509 the home network by: 511 - Interface Binding: the Hidden Primary Server listens on the WAN 512 Interface, whereas a regular authoritative server for the home 513 network would listen on the home network interface. 515 - Limited exchanges: the purpose of the Hidden Primary Server is to 516 synchronizes with the Public Authoritative Name Server Set, not 517 to serve zone. As a result, exchanges are performed with 518 specific nodes (the Public Authoritative Name Server Sets). 519 Then exchange types are limited. The only legitimate exchanges 520 are: NOTIFY initiated by the Hidden Primary and IXFR or AXFR 521 exchanges initiated by the Public Authoritative Name Server 522 Set. On the other hand regular authoritative servers would 523 respond any hosts on the home network, and any DNS(SEC) query 524 would be considered. The CPE SHOULD filter IXFR/AXFR traffic 525 and drop traffic not initiated by the Public Authoritative Name 526 Server Set. The CPE MUST listen for DNS on TCP and UDP and at 527 least allow SOA lookups to the DNS Homenet Zone. 529 5.2. Securing Synchronization 531 Exchange between the Public Authoritative Name Server Sets and the 532 CPE MUST be secured, at least for integrity protection and for 533 authentication. 535 TSIG [RFC2845] or SIG(0) [RFC2931] can be used to secure the DNS 536 communications between the CPE and the Public DNS(SEC) Servers. TSIG 537 uses a symmetric key which can be managed by TKEY [RFC2930]. 538 Management of the key involved in SIG(0) is performed through zone 539 updates. How to roll the keys with SIG(0) is out-of-scope of this 540 document. The advantage of these mechanisms is that they are only 541 associated with the DNS application. Not relying on shared libraries 542 ease testing and integration. On the other hand, using TSIG, TKEY or 543 SIG(0) requires these mechanisms to be implemented on the DNS(SEC) 544 Server's implementation running on the CPE, which adds codes. 546 Another disadvantage is that TKEY does not provide authentication 547 mechanism. 549 Protocols like TLS [RFC5246] / DTLS [RFC6347] can be used to secure 550 the transactions between the Public Authoritative Name Server Sets 551 and the CPE. The advantage of TLS/DTLS is that this technology is 552 widely deployed, and most of the boxes already embeds a TLS/DTLS 553 libraries, eventually taking advantage of hardware acceleration. 554 Then TLS/DTLS provides authentication facilities and can use 555 certificates to authenticate the Public Authoritative Name Server Set 556 and the CPE. On the other hand, using TLS/DTLS requires to integrate 557 DNS exchange over TLS/DTLS, as well as a new service port. This is 558 why we do not recommend this option. 560 IPsec [RFC4301] IKEv2 [RFC7296] can also be used to secure the 561 transactions between the CPE and the Public Authoritative Servers. 562 Similarly to TLS/DTLS, most CPE already embeds a IPsec stack, and 563 IKEv2 provides multiple authentications possibilities with its EAP 564 framework. In addition, IPsec can be used to protect the DNS 565 exchanges between the CPE and the Public Authoritative Servers 566 without any modifications of the DNS Servers or client. DNS 567 integration over IPsec only requires an additional security policy in 568 the Security Policy Database. One disadvantage of IPsec is that it 569 hardly goes through NATs and firewalls. However, in our case, the 570 CPE is connected to the Internet, and IPsec communication between the 571 CPE and Public Authoritative Name Server Set SHOULD NOT be impacted 572 by middle boxes. 574 How the PSK can be used by any of the TSIG, TLS/DTLS or IPsec 575 protocols: Authentication based on certificates implies a mutual 576 authentication and thus requires the CPE to manage a private key, a 577 public key or certificates as well as Certificate Authorities. This 578 adds complexity to the configuration especially on the CPE side. For 579 this reason, we recommend that CPE MAY use PSK or certificate base 580 authentication and that Public Authoritative Servers Servers MUST 581 support PSK and certificate based authentication. 583 Note also that authentication of the messages exchanged between the 584 CPE and the Public Authoritative Name Server Set should not involve 585 the IP address to index the appropriated keys. As detailed in 586 Section 9, the IP addresses of the Public Authoritative Name Server 587 Set and the Hidden Primary are subject to change, for example while 588 the network is being renumbered. This means that the necessary keys 589 to authenticate transaction must not be indexed using the IP and be 590 resilient to IP updates. 592 5.3. CPE Security Policies 594 This section details security policies related to the Hidden Primary 595 / Secondary synchronization. 597 The Hidden Primary, as described in this document SHOULD drop any 598 queries from the home network. This can be performed with port 599 binding and/or firewall rules. 601 The Hidden Primary SHOULD drop on the WAN interface any DNS queries 602 that is not issued from the Public Authoritative Name Server Set. 604 The Hidden Primary SHOULD drop any outgoing packets other than DNS 605 NOTIFY query, SOA response, IXFR response or AXFR responses. 607 The Hidden Primary SHOULD drop any incoming packets other than DNS 608 NOTIFY response, SOA query, IXFR query or AXFR query. 610 The Hidden Primary SHOULD drop any non protected IXFR or AXFR 611 exchange. This depends how the synchronization is secured. 613 6. DNSSEC compliant Homenet Architecture 615 [RFC7368] in Section 3.7.3 recommends DNSSEC to be deployed on the 616 both the authoritative server and the resolver. The resolver side is 617 out of scope of this document, and only the authoritative part is 618 considered. 620 Deploying DNSSEC requires signing the zone and configuring a secure 621 delegation. As described in Section 4.1, signing can be performed by 622 the CPE or by the Public Authoritative Name Server Sets. Section 6.1 623 details the implications of these two alternatives. Similarly, the 624 secure delegation can be performed by the CPE or by the Public 625 Authoritative Servers. Section 6.2 discusses these two alternatives. 627 6.1. Zone Signing 629 This section discusses the pros and cons when zone signing is 630 performed by the CPE or by the Public Authoritative Name Servers Set. 631 It is recommended the CPE signs the zone unless there is a strong 632 argument against it, like a CPE that is not able to sign the zone. 633 In that case zone signing may be performed by the Public 634 Authoritative Name Servers Set on behalf of the CPE. 636 Reasons for signing the zone by the CPE are: 638 - 1: Keeping the Homenet Zone and the Public Zone equals to securely 639 optimize DNS resolution. As the Public Zone is signed with 640 DNSSEC, RRsets are authenticated and thus DNS responses can be 641 validated even though they are not provided by the 642 authoritative server. This provides the CPE the ability to 643 respond on behalf of the Public Authoritative Primary. This 644 could be useful for example if, in the future, the CPE could 645 announce to the home network that the CPE can act a a local 646 authoritative primary or equivalent for the Homenet Zone. 647 Currently the CPE is not expected to receive authoritative DNS 648 queries as its IP address is not mentioned in the Public Zone. 649 On the other hand most CPEs host a resolving function, and 650 could be configured to perform a local lookup to the Homenet 651 Zone instead of initiating a DNS exchange with the Public 652 Authoritative Primary. Note that outsourcing the zone signing 653 operation requires that all DNSSEC queries be cached to perform 654 a local lookup, otherwise a resolution with the Public 655 Authoritative Primary is performed. 657 - 2: Keeping the Homenet Zone and the Public Zone equals to securely 658 address the connectivity disruption independence exposed in 659 [RFC7368] section 4.4.1 and 3.7.5. As local lookups are 660 possible in case of network disruption, communications within 661 the home network can still rely on the DNSSEC service. Note 662 that outsourcing the zone signing operation does not address 663 connectivity disruption independence with DNSSEC. Instead 664 local lookup would provide DNS as opposed to DNSSEC responses 665 provided by the Public Authoritative Primaries. 667 - 3: Keeping the Homenet Zone and the Public Zone equals to 668 guarantee coherence between DNS(SEC) responses. Using a unique 669 zone is one way to guarantee uniqueness of the responses among 670 servers and places. Issues generated by different views are 671 discussed in more details in Section 7. 673 - 2: Privacy and Integrity of the DNS Zone are better guaranteed. 674 When the Zone is signed by the CPE, it makes modification of 675 the DNS data -- for example for flow redirection -- not 676 possible. As a result, signing the Homenet Zone by the CPE 677 provides better protection for the end user privacy. 679 Reasons for signing the zone by the Public Authoritative Servers are: 681 - 1: The CPE is not able to sign the zone, most likely because its 682 firmware does not make it possible. However the reason is 683 expected to be less and less valid over time. 685 - 2: Outsourcing DNSSEC management operations. Management 686 operations involve key-roll over which can be done 687 automatically by the CPE and transparently for the end user. 689 As result avoiding DNSSEC management is mostly motivated by bad 690 software implementations. 692 - 3: Reducing the impact of CPE replacement on the Public Zone. 693 Unless the CPE private keys are backuped, CPE replacement 694 results in a emergency key roll over. This can be mitigated 695 also by using relatively small TTLs. 697 - 4: Reducing configuration impacts on the end user. Unless there 698 are some zero configuration mechanisms to provide credentials 699 between the new CPE and the Public Authoritative Name Server 700 Sets. Authentications to Public Authoritative Name Server Set 701 should be re-configured. As CPE replacement is not expected to 702 happen regularly, end users may not be at ease with such 703 configuration settings. However, mechanisms as described in 704 [I-D.ietf-homenet-naming-architecture-dhc-options] use DHCP 705 Options to outsource the configuration and avoid this issue. 707 - 5: Public Authoritative Servers are more likely to handle securely 708 private keys than the CPE. However, having all private 709 information at one place may also balance that risk. 711 6.2. Secure Delegation 713 The secure delegation is set if the DS RRset is properly set in the 714 parent zone. Secure delegation can be performed by the CPE or the 715 Public Authoritative Servers. 717 The DS RRset can be updated manually by the CPE or the Public 718 Authoritative Servers. This can be used then with nsupdate for 719 example but requires the CPE or the Public Authoritative Server to be 720 authenticated by the Parent Zone Server. Such a trust channel 721 between the CPE and the Parent Zone server may be hard to maintain, 722 and thus may be easier to establish with the Public Authoritative 723 Server. On the other hand, [RFC7344] may mitigate such issues. 725 7. Handling Different Views 727 The DNS Homenet Zone provides information about the home network and 728 some user may be tempted to have different information regarding the 729 origin of the DNS query. More specifically, some users may be 730 tempted to provide a different view for DNS queries originating from 731 the home network and for DNS queries coming from the wild Internet. 732 Each view can be associated to a dedicated Homenet Zone. Note that 733 this document does not specify how DNS queries coming from the home 734 network are addressed to the DNS(SEC) Homenet Zone. This could be 735 done via the DNS resolver hosted on the CPE for example. 737 This section is not normative. Section 7.1 details why some nodes 738 may only be reachable from the home network and not from the global 739 Internet. Section 7.2 briefly describes the consequences of having 740 distinct views such as a "home network view" and a "Internet view". 741 Finally, Section 7.3 provides guidance to on how to resolve names 742 that are only significant in the home network without creating 743 different views. 745 7.1. Misleading Reasons for Local Scope DNS Zone 747 The main motivation to handle different views is to provide different 748 information depending on the location the DNS query is emitted. Here 749 are a few motivations for doing so: 751 - 1: An end user may want to have services not published on the 752 Internet. Services like the CPE administration interface that 753 provides the GUI to administrate your CPE may not be published 754 on the Internet. Similarly services like the mapper that 755 registers the devices of your home network may not be published 756 on the Internet. In both case, these services should only be 757 known/used by the network administrator. To restrict the 758 access of such services, the home network administrator may 759 chose to publish these information only within the home 760 network, where it may suppose users are more trustable then on 761 the Internet. Even though, this assumption may not be valid, 762 at least, this reduces the surface of attack. 764 - 2: Services within the home network may be reachable using non 765 global IP addresses. IPv4 and NAT may be one reason. On the 766 other hand IPv6 may favor link-local or site-local IP 767 addresses. These IP addresses are not significant outside the 768 boundaries of the home network. As a result, they may be 769 published in the home network view, and should not be published 770 in the Internet. 772 - 3: If the CPE does not sign the Homenet Zone and outsource the 773 signing process, the two views are at least different since, 774 one is protected with DNSSEC whereas the other is not. 776 7.2. Consequences 778 Enabling different views leads to a non-coherent naming system. 779 Basically, depending on where resolution is performed, some services 780 will not be available. This may be especially inconvenient with 781 devices with multiple interfaces that are attached both to the 782 Internet via a 3G/4G interface and to the home network via a WLAN 783 interface. 785 Regarding local-scope IP addresses, such device may end up with poor 786 connectivity. Suppose, for example, the DNS resolution is performed 787 via the WLAN interface attached to the CPE, the response provides 788 local-scope IP addresses and the communication is initiated on the 789 3G/4G interface. Communications with local-scope addresses will be 790 unreachable on the Internet, thus aborting the communication. The 791 same situation occurs if a device is flip / flopping between various 792 WLAN networks. 794 Regarding DNSSEC, devices with multiple interfaces will have 795 difficulties to secure the naming resolution as responses emitted 796 from the home network may not be signed. 798 For devices with all its interfaces attached to a single 799 administrative domain, that is to say the home network or the 800 Internet. Incoherence between DNS responses may also happen if the 801 device is able to perform DNS resolutions. DNS resolutions performed 802 via the CPE resolver may be different then those performed over the 803 Internet. 805 7.3. Guidance and Recommendations 807 As exposed in Section 7.2, it is recommended to avoid different 808 views. If network administrators chose to implement multiple views, 809 impacts on devices' resolution should be evaluated. 811 A consequence the DNS(SEC) Homenet Zone is expected to be the exact 812 copy of the DNS(SEC) Public Zone. As a result, services that are not 813 expected to be published on the Internet should not be part of the 814 DNS(SEC) Homenet Zone, local-scope address should not be part of the 815 DNS(SEC) Homenet Zone, and when possible, the CPE should sign the 816 DNS(SEC) Homenet Zone. 818 The DNS(SEC) Homenet Zone is expected to host public information. It 819 is not to the DNS service to define local home networks boundaries. 820 Instead, local scope information is expected to be provided to the 821 home network using local scope naming services. mDNS [RFC6762] DNS-SD 822 [RFC6763] are one of these services. Currently mDNS is limited to a 823 single link network. However, future protocols are expected to 824 leverage this constraint as pointed out in 825 [I-D.ietf-dnssd-requirements]. 827 8. Reverse Zone 829 Most of the description considered the DNS Homenet Zone as the non- 830 Reverse Zone. This section is focused on the Reverse Zone. 832 First, all considerations for the DNS Homenet Zone apply to the 833 Reverse Homenet Zone. The main difference between the Reverse DNS 834 Homenet Zone and the DNS Homenet Zone is that the parent zone of the 835 Reverse Homenet Zone is most likely managed by the ISP. As the ISP 836 also provides the IP prefix to the CPE, it may be able to 837 authenticate the CPE. If the Reverse Public Authoritative Name 838 Server Set is managed by the ISP, credentials to authenticate the CPE 839 for the zone synchronization may be set automatically and 840 transparently to the end user. 841 [I-D.ietf-homenet-naming-architecture-dhc-options] describes how 842 automatic configuration may be performed. 844 With IPv6, the domain space for IP address is so large, that reverse 845 zone may be confronted to a scalability issue. How to reverse zone 846 is generated is out of scope of this document. 847 [I-D.howard-dnsop-ip6rdns] provides guidance on how to address the 848 scalability issue. 850 9. Renumbering 852 This section details how renumbering is handled by the Hidden Primary 853 server or the Public Authoritative Name Server Set which acts as a 854 secondary server. Both types of renumbering also designated as 855 "make-before-break" or "break-before-make" are discussed. 857 In the make-before-break renumbering scenario, the new prefix is 858 advertised, the network is configured to prepare the transition to 859 the new prefix. During a period of time, the two prefixes old and 860 new coexist, before the old prefix is completely removed. In the 861 break-before-make renumbering scenario, the new prefix is advertised 862 making the old prefix obsolete. 864 Renumbering has been extensively described in [RFC4192] and analyzed 865 in [RFC7010] and the reader is expected to become familiar with them. 867 9.1. Hidden Primary 869 In a renumbering scenario, the Hidden Primary is informed it is being 870 renumbered. In most cases, it occurs as the whole home network is 871 being renumbered. As a result, the DNS(SEC) Homenet Zone will also 872 be updated. Although the new and old IP addresses may be stored in 873 the DNS(SEC) Homenet Zone, we recommend that only the newly reachable 874 IP addresses be mentioned. 876 To avoid reachability disruption, IP connectivity information 877 provided by the DNS should be coherent with the IP plane. In our 878 case, this means the old IP address should not be provided via the 879 DNS, when it is not reachable anymore. Let for example TTL be the 880 TTL associate to a RRset of the Homenet Zone, it may be cache during 881 TTL seconds. Let T_NEW be the time the new IP address replaces the 882 old IP address in the DNS, and T_OLD_UNREACHABLE the time the old IP 883 is not reachable anymore. In the case of the make-before-break, 884 seamless reachability is provided as long as T_OLD_UNREACHABLE - 885 T_NEW > 2 * TTL. If this is not satisfied, then devices associated 886 to the old IP address in the home network may become unreachable for 887 2 * TTL - (T_OLD_UNREACHABLE - T_NEW). In the case of a break- 888 before-make, T_OLD_UNREACHABLE = T_NEW, and the device may become non 889 reachable up to 2 * TTL. 891 Once the DNS(SEC) Homenet Zone file has been updated on the Hidden 892 Primary, the Hidden Primary needs to inform the Public Authoritative 893 Naming Server Set that the DNS(SEC) Homenet Zone has been updated and 894 that the IP address to use to retrieve the updated zone has also been 895 updated. Both information are updated using the regular DNS 896 exchanges. More specifically, mechanisms to update a IP address 897 provided by lower layers with for protocols like SCTP [RFC4960], 898 MOBIKE [RFC4555] are not considered in this document. 900 The Hidden Primary informs the Public Authoritative Name Server Set 901 the DNS(SEC) Homenet Zone has been updated by sending a NOTIFY 902 payload with the new IP address. In addition, this NOTIFY payload is 903 authenticated using SIG(0) or TSIG. When the Public Authoritative 904 Name Server Set receives the NOTIFY payload, it MUST authenticate it. 905 Note that the cryptographic key used for the authentication should be 906 indexed by the Homenet Domain Name contained in the NOTIFY payload as 907 well as the RRSIG. In other words, the IP address should not be used 908 as an index. If authentication succeeds, the Public Authoritative 909 Name Server Set MUST also notice the IP address has been modified and 910 perform a reachability check before updating its primary 911 configuration. The routability check is performed by sending a SOA 912 request to the Hidden Primary using the source IP address of the 913 NOTIFY. This exchange is also secured, and if an authenticated 914 response is received from the Hidden Primary with the new IP address, 915 the Public Authoritative Name Server Set updates its configuration 916 file and retrieve the DNS(SEC) Homenet Zone using an AXFR or a IXFR 917 exchange. 919 Note that the primary reason for providing the IP address is that the 920 Hidden Primary is not publicly announced in the DNS. If the Hidden 921 Primary were publicly announced in the DNS, then the IP address 922 update could have been performed using the DNS as described in 923 Section 9.2. 925 9.2. Public Authoritative Name Server Set 927 Renumbering of the Public Authoritative Name Server Set results in 928 the Public Authoritative Name Server Set to change its IP address. 929 The Public Authoritative Name Server Set is a secondary, so its 930 renumbering does not impact the DNS(SEC) Homenet Zone. In fact, 931 exchanges to the Public Authoritative Name Server Set are restricted 932 to the DNS(SEC) Homenet Zone synchronization. In our case, the 933 Hidden Primary MUST be able to send NOTIFY payloads to the Public 934 Authoritative Name Server Set. 936 If the Public Authoritative Name Server Set is configured in Hidden 937 Primary configuration file with a FQDN, then the update of the IP 938 address is performed by the DNS(SEC). More specifically, before 939 sending the NOTIFY, the Hidden Primary performs a DNS(SEC) resolution 940 to retrieve the IP address of the secondary. 942 As described in Section 9.1, the Public Authoritative Name Server Set 943 DNS information should be coherent with the IP plane. Let TTL be the 944 TTL associated to the Public Authoritative Name Server Set FQDN, 945 T_NEW the time the new IP address replaces the old one and 946 T_OLD_UNREACHABLE the time the Public Authoritative Name Server Set 947 is not reachable anymore with its old IP address. Seamless 948 reachability is provided as long as T_OLD_UNREACHABLE - T_NEW > 2 * 949 TTL. If this condition is not met, the Public Authoritative Name 950 Server Set may be unreachable during 2 * TTL - (T_OLD_UNREACHABLE - 951 T_NEW). In the case of a break-before-make, T_OLD_UNREACHABLE = 952 T_NEW, and it may become non reachable up to 2 * TTL. 954 Some DNS infrastructure uses the IP address to designate the 955 secondary, in which case, other mechanisms must be found. The reason 956 for using IP addresses instead of names is generally, to reach an 957 internal interface that is not designated by a FQDN. Such scenarios 958 are considered as out of scope in the case of home networks. 960 10. Privacy Considerations 962 Outsourcing the DNS Authoritative service from the CPE to a third 963 entity comes with a few privacy related concerns. 965 First the DNS Homenet Zone contains a full description of the 966 services hosted in the network. These services may not be expected 967 to be publicly shared although their names remains accessible though 968 the Internet. Even though DNS makes information public, the DNS does 969 not expect to make the complete list of service public. In fact, 970 making information public still requires the key (or FQDN) of each 971 service to be known by the resolver in order to retrieve information 972 of the services. More specifically, making mywebsite.example.com 973 public in the DNS, is not sufficient to make resolvers aware of the 974 existence web site. 976 In order to prevent the complete DN(SEC) Homenet Zone to be published 977 on the Internet, one should prevent AXFR queries on the Public 978 Authoritative Primaries. Similarly, to avoid zone-walking one should 979 prefer NSEC3 [RFC5155] over NSEC [RFC4034]. 981 When the DNS Homenet Zone is outsourced the end user must be aware 982 that it provides a complete description of the services available on 983 the home network. More specifically, names usually provides a clear 984 indication of the service and eventually the device, by as the DNS 985 Homenet Zone contains the IP addresses associated to the service, 986 they limit the scope of the scan. 988 In addition to the DNS Homenet Zone, the third party can also monitor 989 the traffic associated to the DNS Homenet Zone. This traffic may 990 provide indication of the services you use, how and when you use 991 these services. Although, cache may alter this information inside 992 the home network, it is likely that outside your home network this 993 information will not be cached. 995 11. Security Considerations 997 The Homenet Naming Architecture described in this document solves 998 exposing the CPE's DNS service as a DoS attack vector. 1000 11.1. Names are less secure than IP addresses 1002 This document describes how an End User can make his services and 1003 devices from his home network reachable on the Internet with Names 1004 rather than IP addresses. This exposes the home network to attackers 1005 since names are expected to provide less randomness than IP 1006 addresses. The naming delegation protects the End User's privacy by 1007 not providing the complete zone of the home network to the ISP. 1008 However, using the DNS with names for the home network exposes the 1009 home network and its components to dictionary attacks. In fact, with 1010 IP addresses, the Interface Identifier is 64 bit length leading to 1011 2^64 possibilities for a given subnetwork. This is not to mention 1012 that the subnet prefix is also of 64 bit length, thus providing 1013 another 2^64 possibilities. On the other hand, names used either for 1014 the home network domain or for the devices present less randomness 1015 (livebox, router, printer, nicolas, jennifer, ...) and thus exposes 1016 the devices to dictionary attacks. 1018 11.2. Names are less volatile than IP addresses 1020 IP addresses may be used to locate a device, a host or a Service. 1021 However, home networks are not expected to be assigned the same 1022 Prefix over time. As a result observing IP addresses provides some 1023 ephemeral information about who is accessing the service. On the 1024 other hand, Names are not expected to be as volatile as IP addresses. 1025 As a result, logging Names, over time, may be more valuable that 1026 logging IP addresses, especially to profile End User's 1027 characteristics. 1029 PTR provides a way to bind an IP address to a Name. In that sense 1030 responding to PTR DNS queries may affect the End User's Privacy. For 1031 that reason we recommend that End Users may choose to respond or not 1032 to PTR DNS queries and may return a NXDOMAIN response. 1034 11.3. DNS Reflection Attacks 1036 An attacker uses a reflection attack when it sends traffic to an 1037 intermediary node that in turn sends back some traffic to the victim. 1038 Motivations for using an intermediary node might be anonymity of the 1039 attacker as wells as amplification of the traffic. Typically, when 1040 the intermediary node is a DNSSEC server, the attacker sends a DNSSEC 1041 query and the victim is likely to receive a DNSSEC response. This 1042 section analyzes how the different components may be involved in a 1043 reflection attack. Section 11.3.1 considers the Hidden Primary, 1044 Section 11.3.2 the Public Authoritative Name Server Set, and 1045 Section 11.3.3 the Public Authoritative Primary. 1047 11.3.1. Reflection Attack involving the Hidden Primary 1049 With the current architecture, the Hidden Primary is only expected to 1050 receive DNS queries of type SOA, AXFR or IXFR. This section analyzes 1051 how these DNS queries may be used by an attacker to perform a 1052 reflection attack. 1054 At first, DNS queries of type AXFR and IXFR uses TCP and as such a 1055 less subject to reflection attacks. This makes SOA query the only 1056 remaining vector of attacks for reflection based on UDP. 1058 Firstly, SOA queries are not associated with a large amplification 1059 factor compared to queries of type "ANY" or to query of non existing 1060 FQDNs. This reduces the probability a DNS query of type SOA is 1061 involved in a DDoS attack. In addition, SOA queries are expected to 1062 follow a very specific pattern which makes rate limiting techniques 1063 an efficient way to limit such attacks, with a limited impact on the 1064 naming service of the home network. 1066 This paragraph analyzes how a Hidden Primary could mitigate a flood 1067 of SOA requests. Motivations for such flood might be a reflection 1068 attack, but could be also an attack performed against the Hidden 1069 Primary for resource exhaustion. At first, the Hidden Primary only 1070 expects traffic from the Public Authoritative Name Server Set that is 1071 its associated secondary. Even though secondary servers may be 1072 renumbered, as exposed in Section 9, the Hidden Primary is likely to 1073 perform a DNSSEC resolution and find out the associated secondary's 1074 IP addresses in use. As a result, the Hidden Primary is likely to 1075 limit the origin of its incoming traffic based on the origin IP 1076 address. 1078 With filtering rules base on the IP address, SOA flooding attacks are 1079 limited to forged packets with the IP address of the secondary 1080 server. In other words, the only victims are the Hidden Primary 1081 itself or the secondary. There is a need for the Hidden Primary to 1082 limit that flood to limit the impact of the reflection attack on the 1083 secondary, and to limit the resource needed to carry on the traffic 1084 by the CPE hosting the Hidden Primary. On the other hand, mitigation 1085 should be appropriately done, as to limit the impact on the 1086 legitimate SOA sent by the secondary. 1088 The main reason for the Public Authoritative Name Server Set to send 1089 a SOA query is to update the SOA RRset after the TTL expires, to 1090 check serial number upon the receipt of a NOTIFY query from the 1091 Hidden Primary or to re-send the SOA request when the response has 1092 not been received. When a flood of SOA queries is received by the 1093 Hidden Primary, the Hidden Primary can assume it is involved in an 1094 attack. There are a few legitimate time slot the secondary is 1095 expected to send a SOA query. These times may be specific times like 1096 T_NOTIFY the emission of a NOTIFY query, T_SOA + 2/3 TTL, T_SOA + 1097 TTL, T_SOA + T_REFRESH where TTL designates the SOA TTL value, 1098 T_REFRESH the refresh time defined in the SOA RRset, and T_SOA the 1099 last time the SOA has been queried. Outside a few minutes following 1100 these specific time, the probability the CPE discard a legitimate SOA 1101 query is very low. Within these time slots, the probability the 1102 secondary may have its legitimate query rejected is higher. If a 1103 legitimate SOA is discarded, the secondary will re-send SOA query 1104 every "retry time" second until "expire time" seconds occurs, where 1105 "retry time" and "expire time" have been defined in the SOA. 1107 As a result, it is recommended to set rate limiting policies to 1108 preserve the CPE resource. If a flood lasts more than the expired 1109 time defined by the SOA, it is recommended to re-initiate a 1110 synchronization between the Hidden Primary and the secondaries. 1112 11.3.2. Reflection Attacks involving the Public Authoritative Name 1113 Server Set 1115 The Public Authoritative Name Server Set acts as a secondary toward 1116 the Hidden Primary. The secondary expects to receive NOTIFY query, 1117 SOA responses, AXFR and IXFR responses from the Hidden Primary. 1119 Sending NOTIFY query to the secondary generates a NOTIFY response as 1120 well as an SOA query to the Hidden Primary. As mentioned in 1121 [RFC1996], this is a "known benign denial of service attack". As a 1122 result, the Public Authoritative Name Server Set should enforce rate 1123 limiting on the SOA queries and NOTIFY responses that are sent to the 1124 Hidden Primary. Most likely, when the secondary is flooded with 1125 valid and signed NOTIFY queries it is under a replay attack which is 1126 discussed in Section 11.5. The key thing here is that the secondary 1127 is likely to be designed to address much traffic than the Hidden 1128 Primary hosted on a CPE. 1130 This paragraph details how the secondary may limit the NOTIFY 1131 queries. Because the Hidden Primary may be renumbered, the secondary 1132 may not proceed to IP filtering based on the IP address. In 1133 addition, a given secondary may be shared among multiple Hidden 1134 Primaries which makes filtering rules based on IP harder to set. At 1135 last, time at which a NOTIFY is sent by the Hidden Primary is not 1136 predictable. However, a flood of NOTIFY may be easily detected as a 1137 NOTIFY for a given DNS Homenet Zone is expected to have a very 1138 limited number of different IP addresses even though renumbering 1139 occurs. As a result, the secondary, can rate limit incoming NOTIFY 1140 queries. 1142 It is recommended the Hidden Primary sends NOTIFY as long as the zone 1143 has not been updated by the secondary. Multiple SOA queries may 1144 indicate the secondary is under attack. 1146 11.3.3. Reflection Attacks involving the Public Authoritative Primary 1148 The Public Authoritative Primary implication of reflection attacks is 1149 similar as any public authoritative server. These is not specific to 1150 the architecture described in this document, and thus considered as 1151 out of scope. 1153 In fact, one of the motivation of the architecture described in this 1154 document was to expose the Public Authoritative Primary to attacks 1155 instead of the CPE. 1157 11.4. Flooding Attack 1159 The purpose of flooding attacks is mostly resource exhaustion where 1160 the resource can be bandwidth or CPU for example. 1162 One of the goal of the architecture described in the document is to 1163 limit the surface of attack for the CPE. This is done, by 1164 outsourcing the DNS service to the Public Authoritative Primaries. 1165 By doing so, the CPE limits its DNS interactions between the Hidden 1166 Primary and the Public Authoritative Name Server Set. This limits the 1167 number of entity the CPE interacts with as well as the scope of DNS 1168 exchanges - basically NOTIFY, SOA, AXFR, IXFR. 1170 The use of an authenticated channel with SIG(0) or TSIG between the 1171 CPE and the Public Authoritative Name Server Set, enables to detect 1172 illegitimate DNS queries, and take appropriated actions - like 1173 dropping the queries. If signatures are validated, then most likely, 1174 the CPE is under a replay attack, as detailed in Section 11.5 1176 In order to limit the resource required for authentication, it is 1177 recommended to use TSIG that uses symmetric cryptography over SIG(0) 1178 that uses asymmetric cryptography. 1180 11.5. Replay Attack 1182 Replay attacks consist in sending a message that has already been 1183 sent. As the Hidden Primary and the Public Authoritative Name Server 1184 Set use an authenticated channel, replay attacks are mostly expected 1185 to used over forged DNS queries in order to provide valid traffic. 1187 On an attacker points of view, using a correctly authenticated DNS 1188 query, may not be detected as an attack, and thus may generate the 1189 corresponding response. Generating and sending a response consumes 1190 more resources then dropping the query and thus could be used for 1191 resource exhaustion attacks. In addition, as the authentication is 1192 performed at the DNS layer, the IP address could be impersonated in 1193 order to perform a reflection attack. 1195 Section 11.3 details how to mitigate reflection attacks and 1196 Section 11.4 details how to mitigate resource exhaustion. Both 1197 section assumes a context of DoS with a flood of DNS queries. This 1198 section address replay attack as a way to limit the surface of these 1199 attacks. 1201 As SIG(0) and TSIG uses inception and expiration time, the time frame 1202 for replay attack is limited. SIG(0) and TSIG recommends a fudge 1203 value of 5 minutes. This value has been set as a compromise between 1204 loose time synchronization of the devices and short live time for the 1205 message. As a result, better time synchronization policies could 1206 reduce the time window of the attack. 1208 12. IANA Considerations 1210 This document has no actions for IANA. 1212 13. Acknowledgment 1214 The authors wish to thank Philippe Lemordant for its contributions on 1215 the early versions of the draft; Ole Troan for pointing out issues 1216 with the IPv6 routed home concept and placing the scope of this 1217 document in a wider picture; Mark Townsley for encouragement and 1218 injecting a healthy debate on the merits of the idea; Ulrik de Bie 1219 for providing alternative solutions; Paul Mockapetris, Christian 1220 Jacquenet, Francis Dupont and Ludovic Eschard for their remarks on 1221 CPE and low power devices; Olafur Gudmundsson for clarifying DNSSEC 1222 capabilities of small devices; Simon Kelley for its feedback as 1223 dnsmasq implementer; Andrew Sullivan, Mark Andrew, Ted Lemon, Mikael 1224 Abrahamson, Michael Richardson and Ray Bellis for their feed backs on 1225 handling different views as well as clarifying the impact of 1226 outsourcing the zone signing operation outside the CPE; Ray Hunter, 1227 Mark Andrew and Peter Koch for clarifying the renumbering. 1229 14. References 1231 14.1. Normative References 1233 [RFC1034] Mockapetris, P., "Domain names - concepts and facilities", 1234 STD 13, RFC 1034, November 1987. 1236 [RFC1035] Mockapetris, P., "Domain names - implementation and 1237 specification", STD 13, RFC 1035, November 1987. 1239 [RFC1995] Ohta, M., "Incremental Zone Transfer in DNS", RFC 1995, 1240 August 1996. 1242 [RFC1996] Vixie, P., "A Mechanism for Prompt Notification of Zone 1243 Changes (DNS NOTIFY)", RFC 1996, August 1996. 1245 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1246 Requirement Levels", BCP 14, RFC 2119, March 1997. 1248 [RFC2136] Vixie, P., Thomson, S., Rekhter, Y., and J. Bound, 1249 "Dynamic Updates in the Domain Name System (DNS UPDATE)", 1250 RFC 2136, April 1997. 1252 [RFC2142] Crocker, D., "MAILBOX NAMES FOR COMMON SERVICES, ROLES AND 1253 FUNCTIONS", RFC 2142, May 1997. 1255 [RFC2308] Andrews, M., "Negative Caching of DNS Queries (DNS 1256 NCACHE)", RFC 2308, March 1998. 1258 [RFC2845] Vixie, P., Gudmundsson, O., Eastlake, D., and B. 1259 Wellington, "Secret Key Transaction Authentication for DNS 1260 (TSIG)", RFC 2845, May 2000. 1262 [RFC2930] Eastlake, D., "Secret Key Establishment for DNS (TKEY 1263 RR)", RFC 2930, September 2000. 1265 [RFC2931] Eastlake, D., "DNS Request and Transaction Signatures ( 1266 SIG(0)s)", RFC 2931, September 2000. 1268 [RFC4034] Arends, R., Austein, R., Larson, M., Massey, D., and S. 1269 Rose, "Resource Records for the DNS Security Extensions", 1270 RFC 4034, March 2005. 1272 [RFC4301] Kent, S. and K. Seo, "Security Architecture for the 1273 Internet Protocol", RFC 4301, December 2005. 1275 [RFC4555] Eronen, P., "IKEv2 Mobility and Multihoming Protocol 1276 (MOBIKE)", RFC 4555, June 2006. 1278 [RFC4960] Stewart, R., "Stream Control Transmission Protocol", RFC 1279 4960, September 2007. 1281 [RFC5155] Laurie, B., Sisson, G., Arends, R., and D. Blacka, "DNS 1282 Security (DNSSEC) Hashed Authenticated Denial of 1283 Existence", RFC 5155, March 2008. 1285 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 1286 (TLS) Protocol Version 1.2", RFC 5246, August 2008. 1288 [RFC5936] Lewis, E. and A. Hoenes, "DNS Zone Transfer Protocol 1289 (AXFR)", RFC 5936, June 2010. 1291 [RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer 1292 Security Version 1.2", RFC 6347, January 2012. 1294 [RFC6644] Evans, D., Droms, R., and S. Jiang, "Rebind Capability in 1295 DHCPv6 Reconfigure Messages", RFC 6644, July 2012. 1297 [RFC6762] Cheshire, S. and M. Krochmal, "Multicast DNS", RFC 6762, 1298 February 2013. 1300 [RFC6763] Cheshire, S. and M. Krochmal, "DNS-Based Service 1301 Discovery", RFC 6763, February 2013. 1303 [RFC7296] Kaufman, C., Hoffman, P., Nir, Y., Eronen, P., and T. 1304 Kivinen, "Internet Key Exchange Protocol Version 2 1305 (IKEv2)", STD 79, RFC 7296, October 2014. 1307 14.2. Informational References 1309 [I-D.howard-dnsop-ip6rdns] 1310 Howard, L., "Reverse DNS in IPv6 for Internet Service 1311 Providers", draft-howard-dnsop-ip6rdns-00 (work in 1312 progress), June 2014. 1314 [I-D.ietf-dnssd-requirements] 1315 Lynn, K., Cheshire, S., Blanchet, M., and D. Migault, 1316 "Requirements for Scalable DNS-SD/mDNS Extensions", draft- 1317 ietf-dnssd-requirements-06 (work in progress), March 2015. 1319 [I-D.ietf-homenet-naming-architecture-dhc-options] 1320 Migault, D., Cloetens, W., Griffiths, C., and R. Weber, 1321 "DHCP Options for Homenet Naming Architecture", draft- 1322 ietf-homenet-naming-architecture-dhc-options-01 (work in 1323 progress), February 2015. 1325 [RFC1033] Lottor, M., "Domain administrators operations guide", RFC 1326 1033, November 1987. 1328 [RFC4192] Baker, F., Lear, E., and R. Droms, "Procedures for 1329 Renumbering an IPv6 Network without a Flag Day", RFC 4192, 1330 September 2005. 1332 [RFC7010] Liu, B., Jiang, S., Carpenter, B., Venaas, S., and W. 1333 George, "IPv6 Site Renumbering Gap Analysis", RFC 7010, 1334 September 2013. 1336 [RFC7344] Kumari, W., Gudmundsson, O., and G. Barwood, "Automating 1337 DNSSEC Delegation Trust Maintenance", RFC 7344, September 1338 2014. 1340 [RFC7368] Chown, T., Arkko, J., Brandt, A., Troan, O., and J. Weil, 1341 "IPv6 Home Networking Architecture Principles", RFC 7368, 1342 October 2014. 1344 Appendix A. Document Change Log 1346 [RFC Editor: This section is to be removed before publication] 1348 -06: 1350 Ray Hunter is added in acknowledgment. 1352 Adding Renumbering section with comments from Dallas meeting 1354 Replacing Master / Primary - Slave / Secondary 1356 Security Consideration has been updated with Reflection attacks, 1357 flooding attacks, and replay attacks. 1359 -05: 1361 *Clarifying on handling different views: 1363 - 1: How the CPE may be involved in the resolution and responds 1364 without necessarily requesting the Public Primaries (and 1365 eventually the Hidden Primary) 1367 - 2: How to handle local scope resolution that is link-local, site- 1368 local and NAT IP addresses as well as Private domain names that 1369 the administrator does not want to publish outside the home 1370 network. 1372 Adding a Privacy Considerations Section 1374 Clarification on pro/cons outsourcing zone-signing 1376 Documenting how to handle reverse zones 1378 Adding reference to RFC 2308 1380 -04: 1382 *Clarifications on zone signing 1384 *Rewording 1386 *Adding section on different views 1388 *architecture clarifications 1390 -03: 1392 *Simon's comments taken into consideration 1394 *Adding SOA, PTR considerations 1396 *Removing DNSSEC performance paragraphs on low power devices 1398 *Adding SIG(0) as a mechanism for authenticating the servers 1400 *Goals clarification: the architecture described in the document 1) 1401 does not describe new protocols, and 2) can be adapted to specific 1402 cases for advance users. 1404 -02: 1406 *remove interfaces: "Public Authoritative Server Naming Interface" is 1407 replaced by "Public Authoritative Primary(ies)". "Public 1408 Authoritative Server Management Interface" is replaced by "Public 1409 Authoritative Name Server Set". 1411 -01.3: 1413 *remove the authoritative / resolver services of the CPE. 1414 Implementation dependent 1416 *remove interactions with mdns and dhcp. Implementation dependent. 1418 *remove considerations on low powered devices 1420 *remove position toward homenet arch 1422 *remove problem statement section 1424 -01.2: 1426 * add a CPE description to show that the architecture can fit CPEs 1428 * specification of the architecture for very low powered devices. 1430 * integrate mDNS and DHCP interactions with the Homenet Naming 1431 Architecture. 1433 * Restructuring the draft. 1) We start from the homenet-arch draft to 1434 derive a Naming Architecture, then 2) we show why CPE need mechanisms 1435 that do not expose them to the Internet, 3) we describe the 1436 mechanisms. 1438 * I remove the terminology and expose it in the figures A and B. 1440 * remove the Front End Homenet Naming Architecture to Homenet Naming 1442 -01: 1444 * Added C. Griffiths as co-author. 1446 * Updated section 5.4 and other sections of draft to update section 1447 on Hidden Primary / Slave functions with CPE as Hidden Primary/ 1448 Homenet Server. 1450 * For next version, address functions of MDNS within Homenet Lan and 1451 publishing details northbound via Hidden Primary. 1453 -00: First version published. 1455 Authors' Addresses 1457 Daniel Migault 1458 Ericsson 1459 8400 boulevard Decarie 1460 Montreal, QC H4P 2N2 1461 Canada 1463 Email: mglt.ietf@gmail.com 1465 Wouter Cloetens 1466 SoftAtHome 1467 vaartdijk 3 701 1468 3018 Wijgmaal 1469 Belgium 1471 Email: wouter.cloetens@softathome.com 1473 Chris Griffiths 1474 Dyn 1475 150 Dow Street 1476 Manchester, NH 03101 1477 US 1479 Email: cgriffiths@dyn.com 1480 URI: http://dyn.com 1481 Ralf Weber 1482 Nominum 1483 2000 Seaport Blvd #400 1484 Redwood City, CA 94063 1485 US 1487 Email: ralf.weber@nominum.com 1488 URI: http://www.nominum.com