draft-ietf-ipsecme-split-dns-11.txt   draft-ietf-ipsecme-split-dns-12.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 20, 2019 Red Hat Expires: February 7, 2019 Red Hat
July 19, 2018 August 6, 2018
Split DNS Configuration for IKEv2 Split DNS Configuration for IKEv2
draft-ietf-ipsecme-split-dns-11 draft-ietf-ipsecme-split-dns-12
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".
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 https://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 20, 2019. This Internet-Draft will expire on February 7, 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
(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
skipping to change at page 2, line 23 skipping to change at page 2, line 23
3.1. Configuration Request . . . . . . . . . . . . . . . . . . 4 3.1. Configuration Request . . . . . . . . . . . . . . . . . . 4
3.2. Configuration Reply . . . . . . . . . . . . . . . . . . . 4 3.2. Configuration Reply . . . . . . . . . . . . . . . . . . . 4
3.3. Mapping DNS Servers to Domains . . . . . . . . . . . . . 5 3.3. Mapping DNS Servers to Domains . . . . . . . . . . . . . 5
3.4. Example Exchanges . . . . . . . . . . . . . . . . . . . . 5 3.4. Example Exchanges . . . . . . . . . . . . . . . . . . . . 5
3.4.1. Simple Case . . . . . . . . . . . . . . . . . . . . . 5 3.4.1. Simple Case . . . . . . . . . . . . . . . . . . . . . 5
3.4.2. Requesting Domains and DNSSEC trust anchors . . . . . 6 3.4.2. Requesting Domains and DNSSEC trust anchors . . . . . 6
4. Payload Formats . . . . . . . . . . . . . . . . . . . . . . . 6 4. Payload Formats . . . . . . . . . . . . . . . . . . . . . . . 6
4.1. INTERNAL_DNS_DOMAIN Configuration Attribute Type Request 4.1. INTERNAL_DNS_DOMAIN Configuration Attribute Type Request
and Reply . . . . . . . . . . . . . . . . . . . . . . . . 7 and Reply . . . . . . . . . . . . . . . . . . . . . . . . 7
4.2. INTERNAL_DNSSEC_TA Configuration Attribute . . . . . . . 7 4.2. INTERNAL_DNSSEC_TA Configuration Attribute . . . . . . . 7
5. INTERNAL_DNS_DOMAIN Usage Guidelines . . . . . . . . . . . . 8 5. INTERNAL_DNS_DOMAIN Usage Guidelines . . . . . . . . . . . . 9
6. INTERNAL_DNSSEC_TA Usage Guidelines . . . . . . . . . . . . . 9 6. INTERNAL_DNSSEC_TA Usage Guidelines . . . . . . . . . . . . . 10
7. Security Considerations . . . . . . . . . . . . . . . . . . . 11 7. Security Considerations . . . . . . . . . . . . . . . . . . . 11
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12
9. References . . . . . . . . . . . . . . . . . . . . . . . . . 12 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 12
9.1. Normative References . . . . . . . . . . . . . . . . . . 12 9.1. Normative References . . . . . . . . . . . . . . . . . . 12
9.2. Informative References . . . . . . . . . . . . . . . . . 13 9.2. Informative References . . . . . . . . . . . . . . . . . 13
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 13 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 13
1. Introduction 1. Introduction
Split DNS is a common configuration for secure tunnels, such as Split DNS is a common configuration for secure tunnels, such as
Virtual Private Networks in which host machines private to an Virtual Private Networks in which host machines private to an
organization can only be resolved using internal DNS resolvers organization can only be resolved using internal DNS resolvers
skipping to change at page 8, line 45 skipping to change at page 8, line 45
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. [RFC4034] Section 5.1 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 attribute MUST be ignored and treated as a INTERNAL_DNS_DOMAIN or another INTERNAL_DNSSEC_TA attribute applying
protocol error. to the same domain name MUST be ignored and treated as a protocol
error.
5. INTERNAL_DNS_DOMAIN Usage Guidelines 5. INTERNAL_DNS_DOMAIN 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 10, line 23 skipping to change at page 10, line 32
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 one or more domain IKE clients willing to accept INTERNAL_DNSSEC_TA attributes MUST use
names for which it will allow INTERNAL_DNSSEC_TA updates. This list a whitelist of one or more domains that can be updated out of band.
can either be sent in the CFG_REQUEST payload, or else be applied IKE clients with an empty whitelist MUST NOT use any
after reception of the CFG_REPLY payload. INTERNAL_DNSSEC_TA attributes received over IKE. Such clients MAY
interpret receiving an INTERNAL_DNSSEC_TA attribute for a non-
whitelisted domain as an indication that their local configuration
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 NOT be whitelisted. Other generic or The DNS root zone (".") MUST NOT be whitelisted. Other generic or
public domains, such as top-level domains, similarly SHOULD NOT be public domains, such as top-level domains, similarly SHOULD NOT be
whitelisted. 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.
 End of changes. 7 change blocks. 
13 lines changed or deleted 17 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/