ADD M. Boucadair Internet-Draft Orange Intended status: Standards Track T. Reddy Expires: March 13, 2021 McAfee D. Wing Citrix V. Smyslov ELVIS-PLUS September 9, 2020 Internet Key Exchange Protocol Version 2 (IKEv2) Configuration for Encrypted DNS draft-btw-add-ipsecme-ike-01 Abstract This document specifies a new Internet Key Exchange Protocol Version 2 (IKEv2) Configuration Payload Attribute Types for encrypted DNS with a focus on DNS-over-HTTPS (DoH), DNS-over-TLS (DoT), and DNS- over-QUIC (DoQ). Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at https://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on March 13, 2021. Copyright Notice Copyright (c) 2020 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents Boucadair, et al. Expires March 13, 2021 [Page 1] Internet-Draft IKEv2 for Encrypted DNS September 2020 carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 3. Sample Deployment Scenarios . . . . . . . . . . . . . . . . . 3 3.1. Roaming Enterprise Users . . . . . . . . . . . . . . . . 3 3.2. VPN Service Provider . . . . . . . . . . . . . . . . . . 4 3.3. DNS Offload . . . . . . . . . . . . . . . . . . . . . . . 4 4. IKEv2 Configuration Payload Attribute Types for Encrypted DNS 4 5. IKEv2 Protocol Exchange . . . . . . . . . . . . . . . . . . . 6 6. URI Template . . . . . . . . . . . . . . . . . . . . . . . . 7 7. Security Considerations . . . . . . . . . . . . . . . . . . . 7 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 8.1. Configuration Payload Attribute Types . . . . . . . . . . 8 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 9 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 9 10.1. Normative References . . . . . . . . . . . . . . . . . . 9 10.2. Informative References . . . . . . . . . . . . . . . . . 10 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 11 1. Introduction This document specifies encrypted DNS configuration for an Internet Key Exchange Protocol Version 2 (IKEv2) [RFC7296] initiator, particularly the Authentication Domain Name (ADN, defined in [RFC8310]) of DNS-over-HTTPS (DoH) [RFC8484], DNS-over-TLS (DoT) [RFC7858], or DNS-over-QUIC (DoQ) [I-D.ietf-dprive-dnsoquic]. This document introduces new IKEv2 Configuration Payload Attribute Types (Section 4) for the support of DoT, DoH, and DoQ DNS servers. This document targets the deployments discussed in Section 3.3 of [I-D.box-add-requirements]. Sample use cases are discussed in Section 3. The Configuration Payload Attribute Types defined in this document are not specific to these deployments, but can also be used in other deployment contexts. Note that, for many years, typical designs have often considered that the DNS server was usually located inside the protected domain, but could be located outside of it. With DoH, DoT, or DoQ the latter option becomes plausible. Boucadair, et al. Expires March 13, 2021 [Page 2] Internet-Draft IKEv2 for Encrypted DNS September 2020 2. Terminology The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119][RFC8174] when, and only when, they appear in all capitals, as shown here. This document makes use of the terms defined in [RFC8499] and [I-D.ietf-dnsop-terminology-ter]. Also, this document makes use of the terms defined in [RFC7296]. In particular, readers should be familiar with "initiator" and "responder" terms used in that document. Do53 refers to unencrypted DNS. Encrypted DNS refers to as scheme where DNS messages are sent over an encrypted channel. Examples of encrypted DNS are DoT, DoH, and DoQ. ENCDNS_IP*_* refers to any IKEv2 Configuration Payload Attribute Types defined in Section 4. ENCDNS_IP4_* refers to an IKEv2 Configuration Payload Attribute Type that carries one or multiple IPv4 addresses of an encrypted DNS server. ENCDNS_IP6_* refers to an IKEv2 Configuration Payload Attribute Type that carries one or multiple IPv6 addresses of an encrypted DNS server. 3. Sample Deployment Scenarios 3.1. Roaming Enterprise Users In this Enterprise scenario (Section 1.1.3 of [RFC7296]), a roaming user connects to the Enterprise network through an IPsec tunnel. The split-tunnel Virtual Private Network (VPN) configuration allows the endpoint to access hosts that resides in the Enterprise network [RFC8598] using that tunnel; other traffic not destined to the Enterprise does not traverse the tunnel. In contrast, a non-split- tunnel VPN configuration causes all traffic to traverse the tunnel into the enterprise. For both split- and non-split-tunnel configurations, the use of encrypted DNS instead of Do53 provides privacy and integrity protection along the entire path (rather than just to the VPN Boucadair, et al. Expires March 13, 2021 [Page 3] Internet-Draft IKEv2 for Encrypted DNS September 2020 termination device) and can communicate the encrypted DNS server policies. For split-tunnel VPN configurations, the endpoint uses the Enterprise-provided encrypted DNS server to resolve internal-only domain names. For non-split-tunnel VPN configurations, the endpoint uses the Enterprise-provided encrypted DNS server to resolve both internal and external domain names. Enterprise networks are susceptible to internal and external attacks. To minimize that risk all enterprise traffic is encrypted (Section 2.1 of [I-D.arkko-farrell-arch-model-t]). 3.2. VPN Service Provider Legacy VPN service providers usually preserve end-users' data confidentiality by sending all communication traffic through an encrypted tunnel. A VPN service provider can also provide guarantees about the security of the VPN network by filtering malware and phishing domains. Browsers and OSes support DoH/DoT; VPN providers may no longer expect DNS clients to fallback to Do53 just because it is a closed network. The encrypted DNS server hosted by the VPN service provider can be securely discovered by the endpoint using the IKEv2 Configuration Payload Attribute Type. 3.3. DNS Offload VPN service providers typically allow split-tunnel VPN configuration in which users can choose applications that can be excluded from the tunnel. For example, users may exclude applications that restrict VPN access. The encrypted DNS server hosted by the VPN service provider can be securely discovered by the endpoint using the IKEv2 Configuration Payload Attribute Type. 4. IKEv2 Configuration Payload Attribute Types for Encrypted DNS The ENCDNS_IP*_* IKEv2 Configuration Payload Attribute Types are used to configure a DoT, DoH, or DoQ DNS server. All these attributes share the format shown in Figure 1. Boucadair, et al. Expires March 13, 2021 [Page 4] Internet-Draft IKEv2 for Encrypted DNS September 2020 1 2 3 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 +-+-----------------------------+-------------------------------+ |R| Attribute Type | Length | +-+-----------------------------+---------------+---------------+ | Port Number | RESERVED | Num Addresses | +-------------------------------+---------------+---------------+ | | ~ IP Addresses ~ | | +---------------------------------------------------------------+ | | ~ DNS Authentication Domain Name ~ | | +---------------------------------------------------------------+ Figure 1: Attributes Format The fields of the attribute shown in Figure 1 are as follows: o R (Reserved, 1 bit) - This bit MUST be set to zero and MUST be ignored on receipt (see Section 3.15.1 of [RFC7296] for details). o Attribute Type (15 bits) - Identifier for Configuration Attribute Type; is set to one of the values listed in Section 8.1. o Length (2 octets, unsigned integer) - Length of the data in octets. In particular, this field is set to: * 0 if the Configuration payload has types CFG_REQUEST or CFG_ACK. * (2 + Length of the ADN + N * 4) for ENCDNS_IP4_* attributes if the Configuration payload of a has types CFG_REPLY or CFG_SET; N being the number of included IPv4 addresses ('Num addresses'). * (2 + Length of the ADN + N * 16) for ENCDNS_IP6_* attributes if the Configuration payload has types CFG_REPLY or CFG_SET; N being the number of included IPv6 addresses ('Num addresses'). o Port Number (2 octets, unsigned integer) - Indicates the port number to be used for the encrypted DNS. As a reminder, the default port number is 853 for DoT and 443 for DoH. o RESERVED (1 octet) - These bits are reserved for future use. These bits MUST be set to zero by the sender and MUST be ignored by the receiver. Boucadair, et al. Expires March 13, 2021 [Page 5] Internet-Draft IKEv2 for Encrypted DNS September 2020 o Num Addresses (1 octet) - Indicates the number of enclosed IPv4 (for ENCDNS_IP4_* attribute types) or IPv6 (for ENCDNS_IP6_* attribute types) addresses. o IP Address(es) (variable) - One or more IPv4 or IPv6 addresses to be used to reach the encrypted DNS identified by the name in the DNS Authentication Domain Name. o Authentication Domain Name (variable) - A fully qualified domain name of the DoT, DoH, or DoQ DNS server following the syntax defined in [RFC5890]. The name MUST NOT contain any terminators (e.g., NULL, CR). An example of valid ADN for DoH server is "doh1.example.com". 5. IKEv2 Protocol Exchange This section describes how an initiator can be configured with an encrypted DNS server (e.g., DoH, DoT) using IKEv2. Initiators indicate the support of an encrypted DNS in the CFG_REQUEST payloads by including one or multiple ENCDNS_IP*_* attributes, while responders supply the encrypted DNS configuration in the CFG_REPLY payloads. Concretely: If the initiator supports encrypted DNS, it includes one or more ENCDNS_IP*_* attributes in the CFG_REQUEST with the "Attribute Type" set to the requested encrypted DNS type (Section 4). For each supported encrypted DNS type the initiator MUST include exactly one attribute with the Length field set to 0, so that no data is included for these attributes. For each ENCDNS_IP*_* attribute from the CFG_REQUEST, if the responder supports the corresponding encrypted DNS type, and absent any policy, the responder sends back an ENCDNS_IP*_* attribute in the CFG_REPLY with this encrypted DNS type and an appropriate list of IP addresses, a port number, and an ADN. The list of IP addresses MUST NOT be empty. Multiple instances of the same ENCDNS_IP*_* attribute MAY be returned if distinct ADNs (or port numbers) are to be returned by the responder. If the CFG_REQUEST includes an ENCDNS_IP*_* attribute but the CFG_REPLY does not include an ENCDNS_IP*_* matching the requested encrypted DNS type, this is an indication that requested encrypted DNS type(s) is not supported by the responder or the responder is not configured to provide corresponding server addresses. Boucadair, et al. Expires March 13, 2021 [Page 6] Internet-Draft IKEv2 for Encrypted DNS September 2020 The behavior of the responder if it receives both ENCDNS_IP*_* and INTERNAL_IP6_DNS (or INTERNAL_IP4_DNS) attributes is policy-based and deployment-specific. However, it is RECOMMENDED that if the responder includes at least one ENCDNS_IP*_* attribute in the reply, it should not include any of INTERNAL_IP4_DNS/ INTERNAL_IP6_DNS attributes. The DNS client establishes an encrypted DNS session (e.g., DoT, DoH, DoQ) with the address(es) conveyed in ENCDNS_IP*_* and uses the mechanism discussed in Section 8 of [RFC8310] to authenticate the DNS server certificate using the authentication domain name conveyed in ENCDNS_IP*_*. If the IPsec connection is a split-tunnel configuration and the initiator negotiated INTERNAL_DNS_DOMAIN as per [RFC8598], the DNS client MUST resolve the internal names using ENCDNS_IP*_* DNS servers. Note: [RFC8598] requires INTERNAL_IP6_DNS (or INTERNAL_IP4_DNS) attribute to be mandatory present when INTERNAL_DNS_DOMAIN is included. This specification relaxes that constraint in the presence of ENCDNS_IP*_* attributes. 6. URI Template DoH servers may support more than one URI Template [RFC8484]. Also, if the resolver hosts several DoH services (e.g., no-filtering, blocking adult content, blocking malware), these services can be discovered as templates. Upon discovery of a DoH resolver (Section 5), the DoH client contacts that DoH resolver to retrieve the list of supported DoH services using the well-known URI defined in [I-D.btw-add-rfc8484-clarification]. DoH clients re-iterates that request regularly to retrieve an updated list of supported DoH services. How a DoH client makes use of the configured DoH services is out of the scope of this document. 7. Security Considerations This document adheres to the security considerations defined in [RFC7296]. In particular, this document does not alter the trust on the DNS configuration provided by a responder. Networks are susceptible to internal attacks as discussed in Section 3.2 of [I-D.arkko-farrell-arch-model-t]. Hosting encrypted Boucadair, et al. Expires March 13, 2021 [Page 7] Internet-Draft IKEv2 for Encrypted DNS September 2020 DNS server even in case of split-VPN configuration minimizes the attack vector (e.g., a compromised network device cannot monitor/ modify DNS traffic). This specification describes a mechanism to restrict access to the DNS messages to only the parties that need to know. In most deployment scenarios, the initiator expects that it is using the encrypted DNS server hosted by a specific organization or enterprise. The DNS client can validate the signatory (i.e., cryptographically attested by the organization hosting the encrypted DNS server) using, for example, [I-D.reddy-add-server-policy-selection], and the user can review human-readable privacy policy information of the DNS server and assess whether the DNS server performs DNS-based content filtering. This helps to protect from a compromised IKE server advertising a malicious encrypted DNS server. The initiator may trust the encrypted DNS servers supplied by means of IKEv2 from a trusted responder more than the locally provided DNS servers, especially in the case of connecting to unknown or untrusted networks (e.g., coffee shops or hotel networks). If the encrypted DNS server that was discovered by means of IKEv2 does not meet the privacy preserving data policy and filtering requirements of the user, the user can instruct the DNS client to take appropriate actions. For example, the action can be to use the local encrypted DNS server only to access internal-only DNS names and use another DNS server (that addresses his/her expectations) for public domains. Such actions and their handling is out of scope. If IKEv2 responder has used NULL Authentication method [RFC7619] to authenticate itself, the initiator MUST NOT use returned ENCDNS_IP*_* servers configuration unless it is pre-configured in the OS or the browser. This specification does not extend the scope of accepting DNSSEC trust anchors beyond the usage guidelines defined in Section 6 of [RFC8598]. 8. IANA Considerations 8.1. Configuration Payload Attribute Types This document requests IANA to assign the following new IKEv2 Configuration Payload Attribute Types from the "IKEv2 Configuration Payload Attribute Types" namespace available at https://www.iana.org/assignments/ikev2-parameters/ ikev2-parameters.xhtml#ikev2-parameters-21. Boucadair, et al. Expires March 13, 2021 [Page 8] Internet-Draft IKEv2 for Encrypted DNS September 2020 Multi- Value Attribute Type Valued Length Reference ------ ------------------- ------ ---------- ------------ TBA1 ENCDNS_IP4_DOT YES 0 or more RFC XXXX TBA2 ENCDNS_IP6_DOT YES 0 or more RFC XXXX TBA3 ENCDNS_IP4_DOH YES 0 or more RFC XXXX TBA4 ENCDNS_IP6_DOH YES 0 or more RFC XXXX TBA5 ENCDNS_IP4_DOQ YES 0 or more RFC XXXX TBA6 ENCDNS_IP6_DOQ YES 0 or more RFC XXXX 9. Acknowledgements Many thanks to Yoav Nir, Christian Jacquenet, Paul Wouters, and Tommy Pauly for the review and comments. Yoav and Paul suggested the use of one single attribute carrying both the name and an IP address instead of depending on the existing INTERNAL_IP6_DNS and INTERNAL_IP4_DNS attributes. Christian Huitema suiggested to return a port number in the attributes. 10. References 10.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . [RFC5890] Klensin, J., "Internationalized Domain Names for Applications (IDNA): Definitions and Document Framework", RFC 5890, DOI 10.17487/RFC5890, August 2010, . [RFC7296] Kaufman, C., Hoffman, P., Nir, Y., Eronen, P., and T. Kivinen, "Internet Key Exchange Protocol Version 2 (IKEv2)", STD 79, RFC 7296, DOI 10.17487/RFC7296, October 2014, . [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, . Boucadair, et al. Expires March 13, 2021 [Page 9] Internet-Draft IKEv2 for Encrypted DNS September 2020 [RFC8310] Dickinson, S., Gillmor, D., and T. Reddy, "Usage Profiles for DNS over TLS and DNS over DTLS", RFC 8310, DOI 10.17487/RFC8310, March 2018, . 10.2. Informative References [I-D.arkko-farrell-arch-model-t] Arkko, J. and S. Farrell, "Challenges and Changes in the Internet Threat Model", draft-arkko-farrell-arch-model- t-04 (work in progress), July 2020. [I-D.box-add-requirements] Box, C., Pauly, T., Wood, C., and T. Reddy.K, "Requirements for Adaptive DNS Discovery", draft-box-add- requirements-00 (work in progress), September 2020. [I-D.btw-add-rfc8484-clarification] Boucadair, M., Cook, N., Reddy.K, T., and D. Wing, "Supporting Redirection for DNS Queries over HTTPS (DoH)", draft-btw-add-rfc8484-clarification-02 (work in progress), July 2020. [I-D.ietf-dnsop-terminology-ter] Hoffman, P., "Terminology for DNS Transports and Location", draft-ietf-dnsop-terminology-ter-02 (work in progress), August 2020. [I-D.ietf-dprive-dnsoquic] Huitema, C., Mankin, A., and S. Dickinson, "Specification of DNS over Dedicated QUIC Connections", draft-ietf- dprive-dnsoquic-00 (work in progress), April 2020. [I-D.reddy-add-server-policy-selection] Reddy.K, T., Wing, D., Richardson, M., and M. Boucadair, "DNS Server Selection: DNS Server Information with Assertion Token", draft-reddy-add-server-policy- selection-04 (work in progress), July 2020. [RFC7619] Smyslov, V. and P. Wouters, "The NULL Authentication Method in the Internet Key Exchange Protocol Version 2 (IKEv2)", RFC 7619, DOI 10.17487/RFC7619, August 2015, . [RFC7858] Hu, Z., Zhu, L., Heidemann, J., Mankin, A., Wessels, D., and P. Hoffman, "Specification for DNS over Transport Layer Security (TLS)", RFC 7858, DOI 10.17487/RFC7858, May 2016, . Boucadair, et al. Expires March 13, 2021 [Page 10] Internet-Draft IKEv2 for Encrypted DNS September 2020 [RFC8484] Hoffman, P. and P. McManus, "DNS Queries over HTTPS (DoH)", RFC 8484, DOI 10.17487/RFC8484, October 2018, . [RFC8499] Hoffman, P., Sullivan, A., and K. Fujiwara, "DNS Terminology", BCP 219, RFC 8499, DOI 10.17487/RFC8499, January 2019, . [RFC8598] Pauly, T. and P. Wouters, "Split DNS Configuration for the Internet Key Exchange Protocol Version 2 (IKEv2)", RFC 8598, DOI 10.17487/RFC8598, May 2019, . Authors' Addresses Mohamed Boucadair Orange Rennes 35000 France Email: mohamed.boucadair@orange.com Tirumaleswar Reddy McAfee, Inc. Embassy Golf Link Business Park Bangalore, Karnataka 560071 India Email: TirumaleswarReddy_Konda@McAfee.com Dan Wing Citrix Systems, Inc. USA Email: dwing-ietf@fuggles.com Valery Smyslov ELVIS-PLUS RU Email: svan@elvis.ru Boucadair, et al. Expires March 13, 2021 [Page 11]