idnits 2.17.00 (12 Aug 2021) /tmp/idnits31689/draft-btw-add-ipsecme-ike-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (September 9, 2020) is 619 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 (-02) exists of draft-box-add-requirements-00 == Outdated reference: draft-ietf-dprive-dnsoquic has been published as RFC 9250 == Outdated reference: A later version (-09) exists of draft-reddy-add-server-policy-selection-04 Summary: 0 errors (**), 0 flaws (~~), 4 warnings (==), 1 comment (--). 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: March 13, 2021 McAfee 6 D. Wing 7 Citrix 8 V. Smyslov 9 ELVIS-PLUS 10 September 9, 2020 12 Internet Key Exchange Protocol Version 2 (IKEv2) Configuration for 13 Encrypted DNS 14 draft-btw-add-ipsecme-ike-01 16 Abstract 18 This document specifies a new Internet Key Exchange Protocol Version 19 2 (IKEv2) Configuration Payload Attribute Types for encrypted DNS 20 with a focus on 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 March 13, 2021. 40 Copyright Notice 42 Copyright (c) 2020 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. Sample Deployment Scenarios . . . . . . . . . . . . . . . . . 3 60 3.1. Roaming Enterprise Users . . . . . . . . . . . . . . . . 3 61 3.2. VPN Service Provider . . . . . . . . . . . . . . . . . . 4 62 3.3. DNS Offload . . . . . . . . . . . . . . . . . . . . . . . 4 63 4. IKEv2 Configuration Payload Attribute Types for Encrypted DNS 4 64 5. IKEv2 Protocol Exchange . . . . . . . . . . . . . . . . . . . 6 65 6. URI Template . . . . . . . . . . . . . . . . . . . . . . . . 7 66 7. Security Considerations . . . . . . . . . . . . . . . . . . . 7 67 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 68 8.1. Configuration Payload Attribute Types . . . . . . . . . . 8 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 Internet 78 Key Exchange Protocol Version 2 (IKEv2) [RFC7296] initiator, 79 particularly the Authentication Domain Name (ADN, defined in 80 [RFC8310]) of DNS-over-HTTPS (DoH) [RFC8484], DNS-over-TLS (DoT) 81 [RFC7858], or DNS-over-QUIC (DoQ) [I-D.ietf-dprive-dnsoquic]. 83 This document introduces new IKEv2 Configuration Payload Attribute 84 Types (Section 4) for the support of DoT, DoH, and DoQ DNS servers. 86 This document targets the deployments discussed in Section 3.3 of 87 [I-D.box-add-requirements]. Sample use cases are discussed in 88 Section 3. The Configuration Payload Attribute Types defined in this 89 document are not specific to these deployments, but can also be used 90 in other deployment contexts. 92 Note that, for many years, typical designs have often considered that 93 the DNS server was usually located inside the protected domain, but 94 could be located outside of it. With DoH, DoT, or DoQ the latter 95 option becomes plausible. 97 2. Terminology 99 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 100 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 101 "OPTIONAL" in this document are to be interpreted as described in BCP 102 14 [RFC2119][RFC8174] when, and only when, they appear in all 103 capitals, as shown here. 105 This document makes use of the terms defined in [RFC8499] and 106 [I-D.ietf-dnsop-terminology-ter]. 108 Also, this document makes use of the terms defined in [RFC7296]. In 109 particular, readers should be familiar with "initiator" and 110 "responder" terms used in that document. 112 Do53 refers to unencrypted DNS. 114 Encrypted DNS refers to as scheme where DNS messages are sent over an 115 encrypted channel. Examples of encrypted DNS are DoT, DoH, and DoQ. 117 ENCDNS_IP*_* refers to any IKEv2 Configuration Payload Attribute 118 Types defined in Section 4. 120 ENCDNS_IP4_* refers to an IKEv2 Configuration Payload Attribute Type 121 that carries one or multiple IPv4 addresses of an encrypted DNS 122 server. 124 ENCDNS_IP6_* refers to an IKEv2 Configuration Payload Attribute Type 125 that carries one or multiple IPv6 addresses of an encrypted DNS 126 server. 128 3. Sample Deployment Scenarios 130 3.1. Roaming Enterprise Users 132 In this Enterprise scenario (Section 1.1.3 of [RFC7296]), a roaming 133 user connects to the Enterprise network through an IPsec tunnel. The 134 split-tunnel Virtual Private Network (VPN) configuration allows the 135 endpoint to access hosts that resides in the Enterprise network 136 [RFC8598] using that tunnel; other traffic not destined to the 137 Enterprise does not traverse the tunnel. In contrast, a non-split- 138 tunnel VPN configuration causes all traffic to traverse the tunnel 139 into the enterprise. 141 For both split- and non-split-tunnel configurations, the use of 142 encrypted DNS instead of Do53 provides privacy and integrity 143 protection along the entire path (rather than just to the VPN 144 termination device) and can communicate the encrypted DNS server 145 policies. 147 For split-tunnel VPN configurations, the endpoint uses the 148 Enterprise-provided encrypted DNS server to resolve internal-only 149 domain names. 151 For non-split-tunnel VPN configurations, the endpoint uses the 152 Enterprise-provided encrypted DNS server to resolve both internal and 153 external domain names. 155 Enterprise networks are susceptible to internal and external attacks. 156 To minimize that risk all enterprise traffic is encrypted 157 (Section 2.1 of [I-D.arkko-farrell-arch-model-t]). 159 3.2. VPN Service Provider 161 Legacy VPN service providers usually preserve end-users' data 162 confidentiality by sending all communication traffic through an 163 encrypted tunnel. A VPN service provider can also provide guarantees 164 about the security of the VPN network by filtering malware and 165 phishing domains. 167 Browsers and OSes support DoH/DoT; VPN providers may no longer expect 168 DNS clients to fallback to Do53 just because it is a closed network. 170 The encrypted DNS server hosted by the VPN service provider can be 171 securely discovered by the endpoint using the IKEv2 Configuration 172 Payload Attribute Type. 174 3.3. DNS Offload 176 VPN service providers typically allow split-tunnel VPN configuration 177 in which users can choose applications that can be excluded from the 178 tunnel. For example, users may exclude applications that restrict 179 VPN access. 181 The encrypted DNS server hosted by the VPN service provider can be 182 securely discovered by the endpoint using the IKEv2 Configuration 183 Payload Attribute Type. 185 4. IKEv2 Configuration Payload Attribute Types for Encrypted DNS 187 The ENCDNS_IP*_* IKEv2 Configuration Payload Attribute Types are used 188 to configure a DoT, DoH, or DoQ DNS server. All these attributes 189 share the format shown in Figure 1. 191 1 2 3 192 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 193 +-+-----------------------------+-------------------------------+ 194 |R| Attribute Type | Length | 195 +-+-----------------------------+---------------+---------------+ 196 | Port Number | RESERVED | Num Addresses | 197 +-------------------------------+---------------+---------------+ 198 | | 199 ~ IP Addresses ~ 200 | | 201 +---------------------------------------------------------------+ 202 | | 203 ~ DNS Authentication Domain Name ~ 204 | | 205 +---------------------------------------------------------------+ 207 Figure 1: Attributes Format 209 The fields of the attribute shown in Figure 1 are as follows: 211 o R (Reserved, 1 bit) - This bit MUST be set to zero and MUST be 212 ignored on receipt (see Section 3.15.1 of [RFC7296] for details). 214 o Attribute Type (15 bits) - Identifier for Configuration Attribute 215 Type; is set to one of the values listed in Section 8.1. 217 o Length (2 octets, unsigned integer) - Length of the data in 218 octets. In particular, this field is set to: 220 * 0 if the Configuration payload has types CFG_REQUEST or 221 CFG_ACK. 223 * (2 + Length of the ADN + N * 4) for ENCDNS_IP4_* attributes if 224 the Configuration payload of a has types CFG_REPLY or CFG_SET; 225 N being the number of included IPv4 addresses ('Num 226 addresses'). 228 * (2 + Length of the ADN + N * 16) for ENCDNS_IP6_* attributes if 229 the Configuration payload has types CFG_REPLY or CFG_SET; N 230 being the number of included IPv6 addresses ('Num addresses'). 232 o Port Number (2 octets, unsigned integer) - Indicates the port 233 number to be used for the encrypted DNS. As a reminder, the 234 default port number is 853 for DoT and 443 for DoH. 236 o RESERVED (1 octet) - These bits are reserved for future use. 237 These bits MUST be set to zero by the sender and MUST be ignored 238 by the receiver. 240 o Num Addresses (1 octet) - Indicates the number of enclosed IPv4 241 (for ENCDNS_IP4_* attribute types) or IPv6 (for ENCDNS_IP6_* 242 attribute types) addresses. 244 o IP Address(es) (variable) - One or more IPv4 or IPv6 addresses to 245 be used to reach the encrypted DNS identified by the name in the 246 DNS Authentication Domain Name. 248 o Authentication Domain Name (variable) - A fully qualified domain 249 name of the DoT, DoH, or DoQ DNS server following the syntax 250 defined in [RFC5890]. The name MUST NOT contain any terminators 251 (e.g., NULL, CR). 253 An example of valid ADN for DoH server is "doh1.example.com". 255 5. IKEv2 Protocol Exchange 257 This section describes how an initiator can be configured with an 258 encrypted DNS server (e.g., DoH, DoT) using IKEv2. 260 Initiators indicate the support of an encrypted DNS in the 261 CFG_REQUEST payloads by including one or multiple ENCDNS_IP*_* 262 attributes, while responders supply the encrypted DNS configuration 263 in the CFG_REPLY payloads. Concretely: 265 If the initiator supports encrypted DNS, it includes one or more 266 ENCDNS_IP*_* attributes in the CFG_REQUEST with the "Attribute 267 Type" set to the requested encrypted DNS type (Section 4). For 268 each supported encrypted DNS type the initiator MUST include 269 exactly one attribute with the Length field set to 0, so that no 270 data is included for these attributes. 272 For each ENCDNS_IP*_* attribute from the CFG_REQUEST, if the 273 responder supports the corresponding encrypted DNS type, and 274 absent any policy, the responder sends back an ENCDNS_IP*_* 275 attribute in the CFG_REPLY with this encrypted DNS type and an 276 appropriate list of IP addresses, a port number, and an ADN. The 277 list of IP addresses MUST NOT be empty. Multiple instances of the 278 same ENCDNS_IP*_* attribute MAY be returned if distinct ADNs (or 279 port numbers) are to be returned by the responder. 281 If the CFG_REQUEST includes an ENCDNS_IP*_* attribute but the 282 CFG_REPLY does not include an ENCDNS_IP*_* matching the requested 283 encrypted DNS type, this is an indication that requested encrypted 284 DNS type(s) is not supported by the responder or the responder is 285 not configured to provide corresponding server addresses. 287 The behavior of the responder if it receives both ENCDNS_IP*_* and 288 INTERNAL_IP6_DNS (or INTERNAL_IP4_DNS) attributes is policy-based 289 and deployment-specific. However, it is RECOMMENDED that if the 290 responder includes at least one ENCDNS_IP*_* attribute in the 291 reply, it should not include any of INTERNAL_IP4_DNS/ 292 INTERNAL_IP6_DNS attributes. 294 The DNS client establishes an encrypted DNS session (e.g., DoT, DoH, 295 DoQ) with the address(es) conveyed in ENCDNS_IP*_* and uses the 296 mechanism discussed in Section 8 of [RFC8310] to authenticate the DNS 297 server certificate using the authentication domain name conveyed in 298 ENCDNS_IP*_*. 300 If the IPsec connection is a split-tunnel configuration and the 301 initiator negotiated INTERNAL_DNS_DOMAIN as per [RFC8598], the DNS 302 client MUST resolve the internal names using ENCDNS_IP*_* DNS 303 servers. 305 Note: [RFC8598] requires INTERNAL_IP6_DNS (or INTERNAL_IP4_DNS) 306 attribute to be mandatory present when INTERNAL_DNS_DOMAIN is 307 included. This specification relaxes that constraint in the 308 presence of ENCDNS_IP*_* attributes. 310 6. URI Template 312 DoH servers may support more than one URI Template [RFC8484]. Also, 313 if the resolver hosts several DoH services (e.g., no-filtering, 314 blocking adult content, blocking malware), these services can be 315 discovered as templates. 317 Upon discovery of a DoH resolver (Section 5), the DoH client contacts 318 that DoH resolver to retrieve the list of supported DoH services 319 using the well-known URI defined in 320 [I-D.btw-add-rfc8484-clarification]. DoH clients re-iterates that 321 request regularly to retrieve an updated list of supported DoH 322 services. 324 How a DoH client makes use of the configured DoH services is out of 325 the scope of this document. 327 7. Security Considerations 329 This document adheres to the security considerations defined in 330 [RFC7296]. In particular, this document does not alter the trust on 331 the DNS configuration provided by a responder. 333 Networks are susceptible to internal attacks as discussed in 334 Section 3.2 of [I-D.arkko-farrell-arch-model-t]. Hosting encrypted 335 DNS server even in case of split-VPN configuration minimizes the 336 attack vector (e.g., a compromised network device cannot monitor/ 337 modify DNS traffic). This specification describes a mechanism to 338 restrict access to the DNS messages to only the parties that need to 339 know. 341 In most deployment scenarios, the initiator expects that it is using 342 the encrypted DNS server hosted by a specific organization or 343 enterprise. The DNS client can validate the signatory (i.e., 344 cryptographically attested by the organization hosting the encrypted 345 DNS server) using, for example, 346 [I-D.reddy-add-server-policy-selection], and the user can review 347 human-readable privacy policy information of the DNS server and 348 assess whether the DNS server performs DNS-based content filtering. 349 This helps to protect from a compromised IKE server advertising a 350 malicious encrypted DNS server. 352 The initiator may trust the encrypted DNS servers supplied by means 353 of IKEv2 from a trusted responder more than the locally provided DNS 354 servers, especially in the case of connecting to unknown or untrusted 355 networks (e.g., coffee shops or hotel networks). 357 If the encrypted DNS server that was discovered by means of IKEv2 358 does not meet the privacy preserving data policy and filtering 359 requirements of the user, the user can instruct the DNS client to 360 take appropriate actions. For example, the action can be to use the 361 local encrypted DNS server only to access internal-only DNS names and 362 use another DNS server (that addresses his/her expectations) for 363 public domains. Such actions and their handling is out of scope. 365 If IKEv2 responder has used NULL Authentication method [RFC7619] to 366 authenticate itself, the initiator MUST NOT use returned ENCDNS_IP*_* 367 servers configuration unless it is pre-configured in the OS or the 368 browser. 370 This specification does not extend the scope of accepting DNSSEC 371 trust anchors beyond the usage guidelines defined in Section 6 of 372 [RFC8598]. 374 8. IANA Considerations 376 8.1. Configuration Payload Attribute Types 378 This document requests IANA to assign the following new IKEv2 379 Configuration Payload Attribute Types from the "IKEv2 Configuration 380 Payload Attribute Types" namespace available at 381 https://www.iana.org/assignments/ikev2-parameters/ 382 ikev2-parameters.xhtml#ikev2-parameters-21. 384 Multi- 385 Value Attribute Type Valued Length Reference 386 ------ ------------------- ------ ---------- ------------ 387 TBA1 ENCDNS_IP4_DOT YES 0 or more RFC XXXX 388 TBA2 ENCDNS_IP6_DOT YES 0 or more RFC XXXX 389 TBA3 ENCDNS_IP4_DOH YES 0 or more RFC XXXX 390 TBA4 ENCDNS_IP6_DOH YES 0 or more RFC XXXX 391 TBA5 ENCDNS_IP4_DOQ YES 0 or more RFC XXXX 392 TBA6 ENCDNS_IP6_DOQ YES 0 or more RFC XXXX 394 9. Acknowledgements 396 Many thanks to Yoav Nir, Christian Jacquenet, Paul Wouters, and Tommy 397 Pauly for the review and comments. 399 Yoav and Paul suggested the use of one single attribute carrying both 400 the name and an IP address instead of depending on the existing 401 INTERNAL_IP6_DNS and INTERNAL_IP4_DNS attributes. 403 Christian Huitema suiggested to return a port number in the 404 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 [RFC5890] Klensin, J., "Internationalized Domain Names for 416 Applications (IDNA): Definitions and Document Framework", 417 RFC 5890, DOI 10.17487/RFC5890, August 2010, 418 . 420 [RFC7296] Kaufman, C., Hoffman, P., Nir, Y., Eronen, P., and T. 421 Kivinen, "Internet Key Exchange Protocol Version 2 422 (IKEv2)", STD 79, RFC 7296, DOI 10.17487/RFC7296, October 423 2014, . 425 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 426 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 427 May 2017, . 429 [RFC8310] Dickinson, S., Gillmor, D., and T. Reddy, "Usage Profiles 430 for DNS over TLS and DNS over DTLS", RFC 8310, 431 DOI 10.17487/RFC8310, March 2018, 432 . 434 10.2. Informative References 436 [I-D.arkko-farrell-arch-model-t] 437 Arkko, J. and S. Farrell, "Challenges and Changes in the 438 Internet Threat Model", draft-arkko-farrell-arch-model- 439 t-04 (work in progress), July 2020. 441 [I-D.box-add-requirements] 442 Box, C., Pauly, T., Wood, C., and T. Reddy.K, 443 "Requirements for Adaptive DNS Discovery", draft-box-add- 444 requirements-00 (work in progress), September 2020. 446 [I-D.btw-add-rfc8484-clarification] 447 Boucadair, M., Cook, N., Reddy.K, T., and D. Wing, 448 "Supporting Redirection for DNS Queries over HTTPS (DoH)", 449 draft-btw-add-rfc8484-clarification-02 (work in progress), 450 July 2020. 452 [I-D.ietf-dnsop-terminology-ter] 453 Hoffman, P., "Terminology for DNS Transports and 454 Location", draft-ietf-dnsop-terminology-ter-02 (work in 455 progress), August 2020. 457 [I-D.ietf-dprive-dnsoquic] 458 Huitema, C., Mankin, A., and S. Dickinson, "Specification 459 of DNS over Dedicated QUIC Connections", draft-ietf- 460 dprive-dnsoquic-00 (work in progress), April 2020. 462 [I-D.reddy-add-server-policy-selection] 463 Reddy.K, T., Wing, D., Richardson, M., and M. Boucadair, 464 "DNS Server Selection: DNS Server Information with 465 Assertion Token", draft-reddy-add-server-policy- 466 selection-04 (work in progress), July 2020. 468 [RFC7619] Smyslov, V. and P. Wouters, "The NULL Authentication 469 Method in the Internet Key Exchange Protocol Version 2 470 (IKEv2)", RFC 7619, DOI 10.17487/RFC7619, August 2015, 471 . 473 [RFC7858] Hu, Z., Zhu, L., Heidemann, J., Mankin, A., Wessels, D., 474 and P. Hoffman, "Specification for DNS over Transport 475 Layer Security (TLS)", RFC 7858, DOI 10.17487/RFC7858, May 476 2016, . 478 [RFC8484] Hoffman, P. and P. McManus, "DNS Queries over HTTPS 479 (DoH)", RFC 8484, DOI 10.17487/RFC8484, October 2018, 480 . 482 [RFC8499] Hoffman, P., Sullivan, A., and K. Fujiwara, "DNS 483 Terminology", BCP 219, RFC 8499, DOI 10.17487/RFC8499, 484 January 2019, . 486 [RFC8598] Pauly, T. and P. Wouters, "Split DNS Configuration for the 487 Internet Key Exchange Protocol Version 2 (IKEv2)", 488 RFC 8598, DOI 10.17487/RFC8598, May 2019, 489 . 491 Authors' Addresses 493 Mohamed Boucadair 494 Orange 495 Rennes 35000 496 France 498 Email: mohamed.boucadair@orange.com 500 Tirumaleswar Reddy 501 McAfee, Inc. 502 Embassy Golf Link Business Park 503 Bangalore, Karnataka 560071 504 India 506 Email: TirumaleswarReddy_Konda@McAfee.com 508 Dan Wing 509 Citrix Systems, Inc. 510 USA 512 Email: dwing-ietf@fuggles.com 514 Valery Smyslov 515 ELVIS-PLUS 516 RU 518 Email: svan@elvis.ru