idnits 2.17.00 (12 Aug 2021) /tmp/idnits55153/draft-ietf-ipsecme-add-ike-00.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 copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (16 December 2021) is 156 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 (~~), 3 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: 19 June 2022 Akamai 6 D. Wing 7 Citrix 8 V. Smyslov 9 ELVIS-PLUS 10 16 December 2021 12 Internet Key Exchange Protocol Version 2 (IKEv2) Configuration for 13 Encrypted DNS 14 draft-ietf-ipsecme-add-ike-00 16 Abstract 18 This document specifies a new Internet Key Exchange Protocol Version 19 2 (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 19 June 2022. 40 Copyright Notice 42 Copyright (c) 2021 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 encrypted DNS 81 protocols such as DNS-over-HTTPS (DoH) [RFC8484], DNS-over-TLS (DoT) 82 [RFC7858], or DNS-over-QUIC (DoQ) [I-D.ietf-dprive-dnsoquic]. 84 This document introduces new IKEv2 Configuration Payload Attribute 85 Types (Section 3) for the support of encrypted DNS servers. These 86 attributes can be used to provision authentication domain names, a 87 list of IP addresses, and a set of service parameters. 89 Sample use cases are discussed in Appendix A. The Configuration 90 Payload Attribute Types defined in this document are not specific to 91 these deployments, but can also be used in other deployment contexts. 92 It is out of the scope of this document to provide a comprehensive 93 list of deployment contexts. 95 The encrypted DNS server hosted by the VPN provider can get a domain- 96 validate certificate from a public CA. The VPN client does not need 97 to be provisioned with the root certificate of a private CA to 98 authenticate the certificate of the encrypted DNS server. The 99 encrypted DNS server can run on private IP addresses and its access 100 can be restricted to clients connected to the VPN. 102 Note that, for many years, typical designs have often considered that 103 the DNS server was usually located inside the protected domain, but 104 could be located outside of it. With encrypted DNS, the latter 105 option becomes plausible. 107 2. Terminology 109 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 110 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 111 "OPTIONAL" in this document are to be interpreted as described in BCP 112 14 [RFC2119][RFC8174] when, and only when, they appear in all 113 capitals, as shown here. 115 This document uses of the terms defined in [RFC8499]. 117 Also, this document uses of the terms defined in [RFC7296]. In 118 particular, readers should be familiar with "initiator" and 119 "responder" terms used in that document. 121 This document makes use of the following terms: 123 'Do53': refers to unencrypted DNS. 125 'Encrypted DNS': refers to a scheme where DNS messages are sent over 126 an encrypted channel. Examples of encrypted DNS are DoT, DoH, and 127 DoQ. 129 'ENCDNS_IP*: refers to any IKEv2 Configuration Payload Attribute 130 Types defined in Section 3.1. 132 3. IKEv2 Configuration Payload Attribute Types for Encrypted DNS 134 3.1. ENCDNS_IP* Configuration Payload Attributes 136 The ENCDNS_IP* IKEv2 Configuration Payload Attribute Types are used 137 to configure encrypted DNS servers. All these attributes share the 138 format shown in Figure 1. 140 1 2 3 141 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 142 +-+-----------------------------+-------------------------------+ 143 |R| Attribute Type | Length | 144 +-+-----------------------------+---------------+---------------+ 145 | Service Priority | Num Addresses | ADN Length | 146 +-------------------------------+---------------+---------------+ 147 ~ IP Addresses ~ 148 +---------------------------------------------------------------+ 149 ~ Authentication Domain Name ~ 150 +---------------------------------------------------------------+ 151 ~ Service Parameters (SvcParams) ~ 152 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 154 Figure 1: Attributes Format 156 The fields of the attribute shown in Figure 1 are as follows: 158 * R (Reserved, 1 bit) - This bit MUST be set to zero and MUST be 159 ignored on receipt (see Section 3.15.1 of [RFC7296] for details). 161 * Attribute Type (15 bits) - Identifier for Configuration Attribute 162 Type; is set to TBA1 or TBA2 values listed in Section 6.1. 164 * Length (2 octets, unsigned integer) - Length of the data in 165 octets. In particular, this field is set to: 167 - 0 if the Configuration payload has types CFG_REQUEST (if no 168 specific DNS server is requested) or CFG_ACK. 170 - (4 + Length of the ADN + N * 4 + Length of SvcParams) for 171 ENCDNS_IP4 attributes if the Configuration payload has types 172 CFG_REQUEST or CFG_REPLY or CFG_SET; N being the number of 173 included IPv4 addresses ('Num addresses'). 175 - (4 + Length of the ADN + N * 16 + Length of SvcParams) for 176 ENCDNS_IP6 attributes if the Configuration payload has types 177 CFG_REQUEST or CFG_REPLY or CFG_SET; N being the number of 178 included IPv6 addresses ('Num addresses'). 180 * Service Priority (2 octets) - The priority of this attribute 181 compared to other ENCDNS_IP* instances. This field is encoded 182 following the rules specified in Section 2.4.1 of 183 [I-D.ietf-dnsop-svcb-https]. 185 * Num Addresses (1 octet) - Indicates the number of enclosed IPv4 186 (for ENCDNS_IP4 attribute type) or IPv6 (for ENCDNS_IP6 attribute 187 type) addresses. It MUST NOT be set to 0 if the Configuration 188 payload has types CFG_REPLY or CFG_SET. 190 * ADN Length (1 octet) - Indicates the length of the authentication- 191 domain-name field in octets. 193 * IP Address(es) (variable) - One or more IPv4 or IPv6 addresses to 194 be used to reach the encrypted DNS server that is identified by 195 the name in the Authentication Domain Name. 197 * Authentication Domain Name (variable) - A fully qualified domain 198 name of the encrypted DNS server following the syntax defined in 199 [RFC5890]. The name MUST NOT contain any terminators (e.g., NULL, 200 CR). 202 An example of a valid ADN for DoH server is "doh1.example.com". 204 * Service Parameters (SvcParams) (variable) - Specifies a set of 205 service parameters that are encoded following the rules in 206 Section 2.1 of [I-D.ietf-dnsop-svcb-https]. Service parameters 207 may include, for example, a list of ALPN protocol identifiers or 208 alternate port numbers. The service parameters MUST NOT include 209 "ipv4hint" or "ipv6hint" SvcParams as they are superseded by the 210 included IP addresses. 212 If no port service parameter is included, this indicates that 213 default port numbers should be used. As a reminder, the default 214 port number is 853 for DoT, 443 for DoH, and 853 for DoQ. 216 The service parameters apply to all IP addresses in the ENCDNS_IP* 217 Configuration Payload Attribute. 219 3.2. ENCDNS_DIGEST_INFO Configuration Payload Attribute 221 The format of ENCDNS_DIGEST_INFO configuration payload attribute is 222 shown in Figure 2. 224 1 2 3 225 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 226 +-+-----------------------------+-------------------------------+ 227 |R| Attribute Type | Length | 228 +-+-----------------------------+---------------+---------------+ 229 | RESERVED | ADN Length | 230 +-----------------------------------------------+---------------+ 231 ~ Authentication Domain Name ~ 232 +---------------------------------------------------------------+ 233 ~ Hash Algorithm Identifiers ~ 234 +---------------------------------------------------------------+ 235 ~ Certificate Digest ~ 236 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 238 Figure 2: ENCDNS_DIGEST_INFO Attribute Format 240 * R (Reserved, 1 bit) - This bit MUST be set to zero and MUST be 241 ignored on receipt (see Section 3.15.1 of [RFC7296] for details). 243 * Attribute Type (15 bits) - Identifier for Configuration Attribute 244 Type; is set to TBA3 value listed in Section 6.1. 246 * Length (2 octets, unsigned integer) - Length of the data in 247 octets. 249 * RESERVED (3 octets) - These bits are reserved for future use. 250 These bits MUST be set to zero by the sender and MUST be ignored 251 by the receiver. 253 * ADN Length (1 octet) - Indicates the length of the authentication- 254 domain-name field in octets. When set to '0', this means that the 255 digest applies on the ADN conveyed in the ENCDNS_IP* Configuration 256 Payload Attribute(s). 258 * Authentication Domain Name (variable) - A fully qualified domain 259 name of the encrypted DNS server following the syntax defined in 260 [RFC5890]. The name MUST NOT contain any terminators (e.g., NULL, 261 CR). A name is included only when multiple ADNs are included in 262 the ENCDNS_IP* Configuration Payload Attributes. 264 * Hash Algorithm Identifiers (variable) - In a request, this field 265 specifies a list of 16-bit hash algorithm identifiers that are 266 supported by the Encrypted DNS client. In a response, this field 267 specified the 16-bit hash algorithm identifier selected by the 268 server to generate the digest of its certificate. The values of 269 this field are taken from the Hash Algorithm Identifiers of IANA's 270 "Internet Key Exchange Version 2 (IKEv2) Parameters" registry 271 [Hash]. 273 There is no padding between the hash algorithm identifiers. 275 Note that SHA2-256 is mandatory to implement. 277 * Certificate Digest (variable) - MUST only be present in a 278 response. This field includes the digest of the Encrypted DNS 279 server certificate using the algorthm identified in the 'Hash 280 Algorithm Identifiers' field. 282 4. IKEv2 Protocol Exchange 284 This section describes how an initiator can be configured with an 285 encrypted DNS server (e.g., DoH, DoT) using IKEv2. 287 Initiators indicate the support of an encrypted DNS in the 288 CFG_REQUEST payloads by including one or two ENCDNS_IP* attributes, 289 while responders supply the encrypted DNS configuration in the 290 CFG_REPLY payloads. Concretely: 292 If the initiator supports encrypted DNS, it includes one or two 293 ENCDNS_IP* attributes in the CFG_REQUEST. For each IP address 294 family the initiator MUST include exactly one attribute with the 295 Length field set to 0 if no specific DNS server is requested. The 296 initiator MAY include the ENCDNS_DIGEST_INFO attribute with a list 297 of hash algorithms that are supported by the Encrypted DNS client. 299 For each ENCDNS_IP* attribute from the CFG_REQUEST, if the 300 responder supports the corresponding address family, and absent 301 any policy, the responder sends back ENCDNS_IP* attribute(s) in 302 the CFG_REPLY with an appropriate list of IP addresses, service 303 parameters, and an ADN. The list of IP addresses MUST include at 304 least one IP address. The responder may ignore suggested values 305 (if any). Multiple instances of the same ENCDNS_IP* attribute MAY 306 be returned if distinct ADNs or service parameters are to be 307 returned by the responder. The same or distinct IP addresses can 308 be returned in such instances. These instances SHOULD be 309 processed following their service priority (i.e., smaller service 310 priority indicates a higher preference). 312 In addition, the responder MAY return the ENCDNS_DIGEST_INFO 313 attribute to convey a digest of the certificate of the Encrypted 314 DNS and the identifier of the hash algorithm that is used to 315 generate the digest. 317 If the CFG_REQUEST includes an ENCDNS_IP* attribute but the 318 CFG_REPLY does not include an ENCDNS_IP* matching the requested 319 address family, this is an indication that requested address 320 family is not supported by the responder or the responder is not 321 configured to provide corresponding server addresses. 323 If the initiator receives both ENCDNS_IP* and INTERNAL_IP6_DNS (or 324 INTERNAL_IP4_DNS) attributes, it is RECOMMENDED that the initiator 325 uses the Encrypted DNS servers. 327 The DNS client establishes an encrypted DNS session (e.g., DoT, DoH, 328 DoQ) with the address(es) conveyed in ENCDNS_IP* and uses the 329 mechanism discussed in Section 8 of [RFC8310] to authenticate the DNS 330 server certificate using the authentication domain name conveyed in 331 ENCDNS_IP*. 333 If the CFG_REPLY includes an ENCDNS_DIGEST_INFO attribute, the DNS 334 client has to create a digest of the DNS server certificate received 335 in the TLS handshake using the negotiated hash algorithm in the 336 ENCDNS_DIGEST_INFO attribute. If the computed digest for an ADN 337 matches the one sent in the ENCDNS_DIGEST_INFO attribute, the 338 encrypted DNS server certificate is successfully validated. If so, 339 the client continues with the TLS connection as normal. Otherwise, 340 the client MUST treat the server certificate validation failure as a 341 non-recoverable error. This approach is similar to certificate usage 342 PKIX-EE(1) defined in [RFC7671]. 344 If the IPsec connection is a split-tunnel configuration and the 345 initiator negotiated INTERNAL_DNS_DOMAIN as per [RFC8598], the DNS 346 client resolves the internal names using ENCDNS_IP* DNS servers. 348 Note: [RFC8598] requires INTERNAL_IP6_DNS (or INTERNAL_IP4_DNS) 349 attribute to be mandatory present when INTERNAL_DNS_DOMAIN is 350 included. This specification relaxes that constraint in the 351 presence of ENCDNS_IP* attributes. That is, if ENCDNS_IP* 352 attributes are supplied, it is allowed to include 353 INTERNAL_DNS_DOMAIN even in the absence of INTERNAL_IP6_DNS (or 354 INTERNAL_IP4_DNS) attributes. 356 5. Security Considerations 358 This document adheres to the security considerations defined in 359 [RFC7296]. In particular, this document does not alter the trust on 360 the DNS configuration provided by a responder. 362 Networks are susceptible to internal attacks as discussed in 363 Section 3.2 of [I-D.arkko-farrell-arch-model-t]. Hosting encrypted 364 DNS server even in case of split-VPN configuration minimizes the 365 attack vector (e.g., a compromised network device cannot monitor/ 366 modify DNS traffic). This specification describes a mechanism to 367 restrict access to the DNS messages to only the parties that need to 368 know. 370 The initiator may trust the encrypted DNS servers supplied by means 371 of IKEv2 from a trusted responder more than the locally provided DNS 372 servers, especially in the case of connecting to unknown or untrusted 373 networks (e.g., coffee shops or hotel networks). 375 If IKEv2 responder has used NULL Authentication method [RFC7619] to 376 authenticate itself, the initiator MUST NOT use returned ENCDNS_IP* 377 servers configuration unless it is pre-configured in the OS or the 378 browser. 380 This specification does not extend the scope of accepting DNSSEC 381 trust anchors beyond the usage guidelines defined in Section 6 of 382 [RFC8598]. 384 6. IANA Considerations 386 6.1. Configuration Payload Attribute Types 388 This document requests IANA to assign the following new IKEv2 389 Configuration Payload Attribute Types from the "IKEv2 Configuration 390 Payload Attribute Types" namespace available at 391 https://www.iana.org/assignments/ikev2-parameters/ 392 ikev2-parameters.xhtml#ikev2-parameters-21. 394 Multi- 395 Value Attribute Type Valued Length Reference 396 ------ ------------------ ----- --------- --------- 397 TBA1 ENCDNS_IP4 YES 0 or more RFC XXXX 398 TBA2 ENCDNS_IP6 YES 0 or more RFC XXXX 399 TBA3 ENCDNS_ENCDNS_DIGEST_INFO YES 0 or more RFC XXXX 401 7. Acknowledgements 403 Many thanks to Yoav Nir, Christian Jacquenet, Paul Wouters, and Tommy 404 Pauly for the review and comments. 406 Yoav and Paul suggested the use of one single attribute carrying both 407 the name and an IP address instead of depending on the existing 408 INTERNAL_IP6_DNS and INTERNAL_IP4_DNS attributes. 410 Christian Huitema suggested to return a port number in the 411 attributes. 413 8. References 415 8.1. Normative References 417 [Hash] "IKEv2 Hash Algorithms", 418 . 421 [I-D.ietf-dnsop-svcb-https] 422 Schwartz, B., Bishop, M., and E. Nygren, "Service binding 423 and parameter specification via the DNS (DNS SVCB and 424 HTTPS RRs)", Work in Progress, Internet-Draft, draft-ietf- 425 dnsop-svcb-https-08, 12 October 2021, 426 . 429 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 430 Requirement Levels", BCP 14, RFC 2119, 431 DOI 10.17487/RFC2119, March 1997, 432 . 434 [RFC5890] Klensin, J., "Internationalized Domain Names for 435 Applications (IDNA): Definitions and Document Framework", 436 RFC 5890, DOI 10.17487/RFC5890, August 2010, 437 . 439 [RFC7296] Kaufman, C., Hoffman, P., Nir, Y., Eronen, P., and T. 440 Kivinen, "Internet Key Exchange Protocol Version 2 441 (IKEv2)", STD 79, RFC 7296, DOI 10.17487/RFC7296, October 442 2014, . 444 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 445 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 446 May 2017, . 448 [RFC8310] Dickinson, S., Gillmor, D., and T. Reddy, "Usage Profiles 449 for DNS over TLS and DNS over DTLS", RFC 8310, 450 DOI 10.17487/RFC8310, March 2018, 451 . 453 8.2. Informative References 455 [I-D.arkko-farrell-arch-model-t] 456 Arkko, J. and S. Farrell, "Challenges and Changes in the 457 Internet Threat Model", Work in Progress, Internet-Draft, 458 draft-arkko-farrell-arch-model-t-04, 13 July 2020, 459 . 462 [I-D.ietf-dprive-dnsoquic] 463 Huitema, C., Dickinson, S., and A. Mankin, "DNS over 464 Dedicated QUIC Connections", Work in Progress, Internet- 465 Draft, draft-ietf-dprive-dnsoquic-07, 1 December 2021, 466 . 469 [RFC7619] Smyslov, V. and P. Wouters, "The NULL Authentication 470 Method in the Internet Key Exchange Protocol Version 2 471 (IKEv2)", RFC 7619, DOI 10.17487/RFC7619, August 2015, 472 . 474 [RFC7671] Dukhovni, V. and W. Hardaker, "The DNS-Based 475 Authentication of Named Entities (DANE) Protocol: Updates 476 and Operational Guidance", RFC 7671, DOI 10.17487/RFC7671, 477 October 2015, . 479 [RFC7858] Hu, Z., Zhu, L., Heidemann, J., Mankin, A., Wessels, D., 480 and P. Hoffman, "Specification for DNS over Transport 481 Layer Security (TLS)", RFC 7858, DOI 10.17487/RFC7858, May 482 2016, . 484 [RFC8484] Hoffman, P. and P. McManus, "DNS Queries over HTTPS 485 (DoH)", RFC 8484, DOI 10.17487/RFC8484, October 2018, 486 . 488 [RFC8499] Hoffman, P., Sullivan, A., and K. Fujiwara, "DNS 489 Terminology", BCP 219, RFC 8499, DOI 10.17487/RFC8499, 490 January 2019, . 492 [RFC8598] Pauly, T. and P. Wouters, "Split DNS Configuration for the 493 Internet Key Exchange Protocol Version 2 (IKEv2)", 494 RFC 8598, DOI 10.17487/RFC8598, May 2019, 495 . 497 Appendix A. Sample Deployment Scenarios 499 A.1. Roaming Enterprise Users 501 In this Enterprise scenario (Section 1.1.3 of [RFC7296]), a roaming 502 user connects to the Enterprise network through an IPsec tunnel. The 503 split-tunnel Virtual Private Network (VPN) configuration allows the 504 endpoint to access hosts that resides in the Enterprise network 505 [RFC8598] using that tunnel; other traffic not destined to the 506 Enterprise does not traverse the tunnel. In contrast, a non-split- 507 tunnel VPN configuration causes all traffic to traverse the tunnel 508 into the enterprise. 510 For both split- and non-split-tunnel configurations, the use of 511 encrypted DNS instead of Do53 provides privacy and integrity 512 protection along the entire path (rather than just to the VPN 513 termination device) and can communicate the encrypted DNS server 514 policies. 516 For split-tunnel VPN configurations, the endpoint uses the 517 Enterprise-provided encrypted DNS server to resolve internal-only 518 domain names. 520 For non-split-tunnel VPN configurations, the endpoint uses the 521 Enterprise-provided encrypted DNS server to resolve both internal and 522 external domain names. 524 Enterprise networks are susceptible to internal and external attacks. 525 To minimize that risk all enterprise traffic is encrypted 526 (Section 2.1 of [I-D.arkko-farrell-arch-model-t]). 528 A.2. VPN Service Provider 530 Legacy VPN service providers usually preserve end-users' data 531 confidentiality by sending all communication traffic through an 532 encrypted tunnel. A VPN service provider can also provide guarantees 533 about the security of the VPN network by filtering malware and 534 phishing domains. 536 Browsers and OSes support DoH/DoT; VPN providers may no longer expect 537 DNS clients to fallback to Do53 just because it is a closed network. 539 The encrypted DNS server hosted by the VPN service provider can be 540 securely discovered by the endpoint using the IKEv2 Configuration 541 Payload Attribute Type. 543 A.3. DNS Offload 545 VPN service providers typically allow split-tunnel VPN configuration 546 in which users can choose applications that can be excluded from the 547 tunnel. For example, users may exclude applications that restrict 548 VPN access. 550 The encrypted DNS server hosted by the VPN service provider can be 551 securely discovered by the endpoint using the IKEv2 Configuration 552 Payload Attribute Type. 554 Authors' Addresses 555 Mohamed Boucadair 556 Orange 557 35000 Rennes 558 France 560 Email: mohamed.boucadair@orange.com 562 Tirumaleswar Reddy 563 Akamai 564 Embassy Golf Link Business Park 565 Bangalore 560071 566 Karnataka 567 India 569 Email: kondtir@gmail.com 571 Dan Wing 572 Citrix Systems, Inc. 573 United States of America 575 Email: dwing-ietf@fuggles.com 577 Valery Smyslov 578 ELVIS-PLUS 579 Russian Federation 581 Email: svan@elvis.ru