idnits 2.17.1 draft-btw-add-ipsecme-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 (April 7, 2020) is 1479 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) == Outdated reference: A later version (-04) exists of draft-arkko-farrell-arch-model-t-03 == Outdated reference: A later version (-12) exists of draft-btw-add-home-04 == Outdated reference: A later version (-02) exists of draft-ietf-dnsop-terminology-ter-01 == Outdated reference: A later version (-09) exists of draft-reddy-add-server-policy-selection-00 -- Obsolete informational reference (is this intentional?): RFC 8499 (Obsoleted by RFC 9499) Summary: 0 errors (**), 0 flaws (~~), 5 warnings (==), 2 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: October 9, 2020 McAfee 6 D. Wing 7 Citrix 8 V. Smyslov 9 ELVIS-PLUS 10 April 7, 2020 12 Internet Key Exchange Protocol Version 2 (IKEv2) Configuration for 13 Encrypted DNS 14 draft-btw-add-ipsecme-ike-00 16 Abstract 18 This document specifies a new Internet Key Exchange Protocol Version 19 2 (IKEv2) Configuration Payload Attribute Type for encrypted DNS such 20 as DNS-over-HTTPS (DoH) and DNS-over-TLS (DoT). 22 Status of This Memo 24 This Internet-Draft is submitted in full conformance with the 25 provisions of BCP 78 and BCP 79. 27 Internet-Drafts are working documents of the Internet Engineering 28 Task Force (IETF). Note that other groups may also distribute 29 working documents as Internet-Drafts. The list of current Internet- 30 Drafts is at https://datatracker.ietf.org/drafts/current/. 32 Internet-Drafts are draft documents valid for a maximum of six months 33 and may be updated, replaced, or obsoleted by other documents at any 34 time. It is inappropriate to use Internet-Drafts as reference 35 material or to cite them other than as "work in progress." 37 This Internet-Draft will expire on October 9, 2020. 39 Copyright Notice 41 Copyright (c) 2020 IETF Trust and the persons identified as the 42 document authors. All rights reserved. 44 This document is subject to BCP 78 and the IETF Trust's Legal 45 Provisions Relating to IETF Documents 46 (https://trustee.ietf.org/license-info) in effect on the date of 47 publication of this document. Please review these documents 48 carefully, as they describe your rights and restrictions with respect 49 to this document. Code Components extracted from this document must 50 include Simplified BSD License text as described in Section 4.e of 51 the Trust Legal Provisions and are provided without warranty as 52 described in the Simplified BSD License. 54 Table of Contents 56 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 57 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 58 3. Sample Deployment Scenarios . . . . . . . . . . . . . . . . . 3 59 3.1. Roaming Enterprise Users . . . . . . . . . . . . . . . . 3 60 3.2. VPN Service Provider . . . . . . . . . . . . . . . . . . 4 61 3.3. DNS Offload . . . . . . . . . . . . . . . . . . . . . . . 4 62 4. INTERNAL_ENC_DNS Attribute . . . . . . . . . . . . . . . . . 4 63 5. URI Template . . . . . . . . . . . . . . . . . . . . . . . . 6 64 6. IKEv2 Protocol Exchange . . . . . . . . . . . . . . . . . . . 6 65 7. Security Considerations . . . . . . . . . . . . . . . . . . . 7 66 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 67 8.1. Configuration Payload Attribute Type . . . . . . . . . . 8 68 8.2. Encrypted DNS Types . . . . . . . . . . . . . . . . . . . 9 69 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 9 70 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 9 71 10.1. Normative References . . . . . . . . . . . . . . . . . . 9 72 10.2. Informative References . . . . . . . . . . . . . . . . . 10 73 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 11 75 1. Introduction 77 This document specifies encrypted DNS configuration for an IKE 78 initiator, particularly the Authentication Domain Name (ADN, defined 79 in [RFC8310]) of DNS-over-HTTPS (DoH) [RFC8484] or DNS-over-TLS (DoT) 80 [RFC7858] server using Internet Key Exchange Protocol Version 2 81 (IKEv2) [RFC7296]. 83 Particularly, this document introduces a new IKEv2 Configuration 84 Payload Attribute Types (Section 4) for the support of encrypted DNS 85 servers (e.g., DoT, DoH). 87 Sample use cases are discussed in Section 3. The Configuration 88 Payload Attribute Type defined in Section 4 is not specific to these 89 deployments, but can be used in other deployment contexts. 91 Note that, for many years, typical designs has often considered that 92 the DNS server was usually located inside the protected domain, but 93 could theoretically be located outside of it. With DoH or DoT, the 94 latter option becomes plausible. 96 2. Terminology 98 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 99 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 100 "OPTIONAL" in this document are to be interpreted as described in BCP 101 14 [RFC2119][RFC8174] when, and only when, they appear in all 102 capitals, as shown here. 104 This document makes use of the terms defined in [RFC8499] and 105 [I-D.ietf-dnsop-terminology-ter]. 107 Also, this document makes use of the terms defined in [RFC7296]. In 108 particular, readers should be familiar with "initiator" and 109 "responder" terms used in that document. 111 Do53 refers to unencrypted DNS. 113 'DoH/DoT' refers to DNS-over-HTTPS and/or DNS-over-TLS. 115 3. Sample Deployment Scenarios 117 3.1. Roaming Enterprise Users 119 In this Enterprise scenario (Section 1.1.3 of [RFC7296]), a roaming 120 user connects to the Enterprise network through an IPsec tunnel. The 121 split-tunnel Virtual Private Network (VPN) configuration allows the 122 endpoint to access hosts that resides in the Enterprise network 123 [RFC8598] using that tunnel; other traffic not destined to the 124 Enterprise does not traverse the tunnel. In contrast, a non-split- 125 tunnel VPN configuration causes all traffic to traverse the tunnel 126 into the enterprise. 128 For both split- and non-split-tunnel configurations, the use of DoT/ 129 DoH instead of Do53 provides privacy and integrity protection along 130 the entire path (rather than just to the VPN termination device) and 131 can communicate the DoT/DoH server policies. 133 For split-tunnel VPN configurations, the endpoint uses the 134 Enterprise-provided DoT/DoH server to resolve internal-only domain 135 names. 137 For non-split-tunnel VPN configurations, the endpoint uses the 138 Enterprise-provided DoT/DoH server to resolve both internal and 139 external domain names. 141 Enterprise networks are susceptible to internal and external attacks. 142 To minimize that risk all enterprise traffic is encrypted 143 (Section 2.1 of [I-D.arkko-farrell-arch-model-t]). 145 3.2. VPN Service Provider 147 Legacy VPN service providers usually preserve end-users' data 148 confidentiality by sending all communication traffic through an 149 encrypted tunnel. A VPN service provider can also provide guarantees 150 about the security of the VPN network by filtering malware and 151 phishing domains. 153 Browsers and OSes support DoH/DoT; VPN providers may no longer expect 154 DNS clients to fallback to Do53 just because it is a closed network. 156 The DoT/DoH server hosted by the VPN service provider can be securely 157 discovered by the endpoint using the IKEv2 Configuration Payload 158 Attribute Type. 160 3.3. DNS Offload 162 VPN service providers typically allow split-tunnel VPN configuration 163 in which users can choose applications that can be excluded from the 164 tunnel. For example, users may exclude applications that restrict 165 VPN access. 167 VPN service providers can also offer publicly accessible DoH/DoT 168 servers. The split-tunnel VPN configuration allows the client to 169 access the DoH/DoT servers hosted by the VPN provider without 170 traversing the tunnel. 172 The DoT/DoH server hosted by the VPN service provider can be securely 173 discovered by the endpoint using the IKEv2 Configuration Payload 174 Attribute Type. 176 4. INTERNAL_ENC_DNS Attribute 178 The INTERNAL_ENC_DNS IKEv2 Configuration Payload Attribute Type is 179 used to configure an encrypted DNS server. The format of this 180 attribute is shown in Figure 1. 182 1 2 3 183 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 184 +-+-----------------------------+-------------------------------+ 185 |R| Attribute Type | Length | 186 +-+-------------+---------------+-------------------------------+ 187 |S|Enc DNS Type | Num addresses | | 188 +-+-------------+---------------+ + 189 | IPv6 Addresses ~ 190 | +-------------------------------+ 191 ~ | | 192 +-------------------------------+ | 193 | | 194 ~ DNS Authentication Domain Name ~ 195 | | 196 +---------------------------------------------------------------+ 198 Figure 1: INTERNAL_ENC_DNS Attribute Format 200 The fields of the attribute shown in Figure 1 are as follows: 202 o R: Reserved bit; refer to Section 3.15.1 of [RFC7296]. 204 o Attribute Type: MUST be set to TBA (Section 8.1). 206 o Length: Length of the data in octets. It MUST be set to 1 if the 207 Configuration payload has types CFG_REQUEST or CFG_ACK or to (2 + 208 Length of the ADN + N * 16) if the Configuration payload has types 209 CFG_REPLY or CFG_SET; N being the number of included IP addresses 210 ('Num addresses'). 212 o S: Scope bit. This bit controls whether the DNS queries are sent 213 within the tunnel or outside. If set, this bit instructs the 214 initiator to send encrypted DNS queries outside the tunnel. If 215 the bit is unset, the queries are sent inside the tunnel. The 216 default value of this bit is "0". 218 o Encrypted DNS Type: Indicates the type of the encrypted DNS server 219 conveyed in this attribute. The following values are defined: 221 0: Reserved 223 1: DoT 225 2: DoH 227 See Section 8.2 for future assignment considerations. 229 o Num addresses: If Length > 1, it indicates the number of enclosed 230 IP addresses. 232 o IPv6 Address(es): One or more IPv6 addresses to be used to reach 233 the encrypted DNS identified by the name in the DNS Authentication 234 Domain Name. 236 IPv4 addresses MUST be encoded using the IPv4-Mapped IPv6 Address 237 format defined in [RFC4291]. 239 o Authentication Domain Name: A fully qualified domain name of the 240 DoT (or DoH) server following the syntax defined in [RFC5890]. 241 The name MUST NOT contain any terminators (e.g., NULL, CR). 243 An example of valid ADN for DoH server is "doh1.example.com". 245 5. URI Template 247 DoH servers may support more than one URI Template [RFC8484]. The 248 following sub-sections discuss some candidate solutions for a DoH 249 client to retrieve the list of supported templates by a DoH server. 250 Also, if the resolver hosts several DoH services (e.g., no-filtering, 251 blocking adult content, blocking malware), these services can be 252 discovered as templates. 254 This section will be updated to reflect the outcome of the discussion 255 in [I-D.btw-add-home]. 257 How a DoH client makes use of the configured DoH services is out of 258 the scope of this document. 260 6. IKEv2 Protocol Exchange 262 This section describes how an initiator can be configured with an 263 encrypted DNS server (e.g., DoH, DoT) using IKEv2. 265 Initiators indicate the support of an encrypted DNS in the 266 CFG_REQUEST payloads by including INTERNAL_ENC_DNS attribute, while 267 responders supply the encrypted DNS configuration in the CFG_REPLY 268 payloads. Concretely: 270 If the initiator supports encrypted DNS, it includes one or more 271 INTERNAL_ENC_DNS attributes in the CFG_REQUEST with the "Encrypted 272 DNS Type" set to the requested encrypted DNS type (Section 4). 273 For each supported encrypted DNS type the initiator MUST include 274 exactly one INTERNAL_ENC_DNS attribute with the Length field set 275 to 1. 277 If an INTERNAL_ENC_DNS attribute is included in the CFG_REQUEST, 278 the INTERNAL_ENC_DNS attribute MUST NOT include an ADN and list of 279 IP addresses. 281 For each INTERNAL_ENC_DNS attribute from the CFG_REQUEST, if the 282 responder supports the corresponding encrypted DNS type, then it 283 MAY send back an INTERNAL_ENC_DNS attribute in the CFG_REPLY with 284 this encrypted DNS type and an appropriate list of IP addresses 285 and ADN. The list of IP addresses MUST NOT be empty. 287 If the CFG_REQUEST includes an INTERNAL_ENC_DNS attribute but the 288 CFG_REPLY does not include an INTERNAL_ENC_DNS, this is an 289 indication that requested encrypted DNS type(s) is not supported 290 by the responder. 292 The behavior of the responder if it receives both INTERNAL_ENC_DNS 293 and INTERNAL_IP6_DNS (or INTERNAL_IP4_DNS) attributes is policy- 294 based and deployment-specific. However, it is RECOMMENDED that if 295 the responder includes at least one INTERNAL_ENC_DNS attribute in 296 the reply, it should not include any of INTERNAL_IP4_DNS/ 297 INTERNAL_IP6_DNS attributes. 299 The DNS client establishes a DoH/DoT session with the address(es) 300 conveyed in INTERNAL_ENC_DNS and uses the mechanism discussed in 301 Section 8 of [RFC8310] to authenticate the DNS server certificate 302 using the authentication domain name conveyed in INTERNAL_ENC_DNS. 304 If the IPsec connection is a split-tunnel configuration and the 305 initiator negotiated INTERNAL_DNS_DOMAIN as per [RFC8598], the DNS 306 client MUST resolve the internal names using INTERNAL_ENC_DNS DNS 307 servers. 309 Note: [RFC8598] requires INTERNAL_IP6_DNS (or INTERNAL_IP4_DNS) 310 attribute to be mandatory present when INTERNAL_DNS_DOMAIN is 311 included. This specification relaxes that constraint in the 312 presence of INTERNAL_ENC_DNS attribute. 314 7. Security Considerations 316 This document adheres to the security considerations defined in 317 [RFC7296]. In particular, this document does not alter the trust on 318 the DNS configuration provided by a responder. 320 Networks are susceptible to internal attacks as discussed in 321 Section 3.2 of [I-D.arkko-farrell-arch-model-t]. Hosting DoH/DoT 322 server even in case of split-VPN configuration minimizes the attack 323 vector (e.g., a compromised network device cannot monitor/modify DNS 324 traffic). This specification describes a mechanism to restrict 325 access to the DNS messages to only the parties that need to know. 327 In most deployment scenarios, the initiator expects that it is using 328 the DoH/DoT server hosted by a specific organization or enterprise. 329 The DNS client can validate the signatory (i.e., cryptographically 330 attested by the organization hosting the DoH/DoT server) using, for 331 example, [I-D.reddy-add-server-policy-selection], and the user can 332 review human-readable privacy policy information of the DNS server 333 and assess whether the DNS server performs DNS-based content 334 filtering. This helps to protect from a compromised IKE server 335 advertising a malicious DoH/DoT server. 337 The initiator may trust the DoH/DoT servers supplied by means of 338 IKEv2 from a trusted responder more than the locally provided DNS 339 servers, especially in the case of connecting to unknown or untrusted 340 networks (e.g., coffee shops or hotel networks). In addition, the 341 initiator may prefer IKEv2-supplied DoH/DoT servers if they provide 342 additional features (e.g., malware filtering) compared to the pre- 343 configured DNS servers and meets the privacy preserving data policy 344 requirements of the user. 346 If the DoH/DoT server that was discovered by means of IKEv2 does not 347 meet the privacy preserving data policy and filtering requirements of 348 the user, the user can instruct the DNS client to take appropriate 349 actions. For example, the action can be to use the local DoH/DoT 350 server only to access internal-only DNS names and use another DNS 351 server (that addresses his/her expectations) for public domains. 352 Such actions and their handling is out of scope. 354 If IKEv2 is being negotiated with an anonymous or unknown endpoint 355 (such as for Opportunistic Security [RFC7435]), the initiator MUST 356 NOT use INTERNAL_ENC_DNS servers unless it is pre-configured in the 357 OS or the browser. 359 This specification does not extend the scope of accepting DNSSEC 360 trust anchors beyond the usage guidelines defined in Section 6 of 361 [RFC8598]. 363 8. IANA Considerations 365 8.1. Configuration Payload Attribute Type 367 This document requests IANA to assign the following new IKEv2 368 Configuration Payload Attribute Types from the "IKEv2 Configuration 369 Payload Attribute Types" namespace available at 370 https://www.iana.org/assignments/ikev2-parameters/ 371 ikev2-parameters.xhtml#ikev2-parameters-21. 373 Multi- 374 Value Attribute Type Valued Length Reference 375 ------ ------------------- ------ ---------- ------------ 376 TBA INTERNAL_ENC_DNS YES 1 or more RFC XXXX 378 8.2. Encrypted DNS Types 380 This document requests IANA to create a new registry called 381 "Encrypted DNS Types" under "Internet Key Exchange Version 2 (IKEv2) 382 Parameters" available at https://www.iana.org/assignments/ikev2- 383 parameters/ikev2-parameters.xhtml#ikev2-parameters-21. The initial 384 values of the registry is as follows: 386 +-------+----------------------+-----------+ 387 | Value | Description | Reference | 388 +-------+----------------------+-----------+ 389 | 0 | Reserved | RFC XXXX | 390 | 1 | DNS-over-TLS (DoT) | RFC XXXX | 391 | 2 | DNS-over-HTTPs (DoH) | RFC XXXX | 392 +-------+----------------------+-----------+ 394 New values are assigned on a First Come, First Served (FCFS) basis 395 (Section 4.4 of [RFC8126]). 397 9. Acknowledgements 399 Many thanks to Yoav Nir, Christian Jacquenet, Paul Wouters, and Tommy 400 Pauly for the review and comments. 402 Yoav and Paul suggested the use of one single attribute carrying both 403 the name and an IP address instead of depending on the existing 404 INTERNAL_IP6_DNS and INTERNAL_IP4_DNS attributes. 406 10. References 408 10.1. Normative References 410 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 411 Requirement Levels", BCP 14, RFC 2119, 412 DOI 10.17487/RFC2119, March 1997, 413 . 415 [RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing 416 Architecture", RFC 4291, DOI 10.17487/RFC4291, February 417 2006, . 419 [RFC5890] Klensin, J., "Internationalized Domain Names for 420 Applications (IDNA): Definitions and Document Framework", 421 RFC 5890, DOI 10.17487/RFC5890, August 2010, 422 . 424 [RFC7296] Kaufman, C., Hoffman, P., Nir, Y., Eronen, P., and T. 425 Kivinen, "Internet Key Exchange Protocol Version 2 426 (IKEv2)", STD 79, RFC 7296, DOI 10.17487/RFC7296, October 427 2014, . 429 [RFC7858] Hu, Z., Zhu, L., Heidemann, J., Mankin, A., Wessels, D., 430 and P. Hoffman, "Specification for DNS over Transport 431 Layer Security (TLS)", RFC 7858, DOI 10.17487/RFC7858, May 432 2016, . 434 [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for 435 Writing an IANA Considerations Section in RFCs", BCP 26, 436 RFC 8126, DOI 10.17487/RFC8126, June 2017, 437 . 439 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 440 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 441 May 2017, . 443 [RFC8310] Dickinson, S., Gillmor, D., and T. Reddy, "Usage Profiles 444 for DNS over TLS and DNS over DTLS", RFC 8310, 445 DOI 10.17487/RFC8310, March 2018, 446 . 448 [RFC8484] Hoffman, P. and P. McManus, "DNS Queries over HTTPS 449 (DoH)", RFC 8484, DOI 10.17487/RFC8484, October 2018, 450 . 452 10.2. Informative References 454 [I-D.arkko-farrell-arch-model-t] 455 Arkko, J. and S. Farrell, "Challenges and Changes in the 456 Internet Threat Model", draft-arkko-farrell-arch-model- 457 t-03 (work in progress), March 2020. 459 [I-D.btw-add-home] 460 Boucadair, M., Reddy.K, T., Wing, D., and N. Cook, "DNS- 461 over-HTTPS and DNS-over-TLS Server Discovery and 462 Deployment Considerations for Home and Mobile Networks", 463 draft-btw-add-home-04 (work in progress), March 2020. 465 [I-D.ietf-dnsop-terminology-ter] 466 Hoffman, P., "Terminology for DNS Transports and 467 Location", draft-ietf-dnsop-terminology-ter-01 (work in 468 progress), February 2020. 470 [I-D.reddy-add-server-policy-selection] 471 Reddy.K, T., Wing, D., Richardson, M., and M. Boucadair, 472 "DNS Server Selection: DNS Server Information with 473 Assertion Token", draft-reddy-add-server-policy- 474 selection-00 (work in progress), March 2020. 476 [RFC7435] Dukhovni, V., "Opportunistic Security: Some Protection 477 Most of the Time", RFC 7435, DOI 10.17487/RFC7435, 478 December 2014, . 480 [RFC8499] Hoffman, P., Sullivan, A., and K. Fujiwara, "DNS 481 Terminology", BCP 219, RFC 8499, DOI 10.17487/RFC8499, 482 January 2019, . 484 [RFC8598] Pauly, T. and P. Wouters, "Split DNS Configuration for the 485 Internet Key Exchange Protocol Version 2 (IKEv2)", 486 RFC 8598, DOI 10.17487/RFC8598, May 2019, 487 . 489 Authors' Addresses 491 Mohamed Boucadair 492 Orange 493 Rennes 35000 494 France 496 Email: mohamed.boucadair@orange.com 498 Tirumaleswar Reddy 499 McAfee, Inc. 500 Embassy Golf Link Business Park 501 Bangalore, Karnataka 560071 502 India 504 Email: TirumaleswarReddy_Konda@McAfee.com 506 Dan Wing 507 Citrix Systems, Inc. 508 USA 510 Email: dwing-ietf@fuggles.com 511 Valery Smyslov 512 ELVIS-PLUS 513 RU 515 Email: svan@elvis.ru