idnits 2.17.1 draft-btw-add-ipsecme-ike-03.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 (May 17, 2021) is 1074 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 (-12) exists of draft-ietf-dnsop-svcb-https-05 == Outdated reference: A later version (-12) exists of draft-ietf-dprive-dnsoquic-02 -- Obsolete informational reference (is this intentional?): RFC 8499 (Obsoleted by RFC 9499) Summary: 0 errors (**), 0 flaws (~~), 3 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 ADD M. Boucadair 3 Internet-Draft Orange 4 Intended status: Standards Track T. Reddy 5 Expires: November 18, 2021 McAfee 6 D. Wing 7 Citrix 8 V. Smyslov 9 ELVIS-PLUS 10 May 17, 2021 12 Internet Key Exchange Protocol Version 2 (IKEv2) Configuration for 13 Encrypted DNS 14 draft-btw-add-ipsecme-ike-03 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 November 18, 2021. 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 47 (https://trustee.ietf.org/license-info) in effect on the date of 48 publication of this document. Please review these documents 49 carefully, as they describe your rights and restrictions with respect 50 to this document. Code Components extracted from this document must 51 include Simplified BSD License text as described in Section 4.e of 52 the Trust Legal Provisions and are provided without warranty as 53 described in the Simplified BSD License. 55 Table of Contents 57 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 58 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 59 3. IKEv2 Configuration Payload Attribute Types for Encrypted 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 . . . . . . . . . . . . . . . . . . . . . . . . . 9 68 8.1. Normative References . . . . . . . . . . . . . . . . . . 9 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 | RESERVED | 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 o 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 o Attribute Type (15 bits) - Identifier for Configuration Attribute 162 Type; is set to TBA1 or TBA2 values listed in Section 6.1. 164 o 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 or 168 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_REPLY or CFG_SET; N being the number of included IPv4 173 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_REPLY or CFG_SET; N being the number of included IPv6 178 addresses ('Num addresses'). 180 o RESERVED (2 octets) - These bits are reserved for future use. 181 These bits MUST be set to zero by the sender and MUST be ignored 182 by the receiver. 184 o Num Addresses (1 octet) - Indicates the number of enclosed IPv4 185 (for ENCDNS_IP4 attribute type) or IPv6 (for ENCDNS_IP6 attribute 186 type) addresses. It MUST NOT be set to 0. 188 o ADN Length (1 octet) - Indicates the length of the authentication- 189 domain-name field in octets. 191 o IP Address(es) (variable) - One or more IPv4 or IPv6 addresses to 192 be used to reach the encrypted DNS server that is identified by 193 the name in the Authentication Domain Name. 195 o Authentication Domain Name (variable) - A fully qualified domain 196 name of the encrypted DNS server following the syntax defined in 197 [RFC5890]. The name MUST NOT contain any terminators (e.g., NULL, 198 CR). 200 An example of a valid ADN for DoH server is "doh1.example.com". 202 o Service Parameters (SvcParams) (variable) - Specifies a set of 203 service parameters that are encoded following the rules in 204 Section 2.1 of [I-D.ietf-dnsop-svcb-https]. Service parameters 205 may include, for example, a list of ALPN protocol identifiers or 206 alternate port numbers. The service parameters MUST NOT include 207 "ipv4hint" or "ipv6hint" SvcParams as they are superseded by the 208 included IP addresses. 210 If no port service parameter is included, this indicates that 211 default port numbers should be used. As a reminder, the default 212 port number is 853 for DoT and 443 for DoH. 214 The service parameters apply to all IP addresses in the ENCDNS_IP* 215 Configuration Payload Attribute. 217 3.2. ENCDNS_DIGEST_INFO Configuration Payload Attribute 219 The format of ENCDNS_DIGEST_INFO configuration payload attribute is 220 shown in Figure 2. 222 1 2 3 223 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 224 +-+-----------------------------+-------------------------------+ 225 |R| Attribute Type | Length | 226 +-+-----------------------------+---------------+---------------+ 227 | RESERVED | ADN Length | 228 +-----------------------------------------------+---------------+ 229 ~ Authentication Domain Name ~ 230 +---------------------------------------------------------------+ 231 ~ Hash Algorithm Identifiers ~ 232 +---------------------------------------------------------------+ 233 ~ Certificate Digest ~ 234 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 236 Figure 2: ENCDNS_DIGEST_INFO Attribute Format 238 o R (Reserved, 1 bit) - This bit MUST be set to zero and MUST be 239 ignored on receipt (see Section 3.15.1 of [RFC7296] for details). 241 o Attribute Type (15 bits) - Identifier for Configuration Attribute 242 Type; is set to TBA3 value listed in Section 6.1. 244 o Length (2 octets, unsigned integer) - Length of the data in 245 octets. 247 o RESERVED (2 octets) - These bits are reserved for future use. 248 These bits MUST be set to zero by the sender and MUST be ignored 249 by the receiver. 251 o ADN Length (1 octet) - Indicates the length of the authentication- 252 domain-name field in octets. When set to '0', this means that the 253 digest applies on the ADN conveyed in the ENCDNS_IP* Configuration 254 Payload Attribute(s). 256 o Authentication Domain Name (variable) - A fully qualified domain 257 name of the encrypted DNS server following the syntax defined in 258 [RFC5890]. The name MUST NOT contain any terminators (e.g., NULL, 259 CR). A name is included only when multiple ADNs are included in 260 the ENCDNS_IP* Configuration Payload Attributes. 262 o Hash Algorithm Identifiers (variable) - In a request, this field 263 specifies a list of 16-bit hash algorithm identifiers that are 264 supported by the Encrypted DNS client. In a response, this field 265 specified the 16-bit hash algorithm identifier selected by the 266 server to generate the digest of its certificate. The values of 267 this field are taken from the Hash Algorithm Identifiers of IANA's 268 "Internet Key Exchange Version 2 (IKEv2) Parameters" registry 269 [Hash]. 271 There is no padding between the hash algorithm identifiers. 273 Note that SHA2-256 is mandatory to implement. 275 o Certificate Digest (variable) - MUST only be present in a 276 response. This field includes the digest of the Encrypted DNS 277 server certificate using the algorthm identified in the 'Hash 278 Algorithm Identifiers' field. 280 4. IKEv2 Protocol Exchange 282 This section describes how an initiator can be configured with an 283 encrypted DNS server (e.g., DoH, DoT) using IKEv2. 285 Initiators indicate the support of an encrypted DNS in the 286 CFG_REQUEST payloads by including one or two ENCDNS_IP* attributes, 287 while responders supply the encrypted DNS configuration in the 288 CFG_REPLY payloads. Concretely: 290 If the initiator supports encrypted DNS, it includes one or two 291 ENCDNS_IP* attributes in the CFG_REQUEST. For each IP address 292 family the initiator MUST include exactly one attribute with the 293 Length field set to 0, so that no data is included for these 294 attributes. The initiator MAY include the ENCDNS_DIGEST_INFO 295 attribute with a list of hash algorithms that are supported by the 296 Encrypted DNS client. 298 For each ENCDNS_IP* attribute from the CFG_REQUEST, if the 299 responder supports the corresponding address family, and absent 300 any policy, the responder sends back ENCDNS_IP* attribute(s) in 301 the CFG_REPLY with an appropriate list of IP addresses, service 302 parameters, and an ADN. The list of IP addresses MUST include at 303 least one IP address. Multiple instances of the same ENCDNS_IP* 304 attribute MAY be returned if distinct ADNs or service parameters 305 are to be returned by the responder. The same or distinct IP 306 addresses can be returned in such instances. In addition, the 307 responder MAY return the ENCDNS_DIGEST_INFO attribute to convey a 308 digest of the certificate of the Encrypted DNS and the identifier 309 of the hash algorithm that is used to generate the digest. 311 The behavior of the responder if it receives both ENCDNS_IP* and 312 INTERNAL_IP6_DNS (or INTERNAL_IP4_DNS) attributes is policy-based 313 and deployment-specific. However, it is RECOMMENDED that if the 314 responder includes at least one ENCDNS_IP* attribute in the reply, 315 it should not include any of INTERNAL_IP4_DNS/INTERNAL_IP6_DNS 316 attributes. 318 If the CFG_REQUEST includes an ENCDNS_IP* attribute but the 319 CFG_REPLY does not include an ENCDNS_IP* matching the requested 320 address family, this is an indication that requested address 321 family is not supported by the responder or the responder is not 322 configured to provide corresponding server addresses. 324 The DNS client establishes an encrypted DNS session (e.g., DoT, DoH, 325 DoQ) with the address(es) conveyed in ENCDNS_IP* and uses the 326 mechanism discussed in Section 8 of [RFC8310] to authenticate the DNS 327 server certificate using the authentication domain name conveyed in 328 ENCDNS_IP*. 330 If the CFG_REPLY includes an ENCDNS_DIGEST_INFO attribute, the DNS 331 client has to create a digest of the DNS server certificate received 332 in the TLS handshake using the negotiated hash algorithm in the 333 ENCDNS_DIGEST_INFO attribute. If the computed digest for an ADN 334 matches the one sent in the ENCDNS_DIGEST_INFO attribute, the 335 encrypted DNS server certificate is successfully validated. If so, 336 the client continues with the TLS connection as normal. Otherwise, 337 the client MUST treat the server certificate validation failure as a 338 non-recoverable error. This approach is similar to certificate usage 339 PKIX-EE(1) defined in [RFC7671]. 341 If the IPsec connection is a split-tunnel configuration and the 342 initiator negotiated INTERNAL_DNS_DOMAIN as per [RFC8598], the DNS 343 client MUST resolve the internal names using ENCDNS_IP* DNS servers. 345 Note: [RFC8598] requires INTERNAL_IP6_DNS (or INTERNAL_IP4_DNS) 346 attribute to be mandatory present when INTERNAL_DNS_DOMAIN is 347 included. This specification relaxes that constraint in the 348 presence of ENCDNS_IP* attributes. 350 5. Security Considerations 352 This document adheres to the security considerations defined in 353 [RFC7296]. In particular, this document does not alter the trust on 354 the DNS configuration provided by a responder. 356 Networks are susceptible to internal attacks as discussed in 357 Section 3.2 of [I-D.arkko-farrell-arch-model-t]. Hosting encrypted 358 DNS server even in case of split-VPN configuration minimizes the 359 attack vector (e.g., a compromised network device cannot monitor/ 360 modify DNS traffic). This specification describes a mechanism to 361 restrict access to the DNS messages to only the parties that need to 362 know. 364 The initiator may trust the encrypted DNS servers supplied by means 365 of IKEv2 from a trusted responder more than the locally provided DNS 366 servers, especially in the case of connecting to unknown or untrusted 367 networks (e.g., coffee shops or hotel networks). 369 If IKEv2 responder has used NULL Authentication method [RFC7619] to 370 authenticate itself, the initiator MUST NOT use returned ENCDNS_IP* 371 servers configuration unless it is pre-configured in the OS or the 372 browser. 374 This specification does not extend the scope of accepting DNSSEC 375 trust anchors beyond the usage guidelines defined in Section 6 of 376 [RFC8598]. 378 6. IANA Considerations 380 6.1. Configuration Payload Attribute Types 382 This document requests IANA to assign the following new IKEv2 383 Configuration Payload Attribute Types from the "IKEv2 Configuration 384 Payload Attribute Types" namespace available at 385 https://www.iana.org/assignments/ikev2-parameters/ 386 ikev2-parameters.xhtml#ikev2-parameters-21. 388 Multi- 389 Value Attribute Type Valued Length Reference 390 ------ ------------------ ----- --------- --------- 391 TBA1 ENCDNS_IP4 YES 0 or more RFC XXXX 392 TBA2 ENCDNS_IP6 YES 0 or more RFC XXXX 393 TBA3 ENCDNS_ENCDNS_DIGEST_INFO YES 0 or more RFC XXXX 395 7. Acknowledgements 397 Many thanks to Yoav Nir, Christian Jacquenet, Paul Wouters, and Tommy 398 Pauly for the review and comments. 400 Yoav and Paul suggested the use of one single attribute carrying both 401 the name and an IP address instead of depending on the existing 402 INTERNAL_IP6_DNS and INTERNAL_IP4_DNS attributes. 404 Christian Huitema suggested to return a port number in the 405 attributes. 407 8. References 409 8.1. Normative References 411 [Hash] "IKEv2 Hash Algorithms", 412 . 415 [I-D.ietf-dnsop-svcb-https] 416 Schwartz, B., Bishop, M., and E. Nygren, "Service binding 417 and parameter specification via the DNS (DNS SVCB and 418 HTTPS RRs)", draft-ietf-dnsop-svcb-https-05 (work in 419 progress), April 2021. 421 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 422 Requirement Levels", BCP 14, RFC 2119, 423 DOI 10.17487/RFC2119, March 1997, 424 . 426 [RFC5890] Klensin, J., "Internationalized Domain Names for 427 Applications (IDNA): Definitions and Document Framework", 428 RFC 5890, DOI 10.17487/RFC5890, August 2010, 429 . 431 [RFC7296] Kaufman, C., Hoffman, P., Nir, Y., Eronen, P., and T. 432 Kivinen, "Internet Key Exchange Protocol Version 2 433 (IKEv2)", STD 79, RFC 7296, DOI 10.17487/RFC7296, October 434 2014, . 436 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 437 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 438 May 2017, . 440 [RFC8310] Dickinson, S., Gillmor, D., and T. Reddy, "Usage Profiles 441 for DNS over TLS and DNS over DTLS", RFC 8310, 442 DOI 10.17487/RFC8310, March 2018, 443 . 445 8.2. Informative References 447 [I-D.arkko-farrell-arch-model-t] 448 Arkko, J. and S. Farrell, "Challenges and Changes in the 449 Internet Threat Model", draft-arkko-farrell-arch-model- 450 t-04 (work in progress), July 2020. 452 [I-D.ietf-dprive-dnsoquic] 453 Huitema, C., Mankin, A., and S. Dickinson, "Specification 454 of DNS over Dedicated QUIC Connections", draft-ietf- 455 dprive-dnsoquic-02 (work in progress), February 2021. 457 [RFC7619] Smyslov, V. and P. Wouters, "The NULL Authentication 458 Method in the Internet Key Exchange Protocol Version 2 459 (IKEv2)", RFC 7619, DOI 10.17487/RFC7619, August 2015, 460 . 462 [RFC7671] Dukhovni, V. and W. Hardaker, "The DNS-Based 463 Authentication of Named Entities (DANE) Protocol: Updates 464 and Operational Guidance", RFC 7671, DOI 10.17487/RFC7671, 465 October 2015, . 467 [RFC7858] Hu, Z., Zhu, L., Heidemann, J., Mankin, A., Wessels, D., 468 and P. Hoffman, "Specification for DNS over Transport 469 Layer Security (TLS)", RFC 7858, DOI 10.17487/RFC7858, May 470 2016, . 472 [RFC8484] Hoffman, P. and P. McManus, "DNS Queries over HTTPS 473 (DoH)", RFC 8484, DOI 10.17487/RFC8484, October 2018, 474 . 476 [RFC8499] Hoffman, P., Sullivan, A., and K. Fujiwara, "DNS 477 Terminology", BCP 219, RFC 8499, DOI 10.17487/RFC8499, 478 January 2019, . 480 [RFC8598] Pauly, T. and P. Wouters, "Split DNS Configuration for the 481 Internet Key Exchange Protocol Version 2 (IKEv2)", 482 RFC 8598, DOI 10.17487/RFC8598, May 2019, 483 . 485 Appendix A. Sample Deployment Scenarios 487 A.1. Roaming Enterprise Users 489 In this Enterprise scenario (Section 1.1.3 of [RFC7296]), a roaming 490 user connects to the Enterprise network through an IPsec tunnel. The 491 split-tunnel Virtual Private Network (VPN) configuration allows the 492 endpoint to access hosts that resides in the Enterprise network 493 [RFC8598] using that tunnel; other traffic not destined to the 494 Enterprise does not traverse the tunnel. In contrast, a non-split- 495 tunnel VPN configuration causes all traffic to traverse the tunnel 496 into the enterprise. 498 For both split- and non-split-tunnel configurations, the use of 499 encrypted DNS instead of Do53 provides privacy and integrity 500 protection along the entire path (rather than just to the VPN 501 termination device) and can communicate the encrypted DNS server 502 policies. 504 For split-tunnel VPN configurations, the endpoint uses the 505 Enterprise-provided encrypted DNS server to resolve internal-only 506 domain names. 508 For non-split-tunnel VPN configurations, the endpoint uses the 509 Enterprise-provided encrypted DNS server to resolve both internal and 510 external domain names. 512 Enterprise networks are susceptible to internal and external attacks. 513 To minimize that risk all enterprise traffic is encrypted 514 (Section 2.1 of [I-D.arkko-farrell-arch-model-t]). 516 A.2. VPN Service Provider 518 Legacy VPN service providers usually preserve end-users' data 519 confidentiality by sending all communication traffic through an 520 encrypted tunnel. A VPN service provider can also provide guarantees 521 about the security of the VPN network by filtering malware and 522 phishing domains. 524 Browsers and OSes support DoH/DoT; VPN providers may no longer expect 525 DNS clients to fallback to Do53 just because it is a closed network. 527 The encrypted DNS server hosted by the VPN service provider can be 528 securely discovered by the endpoint using the IKEv2 Configuration 529 Payload Attribute Type. 531 A.3. DNS Offload 533 VPN service providers typically allow split-tunnel VPN configuration 534 in which users can choose applications that can be excluded from the 535 tunnel. For example, users may exclude applications that restrict 536 VPN access. 538 The encrypted DNS server hosted by the VPN service provider can be 539 securely discovered by the endpoint using the IKEv2 Configuration 540 Payload Attribute Type. 542 Authors' Addresses 544 Mohamed Boucadair 545 Orange 546 Rennes 35000 547 France 549 Email: mohamed.boucadair@orange.com 550 Tirumaleswar Reddy 551 McAfee, Inc. 552 Embassy Golf Link Business Park 553 Bangalore, Karnataka 560071 554 India 556 Email: TirumaleswarReddy_Konda@McAfee.com 558 Dan Wing 559 Citrix Systems, Inc. 560 USA 562 Email: dwing-ietf@fuggles.com 564 Valery Smyslov 565 ELVIS-PLUS 566 RU 568 Email: svan@elvis.ru