idnits 2.17.00 (12 Aug 2021) /tmp/idnits55677/draft-ietf-ipsecme-add-ike-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- -- The document date (22 March 2022) is 60 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) -- Possible downref: Non-RFC (?) normative reference: ref. 'Hash' == Outdated reference: A later version (-09) exists of draft-ietf-dnsop-svcb-https-08 == Outdated reference: draft-ietf-dprive-dnsoquic has been published as RFC 9250 Summary: 0 errors (**), 0 flaws (~~), 2 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 ipsecme M. Boucadair 3 Internet-Draft Orange 4 Intended status: Standards Track T. Reddy 5 Expires: 23 September 2022 Akamai 6 D. Wing 7 Citrix 8 V. Smyslov 9 ELVIS-PLUS 10 22 March 2022 12 Internet Key Exchange Protocol Version 2 (IKEv2) Configuration for 13 Encrypted DNS 14 draft-ietf-ipsecme-add-ike-01 16 Abstract 18 This document specifies new Internet Key Exchange Protocol Version 2 19 (IKEv2) Configuration Payload Attribute Types for encrypted DNS 20 protocols such as DNS-over-HTTPS (DoH), DNS-over-TLS (DoT), and DNS- 21 over-QUIC (DoQ). 23 Status of This Memo 25 This Internet-Draft is submitted in full conformance with the 26 provisions of BCP 78 and BCP 79. 28 Internet-Drafts are working documents of the Internet Engineering 29 Task Force (IETF). Note that other groups may also distribute 30 working documents as Internet-Drafts. The list of current Internet- 31 Drafts is at https://datatracker.ietf.org/drafts/current/. 33 Internet-Drafts are draft documents valid for a maximum of six months 34 and may be updated, replaced, or obsoleted by other documents at any 35 time. It is inappropriate to use Internet-Drafts as reference 36 material or to cite them other than as "work in progress." 38 This Internet-Draft will expire on 23 September 2022. 40 Copyright Notice 42 Copyright (c) 2022 IETF Trust and the persons identified as the 43 document authors. All rights reserved. 45 This document is subject to BCP 78 and the IETF Trust's Legal 46 Provisions Relating to IETF Documents (https://trustee.ietf.org/ 47 license-info) in effect on the date of publication of this document. 48 Please review these documents carefully, as they describe your rights 49 and restrictions with respect to this document. Code Components 50 extracted from this document must include Revised BSD License text as 51 described in Section 4.e of the Trust Legal Provisions and are 52 provided without warranty as described in the Revised BSD License. 54 Table of Contents 56 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 57 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 58 3. IKEv2 Configuration Payload Attribute Types for Encrypted 59 DNS . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 60 3.1. ENCDNS_IP* Configuration Payload Attributes . . . . . . . 3 61 3.2. ENCDNS_DIGEST_INFO Configuration Payload Attribute . . . 5 62 4. IKEv2 Protocol Exchange . . . . . . . . . . . . . . . . . . . 7 63 5. Security Considerations . . . . . . . . . . . . . . . . . . . 8 64 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 65 6.1. Configuration Payload Attribute Types . . . . . . . . . . 9 66 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 9 67 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 10 68 8.1. Normative References . . . . . . . . . . . . . . . . . . 10 69 8.2. Informative References . . . . . . . . . . . . . . . . . 10 70 Appendix A. Sample Deployment Scenarios . . . . . . . . . . . . 11 71 A.1. Roaming Enterprise Users . . . . . . . . . . . . . . . . 11 72 A.2. VPN Service Provider . . . . . . . . . . . . . . . . . . 12 73 A.3. DNS Offload . . . . . . . . . . . . . . . . . . . . . . . 12 74 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 12 76 1. Introduction 78 This document specifies encrypted DNS configuration for an Internet 79 Key Exchange Protocol Version 2 (IKEv2) [RFC7296] initiator, 80 particularly the Authentication Domain Name (ADN) of DNS servers that 81 support encrypted DNS protocols such as DNS-over-HTTPS (DoH) 82 [RFC8484], DNS-over-TLS (DoT) [RFC7858], or DNS-over-QUIC (DoQ) 83 [I-D.ietf-dprive-dnsoquic]. 85 This document introduces new IKEv2 Configuration Payload Attribute 86 Types (Section 3) for the support of encrypted DNS servers. These 87 attributes can be used to provision ADNs, a list of IP addresses, and 88 a set of service parameters. 90 Sample use cases are discussed in Appendix A. The Configuration 91 Payload Attribute Types defined in this document are not specific to 92 these deployments, but can also be used in other deployment contexts. 93 It is out of the scope of this document to provide a comprehensive 94 list of deployment contexts. 96 The encrypted DNS server hosted by a VPN provider can get a domain- 97 validate certificate from a public Certificate Authority (CA). The 98 VPN client does not need to be provisioned with the root certificate 99 of a private CA to authenticate the certificate of the encrypted DNS 100 server. The encrypted DNS server can run on private IP addresses and 101 its access can be restricted to clients connected to the VPN. 103 Note that, for many years, typical designs have often considered that 104 the DNS server was usually located inside the protected domain, but 105 could be located outside of it. With encrypted DNS, the latter 106 option becomes plausible. 108 2. Terminology 110 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 111 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 112 "OPTIONAL" in this document are to be interpreted as described in BCP 113 14 [RFC2119][RFC8174] when, and only when, they appear in all 114 capitals, as shown here. 116 This document uses of the terms defined in [RFC8499]. 118 Also, this document uses of the terms defined in [RFC7296]. In 119 particular, readers should be familiar with "initiator" and 120 "responder" terms used in that document. 122 This document makes use of the following terms: 124 Do53: refers to unencrypted DNS. 126 Encrypted DNS: refers to a scheme where DNS messages are sent over 127 an encrypted channel. Examples of encrypted DNS are DoT, DoH, and 128 DoQ. 130 ENCDNS_IP*: refers to any IKEv2 Configuration Payload Attribute 131 Types defined in Section 3.1. 133 3. IKEv2 Configuration Payload Attribute Types for Encrypted DNS 135 3.1. ENCDNS_IP* Configuration Payload Attributes 137 The ENCDNS_IP* IKEv2 Configuration Payload Attribute Types are used 138 to configure encrypted DNS servers to an initiator. All these 139 attributes share the format that is shown in Figure 1. 141 1 2 3 142 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 143 +-+-----------------------------+-------------------------------+ 144 |R| Attribute Type | Length | 145 +-+-----------------------------+---------------+---------------+ 146 | Service Priority | Num Addresses | ADN Length | 147 +-------------------------------+---------------+---------------+ 148 ~ IP Addresses ~ 149 +---------------------------------------------------------------+ 150 ~ Authentication Domain Name ~ 151 +---------------------------------------------------------------+ 152 ~ Service Parameters (SvcParams) ~ 153 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 155 Figure 1: Attributes Format 157 The description of the fields of the attribute shown in Figure 1 is 158 as follows: 160 * R (Reserved, 1 bit) - This bit MUST be set to zero and MUST be 161 ignored on receipt (see Section 3.15.1 of [RFC7296] for details). 163 * Attribute Type (15 bits) - Identifier for Configuration Attribute 164 Type; is set to TBA1 or TBA2 values listed in Section 6.1. 166 * Length (2 octets, unsigned integer) - Length of the data in 167 octets. In particular, this field is set to: 169 - 0 if the Configuration payload has types CFG_REQUEST (if no 170 specific DNS server is requested) or CFG_ACK. 172 - (4 + Length of the ADN + N * 4 + Length of SvcParams) for 173 ENCDNS_IP4 attributes if the Configuration payload has types 174 CFG_REQUEST or CFG_REPLY or CFG_SET; N being the number of 175 included IPv4 addresses ('Num addresses'). 177 - (4 + Length of the ADN + N * 16 + Length of SvcParams) for 178 ENCDNS_IP6 attributes if the Configuration payload has types 179 CFG_REQUEST or CFG_REPLY or CFG_SET; N being the number of 180 included IPv6 addresses ('Num addresses'). 182 * Service Priority (2 octets) - The priority of this attribute 183 compared to other ENCDNS_IP* instances. This field is encoded 184 following the rules specified in Section 2.4.1 of 185 [I-D.ietf-dnsop-svcb-https]. 187 AliasMode (Section 2.4.2 of [I-D.ietf-dnsop-svcb-https]) is not 188 supported because such a mode will trigger additional Do53 queries 189 while the data can be supplied directly in the IKE response. As 190 such, this field MUST NOT be set to 0. 192 * Num Addresses (1 octet) - Indicates the number of enclosed IPv4 193 (for ENCDNS_IP4 attribute type) or IPv6 (for ENCDNS_IP6 attribute 194 type) addresses. It MUST NOT be set to 0 if the Configuration 195 payload has types CFG_REPLY or CFG_SET. 197 * ADN Length (1 octet) - Indicates the length of the authentication- 198 domain-name field in octets. 200 * IP Address(es) (variable) - One or more IPv4 or IPv6 addresses to 201 be used to reach the encrypted DNS server that is identified by 202 the name in the Authentication Domain Name. 204 * Authentication Domain Name (variable) - A fully qualified domain 205 name of the encrypted DNS server following the syntax defined in 206 [RFC5890]. The name MUST NOT contain any terminators (e.g., NULL, 207 CR). 209 An example of a valid ADN for DoH server is "doh1.example.com". 211 * Service Parameters (SvcParams) (variable) - Specifies a set of 212 service parameters that are encoded following the rules in 213 Section 2.1 of [I-D.ietf-dnsop-svcb-https]. Service parameters 214 may include, for example, a list of ALPN protocol identifiers or 215 alternate port numbers. The service parameters MUST NOT include 216 "ipv4hint" or "ipv6hint" SvcParams as they are superseded by the 217 included IP addresses. 219 If no port service parameter is included, this indicates that 220 default port numbers should be used. As a reminder, the default 221 port number is 853 for DoT, 443 for DoH, and 853 for DoQ. 223 The service parameters apply to all IP addresses in the ENCDNS_IP* 224 Configuration Payload Attribute. 226 3.2. ENCDNS_DIGEST_INFO Configuration Payload Attribute 228 The format of ENCDNS_DIGEST_INFO configuration payload attribute is 229 shown in Figure 2. 231 1 2 3 232 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 233 +-+-----------------------------+-------------------------------+ 234 |R| Attribute Type | Length | 235 +-+-----------------------------+---------------+---------------+ 236 | RESERVED | ADN Length | 237 +-----------------------------------------------+---------------+ 238 ~ Authentication Domain Name ~ 239 +---------------------------------------------------------------+ 240 ~ Hash Algorithm Identifiers ~ 241 +---------------------------------------------------------------+ 242 ~ Certificate Digest ~ 243 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 245 Figure 2: ENCDNS_DIGEST_INFO Attribute Format 247 * R (Reserved, 1 bit) - This bit MUST be set to zero and MUST be 248 ignored on receipt (see Section 3.15.1 of [RFC7296] for details). 250 * Attribute Type (15 bits) - Identifier for Configuration Attribute 251 Type; is set to TBA3 value listed in Section 6.1. 253 * Length (2 octets, unsigned integer) - Length of the data in 254 octets. 256 * RESERVED (3 octets) - These bits are reserved for future use. 257 These bits MUST be set to zero by the sender and MUST be ignored 258 by the receiver. 260 * ADN Length (1 octet) - Indicates the length of the authentication- 261 domain-name field in octets. When set to '0', this means that the 262 digest applies on the ADN conveyed in the ENCDNS_IP* Configuration 263 Payload Attribute(s). 265 * Authentication Domain Name (variable) - A fully qualified domain 266 name of the encrypted DNS server following the syntax defined in 267 [RFC5890]. The name MUST NOT contain any terminators (e.g., NULL, 268 CR). A name is included only when multiple ADNs are included in 269 the ENCDNS_IP* Configuration Payload Attributes. 271 * Hash Algorithm Identifiers (variable) - In a request, this field 272 specifies a list of 16-bit hash algorithm identifiers that are 273 supported by the encrypted DNS client. In a response, this field 274 specifies the 16-bit hash algorithm identifier selected by the 275 server to generate the digest of its certificate. 277 The values of this field are taken from the Hash Algorithm 278 Identifiers of IANA's "Internet Key Exchange Version 2 (IKEv2) 279 Parameters" registry [Hash]. 281 There is no padding between the hash algorithm identifiers. 283 Note that SHA2-256 is mandatory to implement. 285 * Certificate Digest (variable) - MUST only be present in a 286 response. This field includes the digest of the encrypted DNS 287 server certificate using the algorthm identified in the 'Hash 288 Algorithm Identifiers' field. 290 4. IKEv2 Protocol Exchange 292 This section describes how an initiator can be configured with an 293 encrypted DNS server (e.g., DoH, DoT) using IKEv2. 295 Initiators indicate the support of an encrypted DNS in the 296 CFG_REQUEST payloads by including one or two ENCDNS_IP* attributes, 297 while responders supply the encrypted DNS configuration in the 298 CFG_REPLY payloads. Concretely: 300 If the initiator supports encrypted DNS, it includes one or two 301 ENCDNS_IP* attributes in the CFG_REQUEST. For each IP address 302 family the initiator MUST include exactly one attribute with the 303 Length field set to 0 if no specific DNS server is requested. The 304 initiator MAY include the ENCDNS_DIGEST_INFO attribute with a list 305 of hash algorithms that are supported by the encrypted DNS client. 307 For each ENCDNS_IP* attribute from the CFG_REQUEST, if the 308 responder supports the corresponding address family, and absent 309 any policy, the responder sends back ENCDNS_IP* attribute(s) in 310 the CFG_REPLY with an appropriate list of IP addresses, service 311 parameters, and an ADN. The list of IP addresses MUST include at 312 least one IP address. The responder may ignore suggested values 313 (if any). Multiple instances of the same ENCDNS_IP* attribute MAY 314 be returned if distinct ADNs or service parameters are to be 315 returned by the responder. The same or distinct IP addresses can 316 be returned in such instances. These instances SHOULD be 317 processed following their service priority (i.e., smaller service 318 priority indicates a higher preference). 320 In addition, the responder MAY return the ENCDNS_DIGEST_INFO 321 attribute to convey a digest of the certificate of the encrypted 322 DNS and the identifier of the hash algorithm that is used to 323 generate the digest. 325 If the CFG_REQUEST includes an ENCDNS_IP* attribute but the 326 CFG_REPLY does not include an ENCDNS_IP* matching the requested 327 address family, this is an indication that requested address 328 family is not supported by the responder or the responder is not 329 configured to provide corresponding server addresses. 331 If the initiator receives both ENCDNS_IP* and INTERNAL_IP6_DNS (or 332 INTERNAL_IP4_DNS) attributes, it is RECOMMENDED that the initiator 333 uses the encrypted DNS servers. 335 The DNS client establishes an encrypted DNS session (e.g., DoT, DoH, 336 DoQ) with the address(es) conveyed in ENCDNS_IP* and uses the 337 mechanism discussed in Section 8 of [RFC8310] to authenticate the DNS 338 server certificate using the authentication domain name conveyed in 339 ENCDNS_IP*. 341 If the CFG_REPLY includes an ENCDNS_DIGEST_INFO attribute, the DNS 342 client has to create a digest of the DNS server certificate received 343 in the TLS handshake using the negotiated hash algorithm in the 344 ENCDNS_DIGEST_INFO attribute. If the computed digest for an ADN 345 matches the one sent in the ENCDNS_DIGEST_INFO attribute, the 346 encrypted DNS server certificate is successfully validated. If so, 347 the client continues with the TLS connection as normal. Otherwise, 348 the client MUST treat the server certificate validation failure as a 349 non-recoverable error. This approach is similar to certificate usage 350 PKIX-EE(1) defined in [RFC7671]. 352 If the IPsec connection is a split-tunnel configuration and the 353 initiator negotiated INTERNAL_DNS_DOMAIN as per [RFC8598], the DNS 354 client resolves the internal names using ENCDNS_IP* DNS servers. 356 Note: [RFC8598] requires INTERNAL_IP6_DNS (or INTERNAL_IP4_DNS) 357 attribute to be mandatory present when INTERNAL_DNS_DOMAIN is 358 included. This specification relaxes that constraint in the 359 presence of ENCDNS_IP* attributes. That is, if ENCDNS_IP* 360 attributes are supplied, it is allowed to include 361 INTERNAL_DNS_DOMAIN even in the absence of INTERNAL_IP6_DNS (or 362 INTERNAL_IP4_DNS) attributes. 364 5. Security Considerations 366 This document adheres to the security considerations defined in 367 [RFC7296]. In particular, this document does not alter the trust on 368 the DNS configuration provided by a responder. 370 Networks are susceptible to internal attacks as discussed in 371 Section 3.2 of [I-D.arkko-farrell-arch-model-t]. Hosting encrypted 372 DNS server even in case of split-VPN configuration minimizes the 373 attack vector (e.g., a compromised network device cannot monitor/ 374 modify DNS traffic). This specification describes a mechanism to 375 restrict access to the DNS messages to only the parties that need to 376 know. 378 The initiator may trust the encrypted DNS servers supplied by means 379 of IKEv2 from a trusted responder more than the locally provided DNS 380 servers, especially in the case of connecting to unknown or untrusted 381 networks (e.g., coffee shops or hotel networks). 383 If IKEv2 responder has used NULL Authentication method [RFC7619] to 384 authenticate itself, the initiator MUST NOT use returned ENCDNS_IP* 385 servers configuration unless it is pre-configured in the OS or the 386 browser. 388 This specification does not extend the scope of accepting DNSSEC 389 trust anchors beyond the usage guidelines defined in Section 6 of 390 [RFC8598]. 392 6. IANA Considerations 394 6.1. Configuration Payload Attribute Types 396 This document requests IANA to assign the following new IKEv2 397 Configuration Payload Attribute Types from the "IKEv2 Configuration 398 Payload Attribute Types" namespace available at 399 https://www.iana.org/assignments/ikev2-parameters/ 400 ikev2-parameters.xhtml#ikev2-parameters-21. 402 Multi- 403 Value Attribute Type Valued Length Reference 404 ------ ------------------ ----- --------- --------- 405 TBA1 ENCDNS_IP4 YES 0 or more RFC XXXX 406 TBA2 ENCDNS_IP6 YES 0 or more RFC XXXX 407 TBA3 ENCDNS_ENCDNS_DIGEST_INFO YES 0 or more RFC XXXX 409 7. Acknowledgements 411 Many thanks to Yoav Nir, Christian Jacquenet, Paul Wouters, and Tommy 412 Pauly for the review and comments. 414 Yoav and Paul suggested the use of one single attribute carrying both 415 the name and an IP address instead of depending on the existing 416 INTERNAL_IP6_DNS and INTERNAL_IP4_DNS attributes. 418 Christian Huitema suggested to return a port number in the 419 attributes. 421 8. References 423 8.1. Normative References 425 [Hash] "IKEv2 Hash Algorithms", 426 . 429 [I-D.ietf-dnsop-svcb-https] 430 Schwartz, B., Bishop, M., and E. Nygren, "Service binding 431 and parameter specification via the DNS (DNS SVCB and 432 HTTPS RRs)", Work in Progress, Internet-Draft, draft-ietf- 433 dnsop-svcb-https-08, 12 October 2021, 434 . 437 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 438 Requirement Levels", BCP 14, RFC 2119, 439 DOI 10.17487/RFC2119, March 1997, 440 . 442 [RFC5890] Klensin, J., "Internationalized Domain Names for 443 Applications (IDNA): Definitions and Document Framework", 444 RFC 5890, DOI 10.17487/RFC5890, August 2010, 445 . 447 [RFC7296] Kaufman, C., Hoffman, P., Nir, Y., Eronen, P., and T. 448 Kivinen, "Internet Key Exchange Protocol Version 2 449 (IKEv2)", STD 79, RFC 7296, DOI 10.17487/RFC7296, October 450 2014, . 452 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 453 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 454 May 2017, . 456 [RFC8310] Dickinson, S., Gillmor, D., and T. Reddy, "Usage Profiles 457 for DNS over TLS and DNS over DTLS", RFC 8310, 458 DOI 10.17487/RFC8310, March 2018, 459 . 461 8.2. Informative References 463 [I-D.arkko-farrell-arch-model-t] 464 Arkko, J. and S. Farrell, "Challenges and Changes in the 465 Internet Threat Model", Work in Progress, Internet-Draft, 466 draft-arkko-farrell-arch-model-t-04, 13 July 2020, 467 . 470 [I-D.ietf-dprive-dnsoquic] 471 Huitema, C., Dickinson, S., and A. Mankin, "DNS over 472 Dedicated QUIC Connections", Work in Progress, Internet- 473 Draft, draft-ietf-dprive-dnsoquic-11, 21 March 2022, 474 . 477 [RFC7619] Smyslov, V. and P. Wouters, "The NULL Authentication 478 Method in the Internet Key Exchange Protocol Version 2 479 (IKEv2)", RFC 7619, DOI 10.17487/RFC7619, August 2015, 480 . 482 [RFC7671] Dukhovni, V. and W. Hardaker, "The DNS-Based 483 Authentication of Named Entities (DANE) Protocol: Updates 484 and Operational Guidance", RFC 7671, DOI 10.17487/RFC7671, 485 October 2015, . 487 [RFC7858] Hu, Z., Zhu, L., Heidemann, J., Mankin, A., Wessels, D., 488 and P. Hoffman, "Specification for DNS over Transport 489 Layer Security (TLS)", RFC 7858, DOI 10.17487/RFC7858, May 490 2016, . 492 [RFC8484] Hoffman, P. and P. McManus, "DNS Queries over HTTPS 493 (DoH)", RFC 8484, DOI 10.17487/RFC8484, October 2018, 494 . 496 [RFC8499] Hoffman, P., Sullivan, A., and K. Fujiwara, "DNS 497 Terminology", BCP 219, RFC 8499, DOI 10.17487/RFC8499, 498 January 2019, . 500 [RFC8598] Pauly, T. and P. Wouters, "Split DNS Configuration for the 501 Internet Key Exchange Protocol Version 2 (IKEv2)", 502 RFC 8598, DOI 10.17487/RFC8598, May 2019, 503 . 505 Appendix A. Sample Deployment Scenarios 507 A.1. Roaming Enterprise Users 509 In this Enterprise scenario (Section 1.1.3 of [RFC7296]), a roaming 510 user connects to the Enterprise network through an IPsec tunnel. The 511 split-tunnel Virtual Private Network (VPN) configuration allows the 512 endpoint to access hosts that resides in the Enterprise network 513 [RFC8598] using that tunnel; other traffic not destined to the 514 Enterprise does not traverse the tunnel. In contrast, a non-split- 515 tunnel VPN configuration causes all traffic to traverse the tunnel 516 into the enterprise. 518 For both split- and non-split-tunnel configurations, the use of 519 encrypted DNS instead of Do53 provides privacy and integrity 520 protection along the entire path (rather than just to the VPN 521 termination device) and can communicate the encrypted DNS server 522 policies. 524 For split-tunnel VPN configurations, the endpoint uses the 525 Enterprise-provided encrypted DNS server to resolve internal-only 526 domain names. 528 For non-split-tunnel VPN configurations, the endpoint uses the 529 Enterprise-provided encrypted DNS server to resolve both internal and 530 external domain names. 532 Enterprise networks are susceptible to internal and external attacks. 533 To minimize that risk all enterprise traffic is encrypted 534 (Section 2.1 of [I-D.arkko-farrell-arch-model-t]). 536 A.2. VPN Service Provider 538 Legacy VPN service providers usually preserve end-users' data 539 confidentiality by sending all communication traffic through an 540 encrypted tunnel. A VPN service provider can also provide guarantees 541 about the security of the VPN network by filtering malware and 542 phishing domains. 544 Browsers and OSes support DoH/DoT; VPN providers may no longer expect 545 DNS clients to fallback to Do53 just because it is a closed network. 547 The encrypted DNS server hosted by the VPN service provider can be 548 securely discovered by the endpoint using the IKEv2 Configuration 549 Payload Attribute Type. 551 A.3. DNS Offload 553 VPN service providers typically allow split-tunnel VPN configuration 554 in which users can choose applications that can be excluded from the 555 tunnel. For example, users may exclude applications that restrict 556 VPN access. 558 The encrypted DNS server hosted by the VPN service provider can be 559 securely discovered by the endpoint using the IKEv2 Configuration 560 Payload Attribute Type. 562 Authors' Addresses 563 Mohamed Boucadair 564 Orange 565 35000 Rennes 566 France 567 Email: mohamed.boucadair@orange.com 569 Tirumaleswar Reddy 570 Akamai 571 Embassy Golf Link Business Park 572 Bangalore 560071 573 Karnataka 574 India 575 Email: kondtir@gmail.com 577 Dan Wing 578 Citrix Systems, Inc. 579 United States of America 580 Email: dwing-ietf@fuggles.com 582 Valery Smyslov 583 ELVIS-PLUS 584 Russian Federation 585 Email: svan@elvis.ru