< draft-btw-add-ipsecme-ike-00.txt		draft-btw-add-ipsecme-ike-01.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: October 9, 2020 McAfee		Expires: March 13, 2021 McAfee
	D. Wing		D. Wing
	Citrix		Citrix
	V. Smyslov		V. Smyslov
	ELVIS-PLUS		ELVIS-PLUS
	April 7, 2020		September 9, 2020
	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-00		draft-btw-add-ipsecme-ike-01
	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 Type for encrypted DNS such		2 (IKEv2) Configuration Payload Attribute Types for encrypted DNS
	as DNS-over-HTTPS (DoH) and DNS-over-TLS (DoT).		with a focus on DNS-over-HTTPS (DoH), DNS-over-TLS (DoT), and DNS-
			over-QUIC (DoQ).
	Status of This Memo		Status of This Memo
	This Internet-Draft is submitted in full conformance with the		This Internet-Draft is submitted in full conformance with the
	provisions of BCP 78 and BCP 79.		provisions of BCP 78 and BCP 79.
	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 October 9, 2020.		This Internet-Draft will expire on March 13, 2021.
	Copyright Notice		Copyright Notice
	Copyright (c) 2020 IETF Trust and the persons identified as the		Copyright (c) 2020 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
	skipping to change at page 2, line 17 ¶		skipping to change at page 2, line 18 ¶
	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 . . . . . . . . . . . . . . . . . 3
	3.1. Roaming Enterprise Users . . . . . . . . . . . . . . . . 3		3.1. Roaming Enterprise Users . . . . . . . . . . . . . . . . 3
	3.2. VPN Service Provider . . . . . . . . . . . . . . . . . . 4		3.2. VPN Service Provider . . . . . . . . . . . . . . . . . . 4
	3.3. DNS Offload . . . . . . . . . . . . . . . . . . . . . . . 4		3.3. DNS Offload . . . . . . . . . . . . . . . . . . . . . . . 4
	4. INTERNAL_ENC_DNS Attribute . . . . . . . . . . . . . . . . . 4		4. IKEv2 Configuration Payload Attribute Types for Encrypted DNS 4
	5. URI Template . . . . . . . . . . . . . . . . . . . . . . . . 6		5. IKEv2 Protocol Exchange . . . . . . . . . . . . . . . . . . . 6
	6. IKEv2 Protocol Exchange . . . . . . . . . . . . . . . . . . . 6		6. URI Template . . . . . . . . . . . . . . . . . . . . . . . . 7
	7. Security Considerations . . . . . . . . . . . . . . . . . . . 7		7. Security Considerations . . . . . . . . . . . . . . . . . . . 7
	8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8		8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8
	8.1. Configuration Payload Attribute Type . . . . . . . . . . 8		8.1. Configuration Payload Attribute Types . . . . . . . . . . 8
	8.2. Encrypted DNS Types . . . . . . . . . . . . . . . . . . . 9
	9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 9		9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 9
	10. References . . . . . . . . . . . . . . . . . . . . . . . . . 9		10. References . . . . . . . . . . . . . . . . . . . . . . . . . 9
	10.1. Normative References . . . . . . . . . . . . . . . . . . 9		10.1. Normative References . . . . . . . . . . . . . . . . . . 9
	10.2. Informative References . . . . . . . . . . . . . . . . . 10		10.2. Informative References . . . . . . . . . . . . . . . . . 10
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 11		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 11
	1. Introduction		1. Introduction
	This document specifies encrypted DNS configuration for an IKE		This document specifies encrypted DNS configuration for an Internet
	initiator, particularly the Authentication Domain Name (ADN, defined		Key Exchange Protocol Version 2 (IKEv2) [RFC7296] initiator,
	in [RFC8310]) of DNS-over-HTTPS (DoH) [RFC8484] or DNS-over-TLS (DoT)		particularly the Authentication Domain Name (ADN, defined in
	[RFC7858] server using Internet Key Exchange Protocol Version 2		[RFC8310]) of DNS-over-HTTPS (DoH) [RFC8484], DNS-over-TLS (DoT)
	(IKEv2) [RFC7296].		[RFC7858], or DNS-over-QUIC (DoQ) [I-D.ietf-dprive-dnsoquic].
	Particularly, this document introduces a new IKEv2 Configuration		This document introduces new IKEv2 Configuration Payload Attribute
	Payload Attribute Types (Section 4) for the support of encrypted DNS		Types (Section 4) for the support of DoT, DoH, and DoQ DNS servers.
	servers (e.g., DoT, DoH).
	Sample use cases are discussed in Section 3. The Configuration		This document targets the deployments discussed in Section 3.3 of
	Payload Attribute Type defined in Section 4 is not specific to these		[I-D.box-add-requirements]. Sample use cases are discussed in
	deployments, but can be used in other deployment contexts.		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 has 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 theoretically be located outside of it. With DoH or DoT, the		could be located outside of it. With DoH, DoT, or DoQ the latter
	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] and
	[I-D.ietf-dnsop-terminology-ter].		[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.		Do53 refers to unencrypted DNS.
	'DoH/DoT' refers to DNS-over-HTTPS and/or DNS-over-TLS.		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. 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
	Enterprise does not traverse the tunnel. In contrast, a non-split-		Enterprise does not traverse the tunnel. In contrast, a non-split-
	tunnel VPN configuration causes all traffic to traverse the tunnel		tunnel VPN configuration causes all traffic to traverse the tunnel
	into the enterprise.		into the enterprise.
	For both split- and non-split-tunnel configurations, the use of DoT/		For both split- and non-split-tunnel configurations, the use of
	DoH instead of Do53 provides privacy and integrity protection along		encrypted DNS instead of Do53 provides privacy and integrity
	the entire path (rather than just to the VPN termination device) and		protection along the entire path (rather than just to the VPN
	can communicate the DoT/DoH server policies.		termination device) and can communicate the encrypted DNS server
			policies.
	For split-tunnel VPN configurations, the endpoint uses the		For split-tunnel VPN configurations, the endpoint uses the
	Enterprise-provided DoT/DoH server to resolve internal-only domain		Enterprise-provided encrypted DNS server to resolve internal-only
	names.		domain names.
	For non-split-tunnel VPN configurations, the endpoint uses the		For non-split-tunnel VPN configurations, the endpoint uses the
	Enterprise-provided DoT/DoH server to resolve both internal and		Enterprise-provided encrypted DNS server to resolve both internal and
	external domain names.		external domain names.
	Enterprise networks are susceptible to internal and external attacks.		Enterprise networks are susceptible to internal and external attacks.
	To minimize that risk all enterprise traffic is encrypted		To minimize that risk all enterprise traffic is encrypted
	(Section 2.1 of [I-D.arkko-farrell-arch-model-t]).		(Section 2.1 of [I-D.arkko-farrell-arch-model-t]).
	3.2. VPN Service Provider		3.2. VPN Service Provider
	Legacy VPN service providers usually preserve end-users' data		Legacy VPN service providers usually preserve end-users' data
	confidentiality by sending all communication traffic through an		confidentiality by sending all communication traffic through an
	encrypted tunnel. A VPN service provider can also provide guarantees		encrypted tunnel. A VPN service provider can also provide guarantees
	about the security of the VPN network by filtering malware and		about the security of the VPN network by filtering malware and
	phishing domains.		phishing domains.
	Browsers and OSes support DoH/DoT; VPN providers may no longer expect		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.		DNS clients to fallback to Do53 just because it is a closed network.
	The DoT/DoH server hosted by the VPN service provider can be securely		The encrypted DNS server hosted by the VPN service provider can be
	discovered by the endpoint using the IKEv2 Configuration Payload		securely discovered by the endpoint using the IKEv2 Configuration
	Attribute Type.		Payload Attribute Type.
	3.3. DNS Offload		3.3. DNS Offload
	VPN service providers typically allow split-tunnel VPN configuration		VPN service providers typically allow split-tunnel VPN configuration
	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.
	VPN service providers can also offer publicly accessible DoH/DoT		The encrypted DNS server hosted by the VPN service provider can be
	servers. The split-tunnel VPN configuration allows the client to		securely discovered by the endpoint using the IKEv2 Configuration
	access the DoH/DoT servers hosted by the VPN provider without		Payload Attribute Type.
	traversing the tunnel.
	The DoT/DoH server hosted by the VPN service provider can be securely
	discovered by the endpoint using the IKEv2 Configuration Payload
	Attribute Type.
	4. INTERNAL_ENC_DNS Attribute		4. IKEv2 Configuration Payload Attribute Types for Encrypted DNS
	The INTERNAL_ENC_DNS IKEv2 Configuration Payload Attribute Type is		The ENCDNS_IP*_* IKEv2 Configuration Payload Attribute Types are used
	used to configure an encrypted DNS server. The format of this		to configure a DoT, DoH, or DoQ DNS server. All these attributes
	attribute is 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 |
	+-+-------------+---------------+-------------------------------+		+-+-----------------------------+---------------+---------------+
	|S|Enc DNS Type | Num addresses | |		| Port Number | RESERVED | Num Addresses |
	+-+-------------+---------------+ +		+-------------------------------+---------------+---------------+
	| IPv6 Addresses ~		| |
	| +-------------------------------+		~ IP Addresses ~
	~ | |		| |
	+-------------------------------+ |		+---------------------------------------------------------------+
	| |		| |
	~ DNS Authentication Domain Name ~		~ DNS Authentication Domain Name ~
	| |		| |
	+---------------------------------------------------------------+		+---------------------------------------------------------------+
	Figure 1: INTERNAL_ENC_DNS Attribute 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 bit; refer to Section 3.15.1 of [RFC7296].		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: MUST be set to TBA (Section 8.1).
	o Length: Length of the data in octets. It MUST be set to 1 if the
	Configuration payload has types CFG_REQUEST or CFG_ACK or to (2 +
	Length of the ADN + N * 16) if the Configuration payload has types
	CFG_REPLY or CFG_SET; N being the number of included IP addresses
	('Num addresses').
	o S: Scope bit. This bit controls whether the DNS queries are sent		o Attribute Type (15 bits) - Identifier for Configuration Attribute
	within the tunnel or outside. If set, this bit instructs the		Type; is set to one of the values listed in Section 8.1.
	initiator to send encrypted DNS queries outside the tunnel. If
	the bit is unset, the queries are sent inside the tunnel. The
	default value of this bit is "0".
	o Encrypted DNS Type: Indicates the type of the encrypted DNS server		o Length (2 octets, unsigned integer) - Length of the data in
	conveyed in this attribute. The following values are defined:		octets. In particular, this field is set to:
	0: Reserved		* 0 if the Configuration payload has types CFG_REQUEST or
			CFG_ACK.
	1: DoT		* (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: DoH		* (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').
	See Section 8.2 for future assignment considerations.		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 Num addresses: If Length > 1, it indicates the number of enclosed		o RESERVED (1 octet) - These bits are reserved for future use.
	IP addresses.		These bits MUST be set to zero by the sender and MUST be ignored
			by the receiver.
	o IPv6 Address(es): One or more IPv6 addresses to be used to reach		o Num Addresses (1 octet) - Indicates the number of enclosed IPv4
	the encrypted DNS identified by the name in the DNS Authentication		(for ENCDNS_IP4_* attribute types) or IPv6 (for ENCDNS_IP6_*
	Domain Name.		attribute types) addresses.
	IPv4 addresses MUST be encoded using the IPv4-Mapped IPv6 Address		o IP Address(es) (variable) - One or more IPv4 or IPv6 addresses to
	format defined in [RFC4291].		be used to reach the encrypted DNS identified by the name in the
			DNS Authentication Domain Name.
	o Authentication Domain Name: A fully qualified domain name of the		o Authentication Domain Name (variable) - A fully qualified domain
	DoT (or DoH) server following the syntax defined in [RFC5890].		name of the DoT, DoH, or DoQ DNS server following the syntax
	The name MUST NOT contain any terminators (e.g., NULL, CR).		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".		An example of valid ADN for DoH server is "doh1.example.com".
	5. URI Template		5. IKEv2 Protocol Exchange
	DoH servers may support more than one URI Template [RFC8484]. The
	following sub-sections discuss some candidate solutions for a DoH
	client to retrieve the list of supported templates by a DoH server.
	Also, if the resolver hosts several DoH services (e.g., no-filtering,
	blocking adult content, blocking malware), these services can be
	discovered as templates.
	This section will be updated to reflect the outcome of the discussion
	in [I-D.btw-add-home].
	How a DoH client makes use of the configured DoH services is out of
	the scope of this document.
	6. 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 INTERNAL_ENC_DNS attribute, while		CFG_REQUEST payloads by including one or multiple ENCDNS_IP*_*
	responders supply the encrypted DNS configuration in the CFG_REPLY		attributes, while responders supply the encrypted DNS configuration
	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
	INTERNAL_ENC_DNS attributes in the CFG_REQUEST with the "Encrypted		ENCDNS_IP*_* attributes in the CFG_REQUEST with the "Attribute
	DNS Type" set to the requested encrypted DNS type (Section 4).		Type" set to the requested encrypted DNS type (Section 4). For
	For each supported encrypted DNS type the initiator MUST include		each supported encrypted DNS type the initiator MUST include
	exactly one INTERNAL_ENC_DNS attribute with the Length field set		exactly one attribute with the Length field set to 0, so that no
	to 1.		data is included for these attributes.
	If an INTERNAL_ENC_DNS attribute is included in the CFG_REQUEST,
	the INTERNAL_ENC_DNS attribute MUST NOT include an ADN and list of
	IP addresses.
	For each INTERNAL_ENC_DNS 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, then it		responder supports the corresponding encrypted DNS type, and
	MAY send back an INTERNAL_ENC_DNS attribute in the CFG_REPLY with		absent any policy, the responder sends back an ENCDNS_IP*_*
	this encrypted DNS type and an appropriate list of IP addresses		attribute in the CFG_REPLY with this encrypted DNS type and an
	and ADN. The list of IP addresses MUST NOT be empty.		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 INTERNAL_ENC_DNS attribute but the		If the CFG_REQUEST includes an ENCDNS_IP*_* attribute but the
	CFG_REPLY does not include an INTERNAL_ENC_DNS, this is an		CFG_REPLY does not include an ENCDNS_IP*_* matching the requested
	indication that requested encrypted DNS type(s) is not supported		encrypted DNS type, this is an indication that requested encrypted
	by the responder.		DNS type(s) is not supported by the responder or the responder is
			not configured to provide corresponding server addresses.
	The behavior of the responder if it receives both INTERNAL_ENC_DNS		The behavior of the responder if it receives both ENCDNS_IP*_* and
	and INTERNAL_IP6_DNS (or INTERNAL_IP4_DNS) attributes is policy-		INTERNAL_IP6_DNS (or INTERNAL_IP4_DNS) attributes is policy-based
	based and deployment-specific. However, it is RECOMMENDED that if		and deployment-specific. However, it is RECOMMENDED that if the
	the responder includes at least one INTERNAL_ENC_DNS attribute in		responder includes at least one ENCDNS_IP*_* attribute in the
	the reply, it should not include any of INTERNAL_IP4_DNS/		reply, it should not include any of INTERNAL_IP4_DNS/
	INTERNAL_IP6_DNS attributes.		INTERNAL_IP6_DNS attributes.
	The DNS client establishes a DoH/DoT session with the address(es)		The DNS client establishes an encrypted DNS session (e.g., DoT, DoH,
	conveyed in INTERNAL_ENC_DNS and uses the mechanism discussed in		DoQ) with the address(es) conveyed in ENCDNS_IP*_* and uses the
	Section 8 of [RFC8310] to authenticate the DNS server certificate		mechanism discussed in Section 8 of [RFC8310] to authenticate the DNS
	using the authentication domain name conveyed in INTERNAL_ENC_DNS.		server certificate using the authentication domain name conveyed in
			ENCDNS_IP*_*.
	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 INTERNAL_ENC_DNS 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 INTERNAL_ENC_DNS attribute.		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		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 DoH/DoT		Section 3.2 of [I-D.arkko-farrell-arch-model-t]. Hosting encrypted
	server even in case of split-VPN configuration minimizes the attack		DNS server even in case of split-VPN configuration minimizes the
	vector (e.g., a compromised network device cannot monitor/modify DNS		attack vector (e.g., a compromised network device cannot monitor/
	traffic). This specification describes a mechanism to restrict		modify DNS traffic). This specification describes a mechanism to
	access to the DNS messages to only the parties that need to know.		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		In most deployment scenarios, the initiator expects that it is using
	the DoH/DoT server hosted by a specific organization or enterprise.		the encrypted DNS server hosted by a specific organization or
	The DNS client can validate the signatory (i.e., cryptographically		enterprise. The DNS client can validate the signatory (i.e.,
	attested by the organization hosting the DoH/DoT server) using, for		cryptographically attested by the organization hosting the encrypted
	example, [I-D.reddy-add-server-policy-selection], and the user can		DNS server) using, for example,
	review human-readable privacy policy information of the DNS server		[I-D.reddy-add-server-policy-selection], and the user can review
	and assess whether the DNS server performs DNS-based content		human-readable privacy policy information of the DNS server and
	filtering. This helps to protect from a compromised IKE server		assess whether the DNS server performs DNS-based content filtering.
	advertising a malicious DoH/DoT server.		This helps to protect from a compromised IKE server advertising a
			malicious encrypted DNS server.
	The initiator may trust the DoH/DoT servers supplied by means of		The initiator may trust the encrypted DNS servers supplied by means
	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). In addition, the		networks (e.g., coffee shops or hotel networks).
	initiator may prefer IKEv2-supplied DoH/DoT servers if they provide
	additional features (e.g., malware filtering) compared to the pre-
	configured DNS servers and meets the privacy preserving data policy
	requirements of the user.
	If the DoH/DoT server that was discovered by means of IKEv2 does not		If the encrypted DNS server that was discovered by means of IKEv2
	meet the privacy preserving data policy and filtering requirements of		does not meet the privacy preserving data policy and filtering
	the user, the user can instruct the DNS client to take appropriate		requirements of the user, the user can instruct the DNS client to
	actions. For example, the action can be to use the local DoH/DoT		take appropriate actions. For example, the action can be to use the
	server only to access internal-only DNS names and use another DNS		local encrypted DNS server only to access internal-only DNS names and
	server (that addresses his/her expectations) for public domains.		use another DNS server (that addresses his/her expectations) for
	Such actions and their handling is out of scope.		public domains. Such actions and their handling is out of scope.
	If IKEv2 is being negotiated with an anonymous or unknown endpoint		If IKEv2 responder has used NULL Authentication method [RFC7619] to
	(such as for Opportunistic Security [RFC7435]), the initiator MUST		authenticate itself, the initiator MUST NOT use returned ENCDNS_IP*_*
	NOT use INTERNAL_ENC_DNS servers unless it is pre-configured in the		servers configuration unless it is pre-configured in the OS or 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		8. IANA Considerations
	8.1. Configuration Payload Attribute Type		8.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
	------ ------------------- ------ ---------- ------------		------ ------------------- ------ ---------- ------------
	TBA INTERNAL_ENC_DNS YES 1 or more RFC XXXX		TBA1 ENCDNS_IP4_DOT YES 0 or more RFC XXXX
			TBA2 ENCDNS_IP6_DOT YES 0 or more RFC XXXX
	8.2. Encrypted DNS Types		TBA3 ENCDNS_IP4_DOH YES 0 or more RFC XXXX
			TBA4 ENCDNS_IP6_DOH YES 0 or more RFC XXXX
	This document requests IANA to create a new registry called		TBA5 ENCDNS_IP4_DOQ YES 0 or more RFC XXXX
	"Encrypted DNS Types" under "Internet Key Exchange Version 2 (IKEv2)		TBA6 ENCDNS_IP6_DOQ YES 0 or more RFC XXXX
	Parameters" available at https://www.iana.org/assignments/ikev2-
	parameters/ikev2-parameters.xhtml#ikev2-parameters-21. The initial
	values of the registry is as follows:
	+-------+----------------------+-----------+
	| Value | Description | Reference |
	+-------+----------------------+-----------+
	| 0 | Reserved | RFC XXXX |
	| 1 | DNS-over-TLS (DoT) | RFC XXXX |
	| 2 | DNS-over-HTTPs (DoH) | RFC XXXX |
	+-------+----------------------+-----------+
	New values are assigned on a First Come, First Served (FCFS) basis
	(Section 4.4 of [RFC8126]).
	9. Acknowledgements		9. 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
			attributes.
	10. References		10. References
	10.1. Normative References		10.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>.
	[RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing
	Architecture", RFC 4291, DOI 10.17487/RFC4291, February
	2006, <https://www.rfc-editor.org/info/rfc4291>.
	[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>.
	[RFC7296] Kaufman, C., Hoffman, P., Nir, Y., Eronen, P., and T.		[RFC7296] Kaufman, C., Hoffman, P., Nir, Y., Eronen, P., and T.
	Kivinen, "Internet Key Exchange Protocol Version 2		Kivinen, "Internet Key Exchange Protocol Version 2
	(IKEv2)", STD 79, RFC 7296, DOI 10.17487/RFC7296, October		(IKEv2)", STD 79, RFC 7296, DOI 10.17487/RFC7296, October
	2014, <https://www.rfc-editor.org/info/rfc7296>.		2014, <https://www.rfc-editor.org/info/rfc7296>.
	[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, <https://www.rfc-editor.org/info/rfc7858>.
	[RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for
	Writing an IANA Considerations Section in RFCs", BCP 26,
	RFC 8126, DOI 10.17487/RFC8126, June 2017,
	<https://www.rfc-editor.org/info/rfc8126>.
	[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>.
	[RFC8484] Hoffman, P. and P. McManus, "DNS Queries over HTTPS
	(DoH)", RFC 8484, DOI 10.17487/RFC8484, October 2018,
	<https://www.rfc-editor.org/info/rfc8484>.
	10.2. Informative References		10.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-03 (work in progress), March 2020.		t-04 (work in progress), July 2020.
	[I-D.btw-add-home]		[I-D.box-add-requirements]
	Boucadair, M., Reddy.K, T., Wing, D., and N. Cook, "DNS-		Box, C., Pauly, T., Wood, C., and T. Reddy.K,
	over-HTTPS and DNS-over-TLS Server Discovery and		"Requirements for Adaptive DNS Discovery", draft-box-add-
	Deployment Considerations for Home and Mobile Networks",		requirements-00 (work in progress), September 2020.
	draft-btw-add-home-04 (work in progress), March 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]		[I-D.ietf-dnsop-terminology-ter]
	Hoffman, P., "Terminology for DNS Transports and		Hoffman, P., "Terminology for DNS Transports and
	Location", draft-ietf-dnsop-terminology-ter-01 (work in		Location", draft-ietf-dnsop-terminology-ter-02 (work in
	progress), February 2020.		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]		[I-D.reddy-add-server-policy-selection]
	Reddy.K, T., Wing, D., Richardson, M., and M. Boucadair,		Reddy.K, T., Wing, D., Richardson, M., and M. Boucadair,
	"DNS Server Selection: DNS Server Information with		"DNS Server Selection: DNS Server Information with
	Assertion Token", draft-reddy-add-server-policy-		Assertion Token", draft-reddy-add-server-policy-
	selection-00 (work in progress), March 2020.		selection-04 (work in progress), July 2020.
	[RFC7435] Dukhovni, V., "Opportunistic Security: Some Protection		[RFC7619] Smyslov, V. and P. Wouters, "The NULL Authentication
	Most of the Time", RFC 7435, DOI 10.17487/RFC7435,		Method in the Internet Key Exchange Protocol Version 2
	December 2014, <https://www.rfc-editor.org/info/rfc7435>.		(IKEv2)", RFC 7619, DOI 10.17487/RFC7619, August 2015,
			<https://www.rfc-editor.org/info/rfc7619>.
			[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, <https://www.rfc-editor.org/info/rfc7858>.
			[RFC8484] Hoffman, P. and P. McManus, "DNS Queries over HTTPS
			(DoH)", RFC 8484, DOI 10.17487/RFC8484, October 2018,
			<https://www.rfc-editor.org/info/rfc8484>.
	[RFC8499] Hoffman, P., Sullivan, A., and K. Fujiwara, "DNS		[RFC8499] Hoffman, P., Sullivan, A., and K. Fujiwara, "DNS
	Terminology", BCP 219, RFC 8499, DOI 10.17487/RFC8499,		Terminology", BCP 219, RFC 8499, DOI 10.17487/RFC8499,
	January 2019, <https://www.rfc-editor.org/info/rfc8499>.		January 2019, <https://www.rfc-editor.org/info/rfc8499>.
	[RFC8598] Pauly, T. and P. Wouters, "Split DNS Configuration for the		[RFC8598] Pauly, T. and P. Wouters, "Split DNS Configuration for the
	Internet Key Exchange Protocol Version 2 (IKEv2)",		Internet Key Exchange Protocol Version 2 (IKEv2)",
	RFC 8598, DOI 10.17487/RFC8598, May 2019,		RFC 8598, DOI 10.17487/RFC8598, May 2019,
	<https://www.rfc-editor.org/info/rfc8598>.		<https://www.rfc-editor.org/info/rfc8598>.
End of changes. 59 change blocks.
	224 lines changed or deleted		226 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/