< draft-pauly-ipsecme-split-dns-01.txt		draft-pauly-ipsecme-split-dns-02.txt >
	Network T. Pauly		Network T. Pauly
	Internet-Draft Apple Inc.		Internet-Draft Apple Inc.
	Intended status: Standards Track P. Wouters		Intended status: Standards Track P. Wouters
	Expires: November 28, 2016 Red Hat		Expires: March 25, 2017 Red Hat
	May 27, 2016		September 21, 2016
	Split-DNS Configuration for IKEv2		Split DNS Configuration for IKEv2
	draft-pauly-ipsecme-split-dns-01		draft-pauly-ipsecme-split-dns-02
	Abstract		Abstract
	This document defines two Configuration Payload Attribute Types for		This document defines two Configuration Payload Attribute Types for
	the IKEv2 protocol that define sets of private DNS domains which		the IKEv2 protocol that add support for private DNS domains. These
	should be resolved by DNS servers reachable through an IPsec		domains should be resolved using DNS servers reachable through an
	connection, while leaving all other DNS resolution unchanged. The		IPsec connection, while leaving all other DNS resolution unchanged.
	options define the set of DNS domains, DNS nameserver IP addresses		This approach of resolving a subset of domains using non-public DNS
	and DNSSEC trust anchors to use for these DNS domains. This approach		servers is referred to as "Split DNS".
	of resolving a subset of domains using an IPSec connection is
	referred to as "split-DNS". The information obtained via these
	attribute types can be used to reconfigure the local DNS resolution
	to use DNS forwarding for specific private domains.
	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 http://datatracker.ietf.org/drafts/current/.		Drafts is at http://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 November 28, 2016.		This Internet-Draft will expire on March 25, 2017.
	Copyright Notice		Copyright Notice
	Copyright (c) 2016 IETF Trust and the persons identified as the		Copyright (c) 2016 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
	(http://trustee.ietf.org/license-info) in effect on the date of		(http://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 13 ¶
	include Simplified BSD License text as described in Section 4.e of		include Simplified BSD License text as described in Section 4.e of
	the Trust Legal Provisions and are provided without warranty as		the Trust Legal Provisions and are provided without warranty as
	described in the Simplified BSD License.		described in the Simplified BSD License.
	Table of Contents		Table of Contents
	1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2		1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
	1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3		1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3
	2. Background . . . . . . . . . . . . . . . . . . . . . . . . . 3		2. Background . . . . . . . . . . . . . . . . . . . . . . . . . 3
	3. Protocol Exchange . . . . . . . . . . . . . . . . . . . . . . 3		3. Protocol Exchange . . . . . . . . . . . . . . . . . . . . . . 3
	3.1. Configuration Request . . . . . . . . . . . . . . . . . . 3		3.1. Configuration Request . . . . . . . . . . . . . . . . . . 4
	3.2. Configuration Reply . . . . . . . . . . . . . . . . . . . 4		3.2. Configuration Reply . . . . . . . . . . . . . . . . . . . 4
	3.3. Mapping DNS Servers to Domains . . . . . . . . . . . . . 4		3.3. Mapping DNS Servers to Domains . . . . . . . . . . . . . 5
	3.4. Example Exchanges . . . . . . . . . . . . . . . . . . . . 4		3.4. Example Exchanges . . . . . . . . . . . . . . . . . . . . 5
	3.4.1. Simple Case . . . . . . . . . . . . . . . . . . . . . 4		3.4.1. Simple Case . . . . . . . . . . . . . . . . . . . . . 5
	3.4.2. Requesting Limited Domains . . . . . . . . . . . . . 5		3.4.2. Requesting Limited Domains . . . . . . . . . . . . . 6
	4. Payload Formats . . . . . . . . . . . . . . . . . . . . . . . 6		3.4.3. Requesting Domains and DNSSEC trust anchors . . . . . 6
	4.1. INTERNAL_DNS_DOMAIN Configuration Attribute Type . . . . 6		4. Payload Formats . . . . . . . . . . . . . . . . . . . . . . . 7
	4.2. INTERNAL_DNSSEC_TA Configuration Attribute . . . . . . . 6		4.1. INTERNAL_DNS_DOMAIN Configuration Attribute Type . . . . 7
	5. Split-DNS Usage Guidelines . . . . . . . . . . . . . . . . . 7		4.2. INTERNAL_DNSSEC_TA Configuration Attribute . . . . . . . 8
	6. Security Considerations . . . . . . . . . . . . . . . . . . . 8		5. Split DNS Usage Guidelines . . . . . . . . . . . . . . . . . 8
	7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9		6. Security Considerations . . . . . . . . . . . . . . . . . . . 9
	8. References . . . . . . . . . . . . . . . . . . . . . . . . . 9		7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10
	8.1. Normative References . . . . . . . . . . . . . . . . . . 9		8. References . . . . . . . . . . . . . . . . . . . . . . . . . 10
	8.2. Informative References . . . . . . . . . . . . . . . . . 10		8.1. Normative References . . . . . . . . . . . . . . . . . . 11
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 10		8.2. Informative References . . . . . . . . . . . . . . . . . 11
			Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 11
	1. Introduction		1. Introduction
			Split DNS is a common configuration for secure tunnels, such as
			Virtual Private Networks in which host machines private to an
			organization can only be resolved using internal DNS resolvers
			[RFC2775]. In such configurations, it is often desirable to only
			resolve hosts within a set of private domains using the tunnel, while
			letting resolutions for public hosts be handled by a device's default
			DNS configuration.
	The Internet Key Exchange protocol version 2 [RFC7296] negotiates		The Internet Key Exchange protocol version 2 [RFC7296] negotiates
	configuration parameters using Configuration Payload Attribute Types.		configuration parameters using Configuration Payload Attribute Types.
	This document defines two Configuration Payload Attribute Types that		This document defines two Configuration Payload Attribute Types that
	add support for trusted split-DNS domains. The INTERNAL_DNS_DOMAIN		add support for trusted Split DNS domains.
	attribute type is used to convey one or more DNS domains that should
	be resolved only using the provided DNS nameserver IP addresses,		The INTERNAL_DNS_DOMAIN attribute type is used to convey one or more
	causing these requests to use the IPSec connection. The		DNS domains that should be resolved only using the provided DNS
	INTERNAL_DNSSEC_TA attribute type is used to convey DNSSEC trust		nameserver IP addresses, causing these requests to use the IPsec
	anchors for those domains. When only a subset of traffic is routed		connection.
	into a private network using an IPSec SA, this Configuration Payload
	option can be used to define which private domains should be resolved		The INTERNAL_DNSSEC_TA attribute type is used to convey DNSSEC trust
	through the IPSec connection without affecting the client's global		anchors for those domains.
	DNS resolution. For the purposes of this document, DNS servers
	accessible through an IPsec connection will be referred to as		When only a subset of traffic is routed into a private network using
	"internal DNS servers", and other DNS servers will be referred to as		an IPsec SA, these Configuration Payload options can be used to
	"external DNS servers".		define which private domains should be resolved through the IPsec
			connection without affecting the client's global DNS resolution.
			For the purposes of this document, DNS resolution servers accessible
			through an IPsec connection will be referred to as "internal DNS
			servers", and other DNS servers will be referred to as "external DNS
			servers".
	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. The client device		and INTERNAL_DNSSEC_TA configuration attributes. The client device
	can use the internal DNS server(s) for any DNS queries within the		can use the internal DNS server(s) for any DNS queries within the
	assigned domains, while routing other DNS queries to its regular		assigned domains, while routing other DNS queries to its regular
	external DNS server.		external DNS server.
	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", "MAY", and "OPTIONAL" in this		"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
	document are to be interpreted as described in RFC 2119 [RFC2119].		document are to be interpreted as described in RFC 2119 [RFC2119].
	2. Background		2. Background
	Split-DNS is a common configuration for enterprise VPN deployments,		Split DNS is a common configuration for enterprise VPN deployments,
	in which only one or a few private DNS domains are accessible and		in which only one or a few private DNS domains are accessible and
	resolvable via an IPsec based VPN connection.		resolvable via an IPsec based VPN connection.
	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.
	3. Protocol Exchange		3. Protocol Exchange
			In order to negotiate which domains are considered internal to an
			IKEv2 tunnel, initiators indicate support for Split DNS in their
			CFG_REQUEST payloads, and responders assign internal domains (and
			DNSSEC trust anchors) in their CFG_REPLY payloads. When Split DNS
			has been negotiated, the existing DNS server configuration attributes
			will be interpreted as internal DNS servers that can resolve
			hostnames within the internal domains.
	3.1. Configuration Request		3.1. Configuration Request
	To indicate support for split-DNS, an initiator sending a CFG_REQUEST		To indicate support for Split DNS, an initiator sending a CFG_REQUEST
	payload MAY include one or more INTERNAL_DNS_DOMAIN attributes as		payload MAY include one or more INTERNAL_DNS_DOMAIN attributes as
	defined in Section 4. If an INTERNAL_DNS_DOMAIN attribute is		defined in Section 4. If an INTERNAL_DNS_DOMAIN attribute is
	included in the CFG_REQUEST, the initiator SHOULD also include one or		included in the CFG_REQUEST, the initiator SHOULD also include one or
	both of the INTERNAL_IP4_DNS and INTERNAL_IP6_DNS attributes in its		both of the INTERNAL_IP4_DNS and INTERNAL_IP6_DNS attributes in its
	CFG_REQUEST.		CFG_REQUEST.
	If the length of the INTERNAL_DNS_DOMAIN attribute is zero, then the		If the length of the INTERNAL_DNS_DOMAIN attribute is zero, then the
	initiator is requesting that the attribute be assigned without		initiator is requesting that the attribute be assigned without
	restricting the subdomains that it will accept.		restricting the subdomains that it will accept.
	If the length of the INTERNAL_DNS_DOMAIN is greater than zero, the		If the length of the INTERNAL_DNS_DOMAIN is greater than zero, the
	value is a single DNS domain. The initiator is indicating that it		value is a single DNS domain. The initiator is indicating that it
	will only allow this domain and any sub-domains within this domain to		will only allow this domain and any sub-domains within this domain to
	be resolved using the internal DNS servers. The list of		be resolved using the internal DNS servers. The list of
	INTERNAL_DNS_DOMAIN attributes in the CFG_REQUEST defines the full		INTERNAL_DNS_DOMAIN attributes in the CFG_REQUEST defines the full
	set of domains the intiator is willing to resolve using the internal		set of domains the intiator is willing to resolve using the internal
	DNS servers.		DNS servers.
	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 Split DNS configuration.
			To indicate support for DNSSEC, an initiator sending a CFG_REQUEST
			payload MAY include one or more INTERNAL_DNS_TA attributes as defined
			in Section 4. These payloads MUST immediately follow a
			INTERNAL_DNS_DOMAIN attribute, which binds the DNSSEC trust anchor
			request to the domain.
			An initiator MAY convey its current DNSSEC trust anchors for the
			domain specified in the INTERNAL_DNS_DOMAIN attribute. If it does
			not wish to convey this information, it MUST use a length of 0.
			The absence of INTERNAL_DNS_TA attributes in the CFG_REQUEST payload
			indicates that the initiator does not support or is unwilling to
			accept 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 the CFG_REQUEST contained at least one		their CFG_REPLY payload if the CFG_REQUEST contained at least one
	INTERNAL_DNS_DOMAIN attribute. If the CFG_REQUEST did not contain an		INTERNAL_DNS_DOMAIN attribute. If the CFG_REQUEST did not contain an
	INTERNAL_DNS_DOMAIN attribute, the responder MUST NOT include an		INTERNAL_DNS_DOMAIN attribute, the responder MUST NOT include an
	INTERNAL_DNS_DOMAIN attribute in the CFG_REPLY. If an		INTERNAL_DNS_DOMAIN attribute in the CFG_REPLY. If an
	INTERNAL_DNS_DOMAIN attribute is included in the CFG_REPLY, the		INTERNAL_DNS_DOMAIN attribute is included in the CFG_REPLY, the
	responder SHOULD also include one or both of the INTERNAL_IP4_DNS and		responder SHOULD also include one or both of the INTERNAL_IP4_DNS and
	INTERNAL_IP6_DNS attributes in its CFG_REPLY. If the CFG_REQUEST		INTERNAL_IP6_DNS attributes in its CFG_REPLY. These DNS server
			configurations are necessary to define which servers should receive
			queries for hostnames in internal domains. If the CFG_REQUEST
	included an INTERNAL_DNS_DOMAIN attribute, but the CFG_REPLY does not		included an INTERNAL_DNS_DOMAIN attribute, but the CFG_REPLY does not
	include an INTERNAL_DNS_DOMAIN attribute, the initiator should behave		include an INTERNAL_DNS_DOMAIN attribute, the initiator should behave
	as if split-DNS configurations are not supported by the server.		as if Split DNS configurations are not supported by the server.
	Each INTERNAL_DNS_DOMAIN represents a domain that the DNS servers		Each INTERNAL_DNS_DOMAIN represents a domain that the DNS servers
	address listed in INTERNAL_IP4_DNS and INTERNAL_IP6_DNS can resolve.		address 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 CFG_REPLY MUST NOT assign any domains in its		zero lengths, the CFG_REPLY MUST NOT assign any domains in its
	INTERNAL_DNS_DOMAIN attributes that are not contained within the		INTERNAL_DNS_DOMAIN attributes that are not contained within the
	requested domains. The initiator SHOULD ignore any domains beyond		requested domains. The initiator SHOULD ignore any domains beyond
	its requested list.		its requested list.
	For each DNS domain specified in an INTERNAL_DNS_DOMAIN attribute, an		For each DNS domain specified in an INTERNAL_DNS_DOMAIN attribute,
	INTERNAL_DNSSEC_TA attribute may be included by the responder. This		one or more INTERNAL_DNSSEC_TA attributes MAY be included by the
	attribute lists the corresponding DSSNEC trust anchor in the		responder. This attribute lists the corresponding DSSNEC trust
	presentation format of a DS record as specified in [RFC4034].		anchor in the DNS wire format of a DS record as specified in
			[RFC4034]. The INTERNAL_DNSSEC_TA attribute MUST immediately follow
			the INTERNAL_DNS_DOMAIN attribute that it applies to.
	3.3. Mapping DNS Servers to Domains		3.3. Mapping DNS Servers to Domains
	All DNS servers provided in the CFG_REPLY MUST support resolving		All DNS servers provided in the CFG_REPLY MUST support resolving
	hostnames within all INTERNAL_DNS_DOMAIN domains. In other words,		hostnames within all INTERNAL_DNS_DOMAIN domains. In other words,
	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 and		In this example exchange, the initiator requests INTERNAL_IP4_DNS and
	INTERNAL_DNS_DOMAIN attributes in its CFG_REQUEST, but does not		INTERNAL_DNS_DOMAIN attributes in its CFG_REQUEST, but does not
	specify any value for either. This indicates that it supports split-		specify any value for either. This indicates that it supports Split
	DNS, but has no preference for which DNS requests should be routed		DNS, but has no preference for which DNS requests should be routed
	through the tunnel.		through the tunnel.
	The responder replies with two DNS server addresses, and one internal		The responder replies with two DNS server addresses, and one internal
	domain, "example.com".		domain, "example.com".
	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) =
	skipping to change at page 6, line 18 ¶		skipping to change at page 6, line 47 ¶
	INTERNAL_DNS_DOMAIN(example.com)		INTERNAL_DNS_DOMAIN(example.com)
	INTERNAL_DNS_DOMAIN(other.com)		INTERNAL_DNS_DOMAIN(other.com)
	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_DNS_DOMAIN(example.com)		INTERNAL_DNS_DOMAIN(example.com)
	INTERNAL_DNS_DOMAIN(city.other.com)		INTERNAL_DNS_DOMAIN(city.other.com)
			3.4.3. Requesting Domains and DNSSEC trust anchors
			In this example exchange, the initiator requests INTERNAL_IP4_DNS,
			INTERNAL_DNS_DOMAIN and INTERNAL_DNS_TA attributess in its
			CFG_REQUEST
			Any subsequent DNS queries from the initiator for domains such as
			"www.example.com" or "city.other.com" would be DNSSEC validated using
			the DNSSEC trust anchor received in the CFG_REPLY
			In this example, the initiator has no existing DNSSEC trust anchors
			would the requested domain. the "example.com" dommain has DNSSEC
			trust anchors that are returned, while the "other.com" domain has no
			DNSSEC trust anchors
			CP(CFG_REQUEST) =
			INTERNAL_IP4_ADDRESS()
			INTERNAL_IP4_DNS()
			INTERNAL_DNS_DOMAIN(example.com)
			INTERNAL_DNS_TA()
			INTERNAL_DNS_DOMAIN(other.com)
			INTERNAL_DNS_TA()
			CP(CFG_REPLY) =
			INTERNAL_IP4_ADDRESS(198.51.100.234)
			INTERNAL_IP4_DNS(198.51.100.2)
			INTERNAL_IP4_DNS(198.51.100.4)
			INTERNAL_DNS_DOMAIN(example.com)
			INTERNAL_DNS_TA(43547,8,1,B6225AB2CC613E0DCA7962BDC2342EA4F1B56083)
			INTERNAL_DNS_TA(31406,8,2,F78CF3344F72137235098ECBBD08947C2C90....)
			INTERNAL_DNS_DOMAIN(city.other.com)
	4. Payload Formats		4. Payload Formats
	4.1. INTERNAL_DNS_DOMAIN Configuration Attribute Type		4.1. INTERNAL_DNS_DOMAIN Configuration Attribute Type
	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 ~		~ Domain Name ~
	| |		| |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+---------------------------------------------------------------+
	o Reserved (1 bit) - Defined in IKEv2 RFC [RFC7296].		o Reserved (1 bit) - Defined in IKEv2 RFC [RFC7296].
	o Attribute Type (15 bits) [TBD IANA] - INTERNAL_DNS_DOMAIN.		o Attribute Type (15 bits) [TBD IANA] - INTERNAL_DNS_DOMAIN.
	o Length (2 octets, unsigned integer) - Length of domain name.		o Length (2 octets, unsigned integer) - Length of domain name.
	o Domain Name (0 or more octets) - A domain or subdomain used for		o Domain Name (0 or more octets) - A domain or subdomain used for
	split-DNS rules, such as example.com. This is a string of ASCII		Split DNS rules, such as example.com. This is a string of ASCII
	characters with labels separated by dots, with no trailing dot,		characters with labels separated by dots, with no trailing dot,
	using IDNA [RFC5890] for non-ASCII DNS domains. The value is NOT		using IDNA [RFC5890] for non-ASCII DNS domains. The value is NOT
	null-terminated.		null-terminated.
	4.2. INTERNAL_DNSSEC_TA Configuration Attribute		4.2. INTERNAL_DNSSEC_TA Configuration 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 |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-----------------------------+---------------+---------------+
			| Key Tag | Algorithm | Digest Type |
			+-------------------------------+---------------+---------------+
	| |		| |
	~ DNSSEC TRUST ANCHOR ~		~ Digest ~
	| |		| |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+---------------------------------------------------------------+
	o Reserved (1 bit) - Defined in IKEv2 RFC [RFC7296].		o Reserved (1 bit) - Defined in IKEv2 RFC [RFC7296].
	o Attribute Type (15 bits) [TBD IANA] - INTERNAL_DNSSEC_TA.		o Attribute Type (15 bits) [TBD IANA] - INTERNAL_DNSSEC_TA.
	o Length (2 octets, unsigned integer) - Length of DNSSEC Trust		o Length (2 octets, unsigned integer) - Length of DNSSEC Trust
	Anchor data.		Anchor data.
	o DNSSEC Trust anchor (multiple octets) - The presentation format of		o Key Tag value (0 or 2 octets, unsigned integer) - Key Tag as
	one DS record as specified in [RFC4034]. The TTL value MAY be		specified in [RFC4034] Section 5.1
	omited and when present MUST be ignored. The domain name is
	specified as a Fully Qualified Domain Name (FQDN) - irrespective
	of the presence of a trailing dot, and consits of a string of
	ASCII characters with labels separated by dots and uses IDNA
	[RFC5890] for non-ASCII DNS domains. The value is NOT null-
	terminated.
	5. Split-DNS Usage Guidelines		o DNSKEY algorithm (0 or 1 octet) - Value from the IANA DNS Security
			Algorithm Numbers Registry
			o DS algorithm (0 or 1 octet) - Value from the IANA Delegation
			Signer (DS) Resource Record (RR) Type Digest Algorithms Registry
			o Digest (0 or more octets) - The raw digest as specified in
			[RFC4034] Section 5.1
			5. Split DNS Usage Guidelines
	If a CFG_REPLY payload contains no INTERNAL_DNS_DOMAIN attributes,		If a CFG_REPLY payload contains no INTERNAL_DNS_DOMAIN attributes,
	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.
	For each INTERNAL_DNS_DOMAIN entry in a CFG_REPLY payload, the client		For each INTERNAL_DNS_DOMAIN entry in a CFG_REPLY payload, the client
	SHOULD use the provided INTERNAL_IP4_DNS or INTERNAL_IP6_DNS DNS		SHOULD use the provided INTERNAL_IP4_DNS or INTERNAL_IP6_DNS DNS
	servers as the only resolvers for the listed domains and its sub-		servers as the only resolvers for the listed domains and its sub-
	domains and it SHOULD NOT attempt to resolve the provided DNS domains		domains and it SHOULD NOT attempt to resolve the provided DNS domains
	using its external DNS servers.		using its external DNS servers.
	skipping to change at page 8, line 26 ¶		skipping to change at page 9, line 37 ¶
	explicitly wish to support some Special Use Domain Names.		explicitly wish to support some Special Use Domain Names.
	When an IPsec connection is terminated, the DNS forwarding must be		When an IPsec connection is terminated, the DNS forwarding must be
	unconfigured. The DNS forwarding itself MUST be be deleted. All		unconfigured. The DNS forwarding itself MUST be be deleted. All
	cached data of the INTERNAL_DNS_DOMAIN provided DNS domainis MUST be		cached data of the INTERNAL_DNS_DOMAIN provided DNS domainis MUST be
	flushed. This includes negative cache entries. Obtained DNSSEC		flushed. This includes negative cache entries. Obtained DNSSEC
	trust anchors MUST be removed from the list of trust anchors. The		trust anchors MUST be removed from the list of trust anchors. The
	outstanding DNS request queue MAY be cleared.		outstanding DNS request queue MAY be cleared.
	A domain that is served via INTERNAL_DNS_DOMAIN MUST NOT have		A domain that is served via INTERNAL_DNS_DOMAIN MUST NOT have
	indirect references to DNS records that point to other split-DNS		indirect references to DNS records that point to other Split DNS
	domains that are not served via INTERNAL_DNS_DOMAIN attributes.		domains that are not served via INTERNAL_DNS_DOMAIN attributes.
	Indirect reference RRtypes include CNAME, DNAME, MX and SRV RR's.		Indirect reference RRtypes include CNAME, DNAME, MX and SRV RR's.
	INTERNAL_DNS_DOMAIN and INTERNAL_DNSSEC_TA attributes SHOULD only be		INTERNAL_DNS_DOMAIN and INTERNAL_DNSSEC_TA attributes SHOULD only be
	used on split-tunnel configurations where only a subset of traffic is		used on split tunnel configurations where only a subset of traffic is
	routed into a private remote network using the IPSec connection. If		routed into a private remote network using the IPsec connection. If
	all traffic is routed over the IPsec connection, the existing global		all traffic is 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 exemptions.		specific DNS exemptions.
	6. Security Considerations		6. Security Considerations
	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 be		INTERNAL_DNS_DOMAIN attribute, the IKE connection should be
	terminated.		terminated.
	If the IP address value of the received INTERNAL_IP4_DNS or		If the IP address value of the received INTERNAL_IP4_DNS or
	INTERNAL_IP6_DNS attribute is not covered by the proposed IPsec		INTERNAL_IP6_DNS attribute is not covered by the proposed IPsec
	connection, then the local DNS should not be reconfigured until a		connection, then the local DNS should not be reconfigured until a
	CREATE_CHILD Exchange is received that covers these IP addresses.		CREATE_CHILD Exchange is received that covers these IP addresses.
	INTERNAL_DNSSEC_TA directives MUST have an accompanying		INTERNAL_DNSSEC_TA directives MUST immediately follow an
	INTERNAL_DNS_DOMAIN directive. This prevents the insertion of rogue		INTERNAL_DNS_DOMAIN directive. As the INTERNAL_DNSSEC_TA format
	DNSSEC trust anchors for domains that have not been configured to use		itself does not contain the domain name, it relies on the preceding
	the IPsec connection.		INTERNAL_DNS_DOMAIN to provide the domain for which it specifies the
			trust anchor.
			If the initiator is using DNSSEC validation for a domain in its
			public DNS view, and it requests and receives an INTERNAL_DNS_DOMAIN
			attribute without an INTERNAL_DNSSEC_TA, it will need to reconfigure
			its DNS resolver to allow for an insecure delegation. It SHOULD NOT
			accept insecure delegations for domains that are DNSSEC signed in the
			public DNS view, for which it has not explicitely requested such
			deletation by specifying the domain specifically using a
			INTERNAL_DNS_DOMAIN(domain) request.
	7. IANA Considerations		7. IANA Considerations
	This document defines two new IKEv2 Configuration Payload Attribute		This document defines two new IKEv2 Configuration Payload Attribute
	Types, which are allocated from the "IKEv2 Configuration Payload		Types, which are allocated from the "IKEv2 Configuration Payload
	Attribute Types" namespace.		Attribute Types" namespace.
	Multi-		Multi-
	Value Attribute Type Valued Length Reference		Value Attribute Type Valued Length Reference
	------ ------------------- ------ ---------- ---------------		------ ------------------- ------ ---------- ---------------
	skipping to change at page 10, line 12 ¶		skipping to change at page 11, line 33 ¶
	RFC 5890, DOI 10.17487/RFC5890, August 2010,		RFC 5890, DOI 10.17487/RFC5890, August 2010,
	<http://www.rfc-editor.org/info/rfc5890>.		<http://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, <http://www.rfc-editor.org/info/rfc7296>.		2014, <http://www.rfc-editor.org/info/rfc7296>.
	8.2. Informative References		8.2. Informative References
			[RFC2775] Carpenter, B., "Internet Transparency", RFC 2775,
			DOI 10.17487/RFC2775, February 2000,
			<http://www.rfc-editor.org/info/rfc2775>.
	[RFC6761] Cheshire, S. and M. Krochmal, "Special-Use Domain Names",		[RFC6761] Cheshire, S. and M. Krochmal, "Special-Use Domain Names",
	RFC 6761, DOI 10.17487/RFC6761, February 2013,		RFC 6761, DOI 10.17487/RFC6761, February 2013,
	<http://www.rfc-editor.org/info/rfc6761>.		<http://www.rfc-editor.org/info/rfc6761>.
	[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, <http://www.rfc-editor.org/info/rfc7435>.		December 2014, <http://www.rfc-editor.org/info/rfc7435>.
	Authors' Addresses		Authors' Addresses
	Tommy Pauly		Tommy Pauly
	Apple Inc.		Apple Inc.
	1 Infinite Loop		1 Infinite Loop
	Cupertino, California 95014		Cupertino, California 95014
	US		US
	Email: tpauly@apple.com		Email: tpauly@apple.com
	Paul Wouters		Paul Wouters
	Red Hat		Red Hat
End of changes. 38 change blocks.
	83 lines changed or deleted		170 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/