idnits 2.17.1 draft-btw-add-ipsecme-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 copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (February 19, 2021) is 1160 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 (-12) exists of draft-ietf-dprive-dnsoquic-01 -- Obsolete informational reference (is this intentional?): RFC 8499 (Obsoleted by RFC 9499) Summary: 0 errors (**), 0 flaws (~~), 2 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: August 23, 2021 McAfee 6 D. Wing 7 Citrix 8 V. Smyslov 9 ELVIS-PLUS 10 February 19, 2021 12 Internet Key Exchange Protocol Version 2 (IKEv2) Configuration for 13 Encrypted DNS 14 draft-btw-add-ipsecme-ike-02 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 August 23, 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. Sample Deployment Scenarios . . . . . . . . . . . . . . . . . 4 60 3.1. Roaming Enterprise Users . . . . . . . . . . . . . . . . 4 61 3.2. VPN Service Provider . . . . . . . . . . . . . . . . . . 4 62 3.3. DNS Offload . . . . . . . . . . . . . . . . . . . . . . . 5 63 4. IKEv2 Configuration Payload Attribute Types for Encrypted DNS 5 64 4.1. ENCDNS_IP*_* Configuration Payload Attributes . . . . . . 5 65 4.2. ENCDNS_URI_TEMPLATE Configuration Payload Attribute . . . 6 66 5. IKEv2 Protocol Exchange . . . . . . . . . . . . . . . . . . . 7 67 6. Security Considerations . . . . . . . . . . . . . . . . . . . 9 68 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 69 7.1. Configuration Payload Attribute Types . . . . . . . . . . 9 70 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 10 71 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 10 72 9.1. Normative References . . . . . . . . . . . . . . . . . . 10 73 9.2. Informative References . . . . . . . . . . . . . . . . . 11 74 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 11 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-over-HTTPS 81 (DoH) [RFC8484], DNS-over-TLS (DoT) [RFC7858], or DNS-over-QUIC (DoQ) 82 [I-D.ietf-dprive-dnsoquic]. 84 This document introduces new IKEv2 Configuration Payload Attribute 85 Types (Section 4) for the support of DoT, DoH, and DoQ DNS servers. 86 These attributes can be used to provision authentication domain 87 names, a list of IP addresses, alternate port numbers, and a list of 88 DoH URI Template. The use of IKEv2 to provide these template is 89 meant to allow deployments where customized DoH configuration (e.g., 90 per-subscriber or per-site) is required. 92 Sample use cases are discussed in Section 3. The Configuration 93 Payload Attribute Types defined in this document are not specific to 94 these deployments, but can also be used in other deployment contexts. 95 It is out of the scope of this document to provide a comprehensive 96 list of deployment contexts. 98 The encrypted DNS server hosted by the VPN provider can get a domain- 99 validate certificate from a public CA. The VPN client does not need 100 to be provisioned with the root certificate of a private CA to 101 authenticate the certificate of the encrypted DNS server. The 102 encrypted DNS server can run on private IP addresses and its access 103 can be restricted to clients connected to the VPN. 105 Note that, for many years, typical designs have often considered that 106 the DNS server was usually located inside the protected domain, but 107 could be located outside of it. With encrypted DNS, the latter 108 option becomes plausible. 110 2. Terminology 112 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 113 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 114 "OPTIONAL" in this document are to be interpreted as described in BCP 115 14 [RFC2119][RFC8174] when, and only when, they appear in all 116 capitals, as shown here. 118 This document makes use of the terms defined in [RFC8499]. 120 Also, this document makes use of the terms defined in [RFC7296]. In 121 particular, readers should be familiar with "initiator" and 122 "responder" terms used in that document. 124 This document makes use of the following terms: 126 'Do53': refers to unencrypted DNS. 128 'Encrypted DNS': refers to as scheme where DNS messages are sent 129 over an encrypted channel. Examples of encrypted DNS are DoT, 130 DoH, and DoQ. 132 'ENCDNS_IP*_*': refers to any IKEv2 Configuration Payload Attribute 133 Types defined in Section 4. 135 'ENCDNS_IP4_*': refers to an IKEv2 Configuration Payload Attribute 136 Type that carries one or multiple IPv4 addresses of an encrypted 137 DNS server. 139 'ENCDNS_IP6_*': refers to an IKEv2 Configuration Payload Attribute 140 Type that carries one or multiple IPv6 addresses of an encrypted 141 DNS server. 143 3. Sample Deployment Scenarios 145 3.1. Roaming Enterprise Users 147 In this Enterprise scenario (Section 1.1.3 of [RFC7296]), a roaming 148 user connects to the Enterprise network through an IPsec tunnel. The 149 split-tunnel Virtual Private Network (VPN) configuration allows the 150 endpoint to access hosts that resides in the Enterprise network 151 [RFC8598] using that tunnel; other traffic not destined to the 152 Enterprise does not traverse the tunnel. In contrast, a non-split- 153 tunnel VPN configuration causes all traffic to traverse the tunnel 154 into the enterprise. 156 For both split- and non-split-tunnel configurations, the use of 157 encrypted DNS instead of Do53 provides privacy and integrity 158 protection along the entire path (rather than just to the VPN 159 termination device) and can communicate the encrypted DNS server 160 policies. 162 For split-tunnel VPN configurations, the endpoint uses the 163 Enterprise-provided encrypted DNS server to resolve internal-only 164 domain names. 166 For non-split-tunnel VPN configurations, the endpoint uses the 167 Enterprise-provided encrypted DNS server to resolve both internal and 168 external domain names. 170 Enterprise networks are susceptible to internal and external attacks. 171 To minimize that risk all enterprise traffic is encrypted 172 (Section 2.1 of [I-D.arkko-farrell-arch-model-t]). 174 3.2. VPN Service Provider 176 Legacy VPN service providers usually preserve end-users' data 177 confidentiality by sending all communication traffic through an 178 encrypted tunnel. A VPN service provider can also provide guarantees 179 about the security of the VPN network by filtering malware and 180 phishing domains. 182 Browsers and OSes support DoH/DoT; VPN providers may no longer expect 183 DNS clients to fallback to Do53 just because it is a closed network. 185 The encrypted DNS server hosted by the VPN service provider can be 186 securely discovered by the endpoint using the IKEv2 Configuration 187 Payload Attribute Type. 189 3.3. DNS Offload 191 VPN service providers typically allow split-tunnel VPN configuration 192 in which users can choose applications that can be excluded from the 193 tunnel. For example, users may exclude applications that restrict 194 VPN access. 196 The encrypted DNS server hosted by the VPN service provider can be 197 securely discovered by the endpoint using the IKEv2 Configuration 198 Payload Attribute Type. 200 4. IKEv2 Configuration Payload Attribute Types for Encrypted DNS 202 4.1. ENCDNS_IP*_* Configuration Payload Attributes 204 The ENCDNS_IP*_* IKEv2 Configuration Payload Attribute Types are used 205 to configure a DoT, DoH, or DoQ DNS server. All these attributes 206 share the format shown in Figure 1. 208 1 2 3 209 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 210 +-+-----------------------------+-------------------------------+ 211 |R| Attribute Type | Length | 212 +-+-----------------------------+---------------+---------------+ 213 | Port Number | RESERVED | Num Addresses | 214 +-------------------------------+---------------+---------------+ 215 | | 216 ~ IP Addresses ~ 217 | | 218 +---------------------------------------------------------------+ 219 | | 220 ~ DNS Authentication Domain Name ~ 221 | | 222 +---------------------------------------------------------------+ 224 Figure 1: Attributes Format 226 The fields of the attribute shown in Figure 1 are as follows: 228 o R (Reserved, 1 bit) - This bit MUST be set to zero and MUST be 229 ignored on receipt (see Section 3.15.1 of [RFC7296] for details). 231 o Attribute Type (15 bits) - Identifier for Configuration Attribute 232 Type; is set to one of the TBA1-TBA6 values listed in Section 7.1. 234 o Length (2 octets, unsigned integer) - Length of the data in 235 octets. In particular, this field is set to: 237 * 0 if the Configuration payload has types CFG_REQUEST or 238 CFG_ACK. 240 * (2 + Length of the ADN + N * 4) for ENCDNS_IP4_* attributes if 241 the Configuration payload of a has types CFG_REPLY or CFG_SET; 242 N being the number of included IPv4 addresses ('Num 243 addresses'). 245 * (2 + Length of the ADN + N * 16) for ENCDNS_IP6_* attributes if 246 the Configuration payload has types CFG_REPLY or CFG_SET; N 247 being the number of included IPv6 addresses ('Num addresses'). 249 o Port Number (2 octets, unsigned integer) - Indicates the port 250 number to be used for the encrypted DNS. As a reminder, the 251 default port number is 853 for DoT and 443 for DoH. 253 o RESERVED (1 octet) - These bits are reserved for future use. 254 These bits MUST be set to zero by the sender and MUST be ignored 255 by the receiver. 257 o Num Addresses (1 octet) - Indicates the number of enclosed IPv4 258 (for ENCDNS_IP4_* attribute types) or IPv6 (for ENCDNS_IP6_* 259 attribute types) addresses. 261 o IP Address(es) (variable) - One or more IPv4 or IPv6 addresses to 262 be used to reach the encrypted DNS identified by the name in the 263 DNS Authentication Domain Name. 265 o Authentication Domain Name (variable) - A fully qualified domain 266 name of the DoT, DoH, or DoQ DNS server following the syntax 267 defined in [RFC5890]. The name MUST NOT contain any terminators 268 (e.g., NULL, CR). 270 An example of valid ADN for DoH server is "doh1.example.com". 272 4.2. ENCDNS_URI_TEMPLATE Configuration Payload Attribute 274 DoH servers may support more than one URI Template [RFC8484]. Also, 275 if the resolver hosts several DoH services (e.g., no-filtering, 276 blocking adult content, blocking malware), these services can be 277 discovered as templates. 279 Figure 2 depictes the format of the ENCDNS_URI_TEMPLATE IKEv2 280 Configuration Payload Attribute Type whihc is used to configure DoH 281 URI Template(s). 283 1 2 3 284 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 285 +-+-----------------------------+-------------------------------+ 286 |R| ENCDNS_URI_TEMPLATE | Length | 287 +-+-----------------------------+---------------+---------------+ 288 | | 289 ~ uri-template-data ~ 290 | . . . | 291 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 293 Each instance of the uri-template-data is formatted as follows: 295 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-...-+-+-+-+-+-+-+ 296 | uri-template-len | URI Template | 297 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-...-+-+-+-+-+-+-+ 299 Figure 2: DoH URI Template Attribute Format 301 The fields of the attribute shown in Figure 2 are as follows: 303 o R (Reserved, 1 bit) - This bit MUST be set to zero and MUST be 304 ignored on receipt (see Section 3.15.1 of [RFC7296] for details). 306 o Attribute Type (15 bits) - Identifier for Configuration Attribute 307 Type; is set to ENCDNS_URI_TEMPLATE (TBA7) (see Section 7.1). 309 o Length (2 octets, unsigned integer) - Length of the data in 310 octets. In particular, this field is set to '0' if the 311 Configuration payload has types CFG_REQUEST or CFG_ACK. 313 o uri-template-data (variable) - XXXX. 315 An example of valid URI Template is "XXXX". 317 How a DoH client makes use of the configured DoH services is out of 318 the scope of this document. 320 5. IKEv2 Protocol Exchange 322 This section describes how an initiator can be configured with an 323 encrypted DNS server (e.g., DoH, DoT) using IKEv2. 325 Initiators indicate the support of an encrypted DNS in the 326 CFG_REQUEST payloads by including one or multiple ENCDNS_IP*_* 327 attributes, while responders supply the encrypted DNS configuration 328 in the CFG_REPLY payloads. Concretely: 330 If the initiator supports encrypted DNS, it includes one or more 331 ENCDNS_IP*_* attributes in the CFG_REQUEST with the "Attribute 332 Type" set to the requested encrypted DNS type (Section 4). For 333 each supported encrypted DNS type the initiator MUST include 334 exactly one attribute with the Length field set to 0, so that no 335 data is included for these attributes. If DoH is requested, the 336 initiator includes also ENCDNS_URI_TEMPLATE in the CFG_REQUEST 337 with "Length" set to 0. 339 For each ENCDNS_IP*_* attribute from the CFG_REQUEST, if the 340 responder supports the corresponding encrypted DNS type, and 341 absent any policy, the responder sends back an ENCDNS_IP*_* 342 attribute in the CFG_REPLY with this encrypted DNS type and an 343 appropriate list of IP addresses, a port number, and an ADN. The 344 list of IP addresses MUST NOT be empty. Multiple instances of the 345 same ENCDNS_IP*_* attribute MAY be returned if distinct ADNs (or 346 port numbers) are to be returned by the responder. If the 347 responder includes ENCDNS_IP4_DOH or ENCDNS_IP6_DOH in the 348 response, it MUST also include ENCDNS_URI_TEMPLATE carrying one or 349 more URI Templates. 351 If the CFG_REQUEST includes an ENCDNS_IP*_* attribute but the 352 CFG_REPLY does not include an ENCDNS_IP*_* matching the requested 353 encrypted DNS type, this is an indication that requested encrypted 354 DNS type(s) is not supported by the responder or the responder is 355 not configured to provide corresponding server addresses. 357 The behavior of the responder if it receives both ENCDNS_IP*_* and 358 INTERNAL_IP6_DNS (or INTERNAL_IP4_DNS) attributes is policy-based 359 and deployment-specific. However, it is RECOMMENDED that if the 360 responder includes at least one ENCDNS_IP*_* attribute in the 361 reply, it should not include any of INTERNAL_IP4_DNS/ 362 INTERNAL_IP6_DNS attributes. 364 The DNS client establishes an encrypted DNS session (e.g., DoT, DoH, 365 DoQ) with the address(es) conveyed in ENCDNS_IP*_* and uses the 366 mechanism discussed in Section 8 of [RFC8310] to authenticate the DNS 367 server certificate using the authentication domain name conveyed in 368 ENCDNS_IP*_*. 370 If the IPsec connection is a split-tunnel configuration and the 371 initiator negotiated INTERNAL_DNS_DOMAIN as per [RFC8598], the DNS 372 client MUST resolve the internal names using ENCDNS_IP*_* DNS 373 servers. 375 Note: [RFC8598] requires INTERNAL_IP6_DNS (or INTERNAL_IP4_DNS) 376 attribute to be mandatory present when INTERNAL_DNS_DOMAIN is 377 included. This specification relaxes that constraint in the 378 presence of ENCDNS_IP*_* attributes. 380 6. Security Considerations 382 This document adheres to the security considerations defined in 383 [RFC7296]. In particular, this document does not alter the trust on 384 the DNS configuration provided by a responder. 386 Networks are susceptible to internal attacks as discussed in 387 Section 3.2 of [I-D.arkko-farrell-arch-model-t]. Hosting encrypted 388 DNS server even in case of split-VPN configuration minimizes the 389 attack vector (e.g., a compromised network device cannot monitor/ 390 modify DNS traffic). This specification describes a mechanism to 391 restrict access to the DNS messages to only the parties that need to 392 know. 394 The initiator may trust the encrypted DNS servers supplied by means 395 of IKEv2 from a trusted responder more than the locally provided DNS 396 servers, especially in the case of connecting to unknown or untrusted 397 networks (e.g., coffee shops or hotel networks). 399 If IKEv2 responder has used NULL Authentication method [RFC7619] to 400 authenticate itself, the initiator MUST NOT use returned ENCDNS_IP*_* 401 servers configuration unless it is pre-configured in the OS or the 402 browser. 404 This specification does not extend the scope of accepting DNSSEC 405 trust anchors beyond the usage guidelines defined in Section 6 of 406 [RFC8598]. 408 7. IANA Considerations 410 7.1. Configuration Payload Attribute Types 412 This document requests IANA to assign the following new IKEv2 413 Configuration Payload Attribute Types from the "IKEv2 Configuration 414 Payload Attribute Types" namespace available at 415 https://www.iana.org/assignments/ikev2-parameters/ 416 ikev2-parameters.xhtml#ikev2-parameters-21. 418 Multi- 419 Value Attribute Type Valued Length Reference 420 ------ ------------------- ------ ---------- ------------ 421 TBA1 ENCDNS_IP4_DOT YES 0 or more RFC XXXX 422 TBA2 ENCDNS_IP6_DOT YES 0 or more RFC XXXX 423 TBA3 ENCDNS_IP4_DOH YES 0 or more RFC XXXX 424 TBA4 ENCDNS_IP6_DOH YES 0 or more RFC XXXX 425 TBA5 ENCDNS_IP4_DOQ YES 0 or more RFC XXXX 426 TBA6 ENCDNS_IP6_DOQ YES 0 or more RFC XXXX 427 TBA7 ENCDNS_URI_TEMPLATE YES 0 or more RFC XXXX 429 8. Acknowledgements 431 Many thanks to Yoav Nir, Christian Jacquenet, Paul Wouters, and Tommy 432 Pauly for the review and comments. 434 Yoav and Paul suggested the use of one single attribute carrying both 435 the name and an IP address instead of depending on the existing 436 INTERNAL_IP6_DNS and INTERNAL_IP4_DNS attributes. 438 Christian Huitema suiggested to return a port number in the 439 attributes. 441 9. References 443 9.1. Normative References 445 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 446 Requirement Levels", BCP 14, RFC 2119, 447 DOI 10.17487/RFC2119, March 1997, 448 . 450 [RFC5890] Klensin, J., "Internationalized Domain Names for 451 Applications (IDNA): Definitions and Document Framework", 452 RFC 5890, DOI 10.17487/RFC5890, August 2010, 453 . 455 [RFC7296] Kaufman, C., Hoffman, P., Nir, Y., Eronen, P., and T. 456 Kivinen, "Internet Key Exchange Protocol Version 2 457 (IKEv2)", STD 79, RFC 7296, DOI 10.17487/RFC7296, October 458 2014, . 460 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 461 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 462 May 2017, . 464 [RFC8310] Dickinson, S., Gillmor, D., and T. Reddy, "Usage Profiles 465 for DNS over TLS and DNS over DTLS", RFC 8310, 466 DOI 10.17487/RFC8310, March 2018, 467 . 469 9.2. Informative References 471 [I-D.arkko-farrell-arch-model-t] 472 Arkko, J. and S. Farrell, "Challenges and Changes in the 473 Internet Threat Model", draft-arkko-farrell-arch-model- 474 t-04 (work in progress), July 2020. 476 [I-D.ietf-dprive-dnsoquic] 477 Huitema, C., Mankin, A., and S. Dickinson, "Specification 478 of DNS over Dedicated QUIC Connections", draft-ietf- 479 dprive-dnsoquic-01 (work in progress), October 2020. 481 [RFC7619] Smyslov, V. and P. Wouters, "The NULL Authentication 482 Method in the Internet Key Exchange Protocol Version 2 483 (IKEv2)", RFC 7619, DOI 10.17487/RFC7619, August 2015, 484 . 486 [RFC7858] Hu, Z., Zhu, L., Heidemann, J., Mankin, A., Wessels, D., 487 and P. Hoffman, "Specification for DNS over Transport 488 Layer Security (TLS)", RFC 7858, DOI 10.17487/RFC7858, May 489 2016, . 491 [RFC8484] Hoffman, P. and P. McManus, "DNS Queries over HTTPS 492 (DoH)", RFC 8484, DOI 10.17487/RFC8484, October 2018, 493 . 495 [RFC8499] Hoffman, P., Sullivan, A., and K. Fujiwara, "DNS 496 Terminology", BCP 219, RFC 8499, DOI 10.17487/RFC8499, 497 January 2019, . 499 [RFC8598] Pauly, T. and P. Wouters, "Split DNS Configuration for the 500 Internet Key Exchange Protocol Version 2 (IKEv2)", 501 RFC 8598, DOI 10.17487/RFC8598, May 2019, 502 . 504 Authors' Addresses 506 Mohamed Boucadair 507 Orange 508 Rennes 35000 509 France 511 Email: mohamed.boucadair@orange.com 512 Tirumaleswar Reddy 513 McAfee, Inc. 514 Embassy Golf Link Business Park 515 Bangalore, Karnataka 560071 516 India 518 Email: TirumaleswarReddy_Konda@McAfee.com 520 Dan Wing 521 Citrix Systems, Inc. 522 USA 524 Email: dwing-ietf@fuggles.com 526 Valery Smyslov 527 ELVIS-PLUS 528 RU 530 Email: svan@elvis.ru