< draft-ietf-ipsecme-split-dns-02.txt		draft-ietf-ipsecme-split-dns-03.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: January 30, 2018 Red Hat		Expires: May 16, 2018 Red Hat
	July 29, 2017		November 12, 2017
	Split DNS Configuration for IKEv2		Split DNS Configuration for IKEv2
	draft-ietf-ipsecme-split-dns-02		draft-ietf-ipsecme-split-dns-03
	Abstract		Abstract
	This document defines two Configuration Payload Attribute Types for		This document defines two Configuration Payload Attribute Types for
	the IKEv2 protocol that add support for private DNS domains. These		the IKEv2 protocol that add support for private DNS domains. These
	domains should be resolved using DNS servers reachable through an		domains should be resolved using DNS servers reachable through an
	IPsec connection, while leaving all other DNS resolution unchanged.		IPsec connection, while leaving all other DNS resolution unchanged.
	This approach of resolving a subset of domains using non-public DNS		This approach of resolving a subset of domains using non-public DNS
	servers is referred to as "Split DNS".		servers is referred to as "Split DNS".
	skipping to change at page 1, line 36 ¶		skipping to change at page 1, line 36 ¶
	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 January 30, 2018.		This Internet-Draft will expire on May 16, 2018.
	Copyright Notice		Copyright Notice
	Copyright (c) 2017 IETF Trust and the persons identified as the		Copyright (c) 2017 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 4, line 8 ¶		skipping to change at page 4, line 8 ¶
	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 existing DNS server configuration attributes		has been negotiated, the existing DNS server configuration attributes
	will be interpreted as internal DNS servers that can resolve		will be interpreted as internal DNS servers that can resolve
	hostnames within the internal domains.		hostnames within the internal domains.
	3.1. Configuration Request		3.1. Configuration Request
	To indicate support for Split DNS, an initiator includes one more		To indicate support for Split DNS, an initiator includes one more
	more INTERNAL_DNS_DOMAIN attributes as defined in Section 4 as part		INTERNAL_DNS_DOMAIN attributes as defined in Section 4 as part of the
	of the CFG_REQUEST payload. If an INTERNAL_DNS_DOMAIN attribute is		CFG_REQUEST payload. If an INTERNAL_DNS_DOMAIN attribute is included
	included in the CFG_REQUEST, the initiator SHOULD also include one or		in the CFG_REQUEST, the initiator SHOULD also include one or more
	more INTERNAL_IP4_DNS and INTERNAL_IP6_DNS attributes in the		INTERNAL_IP4_DNS and INTERNAL_IP6_DNS attributes in the CFG_REQUEST.
	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 Split DNS configuration.
	To indicate support for DNSSEC, an initiator includes one or more		To indicate support for DNSSEC, an initiator includes one or more
	INTERNAL_DNS_TA attributes as defined in Section 4 as part of the		INTERNAL_DNSSEC_TA attributes as defined in Section 4 as part of the
	CFG_REQUEST payload. If an INTERNAL_DNS_TA attriute is included in		CFG_REQUEST payload. If an INTERNAL_DNSSEC_TA attriute is included
	the CFG_REQUEST, the initiator SHOULD also include one or more		in the CFG_REQUEST, the initiator SHOULD also include one or more
	INTERNAL_DNS_DOMAIN attributes in the CFG_REQUEST.		INTERNAL_DNS_DOMAIN attributes in the CFG_REQUEST.
	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. If it does		domain specified in the INTERNAL_DNS_DOMAIN attribute. If it does
	not wish to convey this information, it MUST use a length of 0.		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		The absence of INTERNAL_DNSSEC_TA attributes in the CFG_REQUEST
	indicates that the initiator does not support or is unwilling to		payload indicates that the initiator does not support or is unwilling
	accept DNSSEC trust anchor configuration.		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 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 should receive queries for hostnames in internal		which servers should receive queries for hostnames in internal
	domains. If the CFG_REQUEST included an INTERNAL_DNS_DOMAIN		domains. If the CFG_REQUEST included an INTERNAL_DNS_DOMAIN
	skipping to change at page 6, line 8 ¶		skipping to change at page 6, line 8 ¶
	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.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_DNS_DOMAIN and INTERNAL_DNS_TA attributess in the		INTERNAL_DNS_DOMAIN and INTERNAL_DNSSEC_TA attributess in the
	CFG_REQUEST		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.com" would be DNSSEC validated using		"www.example.com" or "city.other.com" would be DNSSEC validated using
	the DNSSEC trust anchor received in the CFG_REPLY		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		would the requested domain. the "example.com" dommain has DNSSEC
	trust anchors that are returned, while the "other.com" domain has no		trust anchors that are returned, while the "other.com" 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_DNS_DOMAIN()		INTERNAL_DNS_DOMAIN()
	INTERNAL_DNS_TA()		INTERNAL_DNSSEC_TA()
	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_TA(43547,8,1,B6225AB2CC613E0DCA7962BDC2342EA4F1B56083)		INTERNAL_DNSSEC_TA(43547,8,1,B6225AB2CC613E0DCA7962BDC2342EA4F1B56083)
	INTERNAL_DNS_TA(31406,8,2,F78CF3344F72137235098ECBBD08947C2C90....)		INTERNAL_DNSSEC_TA(31406,8,2,F78CF3344F72137235098ECBBD08947C2C90....)
	INTERNAL_DNS_DOMAIN(city.other.com)		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 |
	+-+-----------------------------+-------------------------------+		+-+-----------------------------+-------------------------------+
	skipping to change at page 7, line 10 ¶		skipping to change at page 7, line 10 ¶
	o Reserved (1 bit) - Defined in IKEv2 RFC [RFC7296].		o Reserved (1 bit) - Defined in IKEv2 RFC [RFC7296].
	o Attribute Type (15 bits) 25 - INTERNAL_DNS_DOMAIN.		o Attribute Type (15 bits) 25 - 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 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 presentation		used for Split DNS rules, such as example.com, in DNS presentation
	format and optionally using IDNA [RFC5890] for Internationalized		format and optionally using IDNA [RFC5890] for Internationalized
	Domain Names. The value is NOT null-terminated.		Domain Names. Implementors need to be careful that this value is
			not 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 |		| Key Tag | Algorithm | Digest Type |
	+-------------------------------+---------------+---------------+		+-------------------------------+---------------+---------------+
	skipping to change at page 7, line 36 ¶		skipping to change at page 7, line 37 ¶
	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 Key Tag value (0 or 2 octets, unsigned integer) - Key Tag as		o Key Tag value (0 or 2 octets, unsigned integer) - Key Tag as
	specified in [RFC4034] Section 5.1		specified in [RFC4034] Section 5.1
	o DNSKEY algorithm (0 or 1 octet) - Value from the IANA DNS Security		o Algorithm (0 or 1 octet) - DNSKEY algorithm value from the IANA
	Algorithm Numbers Registry		DNS Security Algorithm Numbers Registry
	o DS algorithm (0 or 1 octet) - Value from the IANA Delegation		o DS algorithm (0 or 1 octet) - DS algorithm value from the IANA
	Signer (DS) Resource Record (RR) Type Digest Algorithms Registry		Delegation Signer (DS) Resource Record (RR) Type Digest Algorithms
			Registry
	o Digest (0 or more octets) - The digest as specified in [RFC4034]		o Digest (0 or more octets) - The DNSKEY digest as specified in
	Section 5.1 in presentation format.		[RFC4034] Section 5.1 in presentation format.
	5. Split DNS Usage Guidelines		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.
	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
	number of INTERNAL_DNS_DOMAIN values, the client MUST ignore any		number of INTERNAL_DNS_DOMAIN values, the client MUST ignore any
	other INTERNAL_DNS_DOMAIN values.		other INTERNAL_DNS_DOMAIN values.
	skipping to change at page 9, line 23 ¶		skipping to change at page 9, line 23 ¶
	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 enduser.		information and potentially warn the enduser.
	INTERNAL_DNSSEC_TA directives MUST immediately follow an		INTERNAL_DNSSEC_TA payloads MUST immediately follow an
	INTERNAL_DNS_DOMAIN directive. As the INTERNAL_DNSSEC_TA format		INTERNAL_DNS_DOMAIN payload. As the INTERNAL_DNSSEC_TA format itself
	itself does not contain the domain name, it relies on the preceding		does not contain the domain name, it relies on the preceding
	INTERNAL_DNS_DOMAIN to provide the domain for which it specifies the		INTERNAL_DNS_DOMAIN to provide the domain for which it specifies the
	trust anchor.		trust anchor.
	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 explicitely requested such		public DNS view, for which it has not explicitely requested such
	deletation by specifying the domain specifically using a		deletation by specifying the domain specifically using a
	skipping to change at page 10, line 26 ¶		skipping to change at page 10, line 26 ¶
	Figure 1		Figure 1
	8. References		8. References
	8.1. Normative References		8.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,
	<http://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
	Requirement Levels", BCP 14, RFC 2119,		Requirement Levels", BCP 14, RFC 2119,
	DOI 10.17487/RFC2119, March 1997,		DOI 10.17487/RFC2119, March 1997, <https://www.rfc-
	<http://www.rfc-editor.org/info/rfc2119>.		editor.org/info/rfc2119>.
	[RFC4034] Arends, R., Austein, R., Larson, M., Massey, D., and S.		[RFC4034] Arends, R., Austein, R., Larson, M., Massey, D., and S.
	Rose, "Resource Records for the DNS Security Extensions",		Rose, "Resource Records for the DNS Security Extensions",
	RFC 4034, DOI 10.17487/RFC4034, March 2005,		RFC 4034, DOI 10.17487/RFC4034, March 2005,
	<http://www.rfc-editor.org/info/rfc4034>.		<https://www.rfc-editor.org/info/rfc4034>.
	[RFC5890] Klensin, J., "Internationalized Domain Names for		[RFC5890] Klensin, J., "Internationalized Domain Names for
	Applications (IDNA): Definitions and Document Framework",		Applications (IDNA): Definitions and Document Framework",
	RFC 5890, DOI 10.17487/RFC5890, August 2010,		RFC 5890, DOI 10.17487/RFC5890, August 2010,
	<http://www.rfc-editor.org/info/rfc5890>.		<https://www.rfc-editor.org/info/rfc5890>.
	[RFC7296] Kaufman, C., Hoffman, P., Nir, Y., Eronen, P., and T.		[RFC7296] Kaufman, C., Hoffman, P., Nir, Y., Eronen, P., and T.
	Kivinen, "Internet Key Exchange Protocol Version 2		Kivinen, "Internet Key Exchange Protocol Version 2
	(IKEv2)", STD 79, RFC 7296, DOI 10.17487/RFC7296, October		(IKEv2)", STD 79, RFC 7296, DOI 10.17487/RFC7296, October
	2014, <http://www.rfc-editor.org/info/rfc7296>.		2014, <https://www.rfc-editor.org/info/rfc7296>.
	8.2. Informative References		8.2. Informative References
	[RFC2775] Carpenter, B., "Internet Transparency", RFC 2775,		[RFC2775] Carpenter, B., "Internet Transparency", RFC 2775,
	DOI 10.17487/RFC2775, February 2000,		DOI 10.17487/RFC2775, February 2000, <https://www.rfc-
	<http://www.rfc-editor.org/info/rfc2775>.		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>.		<https://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, <https://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
End of changes. 22 change blocks.
	49 lines changed or deleted		50 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/