idnits 2.17.1 draft-ietf-add-dnr-06.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 (22 March 2022) is 764 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 688, 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-05 == 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: 23 September 2022 Akamai 6 D. Wing 7 Citrix 8 N. Cook 9 Open-Xchange 10 T. Jensen 11 Microsoft 12 22 March 2022 14 DHCP and Router Advertisement Options for the Discovery of Network- 15 designated Resolvers (DNR) 16 draft-ietf-add-dnr-06 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 23 September 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 . . . . . . . . . . 5 64 3.3. Connection Establishment . . . . . . . . . . . . . . . . 5 65 3.4. Multihoming Considerations . . . . . . . . . . . . . . . 6 66 4. DHCPv6 Encrypted DNS Option . . . . . . . . . . . . . . . . . 6 67 4.1. Option Format . . . . . . . . . . . . . . . . . . . . . . 6 68 4.2. DHCPv6 Client Behavior . . . . . . . . . . . . . . . . . 8 69 5. DHCPv4 Encrypted DNS Option . . . . . . . . . . . . . . . . . 8 70 5.1. Option Format . . . . . . . . . . . . . . . . . . . . . . 8 71 5.2. DHCPv4 Client Behavior . . . . . . . . . . . . . . . . . 10 72 6. IPv6 RA Encrypted DNS Option . . . . . . . . . . . . . . . . 10 73 6.1. Option Format . . . . . . . . . . . . . . . . . . . . . . 10 74 6.2. IPv6 Host Behavior . . . . . . . . . . . . . . . . . . . 12 75 7. Security Considerations . . . . . . . . . . . . . . . . . . . 12 76 7.1. Spoofing Attacks . . . . . . . . . . . . . . . . . . . . 13 77 7.2. Deletion Attacks . . . . . . . . . . . . . . . . . . . . 14 78 7.3. Passive Attacks . . . . . . . . . . . . . . . . . . . . . 14 79 7.4. Wireless Security - Authentication Attacks . . . . . . . 14 80 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 81 8.1. DHCPv6 Option . . . . . . . . . . . . . . . . . . . . . . 15 82 8.2. DHCPv4 Option . . . . . . . . . . . . . . . . . . . . . . 15 83 8.3. Neighbor Discovery Option . . . . . . . . . . . . . . . . 15 84 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 15 85 10. Contributing Authors . . . . . . . . . . . . . . . . . . . . 16 86 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 16 87 11.1. Normative References . . . . . . . . . . . . . . . . . . 16 88 11.2. Informative References . . . . . . . . . . . . . . . . . 17 89 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 20 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. 104 The options defined in this document can be deployed in a variety of 105 deployments (e.g., local networks with Customer Premises Equipment 106 (CPEs) that may or may not be managed by an Internet Service Provider 107 (ISP), local networks with or without DNS forwarders). It is out of 108 the scope of this document to provide an inventory of such 109 deployments. 111 2. Terminology 113 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 114 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 115 "OPTIONAL" in this document are to be interpreted as described in BCP 116 14 [RFC2119] [RFC8174] when, and only when, they appear in all 117 capitals, as shown here. 119 This document makes use of the terms defined in [RFC8499]. The 120 following additional terms are used: 122 Do53: refers to unencrypted DNS. 124 Encrypted DNS: refers to a scheme where DNS exchanges are 125 transported over an encrypted channel. Examples of encrypted DNS 126 are DoT, DoH, or DoQ. 128 Encrypted DNS options: refers to the options defined in Sections 4, 129 5, and 6. 131 DHCP: refers to both DHCPv4 and DHCPv6. 133 3. Overview 135 This document describes how a DNS client can discover local encrypted 136 DNS servers using DHCP (Sections 4 and 5) and Neighbor Discovery 137 protocol (Section 6): Encrypted DNS options. 139 These options configure an authentication domain name, a list of IPv6 140 addresses, and a set of service parameters of the encrypted DNS 141 server. More information about the design of these options is 142 provided in the following subsections. 144 3.1. Configuration Data for Encrypted DNS 146 In order to allow for PKIX-based authentication between a DNS client 147 and an encrypted DNS server, the Encrypted DNS options are designed 148 to include an authentication domain name. This ADN is presented as a 149 reference identifier for DNS authentication purposes. This design 150 accommodates the current best practices for issuing certificates as 151 per Section 1.7.2 of [RFC6125]: 153 | Some certification authorities issue server certificates based on 154 | IP addresses, but preliminary evidence indicates that such 155 | certificates are a very small percentage (less than 1%) of issued 156 | certificates. 158 To avoid adding a dependency on another server to resolve the ADN, 159 the Encrypted DNS options return the IP address(es) to locate the 160 encrypted DNS server. These encrypted DNS servers may be hosted on 161 the same or distinct IP addresses. Such a decision is deployment 162 specific. 164 In order to optimize the size of discovery messages when all DNS 165 servers terminate on the same IP address, early versions of this 166 document considered relying upon the discovery mechanisms specified 167 in [RFC2132][RFC3646][RFC8106] to retrieve a list of IP addresses to 168 reach their DNS servers. Nevertheless, this approach requires a 169 client that supports more than one encrypted DNS protocol (e.g., DoH 170 and DoT) to probe that list of IP addresses. To avoid such a 171 probing, the options defined in Sections 4, 5, and 6 associate an IP 172 address with an encrypted DNS protocol. No probing is required in 173 such a design. 175 A list of IP addresses to reach an encrypted DNS server may be 176 returned in an Encrypted DNS option to accommodate current 177 deployments relying upon primary and backup servers. Whether one or 178 more IP addresses are returned in an Encrypted DNS option is 179 deployment specific. For example, a router embedding a recursive 180 server or a forwarder has to include one single IP address pointing 181 to one of its LAN-facing interfaces. This IP address can be a 182 private IPv4 address, a link-local address, a Unique Local IPv6 183 unicast Address (ULA), or a Global Unicast Address (GUA). 185 If more than one IP address are to be returned in an Encrypted DNS 186 option, these addresses are ordered in the preference for use by the 187 client. 189 Because distinct encrypted DNS protocols may be provisioned by a 190 network (e.g., DoT, DoH, and DoQ) and that some of these protocols 191 may make use of customized port numbers instead of default ones, the 192 Encrypted DNS options are designed to return a set of service 193 parameters. These parameters are encoded following the same rules 194 for encoding SvcParams in Section 2.1 of [I-D.ietf-dnsop-svcb-https]. 195 This encoding approach may increase the size of the options but it 196 has the merit to rely upon an existing IANA registry and, thus, to 197 accommodate new encrypted DNS protocols and service parameters that 198 may be defined in the future. For example, "dohpath" service 199 parameter (Section 5.1 of [I-D.ietf-add-svcb-dns]) supplies a 200 relative DoH URI Template. 202 A single option is used to convey both the ADN and IP addresses 203 because otherwise means to correlate an IP address with an ADN will 204 be required if, for example, more than one ADN is supported by the 205 network. 207 The DHCP options defined in Sections 4 and 5 follow the option 208 ordering guidelines in Section 17 of [RFC7227]. 210 AliasMode (Section 2.4.2 of [I-D.ietf-dnsop-svcb-https]) is not 211 supported because such a mode will trigger additional Do53 queries 212 while the data can be supplied directly by DHCP servers. The reader 213 may refer to [RFC7969] for an overview of advanced capabilities that 214 are supported by DHCP servers to populate configuration data (e.g., 215 issue DNS queries). 217 3.2. Handling Configuration Data Conflicts 219 If the encrypted DNS is discovered by a host using both RA and DHCP, 220 the rules discussed in Section 5.3.1 of [RFC8106] MUST be followed. 222 DHCP/RA options to discover encrypted DNS servers (including, DoH URI 223 Templates) takes precedence over DDR [I-D.ietf-add-ddr] since DDR 224 uses Do53 to an external DNS resolver, which is susceptible to both 225 internal and external attacks whereas DHCP/RA is typically protected 226 using the mechanisms discussed in Section 7.1. 228 3.3. Connection Establishment 230 If the local DNS client supports one of the discovered Encrypted DNS 231 protocols identified by Application Layer Protocol Negotiation (ALPN) 232 protocol identifiers, the DNS client establishes an encrypted DNS 233 session following the order of the discovered servers. The client 234 follows the mechanism discussed in Section 8 of [RFC8310] to 235 authenticate the DNS server certificate using the authentication 236 domain name conveyed in the Encrypted DNS options. ALPN-related 237 considerations can be found in Section 6.1 of 238 [I-D.ietf-dnsop-svcb-https]. 240 3.4. Multihoming Considerations 242 Devices may be connected to multiple networks; each providing their 243 own DNS configuration using the discovery mechanisms specified in 244 this document. Nevertheless, it is out of the scope of this 245 specification to discuss DNS selection of multi-interface devices. 246 The reader may refer to [RFC6731] for a discussion of issues and an 247 example of DNS server selection for multi-interfaced devices. 249 4. DHCPv6 Encrypted DNS Option 251 4.1. Option Format 253 The format of the DHCPv6 Encrypted DNS option is shown in Figure 1. 255 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 256 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 257 | OPTION_V6_DNR | Option-length | 258 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 259 | Service Priority | Addr Length | 260 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 261 ~ ipv6-address(es) ~ 262 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 263 | ADN Length | | 264 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + 265 ~ authentication-domain-name ~ 266 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 267 ~ Service Parameters (SvcParams) ~ 268 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 270 Figure 1: DHCPv6 Encrypted DNS Option 272 The fields of the option shown in Figure 1 are as follows: 274 Option-code: OPTION_V6_DNR (TBA1, see Section 8.1) 276 Option-length: Length of the enclosed data in octets. 278 Service Priority: The priority of this OPTION_V6_DNR instance 279 compared to other instances. This field is encoded following the 280 rules specified in Section 2.4.1 of [I-D.ietf-dnsop-svcb-https]. 281 AliasMode (Section 2.4.2 of [I-D.ietf-dnsop-svcb-https]) is not 282 supported. As such, this field MUST NOT be set to 0. 284 Addr Length: Length of enclosed IPv6 addresses in octets. It MUST 285 be a multiple of 16. 287 ipv6-address(es) (variable length): Indicates one or more IPv6 288 addresses to reach the encrypted DNS server. An address can be 289 link-local, ULA, or GUA. The format of this field is shown in 290 Figure 2. 292 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 293 | | 294 | ipv6-address | 295 | | 296 | | 297 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 298 | ... | 299 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 301 Figure 2: Format of the IPv6 Addresses Field 303 ADN Length: Length of the authentication-domain-name field in 304 octets. 306 authentication-domain-name (variable length): A fully qualified 307 domain name of the encrypted DNS server. This field is formatted 308 as specified in Section 10 of [RFC8415]. 310 An example of the authentication-domain-name encoding is shown in 311 Figure 3. This example conveys the FQDN "doh1.example.com.", and 312 the resulting Option-length field is 18. 314 +------+------+------+------+------+------+------+------+------+ 315 | 0x04 | d | o | h | 1 | 0x07 | e | x | a | 316 +------+------+------+------+------+------+------+------+------+ 317 | m | p | l | e | 0x03 | c | o | m | 0x00 | 318 +------+------+------+------+------+------+------+------+------+ 320 Figure 3: An Example of the DNS authentication-domain-name 321 Encoding 323 Service Parameters (SvcParams) (variable length): Specifies a set of 324 service parameters that are encoded following the rules in 325 Section 2.1 of [I-D.ietf-dnsop-svcb-https]. Service parameters 326 may include, for example, a list of ALPN protocol identifiers or 327 alternate port numbers. The service parameters MUST NOT include 328 "ipv4hint" or "ipv6hint" SvcParams as they are superseded by the 329 included IP addresses. 331 If no port service parameter is included, this indicates that 332 default port numbers should be used. As a reminder, the default 333 port number is 853 for DoT, 443 for DoH, and 853 for DoQ. 335 The length of this field is ('Option-length' - 6 - 'ADN Length' - 336 'Addr Length'). 338 4.2. DHCPv6 Client Behavior 340 To discover an encrypted DNS server, the DHCPv6 client MUST include 341 OPTION_V6_DNR in an Option Request Option (ORO), as in Sections 342 18.2.1, 18.2.2, 18.2.4, 18.2.5, 18.2.6, and 21.7 of [RFC8415]. 344 The DHCP client MUST be prepared to receive multiple instances of the 345 OPTION_V6_DNR option; each option is to be treated as a separate 346 encrypted DNS server. These instances SHOULD be processed following 347 their service priority (i.e., smaller service priority indicates a 348 higher preference). 350 The DHCPv6 client MUST silently discard multicast and host loopback 351 addresses conveyed in OPTION_V6_DNR. 353 5. DHCPv4 Encrypted DNS Option 355 5.1. Option Format 357 The format of the DHCPv4 Encrypted DNS option is illustrated in 358 Figure 4. 360 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 361 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 362 | TBA2 | Length | 363 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 364 | Service Priority | 365 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 366 | Addr Length | | 367 +-+-+-+-+-+-+-+-+ + 368 ~ IPv4 Address(es) ~ 369 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 370 | ADN Length | | 371 +-+-+-+-+-+-+-+-+ + 372 ~ authentication-domain-name ~ 373 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 374 ~Service Parameters (SvcParams) ~ 375 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 377 Figure 4: DHCPv4 Encrypted DNS Option 379 The fields of the option shown in Figure 4 are as follows: 381 Code: OPTION_V4_DNR (TBA2, see Section 8.2). 383 Length: Indicates the length of the enclosed data in octets. 385 Service Priority: The priority of this OPTION_V4_DNR instance 386 compared to other instances. This field is encoded following the 387 rules specified in Section 2.4.1 of [I-D.ietf-dnsop-svcb-https]. 388 It MUST NOT be set to 0. 390 Addr Length: Indicates the length of included IPv4 addresses in 391 octets. It MUST be a multiple of 4. 393 IPv4 Address(es) (variable length): Indicates one or more IPv4 394 addresses to reach the encrypted DNS server. Both private and 395 public IPv4 addresses can be included in this field. The format 396 of this field is shown in Figure 5. This format assumes that an 397 IPv4 address is encoded as a1.a2.a3.a4. 399 0 8 16 24 32 40 48 400 +-----+-----+-----+-----+-----+-----+-- 401 | a1 | a2 | a3 | a4 | a1 | a2 | ... 402 +-----+-----+-----+-----+-----+-----+-- 403 IPv4 Address 1 IPv4 Address 2 ... 405 Figure 5: Format of the IPv4 Addresses Field 407 ADN Length: Indicates the length of the authentication-domain-name 408 in octets. 410 authentication-domain-name (variable length): Includes the 411 authentication domain name of the encrypted DNS server. This 412 field is formatted as specified in Section 10 of [RFC8415]. The 413 format of this field is shown in Figure 6. The values s1, s2, s3, 414 etc. represent the domain name labels in the domain name encoding. 416 +-----+-----+-----+-----+-----+-- 417 | s1 | s2 | s3 | s4 | s5 | ... 418 +-----+-----+-----+-----+-----+-- 419 authentication-domain-name 421 Figure 6: Format of the Authentication Domain Name Field 423 Service Paramters (SvcParams) (variable length): Specifies a set of 424 service parameters that are encoded following the rules in 425 Section 2.1 of [I-D.ietf-dnsop-svcb-https]. Service parameters 426 may include, for example, a list of ALPN protocol identifiers or 427 alternate port numbers. The service parameters MUST NOT include 428 "ipv4hint" or "ipv6hint" SvcParams as they are superseded by the 429 included IP addresses. 431 If no port service parameter is included, this indicates that 432 default port numbers should be used. 434 The length of this field is ('Option-length' - 4 - 'ADN Length' - 435 'Addr Length'). 437 OPTION_V4_DNR is a concatenation-requiring option. As such, the 438 mechanism specified in [RFC3396] MUST be used if OPTION_V4_DNR 439 exceeds the maximum DHCPv4 option size of 255 octets. 441 5.2. DHCPv4 Client Behavior 443 To discover an encrypted DNS server, the DHCPv4 client requests the 444 Encrypted DNS server by including OPTION_V4_DNR in a Parameter 445 Request List option [RFC2132]. 447 The DHCPv4 client MUST be prepared to receive multiple instances of 448 the OPTION_V4_DNR option; each option is to be treated as a separate 449 encrypted DNS server. These instances SHOULD be processed following 450 their service priority (i.e., smaller service priority indicates a 451 higher preference). 453 The DHCPv4 client MUST silently discard multicast and host loopback 454 addresses conveyed in OPTION_V4_DNR. 456 6. IPv6 RA Encrypted DNS Option 458 6.1. Option Format 460 This section defines a new Neighbor Discovery option [RFC4861]: IPv6 461 RA Encrypted DNS option. This option is useful in contexts similar 462 to those discussed in Section 1.1 of [RFC8106]. 464 The format of the IPv6 RA Encrypted DNS option is illustrated in 465 Figure 7. 467 0 1 2 3 468 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 469 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 470 | TBA3 | Length | Addr Length | 471 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 472 | Lifetime | 473 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 474 ~ ipv6-address(es) ~ 475 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 476 | ADN Length | | 477 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + 478 ~ authentication-domain-name ~ 479 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 480 | SvcParams Length | | 481 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + 482 ~ Service Parameters (SvcParams) ~ 483 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 485 Figure 7: RA Encrypted DNS Option 487 The fields of the option shown in Figure 7 are as follows: 489 Type: 8-bit identifier of the Encrypted DNS Option as assigned by 490 IANA (TBA3, see Section 8.3). 492 Length: 8-bit unsigned integer. The length of the option (including 493 the Type and Length fields) is in units of 8 octets. 495 Addr Length: 16-bit unsigned integer. This field indicates the 496 length of enclosed IPv6 addresses in octets. It MUST be a 497 multiple of 16. 499 Lifetime: 32-bit unsigned integer. The maximum time in seconds 500 (relative to the time the packet is received) over which the 501 discovered Authentication Domain Name is valid. 503 The value of Lifetime SHOULD by default be at least 3 * 504 MaxRtrAdvInterval, where MaxRtrAdvInterval is the maximum RA 505 interval as defined in [RFC4861]. 507 A value of all one bits (0xffffffff) represents infinity. 509 A value of zero means that this Authentication Domain Name MUST no 510 longer be used. 512 ipv6-address(es) (variable length): One or more IPv6 addresses of 513 the encrypted DNS server. An address can be link-local, ULA, or 514 GUA. 516 All of the addresses share the same Lifetime value. Similar to 517 [RFC8106], if it is desirable to have different Lifetime values 518 per IP address, multiple Encrypted DNS options may be used. 520 The format of this field is shown in Figure 2. 522 ADN Length: 16-bit unsigned integer. This field indicates the 523 length of the authentication-domain-name field in octets. 525 authentication-domain-name (variable length): The domain name of the 526 encrypted DNS server. This field is formatted as specified in 527 Section 10 of [RFC8415]. 529 SvcParams Length: 16-bit unsigned integer. This field indicates the 530 length of the Service Parameters field in octets. 532 Service Paramters (SvcParams) (variable length): Specifies a set of 533 service parameters that are encoded following the rules in 534 Section 2.1 of [I-D.ietf-dnsop-svcb-https]. Service parameters 535 may include, for example, a list of ALPN protocol identifiers or 536 alternate port numbers. The service parameters MUST NOT include 537 "ipv4hint" or "ipv6hint" SvcParams as they are superseded by the 538 included IP addresses. 540 If no port service parameter is included, this indicates that 541 default port numbers should be used. 543 The option MUST be padded with zeros so that the full enclosed data 544 is a multiple of 8 octets (Section 4.6 of [RFC4861]). 546 Multiple Encrypted DNS options may be returned to an IPv6 host. 547 Similar to [RFC8106], these options are ordered in the preference for 548 use by the IPv6 host. 550 6.2. IPv6 Host Behavior 552 The procedure for DNS configuration is the same as it is with any 553 other Neighbor Discovery option [RFC4861]. In addition, the host 554 follows the procedure described in Section 5.3.1 of [RFC8106]. 556 The host MUST silently discard multicast and host loopback addresses 557 conveyed in the Encrypted DNS options. 559 7. Security Considerations 560 7.1. Spoofing Attacks 562 DHCP/RA messages are not encrypted or protected against modification 563 within the LAN. Unless mitigated (described below), the content of 564 DHCP and RA messages can be spoofed or modified by active attackers, 565 such as compromised devices within the local network. An active 566 attacker (Section 3.3 of [RFC3552]) can spoof the DHCP/RA response to 567 provide the attacker's Encrypted DNS server. Note that such an 568 attacker can launch other attacks as discussed in Section 22 of 569 [RFC8415]. The attacker can get a domain name with a domain- 570 validated public certificate from a CA and host an Encrypted DNS 571 server. 573 Attacks of spoofed or modified DHCP responses and RA messages by 574 attackers within the local network may be mitigated by making use of 575 the following mechanisms: 577 * DHCPv6-Shield described in [RFC7610], the router (e.g., a border 578 router, a CPE) discards DHCP response messages received from any 579 local endpoint. 581 * RA-Guard described in [RFC7113], the router discards RAs messages 582 received from any local endpoint. 584 * Source Address Validation Improvement (SAVI) solution for DHCP 585 described in [RFC7513], the router filters packets with forged 586 source IP addresses. 588 The above mechanisms would ensure that the endpoint receives the 589 correct configuration information of the encrypted DNS servers 590 selected by the DHCP server (or RA sender), but cannot provide any 591 information about the DHCP server or the entity hosting the DHCP 592 server (or RA sender) . 594 Encrypted DNS sessions with rogue servers that spoof the IP address 595 of a DNS server will fail because the DNS client will fail to 596 authenticate that rogue server based upon PKIX authentication 597 [RFC6125], particularly the authentication domain name in the 598 Encrypted DNS Option. DNS clients that ignore authentication 599 failures and accept spoofed certificates will be subject to attacks 600 (e.g., redirect to malicious servers, intercept sensitive data). 602 Encrypted DNS connections received from outside the local network 603 MUST be discarded by the encrypted DNS forwarder in the CPE. This 604 behavior adheres to REQ#8 in [RFC6092]; it MUST apply for both IPv4 605 and IPv6. 607 7.2. Deletion Attacks 609 If the DHCP responses or RAs are dropped by the attacker, the client 610 can fallback to use a preconfigured encrypted DNS server. However, 611 the use of policies to select servers is out of the scope of this 612 document. 614 Note that deletion attack is not specific to DHCP/RA. 616 7.3. Passive Attacks 618 A passive attacker (Section 3.2 of [RFC3552]) can identify a host is 619 using DHCP/RA to discover an encrypted DNS server and can infer that 620 host is capable of using DoH/DoT/DoQ to encrypt DNS messages. 621 However, a passive attacker cannot spoof or modify DHCP/RA messages. 623 7.4. Wireless Security - Authentication Attacks 625 Wireless LAN (WLAN) as frequently deployed in local networks (e.g., 626 home networks) is vulnerable to various attacks (e.g., [Evil-Twin], 627 [Krack], [Dragonblood]). Because of these attacks, only 628 cryptographically authenticated communications are trusted on WLANs. 629 This means that an information (e.g., NTP server, DNS server, default 630 domain) provided by such networks via DHCP, DHCPv6, or RA are 631 untrusted because DHCP and RA messages are not authenticated. 633 If the pre-shared key is the same for all clients that connect to the 634 same WLAN, the shared key will be available to all nodes, including 635 attackers. As such, it is possible to mount an active on-path 636 attack. Man-in-the-middle attacks are possible within local networks 637 because such WLAN authentication lacks peer entity authentication. 639 This leads to the need for provisioning unique credentials for 640 different clients. Endpoints can be provisioned with unique 641 credentials (username and password, typically) provided by the local 642 network administrator to mutually authenticate to the local WLAN 643 Access Point (e.g., 802.1x Wireless User Authentication on OpenWRT 644 [dot1x], EAP-pwd [RFC8146]). Not all endpoint devices (e.g., IoT 645 devices) support 802.1x supplicant and need an alternate mechanism to 646 connect to the local network. To address this limitation, unique 647 pre-shared keys can be created for each such device and WPA-PSK is 648 used (e.g., [PSK]). 650 8. IANA Considerations 651 8.1. DHCPv6 Option 653 IANA is requested to assign the following new DHCPv6 Option Code in 654 the registry maintained in [DHCPV6]. 656 +=======+===============+============+===========+================+ 657 | Value | Description | Client ORO | Singleton | Reference | 658 | | | | Option | | 659 +=======+===============+============+===========+================+ 660 | TBA1 | OPTION_V6_DNR | Yes | No | [ThisDocument] | 661 +-------+---------------+------------+-----------+----------------+ 663 Table 1 665 8.2. DHCPv4 Option 667 IANA is requested to assign the following new DHCP Option Code in the 668 registry maintained in [BOOTP]. 670 +------+------------------+-------+----------------+----------------+ 671 | Tag | Name | Data | Meaning | Reference | 672 | | | Length| | | 673 +------+------------------+-------+----------------+----------------+ 674 | TBA2 | OPTION_V4_DNR | N | Encrypted DNS | [ThisDocument] | 675 | | | | Server | | 676 +------+------------------+-------+----------------+----------------+ 678 8.3. Neighbor Discovery Option 680 IANA is requested to assign the following new IPv6 Neighbor Discovery 681 Option type in the "IPv6 Neighbor Discovery Option Formats" sub- 682 registry under the "Internet Control Message Protocol version 6 683 (ICMPv6) Parameters" registry maintained in [ND]. 685 +======+==========================+================+ 686 | Type | Description | Reference | 687 +======+==========================+================+ 688 | TBA3 | DNS Encrypted DNS Option | [ThisDocument] | 689 +------+--------------------------+----------------+ 691 Table 2 693 9. Acknowledgements 695 Many thanks to Christian Jacquenet and Michael Richardson for the 696 review. 698 Thanks to Stephen Farrell, Martin Thomson, Vittorio Bertola, Stephane 699 Bortzmeyer, Ben Schwartz, Iain Sharp, and Chris Box for the comments. 701 Thanks to Mark Nottingham for the feedback on HTTP redirection. 703 The use of DHCP to retrieve an authentication domain name was 704 discussed in Section 7.3.1 of [RFC8310] and 705 [I-D.pusateri-dhc-dns-driu]. 707 Thanks to Bernie Volz for the review of the DHCP part. 709 10. Contributing Authors 711 Nicolai Leymann 712 Deutsche Telekom 713 Germany 715 Email: n.leymann@telekom.de 717 Zhiwei Yan 718 CNNIC 719 No.4 South 4th Street, Zhongguancun 720 Beijing 100190 721 China 723 EMail: yan@cnnic.cn 725 11. References 727 11.1. Normative References 729 [I-D.ietf-dnsop-svcb-https] 730 Schwartz, B., Bishop, M., and E. Nygren, "Service binding 731 and parameter specification via the DNS (DNS SVCB and 732 HTTPS RRs)", Work in Progress, Internet-Draft, draft-ietf- 733 dnsop-svcb-https-08, 12 October 2021, 734 . 737 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 738 Requirement Levels", BCP 14, RFC 2119, 739 DOI 10.17487/RFC2119, March 1997, 740 . 742 [RFC2132] Alexander, S. and R. Droms, "DHCP Options and BOOTP Vendor 743 Extensions", RFC 2132, DOI 10.17487/RFC2132, March 1997, 744 . 746 [RFC3396] Lemon, T. and S. Cheshire, "Encoding Long Options in the 747 Dynamic Host Configuration Protocol (DHCPv4)", RFC 3396, 748 DOI 10.17487/RFC3396, November 2002, 749 . 751 [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, 752 "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, 753 DOI 10.17487/RFC4861, September 2007, 754 . 756 [RFC8106] Jeong, J., Park, S., Beloeil, L., and S. Madanapalli, 757 "IPv6 Router Advertisement Options for DNS Configuration", 758 RFC 8106, DOI 10.17487/RFC8106, March 2017, 759 . 761 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 762 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 763 May 2017, . 765 [RFC8415] Mrugalski, T., Siodelski, M., Volz, B., Yourtchenko, A., 766 Richardson, M., Jiang, S., Lemon, T., and T. Winters, 767 "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)", 768 RFC 8415, DOI 10.17487/RFC8415, November 2018, 769 . 771 11.2. Informative References 773 [BOOTP] "BOOTP Vendor Extensions and DHCP Options", 774 . 777 [DHCPV6] "DHCPv6 Option Codes", . 781 [dot1x] Cisco, "Basic 802.1x Wireless User Authentication", 782 . 785 [Dragonblood] 786 The Unicode Consortium, "Dragonblood: Analyzing the 787 Dragonfly Handshake of WPA3 and EAP-pwd", 788 . 790 [Evil-Twin] 791 The Unicode Consortium, "Evil twin (wireless networks)", 792 . 795 [I-D.ietf-add-ddr] 796 Pauly, T., Kinnear, E., Wood, C. A., McManus, P., and T. 797 Jensen, "Discovery of Designated Resolvers", Work in 798 Progress, Internet-Draft, draft-ietf-add-ddr-05, 31 799 January 2022, . 802 [I-D.ietf-add-svcb-dns] 803 Schwartz, B., "Service Binding Mapping for DNS Servers", 804 Work in Progress, Internet-Draft, draft-ietf-add-svcb-dns- 805 02, 1 February 2022, . 808 [I-D.ietf-dprive-dnsoquic] 809 Huitema, C., Dickinson, S., and A. Mankin, "DNS over 810 Dedicated QUIC Connections", Work in Progress, Internet- 811 Draft, draft-ietf-dprive-dnsoquic-11, 21 March 2022, 812 . 815 [I-D.pusateri-dhc-dns-driu] 816 Pusateri, T. and W. Toorop, "DHCPv6 Options for private 817 DNS Discovery", Work in Progress, Internet-Draft, draft- 818 pusateri-dhc-dns-driu-00, 2 July 2018, 819 . 822 [Krack] The Unicode Consortium, "Key Reinstallation Attacks", 823 2017, . 825 [ND] "IPv6 Neighbor Discovery Option Formats", 826 . 829 [PSK] Cisco, "Identity PSK Feature Deployment Guide", 830 . 834 [RFC3552] Rescorla, E. and B. Korver, "Guidelines for Writing RFC 835 Text on Security Considerations", BCP 72, RFC 3552, 836 DOI 10.17487/RFC3552, July 2003, 837 . 839 [RFC3646] Droms, R., Ed., "DNS Configuration options for Dynamic 840 Host Configuration Protocol for IPv6 (DHCPv6)", RFC 3646, 841 DOI 10.17487/RFC3646, December 2003, 842 . 844 [RFC6092] Woodyatt, J., Ed., "Recommended Simple Security 845 Capabilities in Customer Premises Equipment (CPE) for 846 Providing Residential IPv6 Internet Service", RFC 6092, 847 DOI 10.17487/RFC6092, January 2011, 848 . 850 [RFC6125] Saint-Andre, P. and J. Hodges, "Representation and 851 Verification of Domain-Based Application Service Identity 852 within Internet Public Key Infrastructure Using X.509 853 (PKIX) Certificates in the Context of Transport Layer 854 Security (TLS)", RFC 6125, DOI 10.17487/RFC6125, March 855 2011, . 857 [RFC6731] Savolainen, T., Kato, J., and T. Lemon, "Improved 858 Recursive DNS Server Selection for Multi-Interfaced 859 Nodes", RFC 6731, DOI 10.17487/RFC6731, December 2012, 860 . 862 [RFC7113] Gont, F., "Implementation Advice for IPv6 Router 863 Advertisement Guard (RA-Guard)", RFC 7113, 864 DOI 10.17487/RFC7113, February 2014, 865 . 867 [RFC7227] Hankins, D., Mrugalski, T., Siodelski, M., Jiang, S., and 868 S. Krishnan, "Guidelines for Creating New DHCPv6 Options", 869 BCP 187, RFC 7227, DOI 10.17487/RFC7227, May 2014, 870 . 872 [RFC7513] Bi, J., Wu, J., Yao, G., and F. Baker, "Source Address 873 Validation Improvement (SAVI) Solution for DHCP", 874 RFC 7513, DOI 10.17487/RFC7513, May 2015, 875 . 877 [RFC7610] Gont, F., Liu, W., and G. Van de Velde, "DHCPv6-Shield: 878 Protecting against Rogue DHCPv6 Servers", BCP 199, 879 RFC 7610, DOI 10.17487/RFC7610, August 2015, 880 . 882 [RFC7858] Hu, Z., Zhu, L., Heidemann, J., Mankin, A., Wessels, D., 883 and P. Hoffman, "Specification for DNS over Transport 884 Layer Security (TLS)", RFC 7858, DOI 10.17487/RFC7858, May 885 2016, . 887 [RFC7969] Lemon, T. and T. Mrugalski, "Customizing DHCP 888 Configuration on the Basis of Network Topology", RFC 7969, 889 DOI 10.17487/RFC7969, October 2016, 890 . 892 [RFC8146] Harkins, D., "Adding Support for Salted Password Databases 893 to EAP-pwd", RFC 8146, DOI 10.17487/RFC8146, April 2017, 894 . 896 [RFC8310] Dickinson, S., Gillmor, D., and T. Reddy, "Usage Profiles 897 for DNS over TLS and DNS over DTLS", RFC 8310, 898 DOI 10.17487/RFC8310, March 2018, 899 . 901 [RFC8484] Hoffman, P. and P. McManus, "DNS Queries over HTTPS 902 (DoH)", RFC 8484, DOI 10.17487/RFC8484, October 2018, 903 . 905 [RFC8499] Hoffman, P., Sullivan, A., and K. Fujiwara, "DNS 906 Terminology", BCP 219, RFC 8499, DOI 10.17487/RFC8499, 907 January 2019, . 909 Authors' Addresses 911 Mohamed Boucadair (editor) 912 Orange 913 35000 Rennes 914 France 915 Email: mohamed.boucadair@orange.com 917 Tirumaleswar Reddy (editor) 918 Akamai 919 Embassy Golf Link Business Park 920 Bangalore 560071 921 Karnataka 922 India 923 Email: kondtir@gmail.com 925 Dan Wing 926 Citrix Systems, Inc. 927 United States of America 928 Email: dwing-ietf@fuggles.com 930 Neil Cook 931 Open-Xchange 932 United Kingdom 933 Email: neil.cook@noware.co.uk 934 Tommy Jensen 935 Microsoft 936 United States of America 937 Email: tojens@microsoft.com