idnits 2.17.1 draft-ietf-add-dnr-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 : ---------------------------------------------------------------------------- == There are 1 instance of lines with non-RFC2606-compliant FQDNs in the document. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (May 17, 2021) is 1074 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 671, but not defined == Outdated reference: A later version (-12) exists of draft-ietf-dnsop-svcb-https-05 == Outdated reference: A later version (-02) exists of draft-boucadair-add-deployment-considerations-00 == Outdated reference: A later version (-10) exists of draft-ietf-add-ddr-00 == Outdated reference: A later version (-12) exists of draft-ietf-dprive-dnsoquic-02 == Outdated reference: A later version (-04) exists of draft-schwartz-svcb-dns-03 -- Obsolete informational reference (is this intentional?): RFC 6125 (Obsoleted by RFC 9525) -- Obsolete informational reference (is this intentional?): RFC 8499 (Obsoleted by RFC 9499) Summary: 0 errors (**), 0 flaws (~~), 8 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 ADD M. Boucadair, Ed. 3 Internet-Draft Orange 4 Intended status: Standards Track T. Reddy, Ed. 5 Expires: November 18, 2021 McAfee 6 D. Wing 7 Citrix 8 N. Cook 9 Open-Xchange 10 T. Jensen 11 Microsoft 12 May 17, 2021 14 DHCP and Router Advertisement Options for the Discovery of Network- 15 designated Resolvers (DNR) 16 draft-ietf-add-dnr-02 18 Abstract 20 The document specifies new DHCP and IPv6 Router Advertisement options 21 to discover encrypted DNS servers (e.g., DNS-over-HTTPS, DNS-over- 22 TLS, DNS-over-QUIC). Particularly, it allows to learn an 23 authentication domain name together with a list of IP addresses and a 24 set of service parameters to reach such encrypted DNS servers. 26 Status of This Memo 28 This Internet-Draft is submitted in full conformance with the 29 provisions of BCP 78 and BCP 79. 31 Internet-Drafts are working documents of the Internet Engineering 32 Task Force (IETF). Note that other groups may also distribute 33 working documents as Internet-Drafts. The list of current Internet- 34 Drafts is at https://datatracker.ietf.org/drafts/current/. 36 Internet-Drafts are draft documents valid for a maximum of six months 37 and may be updated, replaced, or obsoleted by other documents at any 38 time. It is inappropriate to use Internet-Drafts as reference 39 material or to cite them other than as "work in progress." 41 This Internet-Draft will expire on November 18, 2021. 43 Copyright Notice 45 Copyright (c) 2021 IETF Trust and the persons identified as the 46 document authors. All rights reserved. 48 This document is subject to BCP 78 and the IETF Trust's Legal 49 Provisions Relating to IETF Documents 50 (https://trustee.ietf.org/license-info) in effect on the date of 51 publication of this document. Please review these documents 52 carefully, as they describe your rights and restrictions with respect 53 to this document. Code Components extracted from this document must 54 include Simplified BSD License text as described in Section 4.e of 55 the Trust Legal Provisions and are provided without warranty as 56 described in the Simplified BSD License. 58 Table of Contents 60 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 61 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 62 3. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 3 63 3.1. Configuration Data for Encrypted DNS . . . . . . . . . . 4 64 3.2. Handling Configuration Data Conflicts . . . . . . . . . . 5 65 3.3. Connection Establishment . . . . . . . . . . . . . . . . 5 66 3.4. Multihoming Considerations . . . . . . . . . . . . . . . 6 67 4. DHCPv6 Encrypted DNS Option . . . . . . . . . . . . . . . . . 6 68 4.1. Option Format . . . . . . . . . . . . . . . . . . . . . . 6 69 4.2. DHCPv6 Client Behavior . . . . . . . . . . . . . . . . . 8 70 5. DHCPv4 Encrypted DNS Option . . . . . . . . . . . . . . . . . 8 71 5.1. Option Format . . . . . . . . . . . . . . . . . . . . . . 8 72 5.2. DHCPv4 Client Behavior . . . . . . . . . . . . . . . . . 10 73 6. IPv6 RA Encrypted DNS Option . . . . . . . . . . . . . . . . 10 74 6.1. Option Format . . . . . . . . . . . . . . . . . . . . . . 10 75 6.2. IPv6 Host Behavior . . . . . . . . . . . . . . . . . . . 12 76 7. Security Considerations . . . . . . . . . . . . . . . . . . . 12 77 7.1. Spoofing Attacks . . . . . . . . . . . . . . . . . . . . 12 78 7.2. Deletion Attacks . . . . . . . . . . . . . . . . . . . . 13 79 7.3. Passive Attacks . . . . . . . . . . . . . . . . . . . . . 14 80 7.4. Wireless Security - Authentication Attacks . . . . . . . 14 81 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 82 8.1. DHCPv6 Option . . . . . . . . . . . . . . . . . . . . . . 14 83 8.2. DHCPv4 Option . . . . . . . . . . . . . . . . . . . . . . 15 84 8.3. Neighbor Discovery Option . . . . . . . . . . . . . . . . 15 85 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 15 86 10. Contributing Authors . . . . . . . . . . . . . . . . . . . . 15 87 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 16 88 11.1. Normative References . . . . . . . . . . . . . . . . . . 16 89 11.2. Informative References . . . . . . . . . . . . . . . . . 17 90 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 19 92 1. Introduction 94 This document focuses on the support of encrypted DNS such as DNS- 95 over-HTTPS (DoH) [RFC8484], DNS-over-TLS (DoT) [RFC7858], or DNS- 96 over-QUIC (DoQ) [I-D.ietf-dprive-dnsoquic] in local networks. 98 In particular, the document specifies how a local encrypted DNS 99 server can be discovered by connected hosts by means of DHCP 100 [RFC2132], DHCPv6 [RFC8415], and IPv6 Router Advertisement (RA) 101 [RFC4861] options. These options are designed to convey the 102 following information: the DNS Authentication Domain Name (ADN), a 103 list of IP addresses, and a set of service parameters. 105 Sample target deployment scenarios are discussed in Section 3 of 106 [I-D.boucadair-add-deployment-considerations]. These scenarios 107 involve Customer Premises Equipment (CPEs) that may or may not be 108 managed by an Internet Service Provider (ISP). Also, considerations 109 related to hosting a DNS forwarder in a local network are described 110 in Section 4 of [I-D.boucadair-add-deployment-considerations]. 112 2. Terminology 114 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 115 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 116 "OPTIONAL" in this document are to be interpreted as described in BCP 117 14 [RFC2119] [RFC8174] when, and only when, they appear in all 118 capitals, as shown here. 120 This document makes use of the terms defined in [RFC8499]. The 121 following additional terms are used: 123 Do53: refers to unencrypted DNS. 125 Encrypted DNS: refers to a scheme where DNS exchanges are 126 transported over an encrypted channel. Examples of encrypted DNS 127 are DNS-over-TLS (DoT) [RFC7858], DNS-over-HTTPS (DoH) [RFC8484], 128 or DNS-over-QUIC (DoQ) [I-D.ietf-dprive-dnsoquic]. 130 Encrypted DNS options: refers to the options defined in Sections 4, 131 5, and 6. 133 DHCP: refers to both DHCPv4 and DHCPv6. 135 3. Overview 137 This document describes how a DNS client can discover local encrypted 138 DNS servers using DHCP (Sections 4 and 5) and Neighbor Discovery 139 protocol (Section 6): Encrypted DNS options. 141 These options configure an authentication domain name, a list of IPv6 142 addresses, and a set of service parameters of the encrypted DNS 143 server. More information about the design of these options is 144 provided in the following subsections. 146 3.1. Configuration Data for Encrypted DNS 148 In order to allow for PKIX-based authentication between a DNS client 149 and an encrypted DNS server, the Encrypted DNS options are designed 150 to include an authentication domain name. This ADN is presented as a 151 reference identifier for DNS authentication purposes. This design 152 accommodates the current best practices for issuing certificates as 153 per Section 1.7.2 of [RFC6125]: 155 | Some certification authorities issue server certificates based on 156 | IP addresses, but preliminary evidence indicates that such 157 | certificates are a very small percentage (less than 1%) of issued 158 | certificates. 160 To avoid adding a dependency on another server to resolve the ADN, 161 the Encrypted DNS options return the IP address(es) to locate the 162 encrypted DNS server. In the various scenarios sketched in 163 [I-D.boucadair-add-deployment-considerations], encrypted DNS servers 164 may terminate on the same IP address or distinct IP addresses. 165 Terminating encrypted DNS servers on the same or distinct IP 166 addresses is deployment specific. 168 In order to optimize the size of discovery messages when all servers 169 terminate on the same IP address, early versions of this document 170 considered relying upon the discovery mechanisms specified in 171 [RFC2132][RFC3646][RFC8106] to retrieve a list of IP addresses to 172 reach their DNS servers. Nevertheless, this approach requires a 173 client that supports more than one encrypted DNS to probe that list 174 of IP addresses. To avoid such probing, the options defined in the 175 following sections associate an IP address with an encrypted DNS 176 type. No probing is required in such a design. 178 A list of IP addresses to reach an encrypted DNS server may be 179 returned in the Encrypted DNS options to accommodate current 180 deployments relying upon primary and backup servers. Whether one IP 181 address or more are returned in an Encrypted DNS option is deployment 182 specific. For example, a router embedding a recursive server or 183 forwarder has to include one single IP address pointing to one of its 184 LAN-facing interfaces. This address can be a private IPv4 address, a 185 link-local address, a Unique Local IPv6 unicast Address (ULA), or a 186 Global Unicast Address (GUA). 188 If more than one IP address are to be returned in an Encrypted DNS 189 option, these addresses are ordered in the preference for use by the 190 client. 192 Because distinct Encrypted DNS protocols may be provisioned by a 193 network (e.g., DoT, DoH, and DoQ) and that some of these protocols 194 may make use of customized port numbers instead of default ones, the 195 Encrypted DNS options are designed to return a set of service 196 parameters. These parameters are encoded following the same rules 197 for encoding SvcParams in Section 2.1 of [I-D.ietf-dnsop-svcb-https]. 198 This encoding approach may increase the size of the options but it 199 has the merit to rely upon an existing IANA registry and thus to 200 accommodate new Encrypted DNS protocols and service parameters that 201 may be defined in the future. For example, "dohpath" service 202 parameter (Section 5.1 of [I-D.schwartz-svcb-dns]) supplies a 203 relative DoH URI Template. 205 A single option is used to convey both the ADN and IP addresses 206 because otherwise means to correlate an IP address with an ADN will 207 be required if, for example, more than one ADN is supported by the 208 network. 210 3.2. Handling Configuration Data Conflicts 212 If the encrypted DNS is discovered by a host using both RA and DHCP, 213 the rules discussed in Section 5.3.1 of [RFC8106] MUST be followed. 215 DHCP/RA options to discover encrypted DNS servers (including, DoH URI 216 Templates) takes precedence over DDR [I-D.ietf-add-ddr] since DDR 217 uses unencrypted DNS to an external DNS resolver, which is 218 susceptible to both internal and external attacks whereas DHCP/RA is 219 typically protected using the mechanisms discussed in Section 7.1. 221 3.3. Connection Establishment 223 If the local DNS client supports one of the discovered Encrypted DNS 224 protocols identified by Application Layer Protocol Negotiation (ALPN) 225 protocol identifiers, the DNS client establishes an encrypted DNS 226 session following the order of the discovered servers. The client 227 follows the mechanism discussed in Section 8 of [RFC8310] to 228 authenticate the DNS server certificate using the authentication 229 domain name conveyed in the Encrypted DNS options. ALPN-related 230 considerations can be found in Section 6.1 of 231 [I-D.ietf-dnsop-svcb-https]. 233 3.4. Multihoming Considerations 235 Devices may be connected to multiple networks; each providing their 236 own DNS configuration using the discovery mechanisms specified in 237 this document. Nevertheless, it is out of the scope of this 238 specification to discuss DNS selection of multi-interface devices. 239 The reader may refer to [RFC6731] for a discussion of issues and an 240 example of DNS server selection for multi-interfaced devices. 242 4. DHCPv6 Encrypted DNS Option 244 4.1. Option Format 246 The format of the DHCPv6 Encrypted DNS option is shown in Figure 1. 248 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 249 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 250 | OPTION_V6_DNR | Option-length | 251 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 252 | ADN Length | | 253 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 254 ~ authentication-domain-name ~ 255 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 256 | Addr Length | | 257 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 258 ~ ipv6-address(es) ~ 259 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 260 | | | 261 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 262 ~ Service Parameters (SvcParams) ~ 263 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 265 Figure 1: DHCPv6 Encrypted DNS Option 267 The fields of the option shown in Figure 1 are as follows: 269 Option-code: OPTION_V6_DNR (TBA1, see Section 8.1) 271 Option-length: Length of the enclosed data in octets. 273 ADN Length: Length of the authentication-domain-name field in 274 octets. 276 authentication-domain-name (variable length): A fully qualified 277 domain name of the encrypted DNS server. This field is formatted 278 as specified in Section 10 of [RFC8415]. 280 An example of the authentication-domain-name encoding is shown in 281 Figure 2. This example conveys the FQDN "doh1.example.com.", and 282 the resulting Option-length field is 18. 284 +------+------+------+------+------+------+------+------+------+ 285 | 0x04 | d | o | h | 1 | 0x07 | e | x | a | 286 +------+------+------+------+------+------+------+------+------+ 287 | m | p | l | e | 0x03 | c | o | m | 0x00 | 288 +------+------+------+------+------+------+------+------+------+ 290 Figure 2: An Example of the DNS authentication-domain-name Encoding 292 Addr Length: Length of enclosed IPv6 addresses in octets. It MUST 293 be a multiple of 16. 295 ipv6-address(es) (variable length): Indicates one or more IPv6 296 addresses to reach the encrypted DNS server. An address can be 297 link-local, ULA, or GUA. The format of this field is shown in 298 Figure 3. 300 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 301 | | 302 | ipv6-address | 303 | | 304 | | 305 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 306 | ... | 307 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 309 Figure 3: Format of the IPv6 Addresses Field 311 Service Parameters (SvcParams) (variable length): Specifies a set of 312 service parameters that are encoded following the rules in 313 Section 2.1 of [I-D.ietf-dnsop-svcb-https]. Service parameters 314 may include, for example, a list of ALPN protocol identifiers or 315 alternate port numbers. The service parameters MUST NOT include 316 "ipv4hint" or "ipv6hint" SvcParams as they are superseded by the 317 included IP addresses. 319 If no port service parameter is included, this indicates that 320 default port numbers should be used. As a reminder, the default 321 port number is 853 for DoT and 443 for DoH. 323 The length of this field is ('Option-length' - 4 - 'ADN Length' - 324 'Addr Length'). 326 Multiple instances of OPTION_V6_DNR may be returned to a DHCPv6 327 client; each pointing to a distinct encrypted DNS server. These 328 instances are ordered in the preference for use by the client. 330 4.2. DHCPv6 Client Behavior 332 To discover an encrypted DNS server, the DHCPv6 client MUST include 333 OPTION_V6_DNR in an Option Request Option (ORO), as in Sections 334 18.2.1, 18.2.2, 18.2.4, 18.2.5, 18.2.6, and 21.7 of [RFC8415]. 336 The DHCP client MUST be prepared to receive multiple OPTION_V6_DNR 337 options; each option is to be treated as a separate encrypted DNS 338 server. 340 The DHCPv6 client MUST silently discard multicast and host loopback 341 addresses conveyed in OPTION_V6_DNR. 343 5. DHCPv4 Encrypted DNS Option 345 5.1. Option Format 347 The format of the DHCPv4 Encrypted DNS option is illustrated in 348 Figure 4. 350 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 351 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 352 | TBA2 | Length | 353 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 354 | ADN Length | | 355 +-+-+-+-+-+-+-+-+ | 356 ~ authentication-domain-name ~ 357 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 358 | Addr Length | | 359 +-+-+-+-+-+-+-+-+ + 360 ~ IPv4 Address(es) ~ 361 | +-+-+-+-+-+-+-+-+ 362 | | | 363 +-+-+-+-+-+-+-+-+ | 364 ~Service Parameters (SvcParams) ~ 365 | | 366 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 368 Figure 4: DHCPv4 Encrypted DNS Option 370 The fields of the option shown in Figure 4 are as follows: 372 Code: OPTION_V4_DNR (TBA2, see Section 8.2). 374 Length: Indicates the length of the enclosed data in octets. 376 ADN Length: Indicates the length of the authentication-domain-name 377 in octets. 379 authentication-domain-name (variable length): Includes the 380 authentication domain name of the encrypted DNS server. This 381 field is formatted as specified in Section 10 of [RFC8415]. The 382 format of this field is shown in Figure 5. The values s1, s2, s3, 383 etc. represent the domain name labels in the domain name encoding. 385 +-----+-----+-----+-----+-----+-- 386 | s1 | s2 | s3 | s4 | s5 | ... 387 +-----+-----+-----+-----+-----+-- 388 authentication-domain-name 390 Figure 5: Format of the Authentication Domain Name Field 392 Addr Length: Indicates the length of included IPv4 addresses in 393 octets. It MUST be a multiple of 4. 395 IPv4 Address(es) (variable length): Indicates one or more IPv4 396 addresses to reach the encrypted DNS server. Both private and 397 public IPv4 addresses can be included in this field. The format 398 of this field is shown in Figure 6. This format assumes that an 399 IPv4 address is encoded as a1.a2.a3.a4. 401 0 8 16 24 32 40 48 402 +-----+-----+-----+-----+-----+-----+-- 403 | a1 | a2 | a3 | a4 | a1 | a2 | ... 404 +-----+-----+-----+-----+-----+-----+-- 405 IPv4 Address 1 IPv4 Address 2 ... 407 Figure 6: Format of the IPv4 Addresses Field 409 Service Paramters (SvcParams) (variable length): Specifies a set of 410 service parameters that are encoded following the rules in 411 Section 2.1 of [I-D.ietf-dnsop-svcb-https]. Service parameters 412 may include, for example, a list of ALPN protocol identifiers or 413 alternate port numbers. The service parameters MUST NOT include 414 "ipv4hint" or "ipv6hint" SvcParams as they are superseded by the 415 included IP addresses. 417 If no port service parameter is included, this indicates that 418 default port numbers should be used. 420 The length of this field is ('Option-length' - 2 - 'ADN Length' - 421 'Addr Length'). 423 OPTION_V4_DNR is a concatenation-requiring option. As such, the 424 mechanism specified in [RFC3396] MUST be used if OPTION_V4_DNR 425 exceeds the maximum DHCPv4 option size of 255 octets. 427 Multiple instances of OPTION_V4_DNR may be returned to a DHCPv4 428 client; each pointing to a distinct encrypted DNS server. These 429 instances are ordered in the preference for use by the client. 431 5.2. DHCPv4 Client Behavior 433 To discover an encrypted DNS server, the DHCPv4 client requests the 434 Encrypted DNS server by including OPTION_V4_DNR in a Parameter 435 Request List option [RFC2132]. 437 The DHCPv4 client MUST be prepared to receive multiple DHCP 438 OPTION_V4_DNR options; each option is to be treated as a separate 439 encrypted DNS server. 441 The DHCPv4 client MUST silently discard multicast and host loopback 442 addresses conveyed in OPTION_V4_DNR. 444 6. IPv6 RA Encrypted DNS Option 446 6.1. Option Format 448 This section defines a new Neighbor Discovery option [RFC4861]: IPv6 449 RA Encrypted DNS option. This option is useful in contexts similar 450 to those discussed in Section 1.1 of [RFC8106]. 452 The format of the IPv6 RA Encrypted DNS option is illustrated in 453 Figure 7. 455 0 1 2 3 456 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 457 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 458 | TBA3 | Length | ADN Length | 459 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 460 | Lifetime | 461 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 462 ~ authentication-domain-name ~ 463 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 464 | Addr Length | | 465 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 466 ~ ipv6-address(es) ~ 467 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 468 | | SvcParams Length | 469 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 470 ~ Service Parameters (SvcParams) ~ 471 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 473 Figure 7: RA Encrypted DNS Option 475 The fields of the option shown in Figure 7 are as follows: 477 Type: 8-bit identifier of the Encrypted DNS Option as assigned by 478 IANA (TBA3, see Section 8.3). 480 Length: 8-bit unsigned integer. The length of the option (including 481 the Type and Length fields) is in units of 8 octets. 483 Lifetime: 32-bit unsigned integer. The maximum time in seconds 484 (relative to the time the packet is received) over which the 485 discovered Authentication Domain Name is valid. 487 The value of Lifetime SHOULD by default be at least 3 * 488 MaxRtrAdvInterval, where MaxRtrAdvInterval is the maximum RA 489 interval as defined in [RFC4861]. 491 A value of all one bits (0xffffffff) represents infinity. 493 A value of zero means that this Authentication Domain Name MUST no 494 longer be used. 496 ADN Length: 16-bit unsigned integer. This field indicates the 497 length of the authentication-domain-name field in octets. 499 authentication-domain-name (variable length): The domain name of the 500 encrypted DNS server. This field is formatted as specified in 501 Section 10 of [RFC8415]. 503 Addr Length: 16-bit unsigned integer. This field indicates the 504 length of enclosed IPv6 addresses in octets. It MUST be a 505 multiple of 16. 507 ipv6-address(es) (variable length): One or more IPv6 addresses of 508 the encrypted DNS server. An address can be link-local, ULA, or 509 GUA. 511 All of the addresses share the same Lifetime value. Similar to 512 [RFC8106], if it is desirable to have different Lifetime values 513 per IP address, multiple Encrypted DNS options may be used. 515 The format of this field is shown in Figure 3. 517 SvcParams Length: 16-bit unsigned integer. This field indicates the 518 length of the Service Parameters field in octets. 520 Service Paramters (SvcParams) (variable length): Specifies a set of 521 service parameters that are encoded following the rules in 522 Section 2.1 of [I-D.ietf-dnsop-svcb-https]. Service parameters 523 may include, for example, a list of ALPN protocol identifiers or 524 alternate port numbers. The service parameters MUST NOT include 525 "ipv4hint" or "ipv6hint" SvcParams as they are superseded by the 526 included IP addresses. 528 If no port service parameter is included, this indicates that 529 default port numbers should be used. 531 The option MUST be padded with zeros so that the full enclosed data 532 is a multiple of 8 octets (Section 4.6 of [RFC4861]). 534 6.2. IPv6 Host Behavior 536 The procedure for DNS configuration is the same as it is with any 537 other Neighbor Discovery option [RFC4861]. In addition, the host 538 follows the procedure described in Section 5.3.1 of [RFC8106]. 540 The host MUST silently discard multicast and host loopback addresses 541 conveyed in the Encrypted DNS options. 543 7. Security Considerations 545 7.1. Spoofing Attacks 547 DHCP/RA messages are not encrypted or protected against modification 548 within the LAN. Unless mitigated (described below), the content of 549 DHCP and RA messages can be spoofed or modified by active attackers, 550 such as compromised devices within the local network. An active 551 attacker (Section 3.3 of [RFC3552]) can spoof the DHCP/RA response to 552 provide the attacker's Encrypted DNS server. Note that such an 553 attacker can launch other attacks as discussed in Section 22 of 554 [RFC8415]. The attacker can get a domain name with a domain- 555 validated public certificate from a CA and host an Encrypted DNS 556 server. 558 Attacks of spoofed or modified DHCP responses and RA messages by 559 attackers within the local network may be mitigated by making use of 560 the following mechanisms: 562 o DHCPv6-Shield described in [RFC7610], the CPE discards DHCP 563 response messages received from any local endpoint. 565 o RA-Guard described in [RFC7113], the CPE discards RAs messages 566 received from any local endpoint. 568 o Source Address Validation Improvement (SAVI) solution for DHCP 569 described in [RFC7513], the CPE filters packets with forged source 570 IP addresses. 572 The above mechanisms would ensure that the endpoint receives the 573 correct configuration information of the encrypted DNS servers 574 selected by the DHCP server (or RA sender), but cannot provide any 575 information about the DHCP server or the entity hosting the DHCP 576 server (or RA sender) . 578 Encrypted DNS sessions with rogue servers that spoof the IP address 579 of a DNS server will fail because the DNS client will fail to 580 authenticate that rogue server based upon PKIX authentication 581 [RFC6125], particularly the authentication domain name in the 582 Encrypted DNS Option. DNS clients that ignore authentication 583 failures and accept spoofed certificates will be subject to attacks 584 (e.g., redirect to malicious servers, intercept sensitive data). 586 Encrypted DNS connections received from outside the local network 587 MUST be discarded by the encrypted DNS forwarder in the CPE. This 588 behavior adheres to REQ#8 in [RFC6092]; it MUST apply for both IPv4 589 and IPv6. 591 7.2. Deletion Attacks 593 If the DHCP responses or RAs are dropped by the attacker, the client 594 can fallback to use a preconfigured encrypted DNS server. However, 595 the use of policies to select servers is out of the scope of this 596 document. 598 Note that deletion attack is not specific to DHCP/RA. 600 7.3. Passive Attacks 602 A passive attacker (Section 3.2 of [RFC3552]) can identify a host is 603 using DHCP/RA to discover an encrypted DNS server and can infer that 604 host is capable of using DoH/DoT/DoQ to encrypt DNS messages. 605 However, a passive attacker cannot spoof or modify DHCP/RA messages. 607 7.4. Wireless Security - Authentication Attacks 609 Wireless LAN (WLAN) as frequently deployed in local networks (e.g., 610 home networks) is vulnerable to various attacks (e.g., [Evil-Twin], 611 [Krack], [Dragonblood]). Because of these attacks, only 612 cryptographically authenticated communications are trusted on WLANs. 613 This means that an information (e.g., NTP server, DNS server, default 614 domain) provided by such networks via DHCP, DHCPv6, or RA are 615 untrusted because DHCP and RA messages are not authenticated. 617 If the pre-shared key is the same for all clients that connect to the 618 same WLAN, the shared key will be available to all nodes, including 619 attackers. As such, it is possible to mount an active on-path 620 attack. Man-in-the-middle attacks are possible within local networks 621 because such WLAN authentication lacks peer entity authentication. 623 This leads to the need for provisioning unique credentials for 624 different clients. Endpoints can be provisioned with unique 625 credentials (username and password, typically) provided by the local 626 network administrator to mutually authenticate to the local WLAN 627 Access Point (e.g., 802.1x Wireless User Authentication on OpenWRT 628 [dot1x], EAP-pwd [RFC8146]). Not all endpoint devices (e.g., IoT 629 devices) support 802.1x supplicant and need an alternate mechanism to 630 connect to the local network. To address this limitation, unique 631 pre-shared keys can be created for each such device and WPA-PSK is 632 used (e.g., [PSK]). 634 8. IANA Considerations 636 8.1. DHCPv6 Option 638 IANA is requested to assign the following new DHCPv6 Option Code in 639 the registry maintained in [DHCPV6]. 641 +-------+---------------+-----------+--------------+----------------+ 642 | Value | Description | Client | Singleton | Reference | 643 | | | ORO | Option | | 644 +-------+---------------+-----------+--------------+----------------+ 645 | TBA1 | OPTION_V6_DNR | Yes | No | [ThisDocument] | 646 +-------+---------------+-----------+--------------+----------------+ 648 8.2. DHCPv4 Option 650 IANA is requested to assign the following new DHCP Option Code in the 651 registry maintained in [BOOTP]. 653 +------+------------------+-------+----------------+----------------+ 654 | Tag | Name | Data | Meaning | Reference | 655 | | | Length| | | 656 +------+------------------+-------+----------------+----------------+ 657 | TBA2 | OPTION_V4_DNR | N | Encrypted DNS | [ThisDocument] | 658 | | | | Server | | 659 +------+------------------+-------+----------------+----------------+ 661 8.3. Neighbor Discovery Option 663 IANA is requested to assign the following new IPv6 Neighbor Discovery 664 Option type in the "IPv6 Neighbor Discovery Option Formats" sub- 665 registry under the "Internet Control Message Protocol version 6 666 (ICMPv6) Parameters" registry maintained in [ND]. 668 +------+--------------------------+----------------+ 669 | Type | Description | Reference | 670 +------+--------------------------+----------------+ 671 | TBA3 | DNS Encrypted DNS Option | [ThisDocument] | 672 +------+--------------------------+----------------+ 674 9. Acknowledgements 676 Many thanks to Christian Jacquenet and Michael Richardson for the 677 review. 679 Thanks to Stephen Farrell, Martin Thomson, Vittorio Bertola, Stephane 680 Bortzmeyer, Ben Schwartz, and Iain Sharp for the comments. 682 Thanks to Mark Nottingham for the feedback on HTTP redirection. 684 The use of DHCP to retrieve an authentication domain name was 685 discussed in Section 7.3.1 of [RFC8310] and 686 [I-D.pusateri-dhc-dns-driu]. 688 Thanks to Bernie Volz for the review of the DHCP part. 690 10. Contributing Authors 691 Nicolai Leymann 692 Deutsche Telekom 693 Germany 695 Email: n.leymann@telekom.de 697 Zhiwei Yan 698 CNNIC 699 No.4 South 4th Street, Zhongguancun 700 Beijing 100190 701 China 703 EMail: yan@cnnic.cn 705 11. References 707 11.1. Normative References 709 [I-D.ietf-dnsop-svcb-https] 710 Schwartz, B., Bishop, M., and E. Nygren, "Service binding 711 and parameter specification via the DNS (DNS SVCB and 712 HTTPS RRs)", draft-ietf-dnsop-svcb-https-05 (work in 713 progress), April 2021. 715 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 716 Requirement Levels", BCP 14, RFC 2119, 717 DOI 10.17487/RFC2119, March 1997, 718 . 720 [RFC2132] Alexander, S. and R. Droms, "DHCP Options and BOOTP Vendor 721 Extensions", RFC 2132, DOI 10.17487/RFC2132, March 1997, 722 . 724 [RFC3396] Lemon, T. and S. Cheshire, "Encoding Long Options in the 725 Dynamic Host Configuration Protocol (DHCPv4)", RFC 3396, 726 DOI 10.17487/RFC3396, November 2002, 727 . 729 [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, 730 "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, 731 DOI 10.17487/RFC4861, September 2007, 732 . 734 [RFC8106] Jeong, J., Park, S., Beloeil, L., and S. Madanapalli, 735 "IPv6 Router Advertisement Options for DNS Configuration", 736 RFC 8106, DOI 10.17487/RFC8106, March 2017, 737 . 739 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 740 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 741 May 2017, . 743 [RFC8415] Mrugalski, T., Siodelski, M., Volz, B., Yourtchenko, A., 744 Richardson, M., Jiang, S., Lemon, T., and T. Winters, 745 "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)", 746 RFC 8415, DOI 10.17487/RFC8415, November 2018, 747 . 749 11.2. Informative References 751 [BOOTP] "BOOTP Vendor Extensions and DHCP Options", 752 . 755 [DHCPV6] "DHCPv6 Option Codes", . 759 [dot1x] Cisco, "Basic 802.1x Wireless User Authentication", 760 . 763 [Dragonblood] 764 The Unicode Consortium, "Dragonblood: Analyzing the 765 Dragonfly Handshake of WPA3 and EAP-pwd", 766 . 768 [Evil-Twin] 769 The Unicode Consortium, "Evil twin (wireless networks)", 770 . 773 [I-D.boucadair-add-deployment-considerations] 774 Boucadair, M., Reddy, T., Wing, D., Cook, N., and T. 775 Jensen, "Discovery of Encrypted DNS Resolvers: Deployment 776 Considerations", draft-boucadair-add-deployment- 777 considerations-00 (work in progress), May 2021. 779 [I-D.ietf-add-ddr] 780 Pauly, T., Kinnear, E., Wood, C. A., McManus, P., and T. 781 Jensen, "Discovery of Designated Resolvers", draft-ietf- 782 add-ddr-00 (work in progress), February 2021. 784 [I-D.ietf-dprive-dnsoquic] 785 Huitema, C., Mankin, A., and S. Dickinson, "Specification 786 of DNS over Dedicated QUIC Connections", draft-ietf- 787 dprive-dnsoquic-02 (work in progress), February 2021. 789 [I-D.pusateri-dhc-dns-driu] 790 Pusateri, T. and W. Toorop, "DHCPv6 Options for private 791 DNS Discovery", draft-pusateri-dhc-dns-driu-00 (work in 792 progress), July 2018. 794 [I-D.schwartz-svcb-dns] 795 Schwartz, B., "Service Binding Mapping for DNS Servers", 796 draft-schwartz-svcb-dns-03 (work in progress), April 2021. 798 [Krack] The Unicode Consortium, "Key Reinstallation Attacks", 799 2017, . 801 [ND] "IPv6 Neighbor Discovery Option Formats", 802 . 805 [PSK] Cisco, "Identity PSK Feature Deployment Guide", 806 . 810 [RFC3552] Rescorla, E. and B. Korver, "Guidelines for Writing RFC 811 Text on Security Considerations", BCP 72, RFC 3552, 812 DOI 10.17487/RFC3552, July 2003, 813 . 815 [RFC3646] Droms, R., Ed., "DNS Configuration options for Dynamic 816 Host Configuration Protocol for IPv6 (DHCPv6)", RFC 3646, 817 DOI 10.17487/RFC3646, December 2003, 818 . 820 [RFC6092] Woodyatt, J., Ed., "Recommended Simple Security 821 Capabilities in Customer Premises Equipment (CPE) for 822 Providing Residential IPv6 Internet Service", RFC 6092, 823 DOI 10.17487/RFC6092, January 2011, 824 . 826 [RFC6125] Saint-Andre, P. and J. Hodges, "Representation and 827 Verification of Domain-Based Application Service Identity 828 within Internet Public Key Infrastructure Using X.509 829 (PKIX) Certificates in the Context of Transport Layer 830 Security (TLS)", RFC 6125, DOI 10.17487/RFC6125, March 831 2011, . 833 [RFC6731] Savolainen, T., Kato, J., and T. Lemon, "Improved 834 Recursive DNS Server Selection for Multi-Interfaced 835 Nodes", RFC 6731, DOI 10.17487/RFC6731, December 2012, 836 . 838 [RFC7113] Gont, F., "Implementation Advice for IPv6 Router 839 Advertisement Guard (RA-Guard)", RFC 7113, 840 DOI 10.17487/RFC7113, February 2014, 841 . 843 [RFC7513] Bi, J., Wu, J., Yao, G., and F. Baker, "Source Address 844 Validation Improvement (SAVI) Solution for DHCP", 845 RFC 7513, DOI 10.17487/RFC7513, May 2015, 846 . 848 [RFC7610] Gont, F., Liu, W., and G. Van de Velde, "DHCPv6-Shield: 849 Protecting against Rogue DHCPv6 Servers", BCP 199, 850 RFC 7610, DOI 10.17487/RFC7610, August 2015, 851 . 853 [RFC7858] Hu, Z., Zhu, L., Heidemann, J., Mankin, A., Wessels, D., 854 and P. Hoffman, "Specification for DNS over Transport 855 Layer Security (TLS)", RFC 7858, DOI 10.17487/RFC7858, May 856 2016, . 858 [RFC8146] Harkins, D., "Adding Support for Salted Password Databases 859 to EAP-pwd", RFC 8146, DOI 10.17487/RFC8146, April 2017, 860 . 862 [RFC8310] Dickinson, S., Gillmor, D., and T. Reddy, "Usage Profiles 863 for DNS over TLS and DNS over DTLS", RFC 8310, 864 DOI 10.17487/RFC8310, March 2018, 865 . 867 [RFC8484] Hoffman, P. and P. McManus, "DNS Queries over HTTPS 868 (DoH)", RFC 8484, DOI 10.17487/RFC8484, October 2018, 869 . 871 [RFC8499] Hoffman, P., Sullivan, A., and K. Fujiwara, "DNS 872 Terminology", BCP 219, RFC 8499, DOI 10.17487/RFC8499, 873 January 2019, . 875 Authors' Addresses 876 Mohamed Boucadair (editor) 877 Orange 878 Rennes 35000 879 France 881 Email: mohamed.boucadair@orange.com 883 Tirumaleswar Reddy (editor) 884 McAfee, Inc. 885 Embassy Golf Link Business Park 886 Bangalore, Karnataka 560071 887 India 889 Email: TirumaleswarReddy_Konda@McAfee.com 891 Dan Wing 892 Citrix Systems, Inc. 893 USA 895 Email: dwing-ietf@fuggles.com 897 Neil Cook 898 Open-Xchange 899 UK 901 Email: neil.cook@noware.co.uk 903 Tommy Jensen 904 Microsoft 905 USA 907 Email: tojens@microsoft.com