< draft-btw-add-ipsecme-ike-01.txt   draft-btw-add-ipsecme-ike-02.txt >
ADD M. Boucadair ADD M. Boucadair
Internet-Draft Orange Internet-Draft Orange
Intended status: Standards Track T. Reddy Intended status: Standards Track T. Reddy
Expires: March 13, 2021 McAfee Expires: August 23, 2021 McAfee
D. Wing D. Wing
Citrix Citrix
V. Smyslov V. Smyslov
ELVIS-PLUS ELVIS-PLUS
September 9, 2020 February 19, 2021
Internet Key Exchange Protocol Version 2 (IKEv2) Configuration for Internet Key Exchange Protocol Version 2 (IKEv2) Configuration for
Encrypted DNS Encrypted DNS
draft-btw-add-ipsecme-ike-01 draft-btw-add-ipsecme-ike-02
Abstract Abstract
This document specifies a new Internet Key Exchange Protocol Version This document specifies a new Internet Key Exchange Protocol Version
2 (IKEv2) Configuration Payload Attribute Types for encrypted DNS 2 (IKEv2) Configuration Payload Attribute Types for encrypted DNS
with a focus on DNS-over-HTTPS (DoH), DNS-over-TLS (DoT), and DNS- with a focus on DNS-over-HTTPS (DoH), DNS-over-TLS (DoT), and DNS-
over-QUIC (DoQ). over-QUIC (DoQ).
Status of This Memo Status of This Memo
skipping to change at page 1, line 39 skipping to change at page 1, line 39
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/. Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on March 13, 2021. This Internet-Draft will expire on August 23, 2021.
Copyright Notice Copyright Notice
Copyright (c) 2020 IETF Trust and the persons identified as the Copyright (c) 2021 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(https://trustee.ietf.org/license-info) in effect on the date of (https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Sample Deployment Scenarios . . . . . . . . . . . . . . . . . 3 3. Sample Deployment Scenarios . . . . . . . . . . . . . . . . . 4
3.1. Roaming Enterprise Users . . . . . . . . . . . . . . . . 3 3.1. Roaming Enterprise Users . . . . . . . . . . . . . . . . 4
3.2. VPN Service Provider . . . . . . . . . . . . . . . . . . 4 3.2. VPN Service Provider . . . . . . . . . . . . . . . . . . 4
3.3. DNS Offload . . . . . . . . . . . . . . . . . . . . . . . 4 3.3. DNS Offload . . . . . . . . . . . . . . . . . . . . . . . 5
4. IKEv2 Configuration Payload Attribute Types for Encrypted DNS 4 4. IKEv2 Configuration Payload Attribute Types for Encrypted DNS 5
5. IKEv2 Protocol Exchange . . . . . . . . . . . . . . . . . . . 6 4.1. ENCDNS_IP*_* Configuration Payload Attributes . . . . . . 5
6. URI Template . . . . . . . . . . . . . . . . . . . . . . . . 7 4.2. ENCDNS_URI_TEMPLATE Configuration Payload Attribute . . . 6
7. Security Considerations . . . . . . . . . . . . . . . . . . . 7 5. IKEv2 Protocol Exchange . . . . . . . . . . . . . . . . . . . 7
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 6. Security Considerations . . . . . . . . . . . . . . . . . . . 9
8.1. Configuration Payload Attribute Types . . . . . . . . . . 8 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9
9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 9 7.1. Configuration Payload Attribute Types . . . . . . . . . . 9
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 9 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 10
10.1. Normative References . . . . . . . . . . . . . . . . . . 9 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 10
10.2. Informative References . . . . . . . . . . . . . . . . . 10 9.1. Normative References . . . . . . . . . . . . . . . . . . 10
9.2. Informative References . . . . . . . . . . . . . . . . . 11
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 11 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 11
1. Introduction 1. Introduction
This document specifies encrypted DNS configuration for an Internet This document specifies encrypted DNS configuration for an Internet
Key Exchange Protocol Version 2 (IKEv2) [RFC7296] initiator, Key Exchange Protocol Version 2 (IKEv2) [RFC7296] initiator,
particularly the Authentication Domain Name (ADN, defined in particularly the Authentication Domain Name (ADN) of DNS-over-HTTPS
[RFC8310]) of DNS-over-HTTPS (DoH) [RFC8484], DNS-over-TLS (DoT) (DoH) [RFC8484], DNS-over-TLS (DoT) [RFC7858], or DNS-over-QUIC (DoQ)
[RFC7858], or DNS-over-QUIC (DoQ) [I-D.ietf-dprive-dnsoquic]. [I-D.ietf-dprive-dnsoquic].
This document introduces new IKEv2 Configuration Payload Attribute This document introduces new IKEv2 Configuration Payload Attribute
Types (Section 4) for the support of DoT, DoH, and DoQ DNS servers. Types (Section 4) for the support of DoT, DoH, and DoQ DNS servers.
These attributes can be used to provision authentication domain
names, a list of IP addresses, alternate port numbers, and a list of
DoH URI Template. The use of IKEv2 to provide these template is
meant to allow deployments where customized DoH configuration (e.g.,
per-subscriber or per-site) is required.
This document targets the deployments discussed in Section 3.3 of Sample use cases are discussed in Section 3. The Configuration
[I-D.box-add-requirements]. Sample use cases are discussed in Payload Attribute Types defined in this document are not specific to
Section 3. The Configuration Payload Attribute Types defined in this these deployments, but can also be used in other deployment contexts.
document are not specific to these deployments, but can also be used It is out of the scope of this document to provide a comprehensive
in other deployment contexts. list of deployment contexts.
The encrypted DNS server hosted by the VPN provider can get a domain-
validate certificate from a public CA. The VPN client does not need
to be provisioned with the root certificate of a private CA to
authenticate the certificate of the encrypted DNS server. The
encrypted DNS server can run on private IP addresses and its access
can be restricted to clients connected to the VPN.
Note that, for many years, typical designs have often considered that Note that, for many years, typical designs have often considered that
the DNS server was usually located inside the protected domain, but the DNS server was usually located inside the protected domain, but
could be located outside of it. With DoH, DoT, or DoQ the latter could be located outside of it. With encrypted DNS, the latter
option becomes plausible. option becomes plausible.
2. Terminology 2. Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in BCP "OPTIONAL" in this document are to be interpreted as described in BCP
14 [RFC2119][RFC8174] when, and only when, they appear in all 14 [RFC2119][RFC8174] when, and only when, they appear in all
capitals, as shown here. capitals, as shown here.
This document makes use of the terms defined in [RFC8499] and This document makes use of the terms defined in [RFC8499].
[I-D.ietf-dnsop-terminology-ter].
Also, this document makes use of the terms defined in [RFC7296]. In Also, this document makes use of the terms defined in [RFC7296]. In
particular, readers should be familiar with "initiator" and particular, readers should be familiar with "initiator" and
"responder" terms used in that document. "responder" terms used in that document.
Do53 refers to unencrypted DNS. This document makes use of the following terms:
Encrypted DNS refers to as scheme where DNS messages are sent over an 'Do53': refers to unencrypted DNS.
encrypted channel. Examples of encrypted DNS are DoT, DoH, and DoQ.
ENCDNS_IP*_* refers to any IKEv2 Configuration Payload Attribute 'Encrypted DNS': refers to as scheme where DNS messages are sent
Types defined in Section 4. over an encrypted channel. Examples of encrypted DNS are DoT,
DoH, and DoQ.
ENCDNS_IP4_* refers to an IKEv2 Configuration Payload Attribute Type 'ENCDNS_IP*_*': refers to any IKEv2 Configuration Payload Attribute
that carries one or multiple IPv4 addresses of an encrypted DNS Types defined in Section 4.
server.
ENCDNS_IP6_* refers to an IKEv2 Configuration Payload Attribute Type 'ENCDNS_IP4_*': refers to an IKEv2 Configuration Payload Attribute
that carries one or multiple IPv6 addresses of an encrypted DNS Type that carries one or multiple IPv4 addresses of an encrypted
server. 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. Sample Deployment Scenarios
3.1. Roaming Enterprise Users 3.1. Roaming Enterprise Users
In this Enterprise scenario (Section 1.1.3 of [RFC7296]), a roaming In this Enterprise scenario (Section 1.1.3 of [RFC7296]), a roaming
user connects to the Enterprise network through an IPsec tunnel. The user connects to the Enterprise network through an IPsec tunnel. The
split-tunnel Virtual Private Network (VPN) configuration allows the split-tunnel Virtual Private Network (VPN) configuration allows the
endpoint to access hosts that resides in the Enterprise network endpoint to access hosts that resides in the Enterprise network
[RFC8598] using that tunnel; other traffic not destined to the [RFC8598] using that tunnel; other traffic not destined to the
skipping to change at page 4, line 47 skipping to change at page 5, line 18
in which users can choose applications that can be excluded from the in which users can choose applications that can be excluded from the
tunnel. For example, users may exclude applications that restrict tunnel. For example, users may exclude applications that restrict
VPN access. VPN access.
The encrypted DNS server hosted by the VPN service provider can be The encrypted DNS server hosted by the VPN service provider can be
securely discovered by the endpoint using the IKEv2 Configuration securely discovered by the endpoint using the IKEv2 Configuration
Payload Attribute Type. Payload Attribute Type.
4. IKEv2 Configuration Payload Attribute Types for Encrypted DNS 4. IKEv2 Configuration Payload Attribute Types for Encrypted DNS
4.1. ENCDNS_IP*_* Configuration Payload Attributes
The ENCDNS_IP*_* IKEv2 Configuration Payload Attribute Types are used The ENCDNS_IP*_* IKEv2 Configuration Payload Attribute Types are used
to configure a DoT, DoH, or DoQ DNS server. All these attributes to configure a DoT, DoH, or DoQ DNS server. All these attributes
share the format shown in Figure 1. share the format shown in Figure 1.
1 2 3 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 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 | |R| Attribute Type | Length |
+-+-----------------------------+---------------+---------------+ +-+-----------------------------+---------------+---------------+
| Port Number | RESERVED | Num Addresses | | Port Number | RESERVED | Num Addresses |
skipping to change at page 5, line 29 skipping to change at page 5, line 48
+---------------------------------------------------------------+ +---------------------------------------------------------------+
Figure 1: Attributes Format Figure 1: Attributes Format
The fields of the attribute shown in Figure 1 are as follows: 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 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). ignored on receipt (see Section 3.15.1 of [RFC7296] for details).
o Attribute Type (15 bits) - Identifier for Configuration Attribute o Attribute Type (15 bits) - Identifier for Configuration Attribute
Type; is set to one of the values listed in Section 8.1. Type; is set to one of the TBA1-TBA6 values listed in Section 7.1.
o Length (2 octets, unsigned integer) - Length of the data in o Length (2 octets, unsigned integer) - Length of the data in
octets. In particular, this field is set to: octets. In particular, this field is set to:
* 0 if the Configuration payload has types CFG_REQUEST or * 0 if the Configuration payload has types CFG_REQUEST or
CFG_ACK. CFG_ACK.
* (2 + Length of the ADN + N * 4) for ENCDNS_IP4_* attributes if * (2 + Length of the ADN + N * 4) for ENCDNS_IP4_* attributes if
the Configuration payload of a has types CFG_REPLY or CFG_SET; the Configuration payload of a has types CFG_REPLY or CFG_SET;
N being the number of included IPv4 addresses ('Num N being the number of included IPv4 addresses ('Num
skipping to change at page 6, line 20 skipping to change at page 6, line 40
be used to reach the encrypted DNS identified by the name in the be used to reach the encrypted DNS identified by the name in the
DNS Authentication Domain Name. DNS Authentication Domain Name.
o Authentication Domain Name (variable) - A fully qualified domain o Authentication Domain Name (variable) - A fully qualified domain
name of the DoT, DoH, or DoQ DNS server following the syntax name of the DoT, DoH, or DoQ DNS server following the syntax
defined in [RFC5890]. The name MUST NOT contain any terminators defined in [RFC5890]. The name MUST NOT contain any terminators
(e.g., NULL, CR). (e.g., NULL, CR).
An example of valid ADN for DoH server is "doh1.example.com". An example of valid ADN for DoH server is "doh1.example.com".
4.2. ENCDNS_URI_TEMPLATE Configuration Payload Attribute
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.
Figure 2 depictes the format of the ENCDNS_URI_TEMPLATE IKEv2
Configuration Payload Attribute Type whihc is used to configure DoH
URI Template(s).
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| ENCDNS_URI_TEMPLATE | Length |
+-+-----------------------------+---------------+---------------+
| |
~ uri-template-data ~
| . . . |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Each instance of the uri-template-data is formatted as follows:
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-...-+-+-+-+-+-+-+
| uri-template-len | URI Template |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-...-+-+-+-+-+-+-+
Figure 2: DoH URI Template Attribute Format
The fields of the attribute shown in Figure 2 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 ENCDNS_URI_TEMPLATE (TBA7) (see Section 7.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.
o uri-template-data (variable) - XXXX.
An example of valid URI Template is "XXXX".
How a DoH client makes use of the configured DoH services is out of
the scope of this document.
5. IKEv2 Protocol Exchange 5. IKEv2 Protocol Exchange
This section describes how an initiator can be configured with an This section describes how an initiator can be configured with an
encrypted DNS server (e.g., DoH, DoT) using IKEv2. encrypted DNS server (e.g., DoH, DoT) using IKEv2.
Initiators indicate the support of an encrypted DNS in the Initiators indicate the support of an encrypted DNS in the
CFG_REQUEST payloads by including one or multiple ENCDNS_IP*_* CFG_REQUEST payloads by including one or multiple ENCDNS_IP*_*
attributes, while responders supply the encrypted DNS configuration attributes, while responders supply the encrypted DNS configuration
in the CFG_REPLY payloads. Concretely: in the CFG_REPLY payloads. Concretely:
If the initiator supports encrypted DNS, it includes one or more If the initiator supports encrypted DNS, it includes one or more
ENCDNS_IP*_* attributes in the CFG_REQUEST with the "Attribute ENCDNS_IP*_* attributes in the CFG_REQUEST with the "Attribute
Type" set to the requested encrypted DNS type (Section 4). For Type" set to the requested encrypted DNS type (Section 4). For
each supported encrypted DNS type the initiator MUST include each supported encrypted DNS type the initiator MUST include
exactly one attribute with the Length field set to 0, so that no exactly one attribute with the Length field set to 0, so that no
data is included for these attributes. data is included for these attributes. If DoH is requested, the
initiator includes also ENCDNS_URI_TEMPLATE in the CFG_REQUEST
with "Length" set to 0.
For each ENCDNS_IP*_* attribute from the CFG_REQUEST, if the For each ENCDNS_IP*_* attribute from the CFG_REQUEST, if the
responder supports the corresponding encrypted DNS type, and responder supports the corresponding encrypted DNS type, and
absent any policy, the responder sends back an ENCDNS_IP*_* absent any policy, the responder sends back an ENCDNS_IP*_*
attribute in the CFG_REPLY with this encrypted DNS type and an attribute in the CFG_REPLY with this encrypted DNS type and an
appropriate list of IP addresses, a port number, and an ADN. The appropriate list of IP addresses, a port number, and an ADN. The
list of IP addresses MUST NOT be empty. Multiple instances of the list of IP addresses MUST NOT be empty. Multiple instances of the
same ENCDNS_IP*_* attribute MAY be returned if distinct ADNs (or same ENCDNS_IP*_* attribute MAY be returned if distinct ADNs (or
port numbers) are to be returned by the responder. port numbers) are to be returned by the responder. If the
responder includes ENCDNS_IP4_DOH or ENCDNS_IP6_DOH in the
response, it MUST also include ENCDNS_URI_TEMPLATE carrying one or
more URI Templates.
If the CFG_REQUEST includes an ENCDNS_IP*_* attribute but the If the CFG_REQUEST includes an ENCDNS_IP*_* attribute but the
CFG_REPLY does not include an ENCDNS_IP*_* matching the requested CFG_REPLY does not include an ENCDNS_IP*_* matching the requested
encrypted DNS type, this is an indication that requested encrypted encrypted DNS type, this is an indication that requested encrypted
DNS type(s) is not supported by the responder or the responder is DNS type(s) is not supported by the responder or the responder is
not configured to provide corresponding server addresses. not configured to provide corresponding server addresses.
The behavior of the responder if it receives both ENCDNS_IP*_* and The behavior of the responder if it receives both ENCDNS_IP*_* and
INTERNAL_IP6_DNS (or INTERNAL_IP4_DNS) attributes is policy-based INTERNAL_IP6_DNS (or INTERNAL_IP4_DNS) attributes is policy-based
and deployment-specific. However, it is RECOMMENDED that if the and deployment-specific. However, it is RECOMMENDED that if the
skipping to change at page 7, line 28 skipping to change at page 9, line 7
If the IPsec connection is a split-tunnel configuration and the If the IPsec connection is a split-tunnel configuration and the
initiator negotiated INTERNAL_DNS_DOMAIN as per [RFC8598], the DNS initiator negotiated INTERNAL_DNS_DOMAIN as per [RFC8598], the DNS
client MUST resolve the internal names using ENCDNS_IP*_* DNS client MUST resolve the internal names using ENCDNS_IP*_* DNS
servers. servers.
Note: [RFC8598] requires INTERNAL_IP6_DNS (or INTERNAL_IP4_DNS) Note: [RFC8598] requires INTERNAL_IP6_DNS (or INTERNAL_IP4_DNS)
attribute to be mandatory present when INTERNAL_DNS_DOMAIN is attribute to be mandatory present when INTERNAL_DNS_DOMAIN is
included. This specification relaxes that constraint in the included. This specification relaxes that constraint in the
presence of ENCDNS_IP*_* attributes. presence of ENCDNS_IP*_* attributes.
6. URI Template 6. Security Considerations
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 This document adheres to the security considerations defined in
[RFC7296]. In particular, this document does not alter the trust on [RFC7296]. In particular, this document does not alter the trust on
the DNS configuration provided by a responder. the DNS configuration provided by a responder.
Networks are susceptible to internal attacks as discussed in Networks are susceptible to internal attacks as discussed in
Section 3.2 of [I-D.arkko-farrell-arch-model-t]. Hosting encrypted Section 3.2 of [I-D.arkko-farrell-arch-model-t]. Hosting encrypted
DNS server even in case of split-VPN configuration minimizes the DNS server even in case of split-VPN configuration minimizes the
attack vector (e.g., a compromised network device cannot monitor/ attack vector (e.g., a compromised network device cannot monitor/
modify DNS traffic). This specification describes a mechanism to modify DNS traffic). This specification describes a mechanism to
restrict access to the DNS messages to only the parties that need to restrict access to the DNS messages to only the parties that need to
know. 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 The initiator may trust the encrypted DNS servers supplied by means
of IKEv2 from a trusted responder more than the locally provided DNS of IKEv2 from a trusted responder more than the locally provided DNS
servers, especially in the case of connecting to unknown or untrusted servers, especially in the case of connecting to unknown or untrusted
networks (e.g., coffee shops or hotel networks). 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 If IKEv2 responder has used NULL Authentication method [RFC7619] to
authenticate itself, the initiator MUST NOT use returned ENCDNS_IP*_* authenticate itself, the initiator MUST NOT use returned ENCDNS_IP*_*
servers configuration unless it is pre-configured in the OS or the servers configuration unless it is pre-configured in the OS or the
browser. browser.
This specification does not extend the scope of accepting DNSSEC This specification does not extend the scope of accepting DNSSEC
trust anchors beyond the usage guidelines defined in Section 6 of trust anchors beyond the usage guidelines defined in Section 6 of
[RFC8598]. [RFC8598].
8. IANA Considerations 7. IANA Considerations
8.1. Configuration Payload Attribute Types 7.1. Configuration Payload Attribute Types
This document requests IANA to assign the following new IKEv2 This document requests IANA to assign the following new IKEv2
Configuration Payload Attribute Types from the "IKEv2 Configuration Configuration Payload Attribute Types from the "IKEv2 Configuration
Payload Attribute Types" namespace available at Payload Attribute Types" namespace available at
https://www.iana.org/assignments/ikev2-parameters/ https://www.iana.org/assignments/ikev2-parameters/
ikev2-parameters.xhtml#ikev2-parameters-21. ikev2-parameters.xhtml#ikev2-parameters-21.
Multi- Multi-
Value Attribute Type Valued Length Reference Value Attribute Type Valued Length Reference
------ ------------------- ------ ---------- ------------ ------ ------------------- ------ ---------- ------------
TBA1 ENCDNS_IP4_DOT YES 0 or more RFC XXXX TBA1 ENCDNS_IP4_DOT YES 0 or more RFC XXXX
TBA2 ENCDNS_IP6_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 TBA3 ENCDNS_IP4_DOH YES 0 or more RFC XXXX
TBA4 ENCDNS_IP6_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 TBA5 ENCDNS_IP4_DOQ YES 0 or more RFC XXXX
TBA6 ENCDNS_IP6_DOQ YES 0 or more RFC XXXX TBA6 ENCDNS_IP6_DOQ YES 0 or more RFC XXXX
TBA7 ENCDNS_URI_TEMPLATE YES 0 or more RFC XXXX
9. Acknowledgements 8. Acknowledgements
Many thanks to Yoav Nir, Christian Jacquenet, Paul Wouters, and Tommy Many thanks to Yoav Nir, Christian Jacquenet, Paul Wouters, and Tommy
Pauly for the review and comments. Pauly for the review and comments.
Yoav and Paul suggested the use of one single attribute carrying both Yoav and Paul suggested the use of one single attribute carrying both
the name and an IP address instead of depending on the existing the name and an IP address instead of depending on the existing
INTERNAL_IP6_DNS and INTERNAL_IP4_DNS attributes. INTERNAL_IP6_DNS and INTERNAL_IP4_DNS attributes.
Christian Huitema suiggested to return a port number in the Christian Huitema suiggested to return a port number in the
attributes. attributes.
10. References 9. References
10.1. Normative References 9.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997, DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>. <https://www.rfc-editor.org/info/rfc2119>.
[RFC5890] Klensin, J., "Internationalized Domain Names for [RFC5890] Klensin, J., "Internationalized Domain Names for
Applications (IDNA): Definitions and Document Framework", Applications (IDNA): Definitions and Document Framework",
RFC 5890, DOI 10.17487/RFC5890, August 2010, RFC 5890, DOI 10.17487/RFC5890, August 2010,
<https://www.rfc-editor.org/info/rfc5890>. <https://www.rfc-editor.org/info/rfc5890>.
skipping to change at page 10, line 10 skipping to change at page 11, line 10
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>. May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[RFC8310] Dickinson, S., Gillmor, D., and T. Reddy, "Usage Profiles [RFC8310] Dickinson, S., Gillmor, D., and T. Reddy, "Usage Profiles
for DNS over TLS and DNS over DTLS", RFC 8310, for DNS over TLS and DNS over DTLS", RFC 8310,
DOI 10.17487/RFC8310, March 2018, DOI 10.17487/RFC8310, March 2018,
<https://www.rfc-editor.org/info/rfc8310>. <https://www.rfc-editor.org/info/rfc8310>.
10.2. Informative References 9.2. Informative References
[I-D.arkko-farrell-arch-model-t] [I-D.arkko-farrell-arch-model-t]
Arkko, J. and S. Farrell, "Challenges and Changes in the Arkko, J. and S. Farrell, "Challenges and Changes in the
Internet Threat Model", draft-arkko-farrell-arch-model- Internet Threat Model", draft-arkko-farrell-arch-model-
t-04 (work in progress), July 2020. 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] [I-D.ietf-dprive-dnsoquic]
Huitema, C., Mankin, A., and S. Dickinson, "Specification Huitema, C., Mankin, A., and S. Dickinson, "Specification
of DNS over Dedicated QUIC Connections", draft-ietf- of DNS over Dedicated QUIC Connections", draft-ietf-
dprive-dnsoquic-00 (work in progress), April 2020. dprive-dnsoquic-01 (work in progress), October 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 [RFC7619] Smyslov, V. and P. Wouters, "The NULL Authentication
Method in the Internet Key Exchange Protocol Version 2 Method in the Internet Key Exchange Protocol Version 2
(IKEv2)", RFC 7619, DOI 10.17487/RFC7619, August 2015, (IKEv2)", RFC 7619, DOI 10.17487/RFC7619, August 2015,
<https://www.rfc-editor.org/info/rfc7619>. <https://www.rfc-editor.org/info/rfc7619>.
[RFC7858] Hu, Z., Zhu, L., Heidemann, J., Mankin, A., Wessels, D., [RFC7858] Hu, Z., Zhu, L., Heidemann, J., Mankin, A., Wessels, D.,
and P. Hoffman, "Specification for DNS over Transport and P. Hoffman, "Specification for DNS over Transport
Layer Security (TLS)", RFC 7858, DOI 10.17487/RFC7858, May Layer Security (TLS)", RFC 7858, DOI 10.17487/RFC7858, May
2016, <https://www.rfc-editor.org/info/rfc7858>. 2016, <https://www.rfc-editor.org/info/rfc7858>.
 End of changes. 34 change blocks. 
115 lines changed or deleted 128 lines changed or added

This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/