idnits 2.17.1 draft-ietf-add-dnr-07.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 (13 April 2022) is 741 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 744, but not defined == Outdated reference: A later version (-12) exists of draft-ietf-dnsop-svcb-https-08 == Outdated reference: A later version (-10) exists of draft-ietf-add-ddr-06 == Outdated reference: A later version (-09) exists of draft-ietf-add-svcb-dns-02 == Outdated reference: A later version (-12) exists of draft-ietf-dprive-dnsoquic-11 -- 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 (~~), 7 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: 15 October 2022 Akamai 6 D. Wing 7 Citrix 8 N. Cook 9 Open-Xchange 10 T. Jensen 11 Microsoft 12 13 April 2022 14 DHCP and Router Advertisement Options for the Discovery of Network- 15 designated Resolvers (DNR) 16 draft-ietf-add-dnr-07 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 15 October 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 . . . . . . . . . . . . . . . . . . . . . . . . 2 60 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 61 3. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 3 62 3.1. Configuration Data for Encrypted DNS . . . . . . . . . . 4 63 3.2. Handling Configuration Data Conflicts . . . . . . . . . . 6 64 3.3. Connection Establishment . . . . . . . . . . . . . . . . 6 65 3.4. Multihoming Considerations . . . . . . . . . . . . . . . 7 66 4. DHCPv6 Encrypted DNS Option . . . . . . . . . . . . . . . . . 7 67 4.1. Option Format . . . . . . . . . . . . . . . . . . . . . . 7 68 4.2. DHCPv6 Client Behavior . . . . . . . . . . . . . . . . . 9 69 5. DHCPv4 Encrypted DNS Option . . . . . . . . . . . . . . . . . 9 70 5.1. Option Format . . . . . . . . . . . . . . . . . . . . . . 9 71 5.2. DHCPv4 Client Behavior . . . . . . . . . . . . . . . . . 11 72 6. IPv6 RA Encrypted DNS Option . . . . . . . . . . . . . . . . 12 73 6.1. Option Format . . . . . . . . . . . . . . . . . . . . . . 12 74 6.2. IPv6 Host Behavior . . . . . . . . . . . . . . . . . . . 14 75 7. Security Considerations . . . . . . . . . . . . . . . . . . . 14 76 7.1. Spoofing Attacks . . . . . . . . . . . . . . . . . . . . 14 77 7.2. Deletion Attacks . . . . . . . . . . . . . . . . . . . . 15 78 7.3. Passive Attacks . . . . . . . . . . . . . . . . . . . . . 15 79 7.4. Wireless Security - Authentication Attacks . . . . . . . 15 80 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16 81 8.1. DHCPv6 Option . . . . . . . . . . . . . . . . . . . . . . 16 82 8.2. DHCPv4 Option . . . . . . . . . . . . . . . . . . . . . . 16 83 8.3. Neighbor Discovery Option . . . . . . . . . . . . . . . . 17 84 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 17 85 10. Contributing Authors . . . . . . . . . . . . . . . . . . . . 17 86 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 18 87 11.1. Normative References . . . . . . . . . . . . . . . . . . 18 88 11.2. Informative References . . . . . . . . . . . . . . . . . 18 89 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 21 91 1. Introduction 93 This document focuses on the support of encrypted DNS such as DNS- 94 over-HTTPS (DoH) [RFC8484], DNS-over-TLS (DoT) [RFC7858], or DNS- 95 over-QUIC (DoQ) [I-D.ietf-dprive-dnsoquic] in local networks. 97 In particular, the document specifies how a local encrypted DNS 98 server can be discovered by connected hosts by means of DHCPv4 99 [RFC2132], DHCPv6 [RFC8415], and IPv6 Router Advertisement (RA) 100 [RFC4861] options. These options are designed to convey the 101 following information: the DNS Authentication Domain Name (ADN), a 102 list of IP addresses, and a set of service parameters. This 103 procedure is called Discovery of Network-designated Resolvers (DNR). 105 The options defined in this document can be deployed in a variety of 106 deployments (e.g., local networks with Customer Premises Equipment 107 (CPEs) that may or may not be managed by an Internet Service Provider 108 (ISP), local networks with or without DNS forwarders). It is out of 109 the scope of this document to provide an inventory of such 110 deployments. 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 DNR: refers to the Discovery of Network-designated Resolvers 126 procedure. 128 Encrypted DNS: refers to a scheme where DNS exchanges are 129 transported over an encrypted channel. Examples of encrypted DNS 130 are DoT, DoH, or DoQ. 132 Encrypted DNS options: refers to the options defined in Sections 4, 133 5, and 6. 135 DHCP: refers to both DHCPv4 and DHCPv6. 137 3. Overview 139 This document describes how a DNS client can discover local encrypted 140 DNS servers using DHCP (Sections 4 and 5) and Neighbor Discovery 141 protocol (Section 6): Encrypted DNS options. 143 These options configure an authentication domain name, a list of IPv6 144 addresses, and a set of service parameters of the encrypted DNS 145 server. More information about the design of these options is 146 provided in the following subsections. 148 3.1. Configuration Data for Encrypted DNS 150 In order to allow for PKIX-based authentication between a DNS client 151 and an encrypted DNS server, the Encrypted DNS options are designed 152 to include an authentication domain name. This ADN is presented as a 153 reference identifier for DNS authentication purposes. This design 154 accommodates the current best practices for issuing certificates as 155 per Section 1.7.2 of [RFC6125]: 157 | Some certification authorities issue server certificates based on 158 | IP addresses, but preliminary evidence indicates that such 159 | certificates are a very small percentage (less than 1%) of issued 160 | certificates. 162 To avoid adding a dependency on another server to resolve the ADN, 163 the Encrypted DNS options return the IP address(es) to locate the 164 encrypted DNS server. These encrypted DNS servers may be hosted on 165 the same or distinct IP addresses. Such a decision is deployment 166 specific. 168 In order to optimize the size of discovery messages when all DNS 169 servers terminate on the same IP address, early versions of this 170 document considered relying upon the discovery mechanisms specified 171 in [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 protocol (e.g., DoH 174 and DoT) to probe that list of IP addresses. To avoid such a 175 probing, the options defined in Sections 4, 5, and 6 associate an IP 176 address with an encrypted DNS protocol. No probing is required in 177 such a design. 179 A list of IP addresses to reach an encrypted DNS server may be 180 returned in an Encrypted DNS option to accommodate current 181 deployments relying upon primary and backup servers. Whether one or 182 more IP addresses are returned in an Encrypted DNS option is 183 deployment specific. For example, a router embedding a recursive 184 server or a forwarder has to include one single IP address pointing 185 to one of its LAN-facing interfaces. This IP address can be a 186 private IPv4 address, a link-local address, a Unique Local IPv6 187 unicast Address (ULA), or a Global Unicast Address (GUA). 189 If more than one IP address are to be returned in an Encrypted DNS 190 option, these addresses are ordered in the preference for use by the 191 client. 193 Because distinct encrypted DNS protocols may be provisioned by a 194 network (e.g., DoT, DoH, and DoQ) and that some of these protocols 195 may make use of customized port numbers instead of default ones, the 196 Encrypted DNS options are designed to return a set of service 197 parameters. These parameters are encoded following the same rules 198 for encoding SvcParams in Section 2.1 of [I-D.ietf-dnsop-svcb-https]. 199 This encoding approach may increase the size of the options but it 200 has the merit to rely upon an existing IANA registry and, thus, to 201 accommodate new encrypted DNS protocols and service parameters that 202 may be defined in the future. At least the following service 203 parameters are RECOMMENDED to be supported by a DNR implementation: 205 alpn: Used to indicate the set of supported protocols (Section 7.1 206 of [I-D.ietf-dnsop-svcb-https]). 208 port: Used to indicate the target port number for the encrypted DNS 209 connection (Section 7.2 of [I-D.ietf-dnsop-svcb-https]). 211 ech: Used to enable Encrypted ClientHello (ECH) (Section 7.3 of 212 [I-D.ietf-dnsop-svcb-https]). 214 dohpath: Used to supply a relative DoH URI Template (Section 5.1 of 215 [I-D.ietf-add-svcb-dns]). 217 A single option is used to convey both the ADN and IP addresses 218 because otherwise means to correlate an IP address with an ADN will 219 be required if, for example, more than one ADN is supported by the 220 network. 222 The DHCP options defined in Sections 4 and 5 follow the option 223 ordering guidelines in Section 17 of [RFC7227]. Likewise, the RA 224 option (Section 6) adheres to the recommendations in Section 9 of 225 [RFC4861]. 227 ServiceMode (Section 2.4.3 of [I-D.ietf-dnsop-svcb-https]) SHOULD be 228 used because the Encrypted DNS options are self-contained and do not 229 require any additional DNS queries. The reader may refer to 230 [RFC7969] for an overview of advanced capabilities that are supported 231 by DHCP servers to populate configuration data (e.g., issue DNS 232 queries). 234 In contexts where putting additional complexity on requesting hosts 235 is acceptable, returning an ADN only can be considered. The supplied 236 ADN will be processed by a host following the procedure in Section 5 237 of [I-D.ietf-add-ddr]. Note that this mode may be subject to active 238 attacks, which can be mitigated by DNSSEC. 240 Other mechanisms may be considered in other contexts (e.g., secure 241 discovery) for the provisioning of encrypted DNS servers. It is 242 RECOMMENDED that at least the following DNR information is made 243 available to a requesting host: 245 * A service priority whenever the discovery mechanism does not rely 246 on implicit ordering if multiple instances of the encrypted DNS 247 are used. 249 * An authentication domain name. 251 * A list of IP addresses to locate the encrypted DNS server. 253 * A set of service parameters. 255 3.2. Handling Configuration Data Conflicts 257 If the encrypted DNS is discovered by a host using both RA and DHCP, 258 the rules discussed in Section 5.3.1 of [RFC8106] MUST be followed. 260 DHCP/RA options to discover encrypted DNS servers (including, DoH URI 261 Templates) takes precedence over Discovery of Designated Resolvers 262 (DDR) [I-D.ietf-add-ddr] since DDR uses Do53 to an external DNS 263 resolver, which is susceptible to both internal and external attacks 264 whereas DHCP/RA is typically protected using the mechanisms discussed 265 in Section 7.1. 267 3.3. Connection Establishment 269 If the local DNS client supports one of the discovered Encrypted DNS 270 protocols identified by Application Layer Protocol Negotiation (ALPN) 271 protocol identifiers, the DNS client establishes an encrypted DNS 272 session following the order of the discovered servers. The client 273 follows the mechanism discussed in Section 8 of [RFC8310] to 274 authenticate the DNS server certificate using the authentication 275 domain name conveyed in the Encrypted DNS options. ALPN-related 276 considerations can be found in Section 6.1 of 277 [I-D.ietf-dnsop-svcb-https]. 279 3.4. Multihoming Considerations 281 Devices may be connected to multiple networks; each providing their 282 own DNS configuration using the discovery mechanisms specified in 283 this document. Nevertheless, it is out of the scope of this 284 specification to discuss DNS selection of multi-interface devices. 285 The reader may refer to [RFC6731] for a discussion of issues and an 286 example of DNS server selection for multi-interfaced devices. 288 4. DHCPv6 Encrypted DNS Option 290 4.1. Option Format 292 The format of the DHCPv6 Encrypted DNS option is shown in Figure 1. 294 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 295 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 296 | OPTION_V6_DNR | Option-length | 297 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 298 | Service Priority | ADN Length | 299 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 300 ~ authentication-domain-name ~ 301 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 302 | Addr Length | | 303 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 304 ~ ipv6-address(es) ~ 305 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 306 | | | 307 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 308 ~ Service Parameters (SvcParams) ~ 309 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 311 Figure 1: DHCPv6 Encrypted DNS Option 313 The fields of the option shown in Figure 1 are as follows: 315 Option-code: OPTION_V6_DNR (TBA1, see Section 8.1) 317 Option-length: Length of the enclosed data in octets. The option 318 length is ('ADN Length' + 4) when only an ADN is included in the 319 option. 321 Service Priority: The priority of this OPTION_V6_DNR instance 322 compared to other instances. This field is encoded following the 323 rules specified in Section 2.4.1 of [I-D.ietf-dnsop-svcb-https]. 325 ADN Length: Length of the authentication-domain-name field in 326 octets. 328 authentication-domain-name (variable length): A fully qualified 329 domain name of the encrypted DNS server. This field is formatted 330 as specified in Section 10 of [RFC8415]. 332 An example of the authentication-domain-name encoding is shown in 333 Figure 2. This example conveys the FQDN "doh1.example.com.", and 334 the resulting Option-length field is 18. 336 +------+------+------+------+------+------+------+------+------+ 337 | 0x04 | d | o | h | 1 | 0x07 | e | x | a | 338 +------+------+------+------+------+------+------+------+------+ 339 | m | p | l | e | 0x03 | c | o | m | 0x00 | 340 +------+------+------+------+------+------+------+------+------+ 342 Figure 2: An Example of the DNS authentication-domain-name 343 Encoding 345 Addr Length: Length of enclosed IPv6 addresses in octets. It MUST 346 be a multiple of 16 for ServiceMode. 348 ipv6-address(es) (variable length): Indicates one or more IPv6 349 addresses to reach the encrypted DNS server. An address can be 350 link-local, ULA, or GUA. The format of this field is shown in 351 Figure 3. 353 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 354 | | 355 | ipv6-address | 356 | | 357 | | 358 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 359 | ... | 360 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 362 Figure 3: Format of the IPv6 Addresses Field 364 Service Parameters (SvcParams) (variable length): Specifies a set of 365 service parameters that are encoded following the rules in 366 Section 2.1 of [I-D.ietf-dnsop-svcb-https]. Service parameters 367 may include, for example, a list of ALPN protocol identifiers or 368 alternate port numbers. The service parameters MUST NOT include 369 "ipv4hint" or "ipv6hint" SvcParams as they are superseded by the 370 included IP addresses. 372 If no port service parameter is included, this indicates that 373 default port numbers should be used. As a reminder, the default 374 port number is 853 for DoT, 443 for DoH, and 853 for DoQ. 376 The length of this field is ('Option-length' - 6 - 'ADN Length' - 377 'Addr Length'). 379 4.2. DHCPv6 Client Behavior 381 To discover an encrypted DNS server, the DHCPv6 client MUST include 382 OPTION_V6_DNR in an Option Request Option (ORO), as in Sections 383 18.2.1, 18.2.2, 18.2.4, 18.2.5, 18.2.6, and 21.7 of [RFC8415]. 385 The DHCPv6 client MUST be prepared to receive multiple instances of 386 the OPTION_V6_DNR option; each option is to be treated as a separate 387 encrypted DNS server. These instances SHOULD be processed following 388 their service priority (i.e., smaller service priority indicates a 389 higher preference). 391 The DHCPv6 client MUST silently discard multicast and host loopback 392 addresses conveyed in OPTION_V6_DNR. 394 5. DHCPv4 Encrypted DNS Option 396 5.1. Option Format 398 The format of the DHCPv4 Encrypted DNS option is illustrated in 399 Figure 4. 401 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 402 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 403 | TBA2 | Length | 404 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 405 | Service Priority | 406 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 407 | ADN Length | | 408 +-+-+-+-+-+-+-+-+ | 409 ~ authentication-domain-name ~ 410 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 411 | Addr Length | | 412 +-+-+-+-+-+-+-+-+ | 413 ~ IPv4 Address(es) ~ 414 | +-+-+-+-+-+-+-+-+ 415 | | | 416 +-+-+-+-+-+-+-+-+ | 417 ~Service Parameters (SvcParams) ~ 418 | | 419 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 421 Figure 4: DHCPv4 Encrypted DNS Option 423 The fields of the option shown in Figure 4 are as follows: 425 Code: OPTION_V4_DNR (TBA2, see Section 8.2). 427 Length: Indicates the length of the enclosed data in octets. The 428 option length is ('ADN Length' + 3) when only an ADN is included 429 in the option. 431 Service Priority: The priority of this OPTION_V4_DNR instance 432 compared to other instances. This field is encoded following the 433 rules specified in Section 2.4.1 of [I-D.ietf-dnsop-svcb-https]. 435 ADN Length: Indicates the length of the authentication-domain-name 436 in octets. 438 authentication-domain-name (variable length): Includes the 439 authentication domain name of the encrypted DNS server. This 440 field is formatted as specified in Section 10 of [RFC8415]. The 441 format of this field is shown in Figure 5. The values s1, s2, s3, 442 etc. represent the domain name labels in the domain name encoding. 444 +-----+-----+-----+-----+-----+-- 445 | s1 | s2 | s3 | s4 | s5 | ... 446 +-----+-----+-----+-----+-----+-- 447 authentication-domain-name 449 Figure 5: Format of the Authentication Domain Name Field 451 Addr Length: Indicates the length of included IPv4 addresses in 452 octets. It MUST be a multiple of 4 for ServiceMode. 454 IPv4 Address(es) (variable length): Indicates one or more IPv4 455 addresses to reach the encrypted DNS server. Both private and 456 public IPv4 addresses can be included in this field. The format 457 of this field is shown in Figure 6. This format assumes that an 458 IPv4 address is encoded as a1.a2.a3.a4. 460 0 8 16 24 32 40 48 461 +-----+-----+-----+-----+-----+-----+-- 462 | a1 | a2 | a3 | a4 | a1 | a2 | ... 463 +-----+-----+-----+-----+-----+-----+-- 464 IPv4 Address 1 IPv4 Address 2 ... 466 Figure 6: Format of the IPv4 Addresses Field 468 Service Paramters (SvcParams) (variable length): Specifies a set of 469 service parameters that are encoded following the rules in 470 Section 2.1 of [I-D.ietf-dnsop-svcb-https]. Service parameters 471 may include, for example, a list of ALPN protocol identifiers or 472 alternate port numbers. The service parameters MUST NOT include 473 "ipv4hint" or "ipv6hint" SvcParams as they are superseded by the 474 included IP addresses. 476 If no port service parameter is included, this indicates that 477 default port numbers should be used. 479 The length of this field is ('Option-length' - 4 - 'ADN Length' - 480 'Addr Length'). 482 OPTION_V4_DNR is a concatenation-requiring option. As such, the 483 mechanism specified in [RFC3396] MUST be used if OPTION_V4_DNR 484 exceeds the maximum DHCPv4 option size of 255 octets. 486 5.2. DHCPv4 Client Behavior 488 To discover an encrypted DNS server, the DHCPv4 client requests the 489 Encrypted DNS server by including OPTION_V4_DNR in a Parameter 490 Request List option [RFC2132]. 492 The DHCPv4 client MUST be prepared to receive multiple instances of 493 the OPTION_V4_DNR option; each option is to be treated as a separate 494 encrypted DNS server. These instances SHOULD be processed following 495 their service priority (i.e., smaller service priority indicates a 496 higher preference). 498 The DHCPv4 client MUST silently discard multicast and host loopback 499 addresses conveyed in OPTION_V4_DNR. 501 6. IPv6 RA Encrypted DNS Option 503 6.1. Option Format 505 This section defines a new Neighbor Discovery option [RFC4861]: IPv6 506 RA Encrypted DNS option. This option is useful in contexts similar 507 to those discussed in Section 1.1 of [RFC8106]. 509 The format of the IPv6 RA Encrypted DNS option is illustrated in 510 Figure 7. 512 0 1 2 3 513 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 514 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 515 | TBA3 | Length | Service Priority | 516 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 517 | Lifetime | 518 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 519 | ADN Length | | 520 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 521 ~ authentication-domain-name ~ 522 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 523 | Addr Length | | 524 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 525 ~ ipv6-address(es) ~ 526 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 527 | | SvcParams Length | 528 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 529 ~ Service Parameters (SvcParams) ~ 530 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 532 Figure 7: RA Encrypted DNS Option 534 The fields of the option shown in Figure 7 are as follows: 536 Type: 8-bit identifier of the Encrypted DNS option as assigned by 537 IANA (TBA3, see Section 8.3). 539 Length: 8-bit unsigned integer. The length of the option (including 540 the Type and Length fields) is in units of 8 octets. 542 Service Priority: The priority of this Encrypted DNS option instance 543 compared to other instances. This field is encoded following the 544 rules specified in Section 2.4.1 of [I-D.ietf-dnsop-svcb-https]. 546 Lifetime: 32-bit unsigned integer. The maximum time in seconds 547 (relative to the time the packet is received) over which the 548 discovered Authentication Domain Name is valid. 550 The value of Lifetime SHOULD by default be at least 3 * 551 MaxRtrAdvInterval, where MaxRtrAdvInterval is the maximum RA 552 interval as defined in [RFC4861]. 554 A value of all one bits (0xffffffff) represents infinity. 556 A value of zero means that this Authentication Domain Name MUST no 557 longer be used. 559 ADN Length: 16-bit unsigned integer. This field indicates the 560 length of the authentication-domain-name field in octets. 562 authentication-domain-name (variable length): The domain name of the 563 encrypted DNS server. This field is formatted as specified in 564 Section 10 of [RFC8415]. 566 Addr Length: 16-bit unsigned integer. This field indicates the 567 length of enclosed IPv6 addresses in octets. It MUST be a 568 multiple of 16 for ServiceMode. 570 ipv6-address(es) (variable length): One or more IPv6 addresses of 571 the encrypted DNS server. An address can be link-local, ULA, or 572 GUA. 574 All of the addresses share the same Lifetime value. Similar to 575 [RFC8106], if it is desirable to have different Lifetime values 576 per IP address, multiple Encrypted DNS options may be used. 578 The format of this field is shown in Figure 3. 580 SvcParams Length: 16-bit unsigned integer. This field indicates the 581 length of the Service Parameters field in octets. 583 Service Paramters (SvcParams) (variable length): Specifies a set of 584 service parameters that are encoded following the rules in 585 Section 2.1 of [I-D.ietf-dnsop-svcb-https]. Service parameters 586 may include, for example, a list of ALPN protocol identifiers or 587 alternate port numbers. The service parameters MUST NOT include 588 "ipv4hint" or "ipv6hint" SvcParams as they are superseded by the 589 included IP addresses. 591 If no port service parameter is included, this indicates that 592 default port numbers should be used. 594 The option MUST be padded with zeros so that the full enclosed data 595 is a multiple of 8 octets (Section 4.6 of [RFC4861]). 597 6.2. IPv6 Host Behavior 599 The procedure for DNS configuration is the same as it is with any 600 other Neighbor Discovery option [RFC4861]. In addition, the host 601 follows the procedure described in Section 5.3.1 of [RFC8106] with 602 the formatting requirements in Section 6.1 substituted for the length 603 validation. 605 The host MUST be prepared to receive multiple Encrypted DNS options 606 in RAs. These instances SHOULD be processed following their service 607 priority (i.e., smaller service priority indicates a higher 608 preference). 610 The host MUST silently discard multicast and host loopback addresses 611 conveyed in the Encrypted DNS options. 613 7. Security Considerations 615 7.1. Spoofing Attacks 617 DHCP/RA messages are not encrypted or protected against modification 618 within the LAN. Unless mitigated (described below), the content of 619 DHCP and RA messages can be spoofed or modified by active attackers, 620 such as compromised devices within the local network. An active 621 attacker (Section 3.3 of [RFC3552]) can spoof the DHCP/RA response to 622 provide the attacker's Encrypted DNS server. Note that such an 623 attacker can launch other attacks as discussed in Section 22 of 624 [RFC8415]. The attacker can get a domain name with a domain- 625 validated public certificate from a CA and host an Encrypted DNS 626 server. 628 Attacks of spoofed or modified DHCP responses and RA messages by 629 attackers within the local network may be mitigated by making use of 630 the following mechanisms: 632 * DHCPv6-Shield described in [RFC7610], the router (e.g., a border 633 router, a CPE) discards DHCP response messages received from any 634 local endpoint. 636 * RA-Guard described in [RFC7113], the router discards RAs messages 637 received from any local endpoint. 639 * Source Address Validation Improvement (SAVI) solution for DHCP 640 described in [RFC7513], the router filters packets with forged 641 source IP addresses. 643 The above mechanisms would ensure that the endpoint receives the 644 correct configuration information of the encrypted DNS servers 645 selected by the DHCP server (or RA sender), but cannot provide any 646 information about the DHCP server or the entity hosting the DHCP 647 server (or RA sender) . 649 Encrypted DNS sessions with rogue servers that spoof the IP address 650 of a DNS server will fail because the DNS client will fail to 651 authenticate that rogue server based upon PKIX authentication 652 [RFC6125], particularly the authentication domain name in the 653 Encrypted DNS Option. DNS clients that ignore authentication 654 failures and accept spoofed certificates will be subject to attacks 655 (e.g., redirect to malicious servers, intercept sensitive data). 657 Encrypted DNS connections received from outside the local network 658 MUST be discarded by the encrypted DNS forwarder in the CPE. This 659 behavior adheres to REQ#8 in [RFC6092]; it MUST apply for both IPv4 660 and IPv6. 662 7.2. Deletion Attacks 664 If the DHCP responses or RAs are dropped by the attacker, the client 665 can fallback to use a preconfigured encrypted DNS server. However, 666 the use of policies to select servers is out of the scope of this 667 document. 669 Note that deletion attack is not specific to DHCP/RA. 671 7.3. Passive Attacks 673 A passive attacker (Section 3.2 of [RFC3552]) can identify a host is 674 using DHCP/RA to discover an encrypted DNS server and can infer that 675 host is capable of using DoH/DoT/DoQ to encrypt DNS messages. 676 However, a passive attacker cannot spoof or modify DHCP/RA messages. 678 7.4. Wireless Security - Authentication Attacks 680 Wireless LAN (WLAN) as frequently deployed in local networks (e.g., 681 home networks) is vulnerable to various attacks (e.g., [Evil-Twin], 682 [Krack], [Dragonblood]). Because of these attacks, only 683 cryptographically authenticated communications are trusted on WLANs. 684 This means that an information (e.g., NTP server, DNS server, default 685 domain) provided by such networks via DHCP, DHCPv6, or RA are 686 untrusted because DHCP and RA messages are not authenticated. 688 If the pre-shared key is the same for all clients that connect to the 689 same WLAN, the shared key will be available to all nodes, including 690 attackers. As such, it is possible to mount an active on-path 691 attack. Man-in-the-middle attacks are possible within local networks 692 because such WLAN authentication lacks peer entity authentication. 694 This leads to the need for provisioning unique credentials for 695 different clients. Endpoints can be provisioned with unique 696 credentials (username and password, typically) provided by the local 697 network administrator to mutually authenticate to the local WLAN 698 Access Point (e.g., 802.1x Wireless User Authentication on OpenWRT 699 [dot1x], EAP-pwd [RFC8146]). Not all endpoint devices (e.g., IoT 700 devices) support 802.1x supplicant and need an alternate mechanism to 701 connect to the local network. To address this limitation, unique 702 pre-shared keys can be created for each such device and WPA-PSK is 703 used (e.g., [PSK]). 705 8. IANA Considerations 707 8.1. DHCPv6 Option 709 IANA is requested to assign the following new DHCPv6 Option Code in 710 the registry maintained in [DHCPV6]. 712 +=======+===============+============+===========+================+ 713 | Value | Description | Client ORO | Singleton | Reference | 714 | | | | Option | | 715 +=======+===============+============+===========+================+ 716 | TBA1 | OPTION_V6_DNR | Yes | No | [ThisDocument] | 717 +-------+---------------+------------+-----------+----------------+ 719 Table 1 721 8.2. DHCPv4 Option 723 IANA is requested to assign the following new DHCP Option Code in the 724 registry maintained in [BOOTP]. 726 +------+------------------+-------+----------------+----------------+ 727 | Tag | Name | Data | Meaning | Reference | 728 | | | Length| | | 729 +------+------------------+-------+----------------+----------------+ 730 | TBA2 | OPTION_V4_DNR | N | Encrypted DNS | [ThisDocument] | 731 | | | | Server | | 732 +------+------------------+-------+----------------+----------------+ 734 8.3. Neighbor Discovery Option 736 IANA is requested to assign the following new IPv6 Neighbor Discovery 737 Option type in the "IPv6 Neighbor Discovery Option Formats" sub- 738 registry under the "Internet Control Message Protocol version 6 739 (ICMPv6) Parameters" registry maintained in [ND]. 741 +======+==========================+================+ 742 | Type | Description | Reference | 743 +======+==========================+================+ 744 | TBA3 | DNS Encrypted DNS Option | [ThisDocument] | 745 +------+--------------------------+----------------+ 747 Table 2 749 9. Acknowledgements 751 Many thanks to Christian Jacquenet and Michael Richardson for the 752 review. 754 Thanks to Stephen Farrell, Martin Thomson, Vittorio Bertola, Stephane 755 Bortzmeyer, Ben Schwartz, Iain Sharp, and Chris Box for the comments. 757 Thanks to Mark Nottingham for the feedback on HTTP redirection that 758 was discussed in previous versions of this specification. 760 The use of DHCP to retrieve an authentication domain name was 761 discussed in Section 7.3.1 of [RFC8310] and 762 [I-D.pusateri-dhc-dns-driu]. 764 Thanks to Bernie Volz for the review of the DHCP part. 766 10. Contributing Authors 768 Nicolai Leymann 769 Deutsche Telekom 770 Germany 772 Email: n.leymann@telekom.de 774 Zhiwei Yan 775 CNNIC 776 No.4 South 4th Street, Zhongguancun 777 Beijing 100190 778 China 780 EMail: yan@cnnic.cn 782 11. References 784 11.1. Normative References 786 [I-D.ietf-dnsop-svcb-https] 787 Schwartz, B., Bishop, M., and E. Nygren, "Service binding 788 and parameter specification via the DNS (DNS SVCB and 789 HTTPS RRs)", Work in Progress, Internet-Draft, draft-ietf- 790 dnsop-svcb-https-08, 12 October 2021, 791 . 794 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 795 Requirement Levels", BCP 14, RFC 2119, 796 DOI 10.17487/RFC2119, March 1997, 797 . 799 [RFC2132] Alexander, S. and R. Droms, "DHCP Options and BOOTP Vendor 800 Extensions", RFC 2132, DOI 10.17487/RFC2132, March 1997, 801 . 803 [RFC3396] Lemon, T. and S. Cheshire, "Encoding Long Options in the 804 Dynamic Host Configuration Protocol (DHCPv4)", RFC 3396, 805 DOI 10.17487/RFC3396, November 2002, 806 . 808 [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, 809 "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, 810 DOI 10.17487/RFC4861, September 2007, 811 . 813 [RFC8106] Jeong, J., Park, S., Beloeil, L., and S. Madanapalli, 814 "IPv6 Router Advertisement Options for DNS Configuration", 815 RFC 8106, DOI 10.17487/RFC8106, March 2017, 816 . 818 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 819 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 820 May 2017, . 822 [RFC8415] Mrugalski, T., Siodelski, M., Volz, B., Yourtchenko, A., 823 Richardson, M., Jiang, S., Lemon, T., and T. Winters, 824 "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)", 825 RFC 8415, DOI 10.17487/RFC8415, November 2018, 826 . 828 11.2. Informative References 830 [BOOTP] "BOOTP Vendor Extensions and DHCP Options", 831 . 834 [DHCPV6] "DHCPv6 Option Codes", . 838 [dot1x] Cisco, "Basic 802.1x Wireless User Authentication", 839 . 842 [Dragonblood] 843 The Unicode Consortium, "Dragonblood: Analyzing the 844 Dragonfly Handshake of WPA3 and EAP-pwd", 845 . 847 [Evil-Twin] 848 The Unicode Consortium, "Evil twin (wireless networks)", 849 . 852 [I-D.ietf-add-ddr] 853 Pauly, T., Kinnear, E., Wood, C. A., McManus, P., and T. 854 Jensen, "Discovery of Designated Resolvers", Work in 855 Progress, Internet-Draft, draft-ietf-add-ddr-06, 4 April 856 2022, . 859 [I-D.ietf-add-svcb-dns] 860 Schwartz, B., "Service Binding Mapping for DNS Servers", 861 Work in Progress, Internet-Draft, draft-ietf-add-svcb-dns- 862 02, 1 February 2022, . 865 [I-D.ietf-dprive-dnsoquic] 866 Huitema, C., Dickinson, S., and A. Mankin, "DNS over 867 Dedicated QUIC Connections", Work in Progress, Internet- 868 Draft, draft-ietf-dprive-dnsoquic-11, 21 March 2022, 869 . 872 [I-D.pusateri-dhc-dns-driu] 873 Pusateri, T. and W. Toorop, "DHCPv6 Options for private 874 DNS Discovery", Work in Progress, Internet-Draft, draft- 875 pusateri-dhc-dns-driu-00, 2 July 2018, 876 . 879 [Krack] The Unicode Consortium, "Key Reinstallation Attacks", 880 2017, . 882 [ND] "IPv6 Neighbor Discovery Option Formats", 883 . 886 [PSK] Cisco, "Identity PSK Feature Deployment Guide", 887 . 891 [RFC3552] Rescorla, E. and B. Korver, "Guidelines for Writing RFC 892 Text on Security Considerations", BCP 72, RFC 3552, 893 DOI 10.17487/RFC3552, July 2003, 894 . 896 [RFC3646] Droms, R., Ed., "DNS Configuration options for Dynamic 897 Host Configuration Protocol for IPv6 (DHCPv6)", RFC 3646, 898 DOI 10.17487/RFC3646, December 2003, 899 . 901 [RFC6092] Woodyatt, J., Ed., "Recommended Simple Security 902 Capabilities in Customer Premises Equipment (CPE) for 903 Providing Residential IPv6 Internet Service", RFC 6092, 904 DOI 10.17487/RFC6092, January 2011, 905 . 907 [RFC6125] Saint-Andre, P. and J. Hodges, "Representation and 908 Verification of Domain-Based Application Service Identity 909 within Internet Public Key Infrastructure Using X.509 910 (PKIX) Certificates in the Context of Transport Layer 911 Security (TLS)", RFC 6125, DOI 10.17487/RFC6125, March 912 2011, . 914 [RFC6731] Savolainen, T., Kato, J., and T. Lemon, "Improved 915 Recursive DNS Server Selection for Multi-Interfaced 916 Nodes", RFC 6731, DOI 10.17487/RFC6731, December 2012, 917 . 919 [RFC7113] Gont, F., "Implementation Advice for IPv6 Router 920 Advertisement Guard (RA-Guard)", RFC 7113, 921 DOI 10.17487/RFC7113, February 2014, 922 . 924 [RFC7227] Hankins, D., Mrugalski, T., Siodelski, M., Jiang, S., and 925 S. Krishnan, "Guidelines for Creating New DHCPv6 Options", 926 BCP 187, RFC 7227, DOI 10.17487/RFC7227, May 2014, 927 . 929 [RFC7513] Bi, J., Wu, J., Yao, G., and F. Baker, "Source Address 930 Validation Improvement (SAVI) Solution for DHCP", 931 RFC 7513, DOI 10.17487/RFC7513, May 2015, 932 . 934 [RFC7610] Gont, F., Liu, W., and G. Van de Velde, "DHCPv6-Shield: 935 Protecting against Rogue DHCPv6 Servers", BCP 199, 936 RFC 7610, DOI 10.17487/RFC7610, August 2015, 937 . 939 [RFC7858] Hu, Z., Zhu, L., Heidemann, J., Mankin, A., Wessels, D., 940 and P. Hoffman, "Specification for DNS over Transport 941 Layer Security (TLS)", RFC 7858, DOI 10.17487/RFC7858, May 942 2016, . 944 [RFC7969] Lemon, T. and T. Mrugalski, "Customizing DHCP 945 Configuration on the Basis of Network Topology", RFC 7969, 946 DOI 10.17487/RFC7969, October 2016, 947 . 949 [RFC8146] Harkins, D., "Adding Support for Salted Password Databases 950 to EAP-pwd", RFC 8146, DOI 10.17487/RFC8146, April 2017, 951 . 953 [RFC8310] Dickinson, S., Gillmor, D., and T. Reddy, "Usage Profiles 954 for DNS over TLS and DNS over DTLS", RFC 8310, 955 DOI 10.17487/RFC8310, March 2018, 956 . 958 [RFC8484] Hoffman, P. and P. McManus, "DNS Queries over HTTPS 959 (DoH)", RFC 8484, DOI 10.17487/RFC8484, October 2018, 960 . 962 [RFC8499] Hoffman, P., Sullivan, A., and K. Fujiwara, "DNS 963 Terminology", BCP 219, RFC 8499, DOI 10.17487/RFC8499, 964 January 2019, . 966 Authors' Addresses 968 Mohamed Boucadair (editor) 969 Orange 970 35000 Rennes 971 France 972 Email: mohamed.boucadair@orange.com 974 Tirumaleswar Reddy (editor) 975 Akamai 976 Embassy Golf Link Business Park 977 Bangalore 560071 978 Karnataka 979 India 980 Email: kondtir@gmail.com 982 Dan Wing 983 Citrix Systems, Inc. 984 United States of America 985 Email: dwing-ietf@fuggles.com 987 Neil Cook 988 Open-Xchange 989 United Kingdom 990 Email: neil.cook@noware.co.uk 992 Tommy Jensen 993 Microsoft 994 United States of America 995 Email: tojens@microsoft.com