idnits 2.17.1 draft-btw-add-home-04.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 (March 16, 2020) is 1501 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) == Missing Reference: 'ThisDocument' is mentioned on line 922, but not defined == Unused Reference: 'RFC7969' is defined on line 1049, but no explicit reference was found in the text == Outdated reference: A later version (-02) exists of draft-ietf-dnsop-terminology-ter-01 == Outdated reference: A later version (-08) exists of draft-reddy-dprive-bootstrap-dns-server-07 -- Obsolete informational reference (is this intentional?): RFC 6125 (Obsoleted by RFC 9525) -- Obsolete informational reference (is this intentional?): RFC 7231 (Obsoleted by RFC 9110) -- Obsolete informational reference (is this intentional?): RFC 8499 (Obsoleted by RFC 9499) Summary: 0 errors (**), 0 flaws (~~), 5 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 ADD M. Boucadair 3 Internet-Draft Orange 4 Intended status: Standards Track T. Reddy 5 Expires: September 17, 2020 McAfee 6 D. Wing 7 Citrix 8 N. Cook 9 Open-Xchange 10 March 16, 2020 12 DNS-over-HTTPS and DNS-over-TLS Server Discovery and Deployment 13 Considerations for Home and Mobile Networks 14 draft-btw-add-home-04 16 Abstract 18 This document discusses DoT/DoH deployment considerations for home 19 networks. It particularly sketches the required steps to use DoT/DoH 20 capabilities provided by local networks. 22 One of the goals of this document is to assess to what extent 23 existing tools can be used to provide a DoT/DoH service. As an 24 outcome, new DHCP and Router Advertisement Options are specified in 25 order to convey a DNS Authentication Domain Name. 27 Status of This Memo 29 This Internet-Draft is submitted in full conformance with the 30 provisions of BCP 78 and BCP 79. 32 Internet-Drafts are working documents of the Internet Engineering 33 Task Force (IETF). Note that other groups may also distribute 34 working documents as Internet-Drafts. The list of current Internet- 35 Drafts is at https://datatracker.ietf.org/drafts/current/. 37 Internet-Drafts are draft documents valid for a maximum of six months 38 and may be updated, replaced, or obsoleted by other documents at any 39 time. It is inappropriate to use Internet-Drafts as reference 40 material or to cite them other than as "work in progress." 42 This Internet-Draft will expire on September 17, 2020. 44 Copyright Notice 46 Copyright (c) 2020 IETF Trust and the persons identified as the 47 document authors. All rights reserved. 49 This document is subject to BCP 78 and the IETF Trust's Legal 50 Provisions Relating to IETF Documents 51 (https://trustee.ietf.org/license-info) in effect on the date of 52 publication of this document. Please review these documents 53 carefully, as they describe your rights and restrictions with respect 54 to this document. Code Components extracted from this document must 55 include Simplified BSD License text as described in Section 4.e of 56 the Trust Legal Provisions and are provided without warranty as 57 described in the Simplified BSD License. 59 Table of Contents 61 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 62 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 63 3. Sample Deployment Scenarios . . . . . . . . . . . . . . . . . 5 64 3.1. Managed CPEs . . . . . . . . . . . . . . . . . . . . . . 5 65 3.2. Unmanaged CPEs . . . . . . . . . . . . . . . . . . . . . 7 66 4. DNS Reference Identifier Option . . . . . . . . . . . . . . . 8 67 4.1. DHCPv6 DNS Reference Identifier Option . . . . . . . . . 9 68 4.2. DHCP DNS Reference Identifier Option . . . . . . . . . . 10 69 4.3. RA DNS Reference Identifier Option . . . . . . . . . . . 10 70 5. DoH URI Templates . . . . . . . . . . . . . . . . . . . . . . 11 71 5.1. Define a Dedicated DHCP/RA Option . . . . . . . . . . . . 11 72 5.2. Retrieve the List Directly from the DoH Server . . . . . 12 73 6. Locating DoH/DoT Servers . . . . . . . . . . . . . . . . . . 12 74 6.1. DoT/DoH Auto-Upgrade . . . . . . . . . . . . . . . . . . 14 75 6.2. Other Deployment Options . . . . . . . . . . . . . . . . 15 76 7. DoT and DoH DNS-SD Considerations . . . . . . . . . . . . . . 15 77 8. Hosting DoH/DoT Forwarder in the CPE . . . . . . . . . . . . 16 78 8.1. Managed CPEs . . . . . . . . . . . . . . . . . . . . . . 16 79 8.1.1. ACME . . . . . . . . . . . . . . . . . . . . . . . . 16 80 8.1.2. Redirection . . . . . . . . . . . . . . . . . . . . . 16 81 8.2. Unmanaged CPEs . . . . . . . . . . . . . . . . . . . . . 17 82 9. Security Considerations . . . . . . . . . . . . . . . . . . . 18 83 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 20 84 10.1. DHCPv6 Option . . . . . . . . . . . . . . . . . . . . . 20 85 10.2. DHCP Option . . . . . . . . . . . . . . . . . . . . . . 20 86 10.3. RA Option . . . . . . . . . . . . . . . . . . . . . . . 20 87 10.4. Service Name . . . . . . . . . . . . . . . . . . . . . . 21 88 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 21 89 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 21 90 12.1. Normative References . . . . . . . . . . . . . . . . . . 21 91 12.2. Informative References . . . . . . . . . . . . . . . . . 22 92 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 24 94 1. Introduction 96 Internet Service Providers (ISPs) traditionally provide DNS resolvers 97 to their customers. Typically, ISPs deploy the following mechanisms 98 to advertise a list of DNS Recursive DNS server(s) to their 99 customers: 101 o Protocol Configuration Options in cellular networks [TS.24008]. 102 o DHCP [RFC2132] (Domain Name Server Option) or DHCPv6 103 [RFC8415][RFC3646] (OPTION_DNS_SERVERS). 104 o IPv6 Router Advertisement [RFC4861][RFC8106] (Type 25 (Recursive 105 DNS Server Option)). 107 The communication between a customer's device (a.k.a., User Equipment 108 (UE)) (possibly via Customer Premises Equipment (CPE)) and an ISP- 109 supplied DNS resolver takes place by using cleartext DNS messages 110 (Do53, [I-D.ietf-dnsop-terminology-ter]). Some examples are depicted 111 in Figure 1. In the case of cellular networks, connectivity can be 112 provided to a UE or to a CPE. Do53 mechanisms used within the Local 113 Area Network (LAN) are similar in both fixed and cellular CPE-based 114 broadband service offerings. 116 (a) Fixed Networks 118 ,--,--,--. ,--,--,--. 119 ,-' +--+ `-. ,-' ISP `-. 120 ( LAN |UE| CPE----( DNS Server ) 121 `-. +--+ ,-' `-. ,-' 122 `--'|-'--' `--'--'--' 123 | | 124 |<=======Do53========>| 126 (b) Cellular Networks 128 |<===========Do53=========>| 129 ,--,-|,--. | 130 ,-' +--+ `-. ,--,--,--. 131 ( LAN |UE| CPE------------+ \ 132 `-. +--+ ,-' ,' ISP `-. 133 `--'--'--' ( DNS Server ) 134 +-----+-. ,-' 135 +--+ | `--'--'--' 136 |UE+-----------+ 137 +--+ 139 Figure 1: Sample Legacy Deployments 141 ISPs use DNS to provide additional services such as (but not limited 142 to) malware filtering, parental control, or VoD (Video on Demand) 143 optimization. DNS is also a central component for mastering the 144 quality of experience for current latency-sensitive services, but 145 also emerging ones (such as those services that pertain to the Ultra 146 Reliability and Low Latency Communications (uRLLC) or Enhanced Mobile 147 Broadband (eMBB). 149 For example, the latency targets set in the context of 5G are 1ms 150 (uRLLC) and 4ms (eMBB). An ISP will be able to address such 151 demanding latency requirements assuming the corresponding services 152 rely upon resources (network, compute, storage) that are located 153 as close to the user as possible (e.g., by means of Edge Computing 154 techniques and resources). Such latency requirements are likely 155 to be addressed by means of optimized designs (DNS, in 156 particular), too. 158 Relying upon local DNS resolvers will therefore contribute to meet 159 the aforementioned service requirements. The use of external 160 resolvers is likely to induce an extra service delay which exceeds by 161 far the service target. 163 This document focuses on the support of DNS-over-HTTPS (DoH) 164 [RFC8484] or DNS-over-TLS (DoT) [RFC7858] in local networks. In 165 particular, the document describes how a local DoH/DoT server can be 166 discovered and used by connected hosts. This document specifies 167 options that allow DNS clients to discover local DoT/DoH servers. In 168 particular, Section 4 describes DHCP, DHCPv6, and RA options to 169 convey the Authentication Domain Name (ADN, defined in [RFC8310]). 171 Some ISPs rely upon external resolvers (e.g., outsourced service or 172 public resolvers); these ISPs provide their customers with the IP 173 addresses of these resolvers. These addresses are typically 174 configured on CPEs using the same mechanisms listed above. Likewise, 175 users can modify the default DNS configuration of their CPEs (e.g., 176 supplied by their ISP) to configure their favorite DNS servers. This 177 document permits such deployments. 179 Both managed and unmanaged CPEs are discussed in the document 180 (Section 3) . 182 2. Terminology 184 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 185 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 186 "OPTIONAL" in this document are to be interpreted as described in BCP 187 14 [RFC2119][RFC8174] when, and only when, they appear in all 188 capitals, as shown here. 190 This document makes use of the terms defined in [RFC8499] and 191 [I-D.ietf-dnsop-terminology-ter]. 193 'DoH/DoT' refers to DNS-over-HTTPS and/or DNS-over-TLS. 195 3. Sample Deployment Scenarios 197 3.1. Managed CPEs 199 ISPs have developed an expertise in managing service-specific 200 configuration information (e.g., CPE WAN Management Protocol 201 [TR-069]). For example, these tools may be used to provision the 202 authentication domain name information (ADN) to managed CPEs if DoH/ 203 DoT is supported by a local network similar to what is depicted in 204 Figure 2. 206 DoH-capable (or DoT) clients establish the DoH (or DoT) session with 207 the discovered DNS server. 209 If a DNS client supports both DoT and DoH, the client try to 210 establish DoH/DoT sessions with the discovered DNS server to 211 determine whether these servers support DoH and/or DoT (Section 6). 212 Alternatively, the DNS client may discover whether the DNS server in 213 the local network supports DoH/DoT by using the mechanism discussed 214 in Section 7. 216 (a) Fixed Networks 218 ,--,--,--. ,--,--,--. 219 ,-' +--+ `-. ,-' ISP `-. 220 ( LAN |UE| CPE----( DNS Server ) 221 `-. +--+ ,-' `-. ,-' 222 `--'|-'--' `--'--'--' 223 | | 224 |<=======DoH/DoT=====>| 226 (b) Cellular Networks 228 |<===========DoH/DoT======>| 229 ,--,-|,--. | 230 ,-' +--+ `-. ,--,--,--. 231 ( LAN |UE| CPE------------+ \ 232 `-. +--+ ,-' ,' ISP `-. 233 `--'--'--' ( DNS Server ) 234 +-----+-. ,-' 235 +--+ | `--'--'--' 236 |UE+-----------+ 237 +--+ 239 Figure 2: DoH/DoT in the WAN 241 Figure 2 shows the scenario where the CPE relays the list of DoT/DoH 242 servers it learns for the network by using mechanisms like DHCP or a 243 specific Router Advertisement message. In such context, direct DoH/ 244 DoT sessions will be established between a host serviced by a CPE and 245 an ISP-supplied DoT/DoH server (see the example depicted in Figure 3 246 for a DoH/DoT-capable host). 248 ,--,--,--. ,--,--,--. 249 ,-' `-. ,-' ISP `-. 250 UE----( LAN CPE----( DNS Server ) 251 | `-. ,-' `-. ,-' 252 | `--'--'--' `--'--'--' 253 | | 254 |<==============DoT/DoH============>| 256 Figure 3: Direct DoH/DoT Sessions 258 Figure 4 shows a deployment where the CPE embeds a caching DNS 259 forwarder. The CPE advertises itself as the default DNS server to 260 the hosts it serves. The CPE relies upon DHCP or RA to advertise 261 itself to internal hosts as the default DoT/DoH/Do53 server. When 262 receiving a DNS request it cannot handle locally, the CPE forwards 263 the request to an upstream DoH/DoT/Do53 resolver. Such deployment is 264 required for IPv4 service continuity purposes (e.g., 265 [I-D.ietf-v6ops-rfc7084-bis]) or for supporting advanced services 266 within the home (e.g., malware filtering, parental control, 267 Manufacturer Usage Description (MUD, [RFC8520] to only allow intended 268 communications to and from an IoT device)). When the CPE behaves as 269 a DNS forwarder, DNS communications can be decomposed into two legs: 271 o The leg between an internal host and the CPE. 273 o The leg between the CPE and an upstream DNS resolver. 275 An ISP that offers DoH/DoT to its customers may enable DoH/DoT in 276 both legs as shown in Figure 4. Additional considerations related to 277 this deployment are discussed in Section 8. 279 ,--,--,--. ,--,--,--. 280 ,-' `-. ,-' ISP `-. 281 UE----( LAN CPE----( DNS Server ) 282 | `-. ,-'| `-. ,-' 283 | `--'--'--' | `--'--'--' 284 | | | 285 |<======DoT/DoH======>|<==DoT/DoH==>| 287 Figure 4: Proxied DoH/DoT Sessions 289 3.2. Unmanaged CPEs 291 Customers may decide to deploy unmanaged CPEs (assuming the CPE is 292 compliant with the network access technical specification that is 293 usually published by ISPs). Upon attachment to the network, an 294 unmanaged CPE receives from the network its service configuration 295 (including the DNS information) by means of, e.g., DHCP. That DNS 296 information is shared within the LAN following the same mechanisms as 297 those discussed in Section 3.1. A host can thus establish DoH/DoT 298 session with a DoH/DoT server similar to what is depicted in 299 Figure 3. 301 Customers may also decide to deploy internal home routers (called 302 hereafter, Internal CPEs) for a variety of reasons that are not 303 detailed here. Absent any explicit configuration on the internal CPE 304 to override the DNS configuration it receives from the ISP-supplied 305 CPE, an Internal CPE relays the DNS information it receives via DHCP/ 306 RA from the ISP-supplied CPE to connected hosts. DoH/DoT sessions 307 can be established by a host with the DoH/DoT servers of the ISP (see 308 Figure 5). 310 ,--,--,--. ,--,--,--. 311 ,-' Internal ,-' ISP `-. 312 UE----( Network#A CPE----CPE---( DNS Server ) 313 | `-. ,-' `-. ,-' 314 | `--'--'--' `--'--'--' 315 | | 316 |<===================DoT/DoH==============>| 318 Figure 5: Direct DoH/DoT Sessions with the ISP DNS Resolver (Internal 319 CPE) 321 Similar to managed CPEs, a user may modify the default DNS 322 configuration of an unmanaged CPE to use his/her favorite DNS servers 323 instead. DoH/DoT sessions can be established directly between a host 324 and a 3rd Party DNS server (see Figure 6). 326 ,--,--,--. ,--, 327 ,' Internal ,-' '- 3rd Party 328 UE----( Network#A CPE----CPE---( ISP )--- DNS Server 329 | `. ,-' `-. -' | 330 | `-'--'--' `--' | 331 | | 332 |<======================DoT/DoH===================>| 334 Figure 6: Direct DoH/DoT Sessions with a Third Party DNS Resolver 336 4. DNS Reference Identifier Option 338 This section describes how a DNS client can discover the ADN of local 339 DoH/DoT server(s) using DHCP (Sections 4.1 and 4.2) and Neighbor 340 Discovery protocol (Section 4.3). 342 As reported in Section 1.7.2 of [RFC6125]: 344 "few certification authorities issue server certificates based on 345 IP addresses, but preliminary evidence indicates that such 346 certificates are a very small percentage (less than 1%) of issued 347 certificates". 349 In order to allow for PKIX-based authentication between a DNS client 350 and a DoH/DoT server while accommodating the current best practices 351 for issuing certificates, this document allows for configuring an 352 authentication domain name to be presented as a reference identifier 353 for DNS authentication purposes. 355 The DNS client establishes a DoH/DoT session with the discovered DNS 356 IP address(es) (Section 6) and uses the mechanism discussed in 357 Section 8 of [RFC8310] to authenticate the DNS server certificate 358 using the authentication domain name conveyed in the DNS Reference 359 Identifier. 361 If the DNS Reference Identifier is discovered by a host using both RA 362 and DHCP, the rules discussed in Section 5.3.1 of [RFC8106] MUST be 363 followed. 365 4.1. DHCPv6 DNS Reference Identifier Option 367 The DHCPv6 DNS Reference Identifier option is used to configure an 368 authentication domain name of the DoH/DoT server. The format of this 369 option is shown in Figure 7. 371 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 372 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 373 | OPTION_V6_DNS_RI | Option-length | 374 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 375 | | 376 | Authentication Domain Name | 377 | | 378 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 380 Figure 7: DHCPv6 DNS Reference Identifier Option 382 The fields of the option shown in Figure 7 are as follows: 384 o Option-code: OPTION_V6_DNS_RI (TBA1, see Section 10.1) 385 o Option-length: Length of the Authentication Domain Name field in 386 octets. 387 o Authentication Domain Name: A fully qualified domain name of the 388 DoH/DoT server. This field is formatted as specified in 389 Section 10 of [RFC8415]. 391 An example of the Authentication Domain Name encoding is shown in 392 Figure 8. This example conveys the FQDN "doh1.example.com.". 394 +------+------+------+------+------+------+------+------+------+ 395 | 0x04 | d | o | h | 1 | 0x07 | e | x | a | 396 +------+------+------+------+------+------+------+------+------+ 397 | m | p | l | e | 0x03 | c | o | m | 0x00 | 398 +------+------+------+------+------+------+------+------+------+ 400 Figure 8: An example of the authentication-domain-name Encoding 402 4.2. DHCP DNS Reference Identifier Option 404 The DHCP DNS Reference Identifier option is used to configure an 405 authentication domain name of the DoH/DoT server. The format of this 406 option is illustrated in Figure 9. 408 Code Length Authentication Domain Name 409 +-----+-----+-----+-----+-----+-----+-----+-- 410 |TBA2 | n | s1 | s2 | s3 | s4 | s5 | ... 411 +-----+-----+-----+-----+-----+-----+-----+-- 413 The values s1, s2, s3, etc. represent the domain name labels in the 414 domain name encoding. 416 Figure 9: DHCP DNS Reference Identifier Option 418 The fields of the option shown in Figure 9 are as follows: 420 o Code: OPTION_V4_DNS_RI (TBA2, see Section 10.2). 421 o Length: Includes the length of the Authentication Domain Name 422 field in octets. 423 o Authentication Domain Name: The domain name of the DoH/DoT server. 424 This field is formatted as specified in Section 10 of [RFC8415]. 426 4.3. RA DNS Reference Identifier Option 428 The IPv6 Router Advertisement (RA) DNS Reference Identifier option is 429 used to configure an authentication domain name of the DoH/DoT 430 server. The format of this option is illustrated in Figure 10. 432 0 1 2 3 433 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 434 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 435 | Type | Length | Reserved | 436 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 437 | Lifetime | 438 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 439 | | 440 : Authentication Domain Name : 441 | | 442 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 444 Figure 10: RA DNS Reference Identifier Option 446 The fields of the option shown in Figure 10 are as follows: 448 o Type: 8-bit identifier of the DNS Reference Identifier Option as 449 assigned by IANA (TBA3, see Section 10.3). 450 o Length: 8-bit unsigned integer. The length of the option 451 (including the Type and Length fields) is in units of 8 octets. 452 o Reserved: This field is unused. It MUST be initialized to zero by 453 the sender and MUST be ignored by the receiver. 454 o Lifetime: 32-bit unsigned integer. The maximum time in seconds 455 (relative to the time the packet is received) over which the 456 authentication domain name MAY be used as a DNS Reference 457 Identifier. 459 The value of Lifetime SHOULD by default be at least 3 * 460 MaxRtrAdvInterval, where MaxRtrAdvInterval is the maximum RA 461 interval as defined in [RFC4861]. 463 A value of all one bits (0xffffffff) represents infinity. 465 A value of zero means that the DNS Reference Identifier MUST no 466 longer be used. 467 o Authentication Domain Name: The domain name of the DoH/DoT server. 468 This field is formatted as specified in Section 10 of [RFC8415]. 470 5. DoH URI Templates 472 DoH servers may support more than one URI Template [RFC8484]. The 473 following sub-sections discuss some candidate solutions for a DoH 474 client to retrieve the list of supported templates by a DoH server. 475 Also, if the resolver hosts several DoH services (e.g., no-filtering, 476 blocking adult content, blocking malware), these services can be 477 discovered as templates. 479 How a DoH client makes use of the configured DoH services is out of 480 scope of this document. 482 o DISCUSSION: More feedback is needed to assess whether URI RA/DHCP 483 options have to be specified. 485 5.1. Define a Dedicated DHCP/RA Option 487 This solution assumes that DHCP servers and access routers maintain 488 an updated list of the templates used by DoH resolvers. 490 The following observations can be made: 492 o In order to avoid that stale DoH information is supplied to 493 connected devices, each time the URI templates are updated at a 494 DoH resolver (e.g., add a new DoH service, withdraw a DoH 495 service), DHCP servers (or access routers for the RA case) have to 496 be updated accordingly to reflect the DNS service change. 498 o This dependency may be affordable if the ISP providing the 499 connectivity service is also the one operating the DoH resolver. 501 o Nevertheless, if the DNS service is provided by a distinct entity 502 than the ISP, an out-of-band mechanism is required to synchronize 503 the list of DoH services that are active on a DoH resolver vs. the 504 list maintained locally by the ISP. 506 o Also, it is not clear how enclosed URI templates will be validated 507 by DHCP clients given that future specifications may allow for 508 other variables in the URI. 510 o Including a large list of templates may cause the size of an RA to 511 exceed the link MTU. In such case, multiple RAs must be used. 513 RA/DHCP has the following advantages: 515 o Notify clients whenever there is a change in the DoH service 516 configuration. 518 o The DoH client can immediately use available DoH services. 520 o It is convenient if very few (stable) URIs are in use. 522 o It allows for customized configuration within the home network. 524 5.2. Retrieve the List Directly from the DoH Server 526 Upon discovery of a DoH resolver (Section 4), the DoH client contacts 527 that DoH resolver to retrieve the list of supported DoH services 528 (e.g., use of a well-known URI). That information is cached by the 529 DoH client for a given period (e.g., 24h). DoH clients re-iterates 530 that request regularly (e.g., 24h) to retrieve an updated list of 531 supported DoH services. Note that a "push" mode can be considered 532 using the mechanism defined in [I-D.ietf-dnssd-push]. 534 This approach allows to avoid adherence of DoH servers with DHCP 535 servers (or access routers) for (de)activating new DoH services. 537 6. Locating DoH/DoT Servers 539 A CPE or a host relies upon discovery mechanisms (such as PCO, DHCP, 540 or RA) to retrieve DoH/DoT servers' reachability information. In the 541 various scenarios sketched in Section 3, Do53, DoH, and DoT may 542 terminate on the same IP address (or distinct IP addresses as 543 depicted in Figure 12). Terminating Do53/DoH/DoT on the same or 544 distinct IP addresses is deployment-specific. 546 From an IP reachability standpoint, DoH/DoT servers SHOULD be located 547 by their address literals rather than their names. This avoids 548 adding a dependency on another server to resolve the DoH/DoT name. 549 Concretely, if Do53/DoH/DoT terminate on same IP addresses, existing 550 discovery mechanisms [RFC2132][RFC3646][RFC8106] can be leveraged to 551 learn the IP addresses of DoT/DoH servers while an authentication 552 domain name is supplied by one of the options discussed in Section 4. 553 An example is depicted in Figure 11. 555 Legacy Do53 556 client 557 |<===DHCP===>| 558 | {@1} | | 559 | | | 560 |======Do53 Query===>| 561 | | | --,--,- 562 ,+-,--,--. | |,/ ISP \. 563 ,-' `-. | ,-' `-. 564 DoH/DoT --( LAN CPE----( S (@1) ) 565 capable client `-. ,-'| `-. ,-' 566 | `--'--'--' | | `--'--'--' 567 |<========DHCP========>| | 568 | {RI, @1} | | 569 | | 570 |<=========DoT/DoH============>| 572 Legend: 573 * S: DNS server 574 * {@1}: IP address of S; returned in a DHCP 575 Domain Name Server option 576 * RI: DNS Reference Identifier 578 Figure 11: Locating DoH/DoT/Do53 (Same DNS Server) 579 Legacy Do53 580 client 581 |<===RA======| 582 | {RI,@1,@2} | | 583 | | | 584 |========Do53 Query=======>| 585 | | --,--,- 586 ,+-,--,--. | ,/ S1 (@1)\. 587 ,-' `-. | ,-' ISP `-. 588 DoH/DoT --( LAN CPE----( ) 589 capable client `-. ,-'| `-. S2 (@2) ,-' 590 | `--'--'--' | `--'--'--' 591 |<=========RA==========| | 592 | {RI,@1,@2} | | 593 | | 594 |<===============DoT/DoH============>| 596 Legend: 597 * S1: Do53 server 598 * S2: DoH/DoT server 599 * @1: IP address of S1 600 * @1: IP address of S2 601 * RI: DNS Reference Identifier 603 Figure 12: Locating DoH/DoT/Do53 (Distinct Servers) 605 The following sub-sections discusses the conditions under which 606 discovered DoT/DoH server can be used. 608 6.1. DoT/DoH Auto-Upgrade 610 Additional considerations are discussed below for the use of DoH and 611 DoT servers provided by local networks: 613 o If the DNS server's IP address discovered by using DHCP/RA is pre- 614 configured in the OS or Browser as a verified resolver (e.g., part 615 of an auto-upgrade program such as [Auto-upgrade]), the DNS client 616 auto-upgrades to use the pre-configured DoH/DoT server tied to the 617 discovered DNS server IP address. In such a case the DNS client 618 will perform additional checks out of band, such as confirming 619 that the Do53 IP address and the DoH server are owned and operated 620 by the same organisation. 622 o Similarly, if the ADN conveyed in DHCP/RA (Section 4) is pre- 623 configured in the OS or browser as a verified resolver, the DNS 624 client auto-upgrades to establish a DoH/DoT session with the ADN. 626 In such case, the DNS client matches the domain name in the DNS 627 Reference Identifier DHCP/RA option with the 'DNS-ID' identifier 628 type within subjectAltName entry in the server certificate 629 conveyed in the TLS handshake. 631 Such an auto-upgrade mechanism would be compatible with the 632 Redirection method of Section 8.1.2, for managed CPEs hosting a DoT/ 633 DoH forwarder. 635 6.2. Other Deployment Options 637 Some deployment options to securely configure hosts are discussed 638 below. These options are provided for the sake of completeness. 640 o If Device Provisioning Protocol (DPP) [DPP] is used, the 641 configurator can securely configure devices in the home network 642 with the local DoT/DoH server using DPP. If the DoT/DoH servers 643 use raw public keys [RFC7250], the Subject Public Key Info (SPKI) 644 pin set [RFC7250] of raw public keys may be encoded in a QR code. 645 The configurator (e.g., mobile device) can scan the QR code and 646 provision SPKI pin set in OS/Browser. The configurator can in- 647 turn securely configure devices (e.g., thermostat) in the home 648 network with the SPKI pin set using DPP. 650 o If a CPE is co-located with security services within the home 651 network, the CPE can use WPA-PSK but with unique pre-shared keys 652 for different endpoints to deal with security issues. In such 653 networks, [I-D.reddy-dprive-bootstrap-dns-server] may be used to 654 securely bootstrap endpoint devices with the authentication domain 655 name and DNS server certificate of the local network's DoH/DoT 656 server. 658 The OS would not know if the WPA pre-shared-key is the same for 659 all clients or a unique pre-shared key is assigned to the host. 660 Hence, the user has to indicate to the system that a unique pre- 661 shared key is assigned to trigger the bootstrapping procedure. 663 If the device joins a home network using a single shared password 664 among all the attached devices, a compromised device can host a 665 fake access point, and the device cannot be securely bootstrapped 666 with the home network's DoH/DoT server. 668 7. DoT and DoH DNS-SD Considerations 670 As an alternative to probing discovered DNS servers in order to check 671 (1) whether they support DoT and/or DoH, and (2) whether customized 672 port numbers are used (instead of 443/853 port numbers), a DNS client 673 MAY use DNS-based Service Discovery (DNS-SD) [RFC6763]. 675 DNS-SD defines a set of naming rules for certain DNS record types 676 that they use for advertising and discovering services. Section 4.1 677 of [RFC6763] specifies that a service instance name in DNS-SD has the 678 following structure: 680 . . 682 The portion specifies the authentication domain name 683 (Section 4). The portion of the DNS service instance name 684 MUST be "_domain-s._tcp" (Section 6 of [RFC7858]) or "_doh._tcp" 685 (Section 10.4). If no DNS-SD records can be retrieved by the DNS 686 client, it MUST wait a time period that is appropriate for the 687 encountered error (e.g., NXDOMAIN, timeout, etc.). 689 8. Hosting DoH/DoT Forwarder in the CPE 691 8.1. Managed CPEs 693 The following mechanisms can be used to host a DoH/DoT forwarder in a 694 managed CPE (Section 3.1). 696 8.1.1. ACME 698 If a CPE is co-located with security services (e.g., malware 699 filtering, parental control, MUD), the ISP can assign a unique FQDN 700 (e.g., cpe1.example.com) and a domain-validated public certificate to 701 the DoH/DoT forwarder hosted on the CPE. Automatic Certificate 702 Management Environment (ACME) [RFC8555] can be used to automate 703 certificate management functions such as domain validation procedure, 704 certificate issuance and certificate revocation. 706 Alternatively, the security service provider can assign a unique FQDN 707 to the managed CPE. DNS requests to the forwarder are sent to the 708 internal IP address, not the external one. The DoH/DoT forwarder 709 will act like a private DoT/DoH server only be accessible from within 710 the home network. 712 8.1.2. Redirection 714 An ISP-managed CPE can be configured with the ISP's DoH resolver IP 715 addresses and ADN, which it will communicate to internal hosts using 716 DHCP/RA. Upon joining the network, a DoH client follows the 717 procedure specified in Section 6.1 to upgrade to DoH. 719 Once the DoH session is established, the ISP DoH server uses HTTP 720 redirection (Section 6.4.4 in [RFC7231]) to redirect the DNS client 721 to the DoH forwarder hosted on the CPE (e.g., 722 cpe1-internal.example.net). The DNS client either uses Do53 or 723 opportunistic privacy profile (Section 7.2 of [RFC8310]) to resolve 724 the domain name in the redirected URI and eventually establishes DoH 725 session with the DoH forwarder in the CPE reachable on the LAN 726 interface. A simplified example is illustrated in Figure 13. 728 PKIX authentication [RFC6125] based upon the domain name in the 729 redirected URI will detect rogue DNS servers. 731 A DNS client that successfully connects to a redirected DoH server 732 may choose to locally cache the server host IP addresses in order to 733 not have to repeat the Do53 query. 735 --,--,- 736 ,+-,--,--. ,/ ISP \. 737 ,-' `-. ,-' `-. 738 DoH/DoT --( LAN CPE----( S (@1) ) 739 capable client `-. ,-'| `-. ,-' 740 | `--'--'--' | | `--'--'--' 741 |<========DHCP========>| | 742 | {RI, @1} | | 743 | | 744 |<============DoH=============>| 745 |<------303 (See Other)--------| 746 | | 747 |-----Do53 Query------>| 748 |<----CPE's LAN @------| 749 | | 750 |<========DoH=========>| 751 | | 752 Legend: 753 * S: DoH/DoT server 754 * @1: IP address of S 756 Figure 13: A Simplified Example of Redirection to the DNS Forwarder 757 in the CPE 759 8.2. Unmanaged CPEs 761 The approach specified in Section 8.1 does not apply for hosting a 762 DNS forwarder in an unmanaged CPE. 764 The unmanaged CPE administrator (referred to as administrator) can 765 host a DoH/DoT forwarder on the unmanaged CPE. This assumes the 766 following: 768 o The DoH/DoT server certificate is managed by the entity in-charge 769 of hosting the DoT/DoH forwarder. 771 o The DoH/DoT forwarder will either be configured to use the ISP's 772 or a 3rd party DoH/DoT server. 774 o The unmanaged CPE will advertise the DoH/DoT forwarder ADN using 775 DHCP/RA to internal hosts. 777 Figure 14 illustrates an example of an unmanaged CPE hosting a 778 forwarder which connects to a 3rd party DoH/DoT server. In this 779 example, the DNS information received from the managed CPE (and 780 therefore from the ISP) is ignored by the Internal CPE hosting the 781 forwarder. 783 ,--,--,--. ,--, 784 ,' Internal Managed ,-' '- 3rd Party 785 UE----( Network#A CPE--------CPE------( ISP )--- DNS Server 786 | `. ,-'| | `-. -' | 787 | `-'--'--' | |<==DHCP==>|`--' | 788 | |<==DHCP==>| | | 789 |<======DHCP=======>| | | 790 | {RI, @i} | | 791 |<=====DoT/DoH=====>|<=============DoT/DoH=============>| 793 Legend: 794 * @i: IP address of the DNS forwarder hosted in the Internal 795 CPE. 797 Figure 14: Example of an Internal CPE Hosting a Forwarder 799 9. Security Considerations 801 An attacker can get a domain name, domain-validated public 802 certificate from a CA, host a DoT/DoH server and claim the best DNS 803 privacy preservation policy. Also, an attacker within the home 804 network can use the public IP address, get an 'IP address'-validated 805 public certificate from a CA, host a DoT/DoH server and claim the 806 best DNS privacy preservation policy. 808 Because DHCP/RA messages are not encrypted or protected against 809 modification in any way, their content can be spoofed or modified by 810 compromised devices within the home network. An attacker can spoof 811 the DHCP/RA response to provide the attacker's DoT/DoH server. Note 812 that such an attacker can launch other attacks as discussed in 813 Section 22 of [RFC8415]. Furthermore, if the browser or the OS is 814 pre-configured with a list of DNS servers and some of which perform 815 malware filtering while others do not, an attacker can prevent 816 contacting the preferred filtering DNS servers causing a downgrade 817 attack to a non-filtering DNS server, which the attacker can leverage 818 to deliver malware. 820 The primary attacks against the methods described in Section 7 are 821 the ones that would lead to impersonation of a DNS server and 822 spoofing the DNS response to indicate that the DNS server does not 823 support DoH or DoT. To protect against DNS-vectored attacks, secured 824 DNS (DNSSEC) can be used to ensure the validity of the received DNS 825 records received. Impersonation of a DoH/DoT server is prevented by 826 validating the certificate presented by the DoH/DoT server. If DHCP/ 827 RA conveys an ADN, but the DNS-SD lookup indicates that the DNS 828 server does not support DoH/DoT, the DNS client can detect the DNS 829 response is spoofed. 831 The use of DoH/DoT also depends on the user's policies. For example, 832 the user may indicate his/her consent to use (or not) the locally- 833 discovered DoH/DoT server or request to review human-readable privacy 834 policy information of a selected DNS server and to assess whether 835 that DNS server performs DNS-based content filtering (e.g., 836 [I-D.reddy-dprive-dprive-privacy-policy]). The DNS client is assumed 837 to adhere to these policies. This document does not make any 838 assumption about the structure of such policies nor mandates specific 839 requirements. Such policies and their handling is out of scope. 841 DoH/DoT servers discovered using insecure discovery mechanisms like 842 DHCP/RA are used by a DNS client if the insecurely discovered DoH/DoT 843 server is pre-configured in the OS or the browser. Section 6.1 844 identifies a set of deployment options under which DHCP/RA RI options 845 can be used. 847 If the insecurely discovered DoH/DoT server is not pre-configured in 848 the OS or browser, the client may validate the signatory (e.g., 849 cryptographically attested by the ISP). However, as discussed above, 850 the use of policies to select servers is out of scope of this 851 document. 853 DoT/DoH sessions with rogue servers spoofing the IP address of a DNS 854 server will fail because the DNS client will fail to authenticate 855 that rogue server based upon PKIX authentication [RFC6125] based upon 856 the authentication domain name in the Reference Identifier Option. 857 DNS clients that ignore authentication failures and accept spoofed 858 certificates will be subject to attacks (e.g., redirect to malicious 859 servers, intercept sensitive data). 861 TCP connections received outside the home network MUST be discarded 862 by the DoH/DoT forwarder in the CPE. This behavior adheres to REQ#8 863 in [RFC6092]; it MUST apply for both IPv4 and IPv6. 865 10. IANA Considerations 867 10.1. DHCPv6 Option 869 IANA is requested to assign the following new DHCPv6 Option Code in 870 the registry maintained in: https://www.iana.org/assignments/dhcpv6- 871 parameters/dhcpv6-parameters.xhtml#dhcpv6-parameters-2. 873 +-------+------------------+---------+-------------+----------------+ 874 | Value | Description | Client | Singleton | Reference | 875 | | | ORO | Option | | 876 +-------+------------------+---------+-------------+----------------+ 877 | TBA1 | OPTION_V6_DNS_RI | Yes | Yes | [ThisDocument] | 878 +-------+------------------+---------+-------------+----------------+ 880 10.2. DHCP Option 882 IANA is requested to assign the following new DHCP Option Code in the 883 registry maintained in: https://www.iana.org/assignments/bootp-dhcp- 884 parameters/bootp-dhcp-parameters.xhtml#options. 886 +------+------------------+-------+----------------+----------------+ 887 | Tag | Name | Data | Meaning | Reference | 888 | | | Length| | | 889 +------+------------------+-------+----------------+----------------+ 890 | TBA2 | OPTION_V4_DNS_RI | N | DoT/DoH server | [ThisDocument] | 891 | | | | authentication | | 892 | | | | domain name | | 893 +------+------------------+-------+----------------+----------------+ 895 10.3. RA Option 897 IANA is requested to assign the following new IPv6 Neighbor Discovery 898 Option type in the "IPv6 Neighbor Discovery Option Formats" sub- 899 registry under the "Internet Control Message Protocol version 6 900 (ICMPv6) Parameters" registry maintained in 901 http://www.iana.org/assignments/icmpv6-parameters/ 902 icmpv6-parameters.xhtml#icmpv6-parameters-5. 904 +------+---------------------------------+----------------+ 905 | Type | Description | Reference | 906 +------+---------------------------------+----------------+ 907 | TBA3 | DNS Reference Identifier Option | [ThisDocument] | 908 +------+---------------------------------+----------------+ 910 10.4. Service Name 912 IANA is requested to allocate the following service name from the 913 registry available at: https://www.iana.org/assignments/service- 914 names-port-numbers/service-names-port-numbers.xhtml. 916 Service Name: doh 917 Port Number: N/A 918 Transport Protocol(s): TCP 919 Description: DNS-over-HTTPS 920 Assignee: IESG 921 Contact: IETF Chair 922 Reference: [ThisDocument] 924 11. Acknowledgements 926 Many thanks to Christian Jacquenet for the review. 928 Thanks to Tommy Jensen, Stephen Farrell, Martin Thomson, and Vittorio 929 Bertola for the comments. 931 12. References 933 12.1. Normative References 935 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 936 Requirement Levels", BCP 14, RFC 2119, 937 DOI 10.17487/RFC2119, March 1997, 938 . 940 [RFC2132] Alexander, S. and R. Droms, "DHCP Options and BOOTP Vendor 941 Extensions", RFC 2132, DOI 10.17487/RFC2132, March 1997, 942 . 944 [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, 945 "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, 946 DOI 10.17487/RFC4861, September 2007, 947 . 949 [RFC6763] Cheshire, S. and M. Krochmal, "DNS-Based Service 950 Discovery", RFC 6763, DOI 10.17487/RFC6763, February 2013, 951 . 953 [RFC7858] Hu, Z., Zhu, L., Heidemann, J., Mankin, A., Wessels, D., 954 and P. Hoffman, "Specification for DNS over Transport 955 Layer Security (TLS)", RFC 7858, DOI 10.17487/RFC7858, May 956 2016, . 958 [RFC8106] Jeong, J., Park, S., Beloeil, L., and S. Madanapalli, 959 "IPv6 Router Advertisement Options for DNS Configuration", 960 RFC 8106, DOI 10.17487/RFC8106, March 2017, 961 . 963 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 964 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 965 May 2017, . 967 [RFC8310] Dickinson, S., Gillmor, D., and T. Reddy, "Usage Profiles 968 for DNS over TLS and DNS over DTLS", RFC 8310, 969 DOI 10.17487/RFC8310, March 2018, 970 . 972 [RFC8415] Mrugalski, T., Siodelski, M., Volz, B., Yourtchenko, A., 973 Richardson, M., Jiang, S., Lemon, T., and T. Winters, 974 "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)", 975 RFC 8415, DOI 10.17487/RFC8415, November 2018, 976 . 978 [RFC8484] Hoffman, P. and P. McManus, "DNS Queries over HTTPS 979 (DoH)", RFC 8484, DOI 10.17487/RFC8484, October 2018, 980 . 982 12.2. Informative References 984 [Auto-upgrade] 985 The Unicode Consortium, "DoH providers: criteria, process 986 for Chrome", . 989 [DPP] The Wi-Fi Alliance, "Device Provisioning Protocol 990 Specification", . 993 [I-D.ietf-dnsop-terminology-ter] 994 Hoffman, P., "Terminology for DNS Transports and 995 Location", draft-ietf-dnsop-terminology-ter-01 (work in 996 progress), February 2020. 998 [I-D.ietf-dnssd-push] 999 Pusateri, T. and S. Cheshire, "DNS Push Notifications", 1000 draft-ietf-dnssd-push-25 (work in progress), October 2019. 1002 [I-D.ietf-v6ops-rfc7084-bis] 1003 Palet, J., "Basic Requirements for IPv6 Customer Edge 1004 Routers", draft-ietf-v6ops-rfc7084-bis-04 (work in 1005 progress), June 2017. 1007 [I-D.reddy-dprive-bootstrap-dns-server] 1008 Reddy.K, T., Wing, D., Richardson, M., and M. Boucadair, 1009 "A Bootstrapping Procedure to Discover and Authenticate 1010 DNS-over-(D)TLS and DNS-over-HTTPS Servers", draft-reddy- 1011 dprive-bootstrap-dns-server-07 (work in progress), 1012 February 2020. 1014 [I-D.reddy-dprive-dprive-privacy-policy] 1015 Reddy.K, T., Wing, D., Richardson, M., and M. Boucadair, 1016 "DNS Server Privacy Statement and Filtering Policy with 1017 Assertion Token", draft-reddy-dprive-dprive-privacy- 1018 policy-03 (work in progress), March 2020. 1020 [RFC3646] Droms, R., Ed., "DNS Configuration options for Dynamic 1021 Host Configuration Protocol for IPv6 (DHCPv6)", RFC 3646, 1022 DOI 10.17487/RFC3646, December 2003, 1023 . 1025 [RFC6092] Woodyatt, J., Ed., "Recommended Simple Security 1026 Capabilities in Customer Premises Equipment (CPE) for 1027 Providing Residential IPv6 Internet Service", RFC 6092, 1028 DOI 10.17487/RFC6092, January 2011, 1029 . 1031 [RFC6125] Saint-Andre, P. and J. Hodges, "Representation and 1032 Verification of Domain-Based Application Service Identity 1033 within Internet Public Key Infrastructure Using X.509 1034 (PKIX) Certificates in the Context of Transport Layer 1035 Security (TLS)", RFC 6125, DOI 10.17487/RFC6125, March 1036 2011, . 1038 [RFC7231] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer 1039 Protocol (HTTP/1.1): Semantics and Content", RFC 7231, 1040 DOI 10.17487/RFC7231, June 2014, 1041 . 1043 [RFC7250] Wouters, P., Ed., Tschofenig, H., Ed., Gilmore, J., 1044 Weiler, S., and T. Kivinen, "Using Raw Public Keys in 1045 Transport Layer Security (TLS) and Datagram Transport 1046 Layer Security (DTLS)", RFC 7250, DOI 10.17487/RFC7250, 1047 June 2014, . 1049 [RFC7969] Lemon, T. and T. Mrugalski, "Customizing DHCP 1050 Configuration on the Basis of Network Topology", RFC 7969, 1051 DOI 10.17487/RFC7969, October 2016, 1052 . 1054 [RFC8499] Hoffman, P., Sullivan, A., and K. Fujiwara, "DNS 1055 Terminology", BCP 219, RFC 8499, DOI 10.17487/RFC8499, 1056 January 2019, . 1058 [RFC8520] Lear, E., Droms, R., and D. Romascanu, "Manufacturer Usage 1059 Description Specification", RFC 8520, 1060 DOI 10.17487/RFC8520, March 2019, 1061 . 1063 [RFC8555] Barnes, R., Hoffman-Andrews, J., McCarney, D., and J. 1064 Kasten, "Automatic Certificate Management Environment 1065 (ACME)", RFC 8555, DOI 10.17487/RFC8555, March 2019, 1066 . 1068 [TR-069] The Broadband Forum, "CPE WAN Management Protocol", 1069 December 2018, . 1072 [TS.24008] 1073 3GPP, "Mobile radio interface Layer 3 specification; Core 1074 network protocols; Stage 3 (Release 16)", December 2019, 1075 . 1077 Authors' Addresses 1079 Mohamed Boucadair 1080 Orange 1081 Rennes 35000 1082 France 1084 Email: mohamed.boucadair@orange.com 1086 Tirumaleswar Reddy 1087 McAfee, Inc. 1088 Embassy Golf Link Business Park 1089 Bangalore, Karnataka 560071 1090 India 1092 Email: TirumaleswarReddy_Konda@McAfee.com 1094 Dan Wing 1095 Citrix Systems, Inc. 1096 USA 1098 Email: dwing-ietf@fuggles.com 1099 Neil Cook 1100 Open-Xchange 1101 UK 1103 Email: neil.cook@noware.co.uk