< draft-ietf-ipsecme-split-dns-09.txt		draft-ietf-ipsecme-split-dns-10.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 19, 2019 Red Hat		Expires: January 19, 2019 Red Hat
	July 18, 2018		July 18, 2018
	Split DNS Configuration for IKEv2		Split DNS Configuration for IKEv2
	draft-ietf-ipsecme-split-dns-09		draft-ietf-ipsecme-split-dns-10
	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 are intended to be resolved using DNS servers reachable		domains are intended to be resolved using DNS servers reachable
	through an IPsec connection, while leaving all other DNS resolution		through an IPsec connection, while leaving all other DNS resolution
	unchanged. This approach of resolving a subset of domains using non-		unchanged. This approach of resolving a subset of domains using non-
	public DNS servers is referred to as "Split DNS".		public DNS servers is referred to as "Split DNS".
	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 https://datatracker.ietf.org/drafts/current/.
	Internet-Drafts are draft documents valid for a maximum of six months		Internet-Drafts are draft documents valid for a maximum of six months
	and may be updated, replaced, or obsoleted by other documents at any		and may be updated, replaced, or obsoleted by other documents at any
	time. It is inappropriate to use Internet-Drafts as reference		time. It is inappropriate to use Internet-Drafts as reference
	material or to cite them other than as "work in progress."		material or to cite them other than as "work in progress."
	This Internet-Draft will expire on January 19, 2019.		This Internet-Draft will expire on January 19, 2019.
	Copyright Notice		Copyright Notice
	Copyright (c) 2018 IETF Trust and the persons identified as the		Copyright (c) 2018 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		(https://trustee.ietf.org/license-info) in effect on the date of
	publication of this document. Please review these documents		publication of this document. Please review these documents
	carefully, as they describe your rights and restrictions with respect		carefully, as they describe your rights and restrictions with respect
	to this document. Code Components extracted from this document must		to this document. Code Components extracted from this document must
	include Simplified BSD License text as described in Section 4.e of		include Simplified BSD License text as described in Section 4.e of
	the Trust Legal Provisions and are provided without warranty as		the Trust Legal Provisions and are provided without warranty as
	described in the Simplified BSD License.		described in the Simplified BSD License.
	Table of Contents		Table of Contents
	1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2		1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
	skipping to change at page 10, line 35 ¶		skipping to change at page 10, line 35 ¶
	certificate. It allows the remote IKE/IPsec server to modify DNS		certificate. It allows the remote IKE/IPsec server to modify DNS
	answers including its DNSSEC cryptographic signatures by overriding		answers including its DNSSEC cryptographic signatures by overriding
	existing DNS information with trust anchor conveyed via IKE and		existing DNS information with trust anchor conveyed via IKE and
	(temporarilly) installed on the IKE client. Of specific concern is		(temporarilly) installed on the IKE client. Of specific concern is
	the overriding of [RFC6698] based TLSA records, which represent a		the overriding of [RFC6698] based TLSA records, which represent a
	confirmation or override of an existing WebPKI TLS certificate.		confirmation or override of an existing WebPKI TLS certificate.
	Other DNS record types that convey cryptographic materials (public		Other DNS record types that convey cryptographic materials (public
	keys or fingerprints) are OPENPGPKEY, SMIMEA, SSHP and IPSECKEY		keys or fingerprints) are OPENPGPKEY, SMIMEA, SSHP and IPSECKEY
	records.		records.
	IKE clients MUST use a preconfigured whitelist of domain names for		IKE clients MUST use a preconfigured whitelist of one or more domain
	which it will allow INTERNAL_DNSSEC_TA updates.		names for which it will allow INTERNAL_DNSSEC_TA updates. This list
			may be sent in the CFG_REQUEST payload, or may be applied after
			reception of the CFG_REPLY payload.
	The DNS root zone (".") MUST NOT be whitelisted.		IKE clients should take care to only whitelist domains that apply to
			internal or managed domains, rather than to generic Internet traffic.
			The DNS root zone (".") MUST NOT be whitelisted. Other generic or
			public domains, such as top-level domains, similarly SHOULD NOT be
			whitelisted.
	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 to prevent invisible installation of trust		explicit human interaction to prevent invisible installation of trust
	anchors.		anchors.
	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.
	skipping to change at page 12, line 32 ¶		skipping to change at page 12, line 37 ¶
	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
	Requirement Levels", BCP 14, RFC 2119,		Requirement Levels", BCP 14, RFC 2119,
	DOI 10.17487/RFC2119, March 1997, <https://www.rfc-		DOI 10.17487/RFC2119, March 1997,
	editor.org/info/rfc2119>.		<https://www.rfc-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,
	<https://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,
	<https://www.rfc-editor.org/info/rfc5890>.		<https://www.rfc-editor.org/info/rfc5890>.
	skipping to change at page 13, line 17 ¶		skipping to change at page 13, line 22 ¶
	(IKEv2)", STD 79, RFC 7296, DOI 10.17487/RFC7296, October		(IKEv2)", STD 79, RFC 7296, DOI 10.17487/RFC7296, October
	2014, <https://www.rfc-editor.org/info/rfc7296>.		2014, <https://www.rfc-editor.org/info/rfc7296>.
	[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC		[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
	2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,		2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
	May 2017, <https://www.rfc-editor.org/info/rfc8174>.		May 2017, <https://www.rfc-editor.org/info/rfc8174>.
	9.2. Informative References		9.2. Informative References
	[RFC2775] Carpenter, B., "Internet Transparency", RFC 2775,		[RFC2775] Carpenter, B., "Internet Transparency", RFC 2775,
	DOI 10.17487/RFC2775, February 2000, <https://www.rfc-		DOI 10.17487/RFC2775, February 2000,
	editor.org/info/rfc2775>.		<https://www.rfc-editor.org/info/rfc2775>.
	[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
End of changes. 7 change blocks.
	10 lines changed or deleted		16 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/