idnits 2.17.1 draft-ietf-add-dnr-09.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 (24 June 2022) is 671 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 771, but not defined == Outdated reference: A later version (-09) exists of draft-ietf-add-svcb-dns-03 == Outdated reference: A later version (-12) exists of draft-ietf-dnsop-svcb-https-10 == Outdated reference: A later version (-10) exists of draft-ietf-add-ddr-07 -- 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 (~~), 6 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: 26 December 2022 Akamai 6 D. Wing 7 Citrix 8 N. Cook 9 Open-Xchange 10 T. Jensen 11 Microsoft 12 24 June 2022 14 DHCP and Router Advertisement Options for the Discovery of Network- 15 designated Resolvers (DNR) 16 draft-ietf-add-dnr-09 18 Abstract 20 The document specifies new DHCP and IPv6 Router Advertisement options 21 to discover encrypted DNS resolvers (e.g., DNS-over-HTTPS, DNS-over- 22 TLS, DNS-over-QUIC). Particularly, it allows a host 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 resolvers. 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 26 December 2022. 43 Copyright Notice 45 Copyright (c) 2022 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 (https://trustee.ietf.org/ 50 license-info) in effect on the date of publication of this document. 51 Please review these documents carefully, as they describe your rights 52 and restrictions with respect to this document. Code Components 53 extracted from this document must include Revised BSD License text as 54 described in Section 4.e of the Trust Legal Provisions and are 55 provided without warranty as described in the Revised BSD License. 57 Table of Contents 59 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 60 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 61 3. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 4 62 3.1. Configuration Data for Encrypted DNS . . . . . . . . . . 4 63 3.1.1. ADN as the Reference Identifier for DNS 64 Authentication . . . . . . . . . . . . . . . . . . . 4 65 3.1.2. Avoiding Dependency on External Resolvers . . . . . . 4 66 3.1.3. Single vs. Multiple IP Addresses . . . . . . . . . . 5 67 3.1.4. Why Not Separate Options for ADN and IP Addresses? . 5 68 3.1.5. Service Parameters . . . . . . . . . . . . . . . . . 5 69 3.1.6. Service Mode vs ADN Only Mode . . . . . . . . . . . . 6 70 3.1.7. Encrypted DNS Options Ordering . . . . . . . . . . . 6 71 3.1.8. Recommended DNR Information . . . . . . . . . . . . . 6 72 3.2. Handling Configuration Data Conflicts . . . . . . . . . . 7 73 3.3. Connection Establishment . . . . . . . . . . . . . . . . 7 74 3.4. Multihoming Considerations . . . . . . . . . . . . . . . 7 75 4. DHCPv6 Encrypted DNS Option . . . . . . . . . . . . . . . . . 7 76 4.1. Option Format . . . . . . . . . . . . . . . . . . . . . . 7 77 4.2. DHCPv6 Client Behavior . . . . . . . . . . . . . . . . . 9 78 5. DHCPv4 Encrypted DNS Option . . . . . . . . . . . . . . . . . 10 79 5.1. Option Format . . . . . . . . . . . . . . . . . . . . . . 10 80 5.2. DHCPv4 Client Behavior . . . . . . . . . . . . . . . . . 12 81 6. IPv6 RA Encrypted DNS Option . . . . . . . . . . . . . . . . 12 82 6.1. Option Format . . . . . . . . . . . . . . . . . . . . . . 12 83 6.2. IPv6 Host Behavior . . . . . . . . . . . . . . . . . . . 14 84 7. Security Considerations . . . . . . . . . . . . . . . . . . . 14 85 7.1. Spoofing Attacks . . . . . . . . . . . . . . . . . . . . 14 86 7.2. Deletion Attacks . . . . . . . . . . . . . . . . . . . . 15 87 7.3. Passive Attacks . . . . . . . . . . . . . . . . . . . . . 16 88 7.4. Wireless Security - Authentication Attacks . . . . . . . 16 89 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16 90 8.1. DHCPv6 Option . . . . . . . . . . . . . . . . . . . . . . 16 91 8.2. DHCPv4 Option . . . . . . . . . . . . . . . . . . . . . . 17 92 8.3. Neighbor Discovery Option . . . . . . . . . . . . . . . . 17 93 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 17 94 10. Contributing Authors . . . . . . . . . . . . . . . . . . . . 18 95 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 18 96 11.1. Normative References . . . . . . . . . . . . . . . . . . 18 97 11.2. Informative References . . . . . . . . . . . . . . . . . 19 98 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 22 100 1. Introduction 102 This document focuses on the support of encrypted DNS such as DNS- 103 over-HTTPS (DoH) [RFC8484], DNS-over-TLS (DoT) [RFC7858], or DNS- 104 over-QUIC (DoQ) [RFC9250] in local networks. 106 In particular, the document specifies how a local encrypted DNS 107 resolver can be discovered by connected hosts by means of DHCPv4 108 [RFC2132], DHCPv6 [RFC8415], and IPv6 Router Advertisement (RA) 109 [RFC4861] options. These options are designed to convey the 110 following information: the DNS Authentication Domain Name (ADN), a 111 list of IP addresses, and a set of service parameters. This 112 procedure is called Discovery of Network-designated Resolvers (DNR). 114 The options defined in this document can be deployed in a variety of 115 deployments (e.g., local networks with Customer Premises Equipment 116 (CPEs) that may or may not be managed by an Internet Service Provider 117 (ISP), local networks with or without DNS forwarders). It is out of 118 the scope of this document to provide an inventory of such 119 deployments. 121 2. Terminology 123 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 124 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 125 "OPTIONAL" in this document are to be interpreted as described in BCP 126 14 [RFC2119] [RFC8174] when, and only when, they appear in all 127 capitals, as shown here. 129 This document makes use of the terms defined in [RFC8499]. The 130 following additional terms are used: 132 Do53: refers to unencrypted DNS. 134 DNR: refers to the Discovery of Network-designated Resolvers 135 procedure. 137 Encrypted DNS: refers to a scheme where DNS exchanges are 138 transported over an encrypted channel. Examples of encrypted DNS 139 are DoT, DoH, or DoQ. 141 Encrypted DNS options: refers to the options defined in Sections 4, 142 5, and 6. 144 DHCP: refers to both DHCPv4 and DHCPv6. 146 3. Overview 148 This document describes how a DNS client can discover local encrypted 149 DNS resolvers using DHCP (Sections 4 and 5) and Neighbor Discovery 150 protocol (Section 6): Encrypted DNS options. 152 These options configure an authentication domain name, a list of IPv6 153 addresses, and a set of service parameters of the encrypted DNS 154 resolver. More information about the design of these options is 155 provided in the following subsections. 157 3.1. Configuration Data for Encrypted DNS 159 3.1.1. ADN as the Reference Identifier for DNS Authentication 161 In order to allow for PKIX-based authentication between a DNS client 162 and an encrypted DNS resolver, the Encrypted DNS options are designed 163 to include an authentication domain name. This ADN is presented as a 164 reference identifier for DNS authentication purposes. This design 165 accommodates the current best practices for issuing certificates as 166 per Section 1.7.2 of [RFC6125]: 168 | Some certification authorities issue server certificates based on 169 | IP addresses, but preliminary evidence indicates that such 170 | certificates are a very small percentage (less than 1%) of issued 171 | certificates. 173 3.1.2. Avoiding Dependency on External Resolvers 175 To avoid adding a dependency on another server to resolve the ADN, 176 the Encrypted DNS options return the IP address(es) to locate the 177 encrypted DNS resolver. These encrypted DNS resolvers may be hosted 178 on the same or distinct IP addresses. Such a decision is deployment 179 specific. 181 In order to optimize the size of discovery messages when all DNS 182 resolvers terminate on the same IP address, early versions of this 183 document considered relying upon the discovery mechanisms specified 184 in [RFC2132][RFC3646][RFC8106] to retrieve a list of IP addresses to 185 reach their DNS resolvers. Nevertheless, this approach requires a 186 client that supports more than one encrypted DNS protocol (e.g., DoH 187 and DoT) to probe that list of IP addresses. To avoid such a 188 probing, the options defined in Sections 4, 5, and 6 associate an IP 189 address with an encrypted DNS protocol. No probing is required in 190 such a design. 192 3.1.3. Single vs. Multiple IP Addresses 194 A list of IP addresses to reach an encrypted DNS resolver may be 195 returned in an Encrypted DNS option to accommodate current 196 deployments relying upon primary and backup resolvers. Also, DNR can 197 be used in contexts where other DNS redundancy schemes (e.g., anycast 198 as in BCP 126 [RFC4786]) are used. 200 Whether one or more IP addresses are returned in an Encrypted DNS 201 option is deployment specific. For example, a router embedding a 202 recursive server or a forwarder has to include one single IP address 203 pointing to one of its LAN-facing interfaces. Typically, this IP 204 address can be a private IPv4 address, a link-local address, a Unique 205 Local IPv6 unicast Address (ULA), or a Global Unicast Address (GUA). 207 If multiple IP addresses are to be returned in an Encrypted DNS 208 option, these addresses are ordered in the preference for use by the 209 client. 211 3.1.4. Why Not Separate Options for ADN and IP Addresses? 213 A single option is used to convey both the ADN and IP addresses 214 because otherwise means to correlate an IP address conveyed in an 215 option with an ADN conveyed in another option will be required if, 216 for example, more than one ADN is supported by the network. 218 3.1.5. Service Parameters 220 Because distinct encrypted DNS protocols may be provisioned by a 221 network (e.g., DoT, DoH, and DoQ) and that some of these protocols 222 may make use of customized port numbers instead of default ones, the 223 Encrypted DNS options are designed to return a set of service 224 parameters. These parameters are encoded following the same rules 225 for encoding SvcParams in Section 2.1 of [I-D.ietf-dnsop-svcb-https]. 226 This encoding approach may increase the size of the options but it 227 has the merit relying upon an existing IANA registry and, thus, 228 accommodating new encrypted DNS protocols and service parameters that 229 may be defined in the future. 231 The following service parameters MUST be supported by a DNR 232 implementation: 234 alpn: Used to indicate the set of supported protocols (Section 7.1 235 of [I-D.ietf-dnsop-svcb-https]). 237 port: Used to indicate the target port number for the encrypted DNS 238 connection (Section 7.2 of [I-D.ietf-dnsop-svcb-https]). 240 In addition, the following service parameters are RECOMMENDED to be 241 supported by a DNR implementation: 243 ech: Used to enable Encrypted ClientHello (ECH) (Section 7.3 of 244 [I-D.ietf-dnsop-svcb-https]). 246 dohpath: Used to supply a relative DoH URI Template (Section 5.1 of 247 [I-D.ietf-add-svcb-dns]). 249 3.1.6. Service Mode vs ADN Only Mode 251 ServiceMode (Section 2.4.3 of [I-D.ietf-dnsop-svcb-https]) SHOULD be 252 used because the Encrypted DNS options are self-contained and do not 253 require any additional DNS queries. The reader may refer to 254 [RFC7969] for an overview of advanced capabilities that are supported 255 by DHCP servers to populate configuration data (e.g., issue DNS 256 queries). 258 In contexts where putting additional complexity on requesting hosts 259 is acceptable, returning an ADN only can be considered. The supplied 260 ADN will be processed by a host following the procedure in Section 5 261 of [I-D.ietf-add-ddr]. Note that this mode may be subject to active 262 attacks, which can be mitigated by DNSSEC. 264 3.1.7. Encrypted DNS Options Ordering 266 The DHCP options defined in Sections 4 and 5 follow the option 267 ordering guidelines in Section 17 of [RFC7227]. 269 Likewise, the RA option (Section 6) adheres to the recommendations in 270 Section 9 of [RFC4861]. 272 3.1.8. Recommended DNR Information 274 Other mechanisms may be considered in other contexts (e.g., secure 275 discovery) for the provisioning of encrypted DNS resolvers. It is 276 RECOMMENDED that at least the following DNR information is made 277 available to a requesting host: 279 * A service priority whenever the discovery mechanism does not rely 280 on implicit ordering if multiple instances of the encrypted DNS 281 are used. 283 * An authentication domain name. 285 * A list of IP addresses to locate the encrypted DNS resolver. 287 * A set of service parameters. 289 3.2. Handling Configuration Data Conflicts 291 If the encrypted DNS is discovered by a host using both RA and DHCP, 292 the rules discussed in Section 5.3.1 of [RFC8106] MUST be followed. 294 DHCP/RA options to discover encrypted DNS resolvers (including, DoH 295 URI Templates) takes precedence over Discovery of Designated 296 Resolvers (DDR) [I-D.ietf-add-ddr] since DDR uses Do53 to an external 297 DNS resolver, which is susceptible to both internal and external 298 attacks whereas DHCP/RA is typically protected using the mechanisms 299 discussed in Section 7.1. 301 3.3. Connection Establishment 303 If the local DNS client supports one of the discovered Encrypted DNS 304 protocols identified by Application Layer Protocol Negotiation (ALPN) 305 protocol identifiers, the DNS client establishes an encrypted DNS 306 session following the order of the discovered resolvers. The client 307 follows the mechanism discussed in Section 8 of [RFC8310] to 308 authenticate the DNS resolver certificate using the authentication 309 domain name conveyed in the Encrypted DNS options. ALPN-related 310 considerations can be found in Section 6.1 of 311 [I-D.ietf-dnsop-svcb-https]. 313 3.4. Multihoming Considerations 315 Devices may be connected to multiple networks; each providing their 316 own DNS configuration using the discovery mechanisms specified in 317 this document. Nevertheless, it is out of the scope of this 318 specification to discuss DNS selection of multi-interface devices. 319 The reader may refer to [RFC6731] for a discussion of issues and an 320 example of DNS resolver selection for multi-interfaced devices. 322 4. DHCPv6 Encrypted DNS Option 324 4.1. Option Format 326 The format of the DHCPv6 Encrypted DNS option is shown in Figure 1. 328 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 329 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 330 | OPTION_V6_DNR | Option-length | 331 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 332 | Service Priority | ADN Length | 333 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 334 ~ authentication-domain-name ~ 335 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 336 | Addr Length | | 337 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 338 ~ ipv6-address(es) ~ 339 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 340 | | | 341 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 342 ~ Service Parameters (SvcParams) ~ 343 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 345 Figure 1: DHCPv6 Encrypted DNS Option 347 The fields of the option shown in Figure 1 are as follows: 349 Option-code: OPTION_V6_DNR (TBA1, see Section 8.1) 351 Option-length: Length of the enclosed data in octets. The option 352 length is ('ADN Length' + 4) when only an ADN is included in the 353 option. 355 Service Priority: The priority of this OPTION_V6_DNR instance 356 compared to other instances. This field is encoded following the 357 rules specified in Section 2.4.1 of [I-D.ietf-dnsop-svcb-https]. 359 ADN Length: Length of the authentication-domain-name field in 360 octets. 362 authentication-domain-name (variable length): A fully qualified 363 domain name of the encrypted DNS resolver. This field is 364 formatted as specified in Section 10 of [RFC8415]. 366 An example of the authentication-domain-name encoding is shown in 367 Figure 2. This example conveys the FQDN "doh1.example.com.", and 368 the resulting Option-length field is 18. 370 +------+------+------+------+------+------+------+------+------+ 371 | 0x04 | d | o | h | 1 | 0x07 | e | x | a | 372 +------+------+------+------+------+------+------+------+------+ 373 | m | p | l | e | 0x03 | c | o | m | 0x00 | 374 +------+------+------+------+------+------+------+------+------+ 375 Figure 2: An Example of the DNS authentication-domain-name 376 Encoding 378 Addr Length: Length of enclosed IPv6 addresses in octets. It MUST 379 be a multiple of 16 for ServiceMode. 381 ipv6-address(es) (variable length): Indicates one or more IPv6 382 addresses to reach the encrypted DNS resolver. An address can be 383 link-local, ULA, or GUA. The format of this field is shown in 384 Figure 3. 386 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 387 | | 388 | ipv6-address | 389 | | 390 | | 391 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 392 | ... | 393 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 395 Figure 3: Format of the IPv6 Addresses Field 397 Service Parameters (SvcParams) (variable length): Specifies a set of 398 service parameters that are encoded following the rules in 399 Section 2.1 of [I-D.ietf-dnsop-svcb-https]. Service parameters 400 may include, for example, a list of ALPN protocol identifiers or 401 alternate port numbers. The service parameters MUST NOT include 402 "ipv4hint" or "ipv6hint" SvcParams as they are superseded by the 403 included IP addresses. 405 If no port service parameter is included, this indicates that 406 default port numbers should be used. As a reminder, the default 407 port number is 853 for DoT, 443 for DoH, and 853 for DoQ. 409 The length of this field is ('Option-length' - 6 - 'ADN Length' - 410 'Addr Length'). 412 4.2. DHCPv6 Client Behavior 414 To discover an encrypted DNS resolver, the DHCPv6 client MUST include 415 OPTION_V6_DNR in an Option Request Option (ORO), as in Sections 416 18.2.1, 18.2.2, 18.2.4, 18.2.5, 18.2.6, and 21.7 of [RFC8415]. 418 The DHCPv6 client MUST be prepared to receive multiple instances of 419 the OPTION_V6_DNR option; each option is to be treated as a separate 420 encrypted DNS resolver. These instances SHOULD be processed 421 following their service priority (i.e., smaller service priority 422 indicates a higher preference). 424 The DHCPv6 client MUST silently discard multicast and host loopback 425 addresses conveyed in OPTION_V6_DNR. 427 5. DHCPv4 Encrypted DNS Option 429 5.1. Option Format 431 The format of the DHCPv4 Encrypted DNS option is illustrated in 432 Figure 4. 434 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 435 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 436 | TBA2 | Length | 437 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 438 | Service Priority | 439 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 440 | ADN Length | | 441 +-+-+-+-+-+-+-+-+ | 442 ~ authentication-domain-name ~ 443 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 444 | Addr Length | | 445 +-+-+-+-+-+-+-+-+ | 446 ~ IPv4 Address(es) ~ 447 | +-+-+-+-+-+-+-+-+ 448 | | | 449 +-+-+-+-+-+-+-+-+ | 450 ~Service Parameters (SvcParams) ~ 451 | | 452 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 454 Figure 4: DHCPv4 Encrypted DNS Option 456 The fields of the option shown in Figure 4 are as follows: 458 Code: OPTION_V4_DNR (TBA2, see Section 8.2). 460 Length: Indicates the length of the enclosed data in octets. The 461 option length is ('ADN Length' + 3) when only an ADN is included 462 in the option. 464 Service Priority: The priority of this OPTION_V4_DNR instance 465 compared to other instances. This field is encoded following the 466 rules specified in Section 2.4.1 of [I-D.ietf-dnsop-svcb-https]. 468 ADN Length: Indicates the length of the authentication-domain-name 469 in octets. 471 authentication-domain-name (variable length): Includes the 472 authentication domain name of the encrypted DNS resolver. This 473 field is formatted as specified in Section 10 of [RFC8415]. An 474 example is provided in Figure 2. 476 Addr Length: Indicates the length of included IPv4 addresses in 477 octets. It MUST be a multiple of 4 for ServiceMode. 479 IPv4 Address(es) (variable length): Indicates one or more IPv4 480 addresses to reach the encrypted DNS resolver. Both private and 481 public IPv4 addresses can be included in this field. The format 482 of this field is shown in Figure 5. This format assumes that an 483 IPv4 address is encoded as a1.a2.a3.a4. 485 0 8 16 24 32 40 48 486 +-----+-----+-----+-----+-----+-----+-- 487 | a1 | a2 | a3 | a4 | a1 | a2 | ... 488 +-----+-----+-----+-----+-----+-----+-- 489 IPv4 Address 1 IPv4 Address 2 ... 491 Figure 5: Format of the IPv4 Addresses Field 493 Service Paramters (SvcParams) (variable length): Specifies a set of 494 service parameters that are encoded following the rules in 495 Section 2.1 of [I-D.ietf-dnsop-svcb-https]. Service parameters 496 may include, for example, a list of ALPN protocol identifiers or 497 alternate port numbers. The service parameters MUST NOT include 498 "ipv4hint" or "ipv6hint" SvcParams as they are superseded by the 499 included IP addresses. 501 If no port service parameter is included, this indicates that 502 default port numbers should be used. 504 The length of this field is ('Option-length' - 4 - 'ADN Length' - 505 'Addr Length'). 507 OPTION_V4_DNR is a concatenation-requiring option. As such, the 508 mechanism specified in [RFC3396] MUST be used if OPTION_V4_DNR 509 exceeds the maximum DHCPv4 option size of 255 octets. 511 5.2. DHCPv4 Client Behavior 513 To discover an encrypted DNS resolver, the DHCPv4 client requests the 514 encrypted DNS resolver by including OPTION_V4_DNR in a Parameter 515 Request List option [RFC2132]. 517 The DHCPv4 client MUST be prepared to receive multiple instances of 518 the OPTION_V4_DNR option; each option is to be treated as a separate 519 encrypted DNS resolver. These instances SHOULD be processed 520 following their service priority (i.e., smaller service priority 521 indicates a higher preference). 523 The DHCPv4 client MUST silently discard multicast and host loopback 524 addresses conveyed in OPTION_V4_DNR. 526 6. IPv6 RA Encrypted DNS Option 528 6.1. Option Format 530 This section defines a new Neighbor Discovery option [RFC4861]: IPv6 531 RA Encrypted DNS option. This option is useful in contexts similar 532 to those discussed in Section 1.1 of [RFC8106]. 534 The format of the IPv6 RA Encrypted DNS option is illustrated in 535 Figure 6. 537 0 1 2 3 538 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 539 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 540 | TBA3 | Length | Service Priority | 541 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 542 | Lifetime | 543 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 544 | ADN Length | | 545 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 546 ~ authentication-domain-name ~ 547 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 548 | Addr Length | | 549 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 550 ~ ipv6-address(es) ~ 551 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 552 | | SvcParams Length | 553 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 554 ~ Service Parameters (SvcParams) ~ 555 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 557 Figure 6: RA Encrypted DNS Option 559 The fields of the option shown in Figure 6 are as follows: 561 Type: 8-bit identifier of the Encrypted DNS option as assigned by 562 IANA (TBA3, see Section 8.3). 564 Length: 8-bit unsigned integer. The length of the option (including 565 the Type and Length fields) is in units of 8 octets. 567 Service Priority: The priority of this Encrypted DNS option instance 568 compared to other instances. This field is encoded following the 569 rules specified in Section 2.4.1 of [I-D.ietf-dnsop-svcb-https]. 571 Lifetime: 32-bit unsigned integer. The maximum time in seconds 572 (relative to the time the packet is received) over which the 573 discovered Authentication Domain Name is valid. 575 The value of Lifetime SHOULD by default be at least 3 * 576 MaxRtrAdvInterval, where MaxRtrAdvInterval is the maximum RA 577 interval as defined in [RFC4861]. 579 A value of all one bits (0xffffffff) represents infinity. 581 A value of zero means that this Authentication Domain Name MUST no 582 longer be used. 584 ADN Length: 16-bit unsigned integer. This field indicates the 585 length of the authentication-domain-name field in octets. 587 authentication-domain-name (variable length): The domain name of the 588 encrypted DNS resolver. This field is formatted as specified in 589 Section 10 of [RFC8415]. 591 Addr Length: 16-bit unsigned integer. This field indicates the 592 length of enclosed IPv6 addresses in octets. It MUST be a 593 multiple of 16 for ServiceMode. 595 ipv6-address(es) (variable length): One or more IPv6 addresses of 596 the encrypted DNS resolver. An address can be link-local, ULA, or 597 GUA. 599 All of the addresses share the same Lifetime value. Similar to 600 [RFC8106], if it is desirable to have different Lifetime values 601 per IP address, multiple Encrypted DNS options may be used. 603 The format of this field is shown in Figure 3. 605 SvcParams Length: 16-bit unsigned integer. This field indicates the 606 length of the Service Parameters field in octets. 608 Service Paramters (SvcParams) (variable length): Specifies a set of 609 service parameters that are encoded following the rules in 610 Section 2.1 of [I-D.ietf-dnsop-svcb-https]. Service parameters 611 may include, for example, a list of ALPN protocol identifiers or 612 alternate port numbers. The service parameters MUST NOT include 613 "ipv4hint" or "ipv6hint" SvcParams as they are superseded by the 614 included IP addresses. 616 If no port service parameter is included, this indicates that 617 default port numbers should be used. 619 The option MUST be padded with zeros so that the full enclosed data 620 is a multiple of 8 octets (Section 4.6 of [RFC4861]). 622 6.2. IPv6 Host Behavior 624 The procedure for DNS configuration is the same as it is with any 625 other Neighbor Discovery option [RFC4861]. In addition, the host 626 follows the same procedure as the one described in Section 5.3.1 of 627 [RFC8106] for processing received Encrypted DNS options with the 628 formatting requirements in Section 6.1 substituted for the length 629 validation. 631 The host MUST be prepared to receive multiple Encrypted DNS options 632 in RAs. These instances SHOULD be processed following their service 633 priority (i.e., smaller service priority indicates a higher 634 preference). 636 The host MUST silently discard multicast and host loopback addresses 637 conveyed in the Encrypted DNS options. 639 7. Security Considerations 641 7.1. Spoofing Attacks 643 DHCP/RA messages are not encrypted or protected against modification 644 within the LAN. Unless mitigated (described below), the content of 645 DHCP and RA messages can be spoofed or modified by active attackers, 646 such as compromised devices within the local network. An active 647 attacker (Section 3.3 of [RFC3552]) can spoof the DHCP/RA response to 648 provide the attacker's encrypted DNS resolver. Note that such an 649 attacker can launch other attacks as discussed in Section 22 of 650 [RFC8415]. The attacker can get a domain name with a domain- 651 validated public certificate from a CA and host an encrypted DNS 652 resolver. 654 Attacks of spoofed or modified DHCP responses and RA messages by 655 attackers within the local network may be mitigated by making use of 656 the following mechanisms: 658 * DHCPv6-Shield described in [RFC7610], the router (e.g., a border 659 router, a CPE) discards DHCP response messages received from any 660 local endpoint. 662 * RA-Guard described in [RFC7113], the router discards RAs messages 663 received from any local endpoint. 665 * Source Address Validation Improvement (SAVI) solution for DHCP 666 described in [RFC7513], the router filters packets with forged 667 source IP addresses. 669 The above mechanisms would ensure that the endpoint receives the 670 correct configuration information of the encrypted DNS resolvers 671 selected by the DHCP server (or RA sender), but cannot provide any 672 information about the DHCP server or the entity hosting the DHCP 673 server (or RA sender) . 675 Encrypted DNS sessions with rogue resolvers that spoof the IP address 676 of a DNS resolver will fail because the DNS client will fail to 677 authenticate that rogue resolver based upon PKIX authentication 678 [RFC6125], particularly the authentication domain name in the 679 Encrypted DNS Option. DNS clients that ignore authentication 680 failures and accept spoofed certificates will be subject to attacks 681 (e.g., redirect to malicious resolvers, intercept sensitive data). 683 Encrypted DNS connections received from outside the local network 684 MUST be discarded by the encrypted DNS forwarder in the CPE. This 685 behavior adheres to REQ#8 in [RFC6092]; it MUST apply for both IPv4 686 and IPv6. 688 7.2. Deletion Attacks 690 If the DHCP responses or RAs are dropped by the attacker, the client 691 can fallback to use a preconfigured encrypted DNS resolver. However, 692 the use of policies to select resolvers is out of the scope of this 693 document. 695 Note that deletion attack is not specific to DHCP/RA. 697 7.3. Passive Attacks 699 A passive attacker (Section 3.2 of [RFC3552]) can identify a host is 700 using DHCP/RA to discover an encrypted DNS resolver and can infer 701 that host is capable of using DoH/DoT/DoQ to encrypt DNS messages. 702 However, a passive attacker cannot spoof or modify DHCP/RA messages. 704 7.4. Wireless Security - Authentication Attacks 706 Wireless LAN (WLAN) as frequently deployed in local networks (e.g., 707 home networks) is vulnerable to various attacks (e.g., [Evil-Twin], 708 [Krack], [Dragonblood]). Because of these attacks, only 709 cryptographically authenticated communications are trusted on WLANs. 710 This means that an information (e.g., NTP server, DNS resolver, 711 domain search list) provided by such networks via DHCP, DHCPv6, or RA 712 are untrusted because DHCP and RA messages are not authenticated. 714 If the pre-shared key (PSK) is the same for all clients that connect 715 to the same WLAN (e.g., WPA-PSK), the shared key will be available to 716 all nodes, including attackers. As such, it is possible to mount an 717 active on-path attack. On-path attacks are possible within local 718 networks because such a WLAN authentication lacks peer entity 719 authentication. 721 This leads to the need for provisioning unique credentials for 722 different clients. Endpoints can be provisioned with unique 723 credentials (username and password, typically) provided by the local 724 network administrator to mutually authenticate to the local WLAN 725 Access Point (e.g., 802.1x Wireless User Authentication on OpenWRT 726 [dot1x], EAP-pwd [RFC8146]). Not all endpoint devices (e.g., IoT 727 devices) support 802.1x supplicant and need an alternate mechanism to 728 connect to the local network. To address this limitation, unique 729 pre-shared keys can be created for each such devices and WPA-PSK is 730 used (e.g., [IPSK]). 732 8. IANA Considerations 734 8.1. DHCPv6 Option 736 IANA is requested to assign the following new DHCPv6 Option Code in 737 the registry maintained in [DHCPV6]. 739 +=======+===============+============+===========+================+ 740 | Value | Description | Client ORO | Singleton | Reference | 741 | | | | Option | | 742 +=======+===============+============+===========+================+ 743 | TBA1 | OPTION_V6_DNR | Yes | No | [ThisDocument] | 744 +-------+---------------+------------+-----------+----------------+ 746 Table 1 748 8.2. DHCPv4 Option 750 IANA is requested to assign the following new DHCP Option Code in the 751 registry maintained in [BOOTP]. 753 +------+------------------+-------+----------------+----------------+ 754 | Tag | Name | Data | Meaning | Reference | 755 | | | Length| | | 756 +------+------------------+-------+----------------+----------------+ 757 | TBA2 | OPTION_V4_DNR | N | Encrypted DNS | [ThisDocument] | 758 | | | | Server | | 759 +------+------------------+-------+----------------+----------------+ 761 8.3. Neighbor Discovery Option 763 IANA is requested to assign the following new IPv6 Neighbor Discovery 764 Option type in the "IPv6 Neighbor Discovery Option Formats" sub- 765 registry under the "Internet Control Message Protocol version 6 766 (ICMPv6) Parameters" registry maintained in [ND]. 768 +======+======================+================+ 769 | Type | Description | Reference | 770 +======+======================+================+ 771 | TBA3 | Encrypted DNS Option | [ThisDocument] | 772 +------+----------------------+----------------+ 774 Table 2 776 9. Acknowledgements 778 Many thanks to Christian Jacquenet and Michael Richardson for the 779 review. 781 Thanks to Stephen Farrell, Martin Thomson, Vittorio Bertola, Stephane 782 Bortzmeyer, Ben Schwartz, Iain Sharp, and Chris Box for the comments. 784 Thanks to Mark Nottingham for the feedback on HTTP redirection that 785 was discussed in previous versions of this specification. 787 The use of DHCP to retrieve an authentication domain name was 788 discussed in Section 7.3.1 of [RFC8310] and 789 [I-D.pusateri-dhc-dns-driu]. 791 Thanks to Bernie Volz for the review of the DHCP part. 793 Thanks to Andrew Campling for the Shepherd review and Eric Vyncke for 794 the AD review. 796 10. Contributing Authors 798 Nicolai Leymann 799 Deutsche Telekom 800 Germany 802 Email: n.leymann@telekom.de 804 Zhiwei Yan 805 CNNIC 806 No.4 South 4th Street, Zhongguancun 807 Beijing 100190 808 China 810 EMail: yan@cnnic.cn 812 11. References 814 11.1. Normative References 816 [I-D.ietf-add-svcb-dns] 817 Schwartz, B., "Service Binding Mapping for DNS Servers", 818 Work in Progress, Internet-Draft, draft-ietf-add-svcb-dns- 819 03, 22 April 2022, . 822 [I-D.ietf-dnsop-svcb-https] 823 Schwartz, B., Bishop, M., and E. Nygren, "Service binding 824 and parameter specification via the DNS (DNS SVCB and 825 HTTPS RRs)", Work in Progress, Internet-Draft, draft-ietf- 826 dnsop-svcb-https-10, 24 May 2022, 827 . 830 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 831 Requirement Levels", BCP 14, RFC 2119, 832 DOI 10.17487/RFC2119, March 1997, 833 . 835 [RFC2132] Alexander, S. and R. Droms, "DHCP Options and BOOTP Vendor 836 Extensions", RFC 2132, DOI 10.17487/RFC2132, March 1997, 837 . 839 [RFC3396] Lemon, T. and S. Cheshire, "Encoding Long Options in the 840 Dynamic Host Configuration Protocol (DHCPv4)", RFC 3396, 841 DOI 10.17487/RFC3396, November 2002, 842 . 844 [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, 845 "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, 846 DOI 10.17487/RFC4861, September 2007, 847 . 849 [RFC8106] Jeong, J., Park, S., Beloeil, L., and S. Madanapalli, 850 "IPv6 Router Advertisement Options for DNS Configuration", 851 RFC 8106, DOI 10.17487/RFC8106, March 2017, 852 . 854 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 855 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 856 May 2017, . 858 [RFC8415] Mrugalski, T., Siodelski, M., Volz, B., Yourtchenko, A., 859 Richardson, M., Jiang, S., Lemon, T., and T. Winters, 860 "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)", 861 RFC 8415, DOI 10.17487/RFC8415, November 2018, 862 . 864 11.2. Informative References 866 [BOOTP] "BOOTP Vendor Extensions and DHCP Options", 867 . 870 [DHCPV6] "DHCPv6 Option Codes", . 874 [dot1x] Cisco, "Basic 802.1x Wireless User Authentication", 875 . 878 [Dragonblood] 879 The Unicode Consortium, "Dragonblood: Analyzing the 880 Dragonfly Handshake of WPA3 and EAP-pwd", 881 . 883 [Evil-Twin] 884 The Unicode Consortium, "Evil twin (wireless networks)", 885 . 888 [I-D.ietf-add-ddr] 889 Pauly, T., Kinnear, E., Wood, C. A., McManus, P., and T. 890 Jensen, "Discovery of Designated Resolvers", Work in 891 Progress, Internet-Draft, draft-ietf-add-ddr-07, 24 June 892 2022, . 895 [I-D.pusateri-dhc-dns-driu] 896 Pusateri, T. and W. Toorop, "DHCPv6 Options for private 897 DNS Discovery", Work in Progress, Internet-Draft, draft- 898 pusateri-dhc-dns-driu-00, 2 July 2018, 899 . 902 [IPSK] Cisco, "Identity PSK Feature Deployment Guide", 903 . 907 [Krack] The Unicode Consortium, "Key Reinstallation Attacks", 908 2017, . 910 [ND] "IPv6 Neighbor Discovery Option Formats", 911 . 914 [RFC3552] Rescorla, E. and B. Korver, "Guidelines for Writing RFC 915 Text on Security Considerations", BCP 72, RFC 3552, 916 DOI 10.17487/RFC3552, July 2003, 917 . 919 [RFC3646] Droms, R., Ed., "DNS Configuration options for Dynamic 920 Host Configuration Protocol for IPv6 (DHCPv6)", RFC 3646, 921 DOI 10.17487/RFC3646, December 2003, 922 . 924 [RFC4786] Abley, J. and K. Lindqvist, "Operation of Anycast 925 Services", BCP 126, RFC 4786, DOI 10.17487/RFC4786, 926 December 2006, . 928 [RFC6092] Woodyatt, J., Ed., "Recommended Simple Security 929 Capabilities in Customer Premises Equipment (CPE) for 930 Providing Residential IPv6 Internet Service", RFC 6092, 931 DOI 10.17487/RFC6092, January 2011, 932 . 934 [RFC6125] Saint-Andre, P. and J. Hodges, "Representation and 935 Verification of Domain-Based Application Service Identity 936 within Internet Public Key Infrastructure Using X.509 937 (PKIX) Certificates in the Context of Transport Layer 938 Security (TLS)", RFC 6125, DOI 10.17487/RFC6125, March 939 2011, . 941 [RFC6731] Savolainen, T., Kato, J., and T. Lemon, "Improved 942 Recursive DNS Server Selection for Multi-Interfaced 943 Nodes", RFC 6731, DOI 10.17487/RFC6731, December 2012, 944 . 946 [RFC7113] Gont, F., "Implementation Advice for IPv6 Router 947 Advertisement Guard (RA-Guard)", RFC 7113, 948 DOI 10.17487/RFC7113, February 2014, 949 . 951 [RFC7227] Hankins, D., Mrugalski, T., Siodelski, M., Jiang, S., and 952 S. Krishnan, "Guidelines for Creating New DHCPv6 Options", 953 BCP 187, RFC 7227, DOI 10.17487/RFC7227, May 2014, 954 . 956 [RFC7513] Bi, J., Wu, J., Yao, G., and F. Baker, "Source Address 957 Validation Improvement (SAVI) Solution for DHCP", 958 RFC 7513, DOI 10.17487/RFC7513, May 2015, 959 . 961 [RFC7610] Gont, F., Liu, W., and G. Van de Velde, "DHCPv6-Shield: 962 Protecting against Rogue DHCPv6 Servers", BCP 199, 963 RFC 7610, DOI 10.17487/RFC7610, August 2015, 964 . 966 [RFC7858] Hu, Z., Zhu, L., Heidemann, J., Mankin, A., Wessels, D., 967 and P. Hoffman, "Specification for DNS over Transport 968 Layer Security (TLS)", RFC 7858, DOI 10.17487/RFC7858, May 969 2016, . 971 [RFC7969] Lemon, T. and T. Mrugalski, "Customizing DHCP 972 Configuration on the Basis of Network Topology", RFC 7969, 973 DOI 10.17487/RFC7969, October 2016, 974 . 976 [RFC8146] Harkins, D., "Adding Support for Salted Password Databases 977 to EAP-pwd", RFC 8146, DOI 10.17487/RFC8146, April 2017, 978 . 980 [RFC8310] Dickinson, S., Gillmor, D., and T. Reddy, "Usage Profiles 981 for DNS over TLS and DNS over DTLS", RFC 8310, 982 DOI 10.17487/RFC8310, March 2018, 983 . 985 [RFC8484] Hoffman, P. and P. McManus, "DNS Queries over HTTPS 986 (DoH)", RFC 8484, DOI 10.17487/RFC8484, October 2018, 987 . 989 [RFC8499] Hoffman, P., Sullivan, A., and K. Fujiwara, "DNS 990 Terminology", BCP 219, RFC 8499, DOI 10.17487/RFC8499, 991 January 2019, . 993 [RFC9250] Huitema, C., Dickinson, S., and A. Mankin, "DNS over 994 Dedicated QUIC Connections", RFC 9250, 995 DOI 10.17487/RFC9250, May 2022, 996 . 998 Authors' Addresses 1000 Mohamed Boucadair (editor) 1001 Orange 1002 35000 Rennes 1003 France 1004 Email: mohamed.boucadair@orange.com 1006 Tirumaleswar Reddy (editor) 1007 Akamai 1008 Embassy Golf Link Business Park 1009 Bangalore 560071 1010 Karnataka 1011 India 1012 Email: kondtir@gmail.com 1014 Dan Wing 1015 Citrix Systems, Inc. 1016 United States of America 1017 Email: dwing-ietf@fuggles.com 1018 Neil Cook 1019 Open-Xchange 1020 United Kingdom 1021 Email: neil.cook@noware.co.uk 1023 Tommy Jensen 1024 Microsoft 1025 United States of America 1026 Email: tojens@microsoft.com