draft-ietf-ipsecme-split-dns-17.txt		rfc8598.txt
	Network T. Pauly		Internet Engineering Task Force (IETF) T. Pauly
	Internet-Draft Apple Inc.		Request for Comments: 8598 Apple Inc.
	Intended status: Standards Track P. Wouters		Category: Standards Track P. Wouters
	Expires: September 12, 2019 Red Hat		ISSN: 2070-1721 Red Hat
	March 11, 2019		May 2019
	Split DNS Configuration for IKEv2		Split DNS Configuration
	draft-ietf-ipsecme-split-dns-17		for the Internet Key Exchange Protocol Version 2 (IKEv2)
	Abstract		Abstract
	This document defines two Configuration Payload Attribute Types		This document defines two Configuration Payload Attribute Types
	(INTERNAL_DNS_DOMAIN and INTERNAL_DNSSEC_TA) for the Internet Key		(INTERNAL_DNS_DOMAIN and INTERNAL_DNSSEC_TA) for the Internet Key
	Exchange Protocol Version 2 (IKEv2). These payloads add support for		Exchange Protocol version 2 (IKEv2). These payloads add support for
	private (internal-only) DNS domains. These domains are intended to		private (internal-only) DNS domains. These domains are intended to
	be resolved using non-public DNS servers that are only reachable		be resolved using non-public DNS servers that are only reachable
	through the IPsec connection. DNS resolution for other domains		through the IPsec connection. DNS resolution for other domains
	remains unchanged. These Configuration Payloads only apply to split		remains unchanged. These Configuration Payloads only apply to split-
	tunnel configurations.		tunnel configurations.
	Status of This Memo		Status of This Memo
	This Internet-Draft is submitted in full conformance with the		This is an Internet Standards Track document.
	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		This document is a product of the Internet Engineering Task Force
	and may be updated, replaced, or obsoleted by other documents at any		(IETF). It represents the consensus of the IETF community. It has
	time. It is inappropriate to use Internet-Drafts as reference		received public review and has been approved for publication by the
	material or to cite them other than as "work in progress."		Internet Engineering Steering Group (IESG). Further information on
			Internet Standards is available in Section 2 of RFC 7841.
	This Internet-Draft will expire on September 12, 2019.		Information about the current status of this document, any errata,
			and how to provide feedback on it may be obtained at
			https://www.rfc-editor.org/info/rfc8598.
	Copyright Notice		Copyright Notice
	Copyright (c) 2019 IETF Trust and the persons identified as the		Copyright (c) 2019 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 . . . . . . . . . . . . . . . . . . . . . . . . 3
	1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3		1.1. Requirements Language . . . . . . . . . . . . . . . . . . 4
	2. Applicability . . . . . . . . . . . . . . . . . . . . . . . . 3		2. Applicability . . . . . . . . . . . . . . . . . . . . . . . . 4
	3. Protocol Exchange . . . . . . . . . . . . . . . . . . . . . . 5		3. Protocol Exchange . . . . . . . . . . . . . . . . . . . . . . 5
	3.1. Configuration Request . . . . . . . . . . . . . . . . . . 5		3.1. Configuration Request . . . . . . . . . . . . . . . . . . 5
	3.2. Configuration Reply . . . . . . . . . . . . . . . . . . . 6		3.2. Configuration Reply . . . . . . . . . . . . . . . . . . . 6
	3.3. Mapping DNS Servers to Domains . . . . . . . . . . . . . 6		3.3. Mapping DNS Servers to Domains . . . . . . . . . . . . . 7
	3.4. Example Exchanges . . . . . . . . . . . . . . . . . . . . 6		3.4. Example Exchanges . . . . . . . . . . . . . . . . . . . . 7
	3.4.1. Simple Case . . . . . . . . . . . . . . . . . . . . . 6		3.4.1. Simple Case . . . . . . . . . . . . . . . . . . . . . 7
	3.4.2. Requesting Domains and DNSSEC trust anchors . . . . . 7		3.4.2. Requesting Domains and DNSSEC Trust Anchors . . . . . 7
	4. Payload Formats . . . . . . . . . . . . . . . . . . . . . . . 8		4. Payload Formats . . . . . . . . . . . . . . . . . . . . . . . 9
	4.1. INTERNAL_DNS_DOMAIN Configuration Attribute Type Request		4.1. INTERNAL_DNS_DOMAIN Configuration Attribute Type Request
	and Reply . . . . . . . . . . . . . . . . . . . . . . . . 8		and Reply . . . . . . . . . . . . . . . . . . . . . . . . 9
	4.2. INTERNAL_DNSSEC_TA Configuration Attribute . . . . . . . 9		4.2. INTERNAL_DNSSEC_TA Configuration Attribute . . . . . . . 9
	5. INTERNAL_DNS_DOMAIN Usage Guidelines . . . . . . . . . . . . 10		5. INTERNAL_DNS_DOMAIN Usage Guidelines . . . . . . . . . . . . 11
	6. INTERNAL_DNSSEC_TA Usage Guidelines . . . . . . . . . . . . . 11		6. INTERNAL_DNSSEC_TA Usage Guidelines . . . . . . . . . . . . . 12
	7. Security Considerations . . . . . . . . . . . . . . . . . . . 12		7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13
	8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14		8. Security Considerations . . . . . . . . . . . . . . . . . . . 14
	9. References . . . . . . . . . . . . . . . . . . . . . . . . . 14		9. References . . . . . . . . . . . . . . . . . . . . . . . . . 15
	9.1. Normative References . . . . . . . . . . . . . . . . . . 14		9.1. Normative References . . . . . . . . . . . . . . . . . . 15
	9.2. Informative References . . . . . . . . . . . . . . . . . 15		9.2. Informative References . . . . . . . . . . . . . . . . . 16
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 15		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 16
	1. Introduction		1. Introduction
	Split tunnel Virtual Private Network ("VPN") configurations only send		Split-tunnel Virtual Private Network (VPN) configurations only send
	packets with a specific destination IP range, usually chosen from		packets with a specific destination IP range, usually chosen from
	[RFC1918], via the VPN. All other traffic is not sent via the VPN.		[RFC1918], via the VPN. All other traffic is not sent via the VPN.
	This allows an enterprise deployment to offer Remote Access VPN		This allows an enterprise deployment to offer remote access VPN
	services without needing to accept and forward all the non-enterprise		services without needing to accept and forward all the non-
	related network traffic generated by their remote users. Resources		enterprise-related network traffic generated by their remote users.
	within the enterprise can be accessed by the user via the VPN, while		Resources within the enterprise can be accessed by the user via the
	all other traffic generated by the user is not send over the VPN.		VPN, while all other traffic generated by the user is not sent over
			the VPN.
	These internal resources tend to only have internal-only DNS names		These internal resources tend to only have internal-only DNS names
	and require the use of special internal-only DNS servers to get		and require the use of special internal-only DNS servers to get
	resolved. Split DNS [RFC2775] is a common configuration that is part		resolved. Split DNS [RFC2775] is commonly configured as part of
	of split tunnel VPN configurations to support configuring Remote		split-tunnel VPN configurations to allow remote access users to use
	Access users to use these special internal-only domain names.		special internal-only domain names.
	The IKEv2 protocol [RFC7296] negotiates configuration parameters		The IKEv2 protocol [RFC7296] negotiates configuration parameters
	using Configuration Payload Attribute Types. This document defines		using Configuration Payload Attribute Types. This document defines
	two Configuration Payload Attribute Types that add support for		two Configuration Payload Attribute Types that add support for
	trusted Split DNS domains.		trusted Split DNS domains.
	The INTERNAL_DNS_DOMAIN attribute type is used to convey that the		The INTERNAL_DNS_DOMAIN attribute type is used to convey that the
	specified DNS domain MUST be resolved using the provided DNS		specified DNS domain MUST be resolved using the provided DNS
	nameserver IP addresses as specified in the INTERNAL_IP4_DNS and		nameserver IP addresses as specified in the INTERNAL_IP4_DNS and
	INTERNAL_IP6_DNS Configuration Payloads, causing these requests to		INTERNAL_IP6_DNS Configuration Payloads, causing these requests to
	use the IPsec connection.		use the IPsec connection.
	The INTERNAL_DNSSEC_TA attribute type is used to convey a DNSSEC		The INTERNAL_DNSSEC_TA attribute type is used to convey a DNSSEC
	trust anchor for such a domain. This is required if the external		trust anchor for such a domain. This is required if the external
	view uses DNSSEC that would prove the internal view does not exist or		view uses DNSSEC, which would prove the internal view does not exist
	would expect a different DNSSEC key on the different versions		or would expect a different DNSSEC key on the different versions
	(internal and external) of the enterprise domain.		(internal and external) of the enterprise domain.
	If an INTERNAL_DNS_DOMAIN is sent by the responder, the responder		If an INTERNAL_DNS_DOMAIN is sent by the responder, the responder
	MUST also include one or more INTERNAL_IP4_DNS or INTERNAL_IP6_DNS		MUST also include one or more INTERNAL_IP4_DNS or INTERNAL_IP6_DNS
	attributes that contain the IPv4 or IPv6 address of the internal DNS		attributes that contain the IPv4 or IPv6 address of the internal DNS
	server.		server.
	For the purposes of this document, DNS resolution servers accessible		For the purposes of this document, DNS resolution servers accessible
	through an IPsec connection will be referred to as "internal DNS		through an IPsec connection will be referred to as "internal DNS
	servers", and other DNS servers will be referred to as "external DNS		servers", and other DNS servers will be referred to as "external DNS
	skipping to change at page 3, line 35 ¶		skipping to change at page 4, line 4 ¶
	server.		server.
	For the purposes of this document, DNS resolution servers accessible		For the purposes of this document, DNS resolution servers accessible
	through an IPsec connection will be referred to as "internal DNS		through an IPsec connection will be referred to as "internal DNS
	servers", and other DNS servers will be referred to as "external DNS		servers", and other DNS servers will be referred to as "external DNS
	servers".		servers".
	Other tunnel-establishment protocols already support the assignment		Other tunnel-establishment protocols already support the assignment
	of Split DNS domains. For example, there are proprietary extensions		of Split DNS domains. For example, there are proprietary extensions
	to IKEv1 that allow a server to assign Split DNS domains to a client.		to IKEv1 that allow a server to assign Split DNS domains to a client.
	However, the IKEv2 standard does not include a method to configure		However, the IKEv2 standard does not include a method to configure
	this option. This document defines a standard way to negotiate this		this option. This document defines a standard way to negotiate this
	option for IKEv2.		option for IKEv2.
	1.1. Requirements Language		1.1. Requirements Language
	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
	14 [RFC2119] [RFC8174] when, and only when, they appear in all		BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all
	captials, as shown here.		capitals, as shown here.
	2. Applicability		2. Applicability
	If the negotiated IPsec connection is not a split tunnel		If the negotiated IPsec connection is not a split-tunnel
	configuration, the INTERNAL_DNS_DOMAIN and INTERNAL_DNSSEC_TA		configuration, the INTERNAL_DNS_DOMAIN and INTERNAL_DNSSEC_TA
	Configuration Payloads MUST be ignored. This prevents generic (non-		Configuration Payloads MUST be ignored. This prevents generic (non-
	enterprise) VPN services from overriding the public DNS hierarchy,		enterprise) VPN services from overriding the public DNS hierarchy,
	which could lead to malicious overrides of DNS and DNSSEC.		which could lead to malicious overrides of DNS and DNSSEC.
	Such configurations SHOULD instead use only the INTERNAL_IP4_DNS and		Such configurations SHOULD instead use only the INTERNAL_IP4_DNS and
	INTERNAL_IP6_DNS Configuration Payloads to ensure all of the user's		INTERNAL_IP6_DNS Configuration Payloads to ensure all of the user's
	DNS traffic is send through the IPsec connection and does not leak		DNS traffic is sent through the IPsec connection and does not leak
	unencrypted onto the local network, as the local network is often		unencrypted information onto the local network, as the local network
	explicitely exempted from IPsec encryption.		is often explicitly exempted from IPsec encryption.
	For split tunnel configurations, an enterprise can require one or		For split-tunnel configurations, an enterprise can require one or
	more DNS domains to be resolved via internal DNS servers. This can		more DNS domains to be resolved via internal DNS servers. This can
	be a special domain, such as "corp.example.com" for an enterprise		be a special domain, such as "corp.example.com" for an enterprise
	that is publicly known to use "example.com". In this case, the		that is publicly known to use "example.com". In this case, the
	remote user needs to be informed what the internal-only domain names		remote user needs to be informed what the internal-only domain names
	are and what the IP addresses of the internal DNS servers are. An		are and what the IP addresses of the internal DNS servers are. An
	enterprise can also run a different version of its public domain on		enterprise can also run a different version of its public domain on
	its internal network. In that case, the VPN client is instructed to		its internal network. In that case, the VPN client is instructed to
	send DNS queries for the enterprise public domain (eg "example.com")		send DNS queries for the enterprise public domain (e.g.,
	to the internal DNS servers. A configuration for this deployment		"example.com") to the internal DNS servers. A configuration for this
	scenario is referred to as a Split DNS configuration.		deployment scenario is referred to as a Split DNS configuration.
	Split DNS configurations are often preferable to sending all DNS		Split DNS configurations are often preferable to sending all DNS
	queries to the enterprise. This allows the remote user to only send		queries to the enterprise. This allows the remote user to only send
	DNS queries for the enterprise to the internal DNS servers. The		DNS queries for the enterprise to the internal DNS servers. The
	enterprise remains unaware of all non-enterprise (DNS) activitiy of		enterprise remains unaware of all non-enterprise (DNS) activity of
	the user. It also allows the enterprise DNS servers to only be		the user. It also allows the enterprise DNS servers to only be
	configured for the enterprise DNS domains which removes the legal and		configured for the enterprise DNS domains, which removes the legal
	technical responsibility of the enterprise to resolve every DNS		and technical responsibility of the enterprise to resolve every DNS
	domain potentially asked for by the remote user.		domain potentially asked for by the remote user.
	A client using these configuration payloads will be able to request		A client using these Configuration Payloads will be able to request
	and receive Split DNS configurations using the INTERNAL_DNS_DOMAIN		and receive Split DNS configurations using the INTERNAL_DNS_DOMAIN
	and INTERNAL_DNSSEC_TA configuration attributes. These attributes		and INTERNAL_DNSSEC_TA configuration attributes. These attributes
	MUST be accompanied by one or more INTERNAL_IP4_DNS or		MUST be accompanied by one or more INTERNAL_IP4_DNS or
	INTERNAL_IP6_DNS configuration attributes. The client device can		INTERNAL_IP6_DNS configuration attributes. The client device can
	then use the internal DNS server(s) for any DNS queries within the		then use the internal DNS server(s) for any DNS queries within the
	assigned domains. DNS queries for other domains SHOULD be sent to		assigned domains. DNS queries for other domains SHOULD be sent to
	the regular DNS service of the client unless it prefers to use the		the regular DNS service of the client unless it prefers to use the
	IPsec tunnel for all its DNS queries. For example, the client could		IPsec tunnel for all its DNS queries. For example, the client could
	trust the IPsec provided DNS servers more than the locally provided		trust the IPsec-provided DNS servers more than the locally provided
	DNS servers especially in the case of connecting to unknown or		DNS servers, especially in the case of connecting to unknown or
	untrusted networks (eg coffee shops or hotel networks). Or the		untrusted networks (e.g., coffee shops or hotel networks). Or the
	client could prefer the IPsec based DNS servers because those provide		client could prefer the IPsec-based DNS servers because they provide
	additional features over the local DNS servers.		additional features compared to the local DNS servers.
	3. Protocol Exchange		3. Protocol Exchange
	In order to negotiate which domains are considered internal to an		In order to negotiate which domains are considered internal to an
	IKEv2 tunnel, initiators indicate support for Split DNS in their		IKEv2 tunnel, initiators indicate support for Split DNS in their
	CFG_REQUEST payloads, and responders assign internal domains (and		CFG_REQUEST payloads, and responders assign internal domains (and
	DNSSEC trust anchors) in their CFG_REPLY payloads. When Split DNS		DNSSEC trust anchors) in their CFG_REPLY payloads. When Split DNS
	has been negotiated, the INTERNAL_IP4_DNS and INTERNAL_IP6_DNS DNS		has been negotiated, the INTERNAL_IP4_DNS and INTERNAL_IP6_DNS DNS
	server configuration attributes will be interpreted as internal DNS		server configuration attributes will be interpreted as internal DNS
	servers that can resolve hostnames within the internal domains.		servers that can resolve hostnames within the internal domains.
	skipping to change at page 5, line 28 ¶		skipping to change at page 5, line 43 ¶
	INTERNAL_DNS_DOMAIN attributes as defined in Section 4 as part of the		INTERNAL_DNS_DOMAIN attributes as defined in Section 4 as part of the
	CFG_REQUEST payload. If an INTERNAL_DNS_DOMAIN attribute is included		CFG_REQUEST payload. If an INTERNAL_DNS_DOMAIN attribute is included
	in the CFG_REQUEST, the initiator MUST also include one or more		in the CFG_REQUEST, the initiator MUST also include one or more
	INTERNAL_IP4_DNS or INTERNAL_IP6_DNS attributes in the CFG_REQUEST.		INTERNAL_IP4_DNS or INTERNAL_IP6_DNS attributes in the CFG_REQUEST.
	The INTERNAL_DNS_DOMAIN attribute sent by the initiator is usually		The INTERNAL_DNS_DOMAIN attribute sent by the initiator is usually
	empty but MAY contain a suggested domain name.		empty but MAY contain a suggested domain name.
	The absence of INTERNAL_DNS_DOMAIN attributes in the CFG_REQUEST		The absence of INTERNAL_DNS_DOMAIN attributes in the CFG_REQUEST
	payload indicates that the initiator does not support or is unwilling		payload indicates that the initiator does not support or is unwilling
	to accept Split DNS configuration.		to accept a Split DNS configuration.
	To indicate support for receiving DNSSEC trust anchors for Split DNS		To indicate support for receiving DNSSEC trust anchors for Split DNS
	domains, an initiator includes one or more INTERNAL_DNSSEC_TA		domains, an initiator includes one or more INTERNAL_DNSSEC_TA
	attributes as defined in Section 4 as part of the CFG_REQUEST		attributes as defined in Section 4 as part of the CFG_REQUEST
	payload. If an INTERNAL_DNSSEC_TA attribute is included in the		payload. If an INTERNAL_DNSSEC_TA attribute is included in the
	CFG_REQUEST, the initiator MUST also include one or more		CFG_REQUEST, the initiator MUST also include one or more
	INTERNAL_DNS_DOMAIN attributes in the CFG_REQUEST. If the initiator		INTERNAL_DNS_DOMAIN attributes in the CFG_REQUEST. If the initiator
	includes an INTERNAL_DNSSEC_TA attribute, but does not include an		includes an INTERNAL_DNSSEC_TA attribute but does not include an
	INTERNAL_DNS_DOMAIN attribute, the responder MAY still respond with		INTERNAL_DNS_DOMAIN attribute, the responder MAY still respond with
	both INTERNAL_DNSSEC_TA and INTERNAL_DNS_DOMAIN attributes.		both INTERNAL_DNSSEC_TA and INTERNAL_DNS_DOMAIN attributes.
	An initiator MAY convey its current DNSSEC trust anchors for the		An initiator MAY convey its current DNSSEC trust anchors for the
	domain specified in the INTERNAL_DNS_DOMAIN attribute. A responder		domain specified in the INTERNAL_DNS_DOMAIN attribute. A responder
	can use this information to determine that it does not need to send a		can use this information to determine that it does not need to send a
	different trust anchor. If the initiator does not wish to convey		different trust anchor. If the initiator does not wish to convey
	this information, it MUST use a length of 0.		this information, it MUST use a length of 0.
	The absence of INTERNAL_DNSSEC_TA attributes in the CFG_REQUEST		The absence of INTERNAL_DNSSEC_TA attributes in the CFG_REQUEST
	payload indicates that the initiator does not support or is unwilling		payload indicates that the initiator does not support or is unwilling
	to accept DNSSEC trust anchor configuration.		to accept the DNSSEC trust anchor configuration.
	3.2. Configuration Reply		3.2. Configuration Reply
	Responders MAY send one or more INTERNAL_DNS_DOMAIN attributes in		Responders MAY send one or more INTERNAL_DNS_DOMAIN attributes in
	their CFG_REPLY payload. If an INTERNAL_DNS_DOMAIN attribute is		their CFG_REPLY payload. If an INTERNAL_DNS_DOMAIN attribute is
	included in the CFG_REPLY, the responder MUST also include one or		included in the CFG_REPLY, the responder MUST also include one or
	both of the INTERNAL_IP4_DNS and INTERNAL_IP6_DNS attributes in the		both of the INTERNAL_IP4_DNS and INTERNAL_IP6_DNS attributes in the
	CFG_REPLY. These DNS server configurations are necessary to define		CFG_REPLY. These DNS server configurations are necessary to define
	which servers can receive queries for hostnames in internal domains.		which servers can receive queries for hostnames in internal domains.
	If the CFG_REQUEST included an INTERNAL_DNS_DOMAIN attribute, but the		If the CFG_REQUEST included an INTERNAL_DNS_DOMAIN attribute but the
	CFG_REPLY does not include an INTERNAL_DNS_DOMAIN attribute, the		CFG_REPLY does not include an INTERNAL_DNS_DOMAIN attribute, the
	initiator MUST behave as if Split DNS configurations are not		initiator MUST behave as if Split DNS configurations are not
	supported by the server, unless the initiator has been configured		supported by the server, unless the initiator has been configured
	with local policy to define a set of Split DNS domains to use by		with local policy to define a set of Split DNS domains to use by
	default.		default.
	Each INTERNAL_DNS_DOMAIN represents a domain that the DNS servers		Each INTERNAL_DNS_DOMAIN represents a domain that the DNS server
	address listed in INTERNAL_IP4_DNS and INTERNAL_IP6_DNS can resolve.		addresses listed in INTERNAL_IP4_DNS and INTERNAL_IP6_DNS can
			resolve.
	If the CFG_REQUEST included INTERNAL_DNS_DOMAIN attributes with non-		If the CFG_REQUEST included INTERNAL_DNS_DOMAIN attributes with non-
	zero lengths, the content MAY be ignored or be interpreted as a		zero lengths, the content MAY be ignored or be interpreted as a
	suggestion by the responder.		suggestion by the responder.
	For each DNS domain specified in an INTERNAL_DNS_DOMAIN attribute,		For each DNS domain specified in an INTERNAL_DNS_DOMAIN attribute,
	one or more INTERNAL_DNSSEC_TA attributes MAY be included by the		one or more INTERNAL_DNSSEC_TA attributes MAY be included by the
	responder. This attribute lists the corresponding internal DNSSEC		responder. This attribute lists the corresponding internal DNSSEC
	trust anchor information of a DS record (see [RFC4034]). The		trust anchor information of a DS record (see [RFC4034]). The
	INTERNAL_DNSSEC_TA attribute MUST immediately follow the		INTERNAL_DNSSEC_TA attribute MUST immediately follow the
	skipping to change at page 6, line 48 ¶		skipping to change at page 7, line 19 ¶
	the INTERNAL_DNS_DOMAIN attributes in a CFG_REPLY payload form a		the INTERNAL_DNS_DOMAIN attributes in a CFG_REPLY payload form a
	single list of Split DNS domains that applies to the entire list of		single list of Split DNS domains that applies to the entire list of
	INTERNAL_IP4_DNS and INTERNAL_IP6_DNS attributes.		INTERNAL_IP4_DNS and INTERNAL_IP6_DNS attributes.
	3.4. Example Exchanges		3.4. Example Exchanges
	3.4.1. Simple Case		3.4.1. Simple Case
	In this example exchange, the initiator requests INTERNAL_IP4_DNS,		In this example exchange, the initiator requests INTERNAL_IP4_DNS,
	INTERNAL_IP6_DNS, and INTERNAL_DNS_DOMAIN attributes in the		INTERNAL_IP6_DNS, and INTERNAL_DNS_DOMAIN attributes in the
	CFG_REQUEST, but does not specify any value for either. This		CFG_REQUEST but does not specify any value for either. This
	indicates that it supports Split DNS, but has no preference for which		indicates that it supports Split DNS but has no preference for which
	DNS requests will be routed through the tunnel.		DNS requests will be routed through the tunnel.
	The responder replies with two DNS server addresses, and two internal		The responder replies with two DNS server addresses and two internal
	domains, "example.com" and "city.other.test".		domains, "example.com" and "city.other.test".
	Any subsequent DNS queries from the initiator for domains such as		Any subsequent DNS queries from the initiator for domains such as
	"www.example.com" SHOULD use 198.51.100.2 or 198.51.100.4 to resolve.		"www.example.com" SHOULD use 198.51.100.2 or 198.51.100.4 to resolve.
	CP(CFG_REQUEST) =		CP(CFG_REQUEST) =
	INTERNAL_IP4_ADDRESS()		INTERNAL_IP4_ADDRESS()
	INTERNAL_IP4_DNS()		INTERNAL_IP4_DNS()
	INTERNAL_IP6_ADDRESS()		INTERNAL_IP6_ADDRESS()
	INTERNAL_IP6_DNS()		INTERNAL_IP6_DNS()
	skipping to change at page 7, line 27 ¶		skipping to change at page 7, line 45 ¶
	CP(CFG_REPLY) =		CP(CFG_REPLY) =
	INTERNAL_IP4_ADDRESS(198.51.100.234)		INTERNAL_IP4_ADDRESS(198.51.100.234)
	INTERNAL_IP4_DNS(198.51.100.2)		INTERNAL_IP4_DNS(198.51.100.2)
	INTERNAL_IP4_DNS(198.51.100.4)		INTERNAL_IP4_DNS(198.51.100.4)
	INTERNAL_IP6_ADDRESS(2001:DB8:0:1:2:3:4:5/64)		INTERNAL_IP6_ADDRESS(2001:DB8:0:1:2:3:4:5/64)
	INTERNAL_IP6_DNS(2001:DB8:99:88:77:66:55:44)		INTERNAL_IP6_DNS(2001:DB8:99:88:77:66:55:44)
	INTERNAL_DNS_DOMAIN(example.com)		INTERNAL_DNS_DOMAIN(example.com)
	INTERNAL_DNS_DOMAIN(city.other.test)		INTERNAL_DNS_DOMAIN(city.other.test)
	3.4.2. Requesting Domains and DNSSEC trust anchors		3.4.2. Requesting Domains and DNSSEC Trust Anchors
	In this example exchange, the initiator requests INTERNAL_IP4_DNS,		In this example exchange, the initiator requests INTERNAL_IP4_DNS,
	INTERNAL_IP6_DNS, INTERNAL_DNS_DOMAIN and INTERNAL_DNSSEC_TA		INTERNAL_IP6_DNS, INTERNAL_DNS_DOMAIN and INTERNAL_DNSSEC_TA
	attributes in the CFG_REQUEST.		attributes in the CFG_REQUEST.
	Any subsequent DNS queries from the initiator for domains such as		Any subsequent DNS queries from the initiator for domains such as
	"www.example.com" or "city.other.test" would be DNSSEC validated		"www.example.com" or "city.other.test" would be DNSSEC validated
	using the DNSSEC trust anchor received in the CFG_REPLY.		using the DNSSEC trust anchor received in the CFG_REPLY.
	In this example, the initiator has no existing DNSSEC trust anchors		In this example, the initiator has no existing DNSSEC trust anchors
	would the requested domain. The "example.com" dommain has DNSSEC		for the requested domain. The "example.com" domain has DNSSEC trust
	trust anchors that are returned, while the "other.test" domain has no		anchors that are returned, while the "other.test" domain has no
	DNSSEC trust anchors.		DNSSEC trust anchors.
	CP(CFG_REQUEST) =		CP(CFG_REQUEST) =
	INTERNAL_IP4_ADDRESS()		INTERNAL_IP4_ADDRESS()
	INTERNAL_IP4_DNS()		INTERNAL_IP4_DNS()
	INTERNAL_IP6_ADDRESS()		INTERNAL_IP6_ADDRESS()
	INTERNAL_IP6_DNS()		INTERNAL_IP6_DNS()
	INTERNAL_DNS_DOMAIN()		INTERNAL_DNS_DOMAIN()
	INTERNAL_DNSSEC_TA()		INTERNAL_DNSSEC_TA()
	skipping to change at page 8, line 26 ¶		skipping to change at page 9, line 7 ¶
	INTERNAL_IP4_DNS(198.51.100.4)		INTERNAL_IP4_DNS(198.51.100.4)
	INTERNAL_IP6_ADDRESS(2001:DB8:0:1:2:3:4:5/64)		INTERNAL_IP6_ADDRESS(2001:DB8:0:1:2:3:4:5/64)
	INTERNAL_IP6_DNS(2001:DB8:99:88:77:66:55:44)		INTERNAL_IP6_DNS(2001:DB8:99:88:77:66:55:44)
	INTERNAL_DNS_DOMAIN(example.com)		INTERNAL_DNS_DOMAIN(example.com)
	INTERNAL_DNSSEC_TA(43547,8,1,B6225AB2CC613E0DCA7962BDC2342EA4...)		INTERNAL_DNSSEC_TA(43547,8,1,B6225AB2CC613E0DCA7962BDC2342EA4...)
	INTERNAL_DNSSEC_TA(31406,8,2,F78CF3344F72137235098ECBBD08947C...)		INTERNAL_DNSSEC_TA(31406,8,2,F78CF3344F72137235098ECBBD08947C...)
	INTERNAL_DNS_DOMAIN(city.other.test)		INTERNAL_DNS_DOMAIN(city.other.test)
	4. Payload Formats		4. Payload Formats
	All multi-octet fields representing integers are laid out in big		All multi-octet fields representing integers are laid out in big-
	endian order (also known as "most significant byte first", or		endian order (also known as "most significant byte first" or "network
	"network byte order").		byte order").
	4.1. INTERNAL_DNS_DOMAIN Configuration Attribute Type Request and Reply		4.1. INTERNAL_DNS_DOMAIN Configuration Attribute Type Request and Reply
	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 |
	+-+-----------------------------+-------------------------------+		+-+-----------------------------+-------------------------------+
	| |		| |
	~ Domain Name in DNS presentation format ~		~ Domain Name in DNS presentation format ~
	| |		| |
	+---------------------------------------------------------------+		+---------------------------------------------------------------+
	o Reserved (1 bit) - Defined in IKEv2 RFC [RFC7296].		o Reserved (1 bit) - Defined in IKEv2 RFC [RFC7296].
	o Attribute Type (15 bits) set to value 25 for INTERNAL_DNS_DOMAIN.		o Attribute Type (15 bits) - set to value 25 for
			INTERNAL_DNS_DOMAIN.
	o Length (2 octets) - Length of domain name.		o Length (2 octets) - Length of domain name.
	o Domain Name (0 or more octets) - A Fully Qualified Domain Name		o Domain Name (0 or more octets) - A Fully Qualified Domain Name
	used for Split DNS rules, such as "example.com", in DNS		used for Split DNS rules, such as "example.com", in DNS
	presentation format and using IDNA A-label [RFC5890] for		presentation format and using an Internationalized Domain Names
	Internationalized Domain Names. Implementors need to be careful		for Applications (IDNA) A-label [RFC5890]. Implementors need to
	that this value is not null-terminated.		be careful that this value is not null terminated.
	4.2. INTERNAL_DNSSEC_TA Configuration Attribute		4.2. INTERNAL_DNSSEC_TA Configuration Attribute
	An INTERNAL_DNSSEC_TA Configuration Attribute can either be empty, or		An INTERNAL_DNSSEC_TA Configuration Attribute can either be empty, or
	it can contain one Trust Anchor by containing a non-zero Length with		it can contain one trust anchor by containing a non-zero Length with
	a DNSKEY Key Tag, DNSKEY Algorithm, Digest Type and Digest Data		a DNSKEY Key Tag, DNSKEY Algorithm, Digest Type and Digest Data
	fields.		fields.
	An empty INTERNAL_DNSSEC_TA CFG attribute:		An empty INTERNAL_DNSSEC_TA CFG attribute:
	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 (set to 0) |		|R| Attribute Type | Length (set to 0) |
	+-+-----------------------------+-------------------------------+		+-+-----------------------------+-------------------------------+
	o Reserved (1 bit) - Defined in IKEv2 RFC [RFC7296].		o Reserved (1 bit) - Defined in IKEv2 RFC [RFC7296].
	o Attribute Type (15 bits) set to value 26 for INTERNAL_DNSSEC_TA.		o Attribute Type (15 bits) - set to value 26 for INTERNAL_DNSSEC_TA.
	o Length (2 octets) - Set to 0 for an empty attribute.		o Length (2 octets) - Set to 0 for an empty attribute.
	A non-empty INTERNAL_DNSSEC_TA CFG attribute:		A non-empty INTERNAL_DNSSEC_TA CFG attribute:
	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 |
	+-+-----------------------------+---------------+---------------+		+-+-----------------------------+---------------+---------------+
	| DNSKEY Key Tag | DNSKEY Alg | Digest Type |		| DNSKEY Key Tag | DNSKEY Alg | Digest Type |
	+-------------------------------+---------------+---------------+		+-------------------------------+---------------+---------------+
	| |		| |
	~ Digest Data ~		~ Digest Data ~
	| |		| |
	+---------------------------------------------------------------+		+---------------------------------------------------------------+
	o Reserved (1 bit) - Defined in IKEv2 RFC [RFC7296].		o Reserved (1 bit) - Defined in IKEv2 RFC [RFC7296].
	o Attribute Type (15 bits) set to value 26 for INTERNAL_DNSSEC_TA.		o Attribute Type (15 bits) - set to value 26 for INTERNAL_DNSSEC_TA.
	o Length (2 octets) - Length of DNSSEC Trust Anchor data (4 octets		o Length (2 octets) - Length of DNSSEC trust anchor data (4 octets
	plus the length of the Digest Data).		plus the length of the Digest Data).
	o DNSKEY Key Tag value (2 octets) - Delegation Signer (DS) Key Tag		o DNSKEY Key Tag (2 octets) - Delegation Signer (DS) Key Tag as
	as specified in [RFC4034] Section 5.1.		specified in Section 5.1 of [RFC4034].
	o DNSKEY Algorithm (1 octet) - DNSKEY algorithm value from the IANA		o DNSKEY Algorithm (1 octet) - DNSKEY algorithm value from the IANA
	DNS Security Algorithm Numbers Registry.		DNS Security Algorithm Numbers Registry.
	o Digest Type (1 octet) - DS algorithm value from the IANA		o Digest Type (1 octet) - DS algorithm value from the IANA
	Delegation Signer (DS) Resource Record (RR) Type Digest Algorithms		Delegation Signer (DS) Resource Record (RR) Type Digest Algorithms
	Registry.		Registry.
	o Digest Data (1 or more octets) - The DNSKEY digest as specified in		o Digest Data (1 or more octets) - The DNSKEY digest as specified in
	[RFC4034] Section 5.1 in presentation format.		Section 5.1 of [RFC4034] in presentation format.
	Each INTERNAL_DNSSEC_TA attribute in the CFG_REPLY payload MUST		Each INTERNAL_DNSSEC_TA attribute in the CFG_REPLY payload MUST
	immediately follow a corresponding INTERNAL_DNS_DOMAIN attribute. As		immediately follow a corresponding INTERNAL_DNS_DOMAIN attribute. As
	the INTERNAL_DNSSEC_TA format itself does not contain the domain		the INTERNAL_DNSSEC_TA format itself does not contain the domain
	name, it relies on the preceding INTERNAL_DNS_DOMAIN to provide the		name, it relies on the preceding INTERNAL_DNS_DOMAIN to provide the
	domain for which it specifies the trust anchor. Any		domain for which it specifies the trust anchor. Any
	INTERNAL_DNSSEC_TA attribute that is not immediately preceded by an		INTERNAL_DNSSEC_TA attribute that is not immediately preceded by an
	INTERNAL_DNS_DOMAIN or another INTERNAL_DNSSEC_TA attribute applying		INTERNAL_DNS_DOMAIN or another INTERNAL_DNSSEC_TA attribute applying
	to the same domain name MUST be ignored.		to the same domain name MUST be ignored.
	skipping to change at page 10, line 37 ¶		skipping to change at page 11, line 27 ¶
	the client MAY use the provided INTERNAL_IP4_DNS or INTERNAL_IP6_DNS		the client MAY use the provided INTERNAL_IP4_DNS or INTERNAL_IP6_DNS
	servers as the default DNS server(s) for all queries.		servers as the default DNS server(s) for all queries.
	If a client is configured by local policy to only accept a limited		If a client is configured by local policy to only accept a limited
	set of INTERNAL_DNS_DOMAIN values, the client MUST ignore any other		set of INTERNAL_DNS_DOMAIN values, the client MUST ignore any other
	INTERNAL_DNS_DOMAIN values.		INTERNAL_DNS_DOMAIN values.
	For each INTERNAL_DNS_DOMAIN entry in a CFG_REPLY payload that is not		For each INTERNAL_DNS_DOMAIN entry in a CFG_REPLY payload that is not
	prohibited by local policy, the client MUST use the provided		prohibited by local policy, the client MUST use the provided
	INTERNAL_IP4_DNS or INTERNAL_IP6_DNS DNS servers as the only		INTERNAL_IP4_DNS or INTERNAL_IP6_DNS DNS servers as the only
	resolvers for the listed domains and its sub-domains and it MUST NOT		resolvers for the listed domains and its subdomains, and it MUST NOT
	attempt to resolve the provided DNS domains using its external DNS		attempt to resolve the provided DNS domains using its external DNS
	servers. Other domain names SHOULD be resolved using some other		servers. Other domain names SHOULD be resolved using some other
	external DNS resolver(s), configured independently from IKE. Queries		external DNS resolver(s) that are configured independently from IKE.
	for these other domains MAY be sent to the internal DNS resolver(s)		Queries for these other domains MAY be sent to the internal DNS
	listed in that CFG_REPLY message, but have no guarantee of being		resolver(s) listed in that CFG_REPLY message, but they have no
	answered. For example, if the INTERNAL_DNS_DOMAIN attribute		guarantee of being answered. For example, if the INTERNAL_DNS_DOMAIN
	specifies "example.test", then "example.test", "www.example.test" and		attribute specifies "example.test", then "example.test",
	"mail.eng.example.test" MUST be resolved using the internal DNS		"www.example.test", and "mail.eng.example.test" MUST be resolved
	resolver(s), but "otherexample.test" and "ple.test" MUST NOT be		using the internal DNS resolver(s), but "otherexample.test" and
	resolved using the internal resolver and MUST use the system's		"ple.test" MUST NOT be resolved using the internal resolver and MUST
	external DNS resolver(s).		use the system's external DNS resolver(s).
	The initiator SHOULD allow the DNS domains listed in the		The initiator SHOULD allow the DNS domains listed in the
	INTERNAL_DNS_DOMAIN attributes to resolve to special IP address		INTERNAL_DNS_DOMAIN attributes to resolve to special IP address
	ranges, such as those of [RFC1918], even if the initiator host is		ranges, such as those of [RFC1918], even if the initiator host is
	otherwise configured to block DNS answer containing these special IP		otherwise configured to block a DNS answer containing these special
	address ranges.		IP address ranges.
	When an IKE SA is terminated, the DNS forwarding MUST be		When an IKE Security Association (SA) is terminated, the DNS
	unconfigured. This includes deleting the DNS forwarding rules;		forwarding MUST be unconfigured. This includes deleting the DNS
	flushing all cached data for DNS domains provided by the		forwarding rules; flushing all cached data for DNS domains provided
	INTERNAL_DNS_DOMAIN attribute, including negative cache entries;		by the INTERNAL_DNS_DOMAIN attribute, including negative cache
	removing any obtained DNSSEC trust anchors from the list of trust		entries; removing any obtained DNSSEC trust anchors from the list of
	anchors; and clearing the outstanding DNS request queue.		trust anchors; and clearing the outstanding DNS request queue.
	INTERNAL_DNS_DOMAIN attributes SHOULD only be used on split tunnel		INTERNAL_DNS_DOMAIN attributes SHOULD only be used on split-tunnel
	configurations where only a subset of traffic is routed into a		configurations where only a subset of traffic is routed into a
	private remote network using the IPsec connection. If all traffic is		private remote network using the IPsec connection. If all traffic is
	routed over the IPsec connection, the existing global		routed over the IPsec connection, the existing global
	INTERNAL_IP4_DNS and INTERNAL_IP6_DNS can be used without creating		INTERNAL_IP4_DNS and INTERNAL_IP6_DNS can be used without creating
	specific DNS or DNSSEC exemptions.		specific DNS or DNSSEC exemptions.
	6. INTERNAL_DNSSEC_TA Usage Guidelines		6. INTERNAL_DNSSEC_TA Usage Guidelines
	DNS records can be used to publish specific records containing trust		DNS records can be used to publish specific records containing trust
	anchors for applications. The most common record type is the TLSA		anchors for applications. The most common record type is the TLSA
	record specified in [RFC6698]. This DNS record type publishes which		record specified in [RFC6698]. This DNS record type publishes which
	Certificate Authority (CA) certificate or End Entity (EE) certificate		Certification Authority (CA) certificate or End Entity (EE)
	to expect for a certain host name. These records are protected by		certificate to expect for a certain host name. These records are
	DNSSEC and thus are trustable by the application. Whether to trust		protected by DNSSEC and thus are trustable by the application.
	TLSA records instead of the traditional WebPKI depends on the local		Whether to trust TLSA records instead of the traditional Web PKI
	policy of the client. By accepting an INTERNAL_DNSSEC_TA trust		depends on the local policy of the client. By accepting an
	anchor via IKE from the remote IKE server, the IPsec client might be		INTERNAL_DNSSEC_TA trust anchor via IKE from the remote IKE server,
	allowing the remote IKE server to override the trusted certificates		the IPsec client might be allowing the remote IKE server to override
	for TLS. Similar override concerns apply to other public key or		the trusted certificates for TLS. Similar override concerns apply to
	fingerprint-based DNS records, such as OPENPGPKEY, SMIMEA or IPSECKEY		other public key or fingerprint-based DNS records, such as
	records.		OPENPGPKEY, SMIMEA, or IPSECKEY records.
	Thus, installing an INTERNAL_DNSSEC_TA trust anchor can be seen as		Thus, installing an INTERNAL_DNSSEC_TA trust anchor can be seen as
	the equivalent of installing an Enterprise CA certificate. It allows		the equivalent of installing an Enterprise CA certificate. It allows
	the remote IKE/IPsec server to modify DNS answers including DNSSEC		the remote IKE/IPsec server to modify DNS answers, including DNSSEC
	cryptographic signatures by overriding existing DNS information with		cryptographic signatures, by overriding existing DNS information with
	trust anchor conveyed via IKE and (temporarilly) installed on the IKE		a trust anchor conveyed via IKE and (temporarily) installed on the
	client. Of specific concern is the overriding of [RFC6698] based		IKE client. Of specific concern is the overriding of TLSA records
	TLSA records, which represent a confirmation or override of an		based on [RFC6698], which represents a confirmation or override of an
	existing WebPKI TLS certificate. Other DNS record types that convey		existing Web PKI TLS certificate. Other DNS record types that convey
	cryptographic materials (public keys or fingerprints) are OPENPGPKEY,		cryptographic materials (public keys or fingerprints) are OPENPGPKEY,
	SMIMEA, SSHP and IPSECKEY records.		SMIMEA, SSHP, and IPSECKEY records.
	IKE clients willing to accept INTERNAL_DNSSEC_TA attributes MUST use		IKE clients willing to accept INTERNAL_DNSSEC_TA attributes MUST use
	a whitelist of one or more domains that can be updated out of band.		a whitelist of one or more domains that can be updated out of band.
	IKE clients with an empty whitelist MUST NOT use any		IKE clients with an empty whitelist MUST NOT use any
	INTERNAL_DNSSEC_TA attributes received over IKE. Such clients MAY		INTERNAL_DNSSEC_TA attributes received over IKE. Such clients MAY
	interpret receiving an INTERNAL_DNSSEC_TA attribute for a non-		interpret receiving an INTERNAL_DNSSEC_TA attribute for a non-
	whitelisted domain as an indication that their local configuration		whitelisted domain as an indication that their local configuration
	may need to be updated out of band.		may need to be updated out of band.
	IKE clients should take care to only whitelist domains that apply to		IKE clients should take care to only whitelist domains that apply to
	internal or managed domains, rather than to generic Internet traffic.		internal or managed domains rather than to generic Internet traffic.
	The DNS root zone (".") MUST be ignored if it appears in a whitelist.		The DNS root zone (".") MUST be ignored if it appears in a whitelist.
	Other generic or public domains, such as top-level domains (TLDs),		Other generic or public domains, such as Top-Level Domains (TLDs),
	similarly MUST be ignored if these appear in a whitelist unless the		similarly MUST be ignored if they appear in a whitelist unless the
	entity actually is the operator of the TLD. To determine this, an		entity actually is the operator of the TLD. To determine this, an
	implementation MAY interactively ask the user when a VPN profile is		implementation MAY interactively ask the user when a VPN profile is
	installed or activated to confirm this. Alternatively, it MAY		installed or activated to confirm this. Alternatively, it MAY
	provide a special override keyword in its provisioning configuration		provide a special override keyword in its provisioning configuration
	to ensure non-interactive agreement can be achieved only by the party		to ensure non-interactive agreement can be achieved only by the party
	provisioning the VPN client, who presumbly is a trusted entity by the		provisioning the VPN client, who presumably is a trusted entity by
	end-user. Similarly, an entity might be using a special domain name,		the end user. Similarly, an entity might be using a special domain
	such as ".internal", for its internal-only view and might wish to		name, such as ".internal", for its internal-only view and might wish
	force its provisioning system to accept such a domain in a Split DNS		to force its provisioning system to accept such a domain in a Split
	configuration.		DNS configuration.
	Any updates to this whitelist of domain names MUST happen via		Any updates to this whitelist of domain names MUST happen via
	explicit human interaction or by a trusted automated provision system		explicit human interaction or by a trusted automated provision system
	to prevent malicious invisible installation of trust anchors in case		to prevent malicious invisible installation of trust anchors in case
	of aIKE server compromise.		of an IKE server compromise.
	IKE clients SHOULD accept any INTERNAL_DNSSEC_TA updates for		IKE clients SHOULD accept any INTERNAL_DNSSEC_TA updates for
	subdomain names of the whitelisted domain names. For example, if		subdomain names of the whitelisted domain names. For example, if
	"example.net" is whitelisted, then INTERNAL_DNSSEC_TA received for		"example.net" is whitelisted, then INTERNAL_DNSSEC_TA received for
	"antartica.example.net" SHOULD be accepted.		"antartica.example.net" SHOULD be accepted.
	IKE clients MUST ignore any received INTERNAL_DNSSEC_TA attributes		IKE clients MUST ignore any received INTERNAL_DNSSEC_TA attributes
	for a FDQN for which it did not receive and accept an		for a Fully Qualified Domain Name (FQDN) for which it did not receive
	INTERNAL_DNS_DOMAIN Configuration Payload.		and accept an INTERNAL_DNS_DOMAIN Configuration Payload.
	In most deployment scenarios, the IKE client has an expectation that		In most deployment scenarios, the IKE client has an expectation that
	it is connecting, using a split-network setup, to a specific		it is connecting to a specific organization or enterprise using a
	organisation or enterprise. A recommended policy would be to only		split-network setup. A recommended policy would be to only accept
	accept INTERNAL_DNSSEC_TA directives from that organization's DNS		INTERNAL_DNSSEC_TA directives from that organization's DNS names.
	names. However, this might not be possible in all deployment		However, this might not be possible in all deployment scenarios, such
	scenarios, such as one where the IKE server is handing out a number		as one where the IKE server is handing out a number of domains that
	of domains that are not within one parent domain.		are not within one parent domain.
	7. Security Considerations		7. IANA Considerations
			This document defines two new IKEv2 Configuration Payload Attribute
			Types, which are allocated from the "IKEv2 Configuration Payload
			Attribute Types" namespace.
			Multi-
			Value Attribute Type Valued Length Reference
			------ ------------------- ------ ---------- ---------------
			25 INTERNAL_DNS_DOMAIN YES 0 or more RFC 8598
			26 INTERNAL_DNSSEC_TA YES 0 or more RFC 8598
			Figure 1
			8. Security Considerations
	As stated in Section 2, if the negotiated IPsec connection is not a		As stated in Section 2, if the negotiated IPsec connection is not a
	split tunnel configuration, the INTERNAL_DNS_DOMAIN and		split-tunnel configuration, the INTERNAL_DNS_DOMAIN and
	INTERNAL_DNSSEC_TA Configuration Payloads MUST be ignored.		INTERNAL_DNSSEC_TA Configuration Payloads MUST be ignored.
	Otherwise, generic VPN service providers could maliciously override		Otherwise, generic VPN service providers could maliciously override
	DNSSEC based trust anchors of public DNS domains.		DNSSEC-based trust anchors of public DNS domains.
	An initiator MUST only accept INTERNAL_DNSSEC_TAs for which it has a		An initiator MUST only accept INTERNAL_DNSSEC_TAs for which it has a
	whitelist, since this mechanism allows the credential used to		whitelist, since this mechanism allows the credential used to
	authenticate an IKEv2 association to be leveraged into authenticating		authenticate an IKEv2 association to be leveraged into authenticating
	credentials for other connections. Initiators should ensure that		credentials for other connections. Initiators should ensure that
	they have sufficient trust in the responder when using this		they have sufficient trust in the responder when using this
	mechanism. An initiator MAY treat a received INTERNAL_DNSSEC_TA for		mechanism. An initiator MAY treat a received INTERNAL_DNSSEC_TA for
	an non-whitelisted domain as a signal to update the whitelist via a		a non-whitelisted domain as a signal to update the whitelist via a
	non-IKE provisioning mechanism. See Section 6 for additional		non-IKE provisioning mechanism. See Section 6 for additional
	security considerations for DNSSEC trust anchors.		security considerations for DNSSEC trust anchors.
	The use of Split DNS configurations assigned by an IKEv2 responder is		The use of Split DNS configurations assigned by an IKEv2 responder is
	predicated on the trust established during IKE SA authentication.		predicated on the trust established during IKE SA authentication.
	However, if IKEv2 is being negotiated with an anonymous or unknown		However, if IKEv2 is being negotiated with an anonymous or unknown
	endpoint (such as for Opportunistic Security [RFC7435]), the		endpoint (such as for Opportunistic Security [RFC7435]), the
	initiator MUST ignore Split DNS configurations assigned by the		initiator MUST ignore Split DNS configurations assigned by the
	responder.		responder.
	If a host connected to an authenticated IKE peer is connecting to		If a host connected to an authenticated IKE peer is connecting to
	another IKE peer that attempts to claim the same domain via the		another IKE peer that attempts to claim the same domain via the
	INTERNAL_DNS_DOMAIN attribute, the IKE connection SHOULD only process		INTERNAL_DNS_DOMAIN attribute, the IKE connection SHOULD only process
	the DNS information if the two connections are part of the same		the DNS information if the two connections are part of the same
	logical entity. Otherwise, the client SHOULD refuse the DNS		logical entity. Otherwise, the client SHOULD refuse the DNS
	information and potentially warn the end-user. For example, if a VPN		information and potentially warn the end user. For example, if a VPN
	profile for "Example Corporation" is installed that provides two		profile for "Example Corporation" is installed that provides two
	IPsec connections, one covering 192.168.100.0/24 and one covering		IPsec connections, one covering 192.168.100.0/24 and one covering
	10.13.14.0/24 it could be that both connections negotiate the same		10.13.14.0/24, it could be that both connections negotiate the same
	INTERNAL_DNS_DOMAIN and INTERNAL_DNSSEC_TA values. Since these are		INTERNAL_DNS_DOMAIN and INTERNAL_DNSSEC_TA values. Since these are
	part of the same remote organisation (or provisioning profile), the		part of the same remote organization (or provisioning profile), the
	Configuration Payloads can be used. However, if a user installs two		Configuration Payloads can be used. However, if a user installs two
	VPN profiles from two different unrelated independent entities, both		VPN profiles from two different unrelated independent entities, both
	of these could be configured to use the same domain, for example		could be configured to use the same domain -- for example,
	".internal". These two connections MUST NOT be allowed to be active		".internal". These two connections MUST NOT be allowed to be active
	at the same time.		at the same time.
	If the initiator is using DNSSEC validation for a domain in its		If the initiator is using DNSSEC validation for a domain in its
	public DNS view, and it requests and receives an INTERNAL_DNS_DOMAIN		public DNS view and it requests and receives an INTERNAL_DNS_DOMAIN
	attribute without an INTERNAL_DNSSEC_TA, it will need to reconfigure		attribute without an INTERNAL_DNSSEC_TA, it will need to reconfigure
	its DNS resolver to allow for an insecure delegation. It SHOULD NOT		its DNS resolver to allow for an insecure delegation. It SHOULD NOT
	accept insecure delegations for domains that are DNSSEC signed in the		accept insecure delegations for domains that are DNSSEC signed in the
	public DNS view, for which it has not explicitly requested such		public DNS view for which it has not explicitly requested such
	deletation by specifying the domain specifically using a		delegation, i.e., for which it has not used an INTERNAL_DNS_DOMAIN
	INTERNAL_DNS_DOMAIN request.		request to specify the domain.
	Deployments that configure INTERNAL_DNS_DOMAIN domains should pay		Deployments that configure INTERNAL_DNS_DOMAIN domains should pay
	close attention to their use of indirect reference RRtypes in their		close attention to their use of indirect reference RRtypes in their
	internal-only domain names. Examples of such RRtypes are NS, CNAME,		internal-only domain names. Examples of such RRtypes are NS, CNAME,
	DNAME, MX or SRV records. For example, if the MX record for		DNAME, MX, or SRV records. For example, if the MX record for
	"internal.example.com" points to "mx.internal.example.net", then both		"internal.example.com" points to "mx.internal.example.net", then both
	"internal.example.com" and "internal.example.net" should be sent		"internal.example.com" and "internal.example.net" should be sent
	using an INTERNAL_DNS_DOMAIN Configuration Payload.		using an INTERNAL_DNS_DOMAIN Configuration Payload.
	IKE clients MAY want to require whitelisted domains for Top Level		IKE clients MAY want to require whitelisted domains for Top-Level
	Domains (TLDs) and Second Level Domains (SLDs) to further prevent		Domains (TLDs) and Second-Level Domains (SLDs) to further prevent
	malicious DNS redirections for well known domains. This prevents		malicious DNS redirections for well-known domains. This prevents
	users from unknowingly giving DNS queries to third parties. This is		users from unknowingly giving DNS queries to third parties. This is
	even more important if those well known domains are not deploying		even more important if those well-known domains are not deploying
	DNSSEC, as the VPN service provider could then even modify the DNS		DNSSEC, as the VPN service provider could then even modify the DNS
	answers without detection.		answers without detection.
	The content of INTERNAL_DNS_DOMAIN and INTERNAL_DNSSEC_TA may be		The content of INTERNAL_DNS_DOMAIN and INTERNAL_DNSSEC_TA may be
	passed to another (DNS) program for processing. As with any network		passed to another (DNS) program for processing. As with any network
	input, the content SHOULD be considered untrusted and handled		input, the content SHOULD be considered untrusted and handled
	accordingly.		accordingly.
	8. IANA Considerations
	This document defines two new IKEv2 Configuration Payload Attribute
	Types, which are allocated from the "IKEv2 Configuration Payload
	Attribute Types" namespace.
	Multi-
	Value Attribute Type Valued Length Reference
	------ ------------------- ------ ---------- ---------------
	25 INTERNAL_DNS_DOMAIN YES 0 or more [this document]
	26 INTERNAL_DNSSEC_TA YES 0 or more [this document]
	Figure 1
	9. References		9. References
	9.1. Normative References		9.1. Normative References
	[RFC1918] Rekhter, Y., Moskowitz, B., Karrenberg, D., de Groot, G.,		[RFC1918] Rekhter, Y., Moskowitz, B., Karrenberg, D., de Groot, G.,
	and E. Lear, "Address Allocation for Private Internets",		and E. Lear, "Address Allocation for Private Internets",
	BCP 5, RFC 1918, DOI 10.17487/RFC1918, February 1996,		BCP 5, RFC 1918, DOI 10.17487/RFC1918, February 1996,
	<https://www.rfc-editor.org/info/rfc1918>.		<https://www.rfc-editor.org/info/rfc1918>.
	[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate		[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
	skipping to change at page 15, line 45 ¶		skipping to change at page 16, line 35 ¶
	[RFC7435] Dukhovni, V., "Opportunistic Security: Some Protection		[RFC7435] Dukhovni, V., "Opportunistic Security: Some Protection
	Most of the Time", RFC 7435, DOI 10.17487/RFC7435,		Most of the Time", RFC 7435, DOI 10.17487/RFC7435,
	December 2014, <https://www.rfc-editor.org/info/rfc7435>.		December 2014, <https://www.rfc-editor.org/info/rfc7435>.
	Authors' Addresses		Authors' Addresses
	Tommy Pauly		Tommy Pauly
	Apple Inc.		Apple Inc.
	One Apple Park Way		One Apple Park Way
	Cupertino, California 95014		Cupertino, California 95014
	US		United States of America
	Email: tpauly@apple.com		Email: tpauly@apple.com
	Paul Wouters		Paul Wouters
	Red Hat		Red Hat
	Email: pwouters@redhat.com		Email: pwouters@redhat.com
End of changes. 77 change blocks.
	187 lines changed or deleted		188 lines changed or added
This html diff was produced by rfcdiff 1.47. The latest version is available from http://tools.ietf.org/tools/rfcdiff/