idnits 2.17.00 (12 Aug 2021) /tmp/idnits50919/draft-ietf-ipsecme-add-ike-02.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 (26 April 2022) is 18 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: 28 October 2022 Akamai 6 D. Wing 7 Citrix 8 V. Smyslov 9 ELVIS-PLUS 10 26 April 2022 12 Internet Key Exchange Protocol Version 2 (IKEv2) Configuration for 13 Encrypted DNS 14 draft-ietf-ipsecme-add-ike-02 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 28 October 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 . . . 6 62 4. IKEv2 Protocol Exchange . . . . . . . . . . . . . . . . . . . 7 63 5. Security Considerations . . . . . . . . . . . . . . . . . . . 9 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 . . . . . . . . . . . . . . . . . 11 70 Appendix A. Sample Deployment Scenarios . . . . . . . . . . . . 12 71 A.1. Roaming Enterprise Users . . . . . . . . . . . . . . . . 12 72 A.2. VPN Service Provider . . . . . . . . . . . . . . . . . . 12 73 A.3. DNS Offload . . . . . . . . . . . . . . . . . . . . . . . 13 74 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 13 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 described 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]. The following service 214 parameters are RECOMMENDED to be supported by an implementation: 216 alpn: Used to indicate the set of supported protocols 217 (Section 7.1 of [I-D.ietf-dnsop-svcb-https]). 219 port: Used to indicate the target port number for the encrypted 220 DNS connection (Section 7.2 of [I-D.ietf-dnsop-svcb-https]). 222 ech: Used to enable Encrypted ClientHello (ECH) (Section 7.3 of 223 [I-D.ietf-dnsop-svcb-https]). 225 dohpath: Used to supply a relative DoH URI Template (Section 5.1 226 of [I-D.ietf-add-svcb-dns]). 228 The service parameters MUST NOT include "ipv4hint" or "ipv6hint" 229 SvcParams as they are superseded by the included IP addresses. 231 If no port service parameter is included, this indicates that 232 default port numbers should be used. As a reminder, the default 233 port number is 853 for DoT, 443 for DoH, and 853 for DoQ. 235 The service parameters apply to all IP addresses in the ENCDNS_IP* 236 Configuration Payload Attribute. 238 3.2. ENCDNS_DIGEST_INFO Configuration Payload Attribute 240 The format of ENCDNS_DIGEST_INFO configuration payload attribute is 241 shown in Figure 2. 243 1 2 3 244 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 245 +-+-----------------------------+-------------------------------+ 246 |R| Attribute Type | Length | 247 +-+-----------------------------+---------------+---------------+ 248 | RESERVED | ADN Length | 249 +-----------------------------------------------+---------------+ 250 ~ Authentication Domain Name ~ 251 +---------------------------------------------------------------+ 252 ~ Hash Algorithm Identifiers ~ 253 +---------------------------------------------------------------+ 254 ~ Certificate Digest ~ 255 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 257 Figure 2: ENCDNS_DIGEST_INFO Attribute Format 259 * R (Reserved, 1 bit) - This bit MUST be set to zero and MUST be 260 ignored on receipt (see Section 3.15.1 of [RFC7296] for details). 262 * Attribute Type (15 bits) - Identifier for Configuration Attribute 263 Type; is set to TBA3 value listed in Section 6.1. 265 * Length (2 octets, unsigned integer) - Length of the data in 266 octets. 268 * RESERVED (3 octets) - These bits are reserved for future use. 269 These bits MUST be set to zero by the sender and MUST be ignored 270 by the receiver. 272 * ADN Length (1 octet) - Indicates the length of the "Authentication 273 Domain Name" field in octets. When set to '0', this means that 274 the digest applies on the ADN conveyed in the ENCDNS_IP* 275 Configuration Payload Attribute(s). 277 * Authentication Domain Name (variable) - A fully qualified domain 278 name of the encrypted DNS server following the syntax defined in 279 [RFC5890]. The name MUST NOT contain any terminators (e.g., NULL, 280 CR). A name is included only when multiple ADNs are included in 281 the ENCDNS_IP* Configuration Payload Attributes. 283 * Hash Algorithm Identifiers (variable) - In a request, this field 284 specifies a list of 16-bit hash algorithm identifiers that are 285 supported by the encrypted DNS client. In a response, this field 286 specifies the 16-bit hash algorithm identifier selected by the 287 server to generate the digest of its certificate. 289 The values of this field are taken from the Hash Algorithm 290 Identifiers of IANA's "Internet Key Exchange Version 2 (IKEv2) 291 Parameters" registry [Hash]. 293 There is no padding between the hash algorithm identifiers. 295 Note that SHA2-256 is mandatory to implement. 297 * Certificate Digest (variable) - MUST only be present in a 298 response. This field includes the digest of the encrypted DNS 299 server certificate using the algorithm identified in the 'Hash 300 Algorithm Identifiers' field. 302 4. IKEv2 Protocol Exchange 304 This section describes how an initiator can be configured with an 305 encrypted DNS server (e.g., DoH, DoT) using IKEv2. 307 Initiators indicate the support of an encrypted DNS in the 308 CFG_REQUEST payloads by including one or two ENCDNS_IP* attributes, 309 while responders supply the encrypted DNS configuration in the 310 CFG_REPLY payloads. Concretely: 312 If the initiator supports encrypted DNS, it includes one or two 313 ENCDNS_IP* attributes in the CFG_REQUEST. For each IP address 314 family the initiator MUST include exactly one attribute with the 315 Length field set to 0 if no specific DNS server is requested. The 316 initiator MAY include the ENCDNS_DIGEST_INFO attribute with a list 317 of hash algorithms that are supported by the encrypted DNS client. 319 For each ENCDNS_IP* attribute from the CFG_REQUEST, if the 320 responder supports the corresponding address family, and absent 321 any policy, the responder sends back ENCDNS_IP* attribute(s) in 322 the CFG_REPLY with an appropriate list of IP addresses, service 323 parameters, and an ADN. The list of IP addresses MUST include at 324 least one IP address. The responder may ignore suggested values 325 (if any). Multiple instances of the same ENCDNS_IP* attribute MAY 326 be returned if distinct ADNs or service parameters are to be 327 returned by the responder. The same or distinct IP addresses can 328 be returned in such instances. These instances SHOULD be 329 processed following their service priority (i.e., smaller service 330 priority indicates a higher preference). 332 In addition, the responder MAY return the ENCDNS_DIGEST_INFO 333 attribute to convey a digest of the certificate of the encrypted 334 DNS and the identifier of the hash algorithm that is used to 335 generate the digest. 337 If the CFG_REQUEST includes an ENCDNS_IP* attribute but the 338 CFG_REPLY does not include an ENCDNS_IP* matching the requested 339 address family, this is an indication that requested address 340 family is not supported by the responder or the responder is not 341 configured to provide corresponding server addresses. 343 If the initiator receives both ENCDNS_IP* and INTERNAL_IP6_DNS (or 344 INTERNAL_IP4_DNS) attributes, it is RECOMMENDED that the initiator 345 uses the encrypted DNS servers. 347 The DNS client establishes an encrypted DNS session (e.g., DoT, DoH, 348 DoQ) with the address(es) conveyed in ENCDNS_IP* and uses the 349 mechanism discussed in Section 8 of [RFC8310] to authenticate the DNS 350 server certificate using the authentication domain name conveyed in 351 ENCDNS_IP*. 353 If the CFG_REPLY includes an ENCDNS_DIGEST_INFO attribute, the DNS 354 client has to create a digest of the DNS server certificate received 355 in the TLS handshake using the negotiated hash algorithm in the 356 ENCDNS_DIGEST_INFO attribute. If the computed digest for an ADN 357 matches the one sent in the ENCDNS_DIGEST_INFO attribute, the 358 encrypted DNS server certificate is successfully validated. If so, 359 the client continues with the TLS connection as normal. Otherwise, 360 the client MUST treat the server certificate validation failure as a 361 non-recoverable error. This approach is similar to certificate usage 362 PKIX-EE(1) defined in [RFC7671]. 364 If the IPsec connection is a split-tunnel configuration and the 365 initiator negotiated INTERNAL_DNS_DOMAIN as per [RFC8598], the DNS 366 client resolves the internal names using ENCDNS_IP* DNS servers. 368 Note: [RFC8598] requires INTERNAL_IP6_DNS (or INTERNAL_IP4_DNS) 369 attribute to be mandatory present when INTERNAL_DNS_DOMAIN is 370 included. This specification relaxes that constraint in the 371 presence of ENCDNS_IP* attributes. That is, if ENCDNS_IP* 372 attributes are supplied, it is allowed to include 373 INTERNAL_DNS_DOMAIN even in the absence of INTERNAL_IP6_DNS (or 374 INTERNAL_IP4_DNS) attributes. 376 5. Security Considerations 378 This document adheres to the security considerations defined in 379 [RFC7296]. In particular, this document does not alter the trust on 380 the DNS configuration provided by a responder. 382 Networks are susceptible to internal attacks as discussed in 383 Section 3.2 of [I-D.arkko-farrell-arch-model-t]. Hosting encrypted 384 DNS servers even in case of split-VPN configuration minimizes the 385 attack vector (e.g., a compromised network device cannot monitor/ 386 modify DNS traffic). This specification describes a mechanism to 387 restrict access to the DNS messages to only the parties that need to 388 know. 390 The initiator may trust the encrypted DNS servers supplied by means 391 of IKEv2 from a trusted responder more than the locally provided DNS 392 servers, especially in the case of connecting to unknown or untrusted 393 networks (e.g., coffee shops or hotel networks). 395 If the IKEv2 responder has used NULL Authentication method [RFC7619] 396 to authenticate itself, the initiator MUST NOT use returned 397 ENCDNS_IP* servers configuration unless it is pre-configured, e.g., 398 in the OS or the browser. 400 This specification does not extend the scope of accepting DNSSEC 401 trust anchors beyond the usage guidelines defined in Section 6 of 402 [RFC8598]. 404 6. IANA Considerations 406 6.1. Configuration Payload Attribute Types 408 This document requests IANA to assign the following new IKEv2 409 Configuration Payload Attribute Types from the "IKEv2 Configuration 410 Payload Attribute Types" namespace available at [IANA-IKE]. 412 Multi- 413 Value Attribute Type Valued Length Reference 414 ------ ------------------ ----- --------- --------- 415 TBA1 ENCDNS_IP4 YES 0 or more RFC XXXX 416 TBA2 ENCDNS_IP6 YES 0 or more RFC XXXX 417 TBA3 ENCDNS_ENCDNS_DIGEST_INFO YES 0 or more RFC XXXX 419 7. Acknowledgements 421 Many thanks to Yoav Nir, Christian Jacquenet, Paul Wouters, and Tommy 422 Pauly for the review and comments. 424 Yoav and Paul suggested the use of one single attribute carrying both 425 the name and an IP address instead of depending on the existing 426 INTERNAL_IP6_DNS and INTERNAL_IP4_DNS attributes. 428 8. References 430 8.1. Normative References 432 [Hash] "IKEv2 Hash Algorithms", 433 . 436 [I-D.ietf-add-svcb-dns] 437 Schwartz, B., "Service Binding Mapping for DNS Servers", 438 Work in Progress, Internet-Draft, draft-ietf-add-svcb-dns- 439 03, 22 April 2022, . 442 [I-D.ietf-dnsop-svcb-https] 443 Schwartz, B., Bishop, M., and E. Nygren, "Service binding 444 and parameter specification via the DNS (DNS SVCB and 445 HTTPS RRs)", Work in Progress, Internet-Draft, draft-ietf- 446 dnsop-svcb-https-08, 12 October 2021, 447 . 450 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 451 Requirement Levels", BCP 14, RFC 2119, 452 DOI 10.17487/RFC2119, March 1997, 453 . 455 [RFC5890] Klensin, J., "Internationalized Domain Names for 456 Applications (IDNA): Definitions and Document Framework", 457 RFC 5890, DOI 10.17487/RFC5890, August 2010, 458 . 460 [RFC7296] Kaufman, C., Hoffman, P., Nir, Y., Eronen, P., and T. 461 Kivinen, "Internet Key Exchange Protocol Version 2 462 (IKEv2)", STD 79, RFC 7296, DOI 10.17487/RFC7296, October 463 2014, . 465 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 466 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 467 May 2017, . 469 [RFC8310] Dickinson, S., Gillmor, D., and T. Reddy, "Usage Profiles 470 for DNS over TLS and DNS over DTLS", RFC 8310, 471 DOI 10.17487/RFC8310, March 2018, 472 . 474 8.2. Informative References 476 [I-D.arkko-farrell-arch-model-t] 477 Arkko, J. and S. Farrell, "Challenges and Changes in the 478 Internet Threat Model", Work in Progress, Internet-Draft, 479 draft-arkko-farrell-arch-model-t-04, 13 July 2020, 480 . 483 [I-D.ietf-dprive-dnsoquic] 484 Huitema, C., Dickinson, S., and A. Mankin, "DNS over 485 Dedicated QUIC Connections", Work in Progress, Internet- 486 Draft, draft-ietf-dprive-dnsoquic-12, 20 April 2022, 487 . 490 [IANA-IKE] "IKEv2 Configuration Payload Attribute Types", 491 . 494 [RFC7619] Smyslov, V. and P. Wouters, "The NULL Authentication 495 Method in the Internet Key Exchange Protocol Version 2 496 (IKEv2)", RFC 7619, DOI 10.17487/RFC7619, August 2015, 497 . 499 [RFC7671] Dukhovni, V. and W. Hardaker, "The DNS-Based 500 Authentication of Named Entities (DANE) Protocol: Updates 501 and Operational Guidance", RFC 7671, DOI 10.17487/RFC7671, 502 October 2015, . 504 [RFC7858] Hu, Z., Zhu, L., Heidemann, J., Mankin, A., Wessels, D., 505 and P. Hoffman, "Specification for DNS over Transport 506 Layer Security (TLS)", RFC 7858, DOI 10.17487/RFC7858, May 507 2016, . 509 [RFC8484] Hoffman, P. and P. McManus, "DNS Queries over HTTPS 510 (DoH)", RFC 8484, DOI 10.17487/RFC8484, October 2018, 511 . 513 [RFC8499] Hoffman, P., Sullivan, A., and K. Fujiwara, "DNS 514 Terminology", BCP 219, RFC 8499, DOI 10.17487/RFC8499, 515 January 2019, . 517 [RFC8598] Pauly, T. and P. Wouters, "Split DNS Configuration for the 518 Internet Key Exchange Protocol Version 2 (IKEv2)", 519 RFC 8598, DOI 10.17487/RFC8598, May 2019, 520 . 522 Appendix A. Sample Deployment Scenarios 524 A.1. Roaming Enterprise Users 526 In this Enterprise scenario (Section 1.1.3 of [RFC7296]), a roaming 527 user connects to the Enterprise network through an IPsec tunnel. The 528 split-tunnel Virtual Private Network (VPN) configuration allows the 529 endpoint to access hosts that resides in the Enterprise network 530 [RFC8598] using that tunnel; other traffic not destined to the 531 Enterprise does not traverse the tunnel. In contrast, a non-split- 532 tunnel VPN configuration causes all traffic to traverse the tunnel 533 into the enterprise. 535 For both split- and non-split-tunnel configurations, the use of 536 encrypted DNS instead of Do53 provides privacy and integrity 537 protection along the entire path (rather than just to the VPN 538 termination device) and can communicate the encrypted DNS server 539 policies. 541 For split-tunnel VPN configurations, the endpoint uses the 542 Enterprise-provided encrypted DNS server to resolve internal-only 543 domain names. 545 For non-split-tunnel VPN configurations, the endpoint uses the 546 Enterprise-provided encrypted DNS server to resolve both internal and 547 external domain names. 549 Enterprise networks are susceptible to internal and external attacks. 550 To minimize that risk all enterprise traffic is encrypted 551 (Section 2.1 of [I-D.arkko-farrell-arch-model-t]). 553 A.2. VPN Service Provider 555 Legacy VPN service providers usually preserve end-users' data 556 confidentiality by sending all communication traffic through an 557 encrypted tunnel. A VPN service provider can also provide guarantees 558 about the security of the VPN network by filtering malware and 559 phishing domains. 561 Browsers and OSes support DoH/DoT; VPN providers may no longer expect 562 DNS clients to fallback to Do53 just because it is a closed network. 564 The encrypted DNS server hosted by the VPN service provider can be 565 securely discovered by the endpoint using the IKEv2 Configuration 566 Payload Attribute Type. 568 A.3. DNS Offload 570 VPN service providers typically allow split-tunnel VPN configuration 571 in which users can choose applications that can be excluded from the 572 tunnel. For example, users may exclude applications that restrict 573 VPN access. 575 The encrypted DNS server hosted by the VPN service provider can be 576 securely discovered by the endpoint using the IKEv2 Configuration 577 Payload Attribute Type. 579 Authors' Addresses 581 Mohamed Boucadair 582 Orange 583 35000 Rennes 584 France 585 Email: mohamed.boucadair@orange.com 587 Tirumaleswar Reddy 588 Akamai 589 Embassy Golf Link Business Park 590 Bangalore 560071 591 Karnataka 592 India 593 Email: kondtir@gmail.com 595 Dan Wing 596 Citrix Systems, Inc. 597 United States of America 598 Email: dwing-ietf@fuggles.com 600 Valery Smyslov 601 ELVIS-PLUS 602 Russian Federation 603 Email: svan@elvis.ru