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.47. The latest version is available from http://tools.ietf.org/tools/rfcdiff/