doc: Add RFC documents

1 files changed, 899 insertions, 0 deletions

diff --git a/doc/rfc/rfc8598.txt b/doc/rfc/rfc8598.txt
new file mode 100644
index 0000000..6f5eaff
--- /dev/null
+++ b/doc/rfc/rfc8598.txt
@@ -0,0 +1,899 @@
+
+
+
+
+
+
+Internet Engineering Task Force (IETF)                          T. Pauly
+Request for Comments: 8598                                    Apple Inc.
+Category: Standards Track                                     P. Wouters
+ISSN: 2070-1721                                                  Red Hat
+                                                                May 2019
+
+
+                        Split DNS Configuration
+        for the Internet Key Exchange Protocol Version 2 (IKEv2)
+
+Abstract
+
+   This document defines two Configuration Payload Attribute Types
+   (INTERNAL_DNS_DOMAIN and INTERNAL_DNSSEC_TA) for the Internet Key
+   Exchange Protocol version 2 (IKEv2).  These payloads add support for
+   private (internal-only) DNS domains.  These domains are intended to
+   be resolved using non-public DNS servers that are only reachable
+   through the IPsec connection.  DNS resolution for other domains
+   remains unchanged.  These Configuration Payloads only apply to split-
+   tunnel configurations.
+
+Status of This Memo
+
+   This is an Internet Standards Track document.
+
+   This document is a product of the Internet Engineering Task Force
+   (IETF).  It represents the consensus of the IETF community.  It has
+   received public review and has been approved for publication by the
+   Internet Engineering Steering Group (IESG).  Further information on
+   Internet Standards is available in Section 2 of RFC 7841.
+
+   Information about the current status of this document, any errata,
+   and how to provide feedback on it may be obtained at
+   https://www.rfc-editor.org/info/rfc8598.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Pauly & Wouters              Standards Track                    [Page 1]
+
+RFC 8598            Split DNS Configuration for IKEv2           May 2019
+
+
+Copyright Notice
+
+   Copyright (c) 2019 IETF Trust and the persons identified as the
+   document authors.  All rights reserved.
+
+   This document is subject to BCP 78 and the IETF Trust's Legal
+   Provisions Relating to IETF Documents
+   (https://trustee.ietf.org/license-info) in effect on the date of
+   publication of this document.  Please review these documents
+   carefully, as they describe your rights and restrictions with respect
+   to this document.  Code Components extracted from this document must
+   include Simplified BSD License text as described in Section 4.e of
+   the Trust Legal Provisions and are provided without warranty as
+   described in the Simplified BSD License.
+
+Table of Contents
+
+   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   3
+     1.1.  Requirements Language . . . . . . . . . . . . . . . . . .   4
+   2.  Applicability . . . . . . . . . . . . . . . . . . . . . . . .   4
+   3.  Protocol Exchange . . . . . . . . . . . . . . . . . . . . . .   5
+     3.1.  Configuration Request . . . . . . . . . . . . . . . . . .   5
+     3.2.  Configuration Reply . . . . . . . . . . . . . . . . . . .   6
+     3.3.  Mapping DNS Servers to Domains  . . . . . . . . . . . . .   7
+     3.4.  Example Exchanges . . . . . . . . . . . . . . . . . . . .   7
+       3.4.1.  Simple Case . . . . . . . . . . . . . . . . . . . . .   7
+       3.4.2.  Requesting Domains and DNSSEC Trust Anchors . . . . .   7
+   4.  Payload Formats . . . . . . . . . . . . . . . . . . . . . . .   9
+     4.1.  INTERNAL_DNS_DOMAIN Configuration Attribute Type Request
+           and Reply . . . . . . . . . . . . . . . . . . . . . . . .   9
+     4.2.  INTERNAL_DNSSEC_TA Configuration Attribute  . . . . . . .   9
+   5.  INTERNAL_DNS_DOMAIN Usage Guidelines  . . . . . . . . . . . .  11
+   6.  INTERNAL_DNSSEC_TA Usage Guidelines . . . . . . . . . . . . .  12
+   7.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .  13
+   8.  Security Considerations . . . . . . . . . . . . . . . . . . .  14
+   9.  References  . . . . . . . . . . . . . . . . . . . . . . . . .  15
+     9.1.  Normative References  . . . . . . . . . . . . . . . . . .  15
+     9.2.  Informative References  . . . . . . . . . . . . . . . . .  16
+   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  16
+
+
+
+
+
+
+
+
+
+
+
+
+Pauly & Wouters              Standards Track                    [Page 2]
+
+RFC 8598            Split DNS Configuration for IKEv2           May 2019
+
+
+1.  Introduction
+
+   Split-tunnel Virtual Private Network (VPN) configurations only send
+   packets with a specific destination IP range, usually chosen from
+   [RFC1918], via the VPN.  All other traffic is not sent via the VPN.
+   This allows an enterprise deployment to offer remote access VPN
+   services without needing to accept and forward all the non-
+   enterprise-related network traffic generated by their remote users.
+   Resources within the enterprise can be accessed by the user via the
+   VPN, while all other traffic generated by the user is not sent over
+   the VPN.
+
+   These internal resources tend to only have internal-only DNS names
+   and require the use of special internal-only DNS servers to get
+   resolved.  Split DNS [RFC2775] is commonly configured as part of
+   split-tunnel VPN configurations to allow remote access users to use
+   special internal-only domain names.
+
+   The IKEv2 protocol [RFC7296] negotiates configuration parameters
+   using Configuration Payload Attribute Types.  This document defines
+   two Configuration Payload Attribute Types that add support for
+   trusted Split DNS domains.
+
+   The INTERNAL_DNS_DOMAIN attribute type is used to convey that the
+   specified DNS domain MUST be resolved using the provided DNS
+   nameserver IP addresses as specified in the INTERNAL_IP4_DNS and
+   INTERNAL_IP6_DNS Configuration Payloads, causing these requests to
+   use the IPsec connection.
+
+   The INTERNAL_DNSSEC_TA attribute type is used to convey a DNSSEC
+   trust anchor for such a domain.  This is required if the external
+   view uses DNSSEC, which would prove the internal view does not exist
+   or would expect a different DNSSEC key on the different versions
+   (internal and external) of the enterprise domain.
+
+   If an INTERNAL_DNS_DOMAIN is sent by the responder, the responder
+   MUST also include one or more INTERNAL_IP4_DNS or INTERNAL_IP6_DNS
+   attributes that contain the IPv4 or IPv6 address of the internal DNS
+   server.
+
+   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".
+
+   Other tunnel-establishment protocols already support the assignment
+   of Split DNS domains.  For example, there are proprietary extensions
+   to IKEv1 that allow a server to assign Split DNS domains to a client.
+
+
+
+Pauly & Wouters              Standards Track                    [Page 3]
+
+RFC 8598            Split DNS Configuration for IKEv2           May 2019
+
+
+   However, the IKEv2 standard does not include a method to configure
+   this option.  This document defines a standard way to negotiate this
+   option for IKEv2.
+
+1.1.  Requirements Language
+
+   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
+   "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
+   "OPTIONAL" in this document are to be interpreted as described in
+   BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all
+   capitals, as shown here.
+
+2.  Applicability
+
+   If the negotiated IPsec connection is not a split-tunnel
+   configuration, the INTERNAL_DNS_DOMAIN and INTERNAL_DNSSEC_TA
+   Configuration Payloads MUST be ignored.  This prevents generic (non-
+   enterprise) VPN services from overriding the public DNS hierarchy,
+   which could lead to malicious overrides of DNS and DNSSEC.
+
+   Such configurations SHOULD instead use only the INTERNAL_IP4_DNS and
+   INTERNAL_IP6_DNS Configuration Payloads to ensure all of the user's
+   DNS traffic is sent through the IPsec connection and does not leak
+   unencrypted information onto the local network, as the local network
+   is often explicitly exempted from IPsec encryption.
+
+   For split-tunnel configurations, an enterprise can require one or
+   more DNS domains to be resolved via internal DNS servers.  This can
+   be a special domain, such as "corp.example.com" for an enterprise
+   that is publicly known to use "example.com".  In this case, the
+   remote user needs to be informed what the internal-only domain names
+   are and what the IP addresses of the internal DNS servers are.  An
+   enterprise can also run a different version of its public domain on
+   its internal network.  In that case, the VPN client is instructed to
+   send DNS queries for the enterprise public domain (e.g.,
+   "example.com") to the internal DNS servers.  A configuration for this
+   deployment scenario is referred to as a Split DNS configuration.
+
+   Split DNS configurations are often preferable to sending all DNS
+   queries to the enterprise.  This allows the remote user to only send
+   DNS queries for the enterprise to the internal DNS servers.  The
+   enterprise remains unaware of all non-enterprise (DNS) activity of
+   the user.  It also allows the enterprise DNS servers to only be
+   configured for the enterprise DNS domains, which removes the legal
+   and technical responsibility of the enterprise to resolve every DNS
+   domain potentially asked for by the remote user.
+
+
+
+
+
+Pauly & Wouters              Standards Track                    [Page 4]
+
+RFC 8598            Split DNS Configuration for IKEv2           May 2019
+
+
+   A client using these Configuration Payloads will be able to request
+   and receive Split DNS configurations using the INTERNAL_DNS_DOMAIN
+   and INTERNAL_DNSSEC_TA configuration attributes.  These attributes
+   MUST be accompanied by one or more INTERNAL_IP4_DNS or
+   INTERNAL_IP6_DNS configuration attributes.  The client device can
+   then use the internal DNS server(s) for any DNS queries within the
+   assigned domains.  DNS queries for other domains SHOULD be sent to
+   the regular DNS service of the client unless it prefers to use the
+   IPsec tunnel for all its DNS queries.  For example, the client could
+   trust the IPsec-provided DNS servers more than the locally provided
+   DNS servers, especially in the case of connecting to unknown or
+   untrusted networks (e.g., coffee shops or hotel networks).  Or the
+   client could prefer the IPsec-based DNS servers because they provide
+   additional features compared to the local DNS servers.
+
+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 INTERNAL_IP4_DNS and INTERNAL_IP6_DNS DNS
+   server configuration attributes will be interpreted as internal DNS
+   servers that can resolve hostnames within the internal domains.
+
+3.1.  Configuration Request
+
+   To indicate support for Split DNS, an initiator includes one or more
+   INTERNAL_DNS_DOMAIN attributes as defined in Section 4 as part of the
+   CFG_REQUEST payload.  If an INTERNAL_DNS_DOMAIN attribute is included
+   in the CFG_REQUEST, the initiator MUST also include one or more
+   INTERNAL_IP4_DNS or INTERNAL_IP6_DNS attributes in the CFG_REQUEST.
+
+   The INTERNAL_DNS_DOMAIN attribute sent by the initiator is usually
+   empty but MAY contain a suggested domain name.
+
+   The absence of INTERNAL_DNS_DOMAIN attributes in the CFG_REQUEST
+   payload indicates that the initiator does not support or is unwilling
+   to accept a Split DNS configuration.
+
+   To indicate support for receiving DNSSEC trust anchors for Split DNS
+   domains, an initiator includes one or more INTERNAL_DNSSEC_TA
+   attributes as defined in Section 4 as part of the CFG_REQUEST
+   payload.  If an INTERNAL_DNSSEC_TA attribute is included in the
+   CFG_REQUEST, the initiator MUST also include one or more
+   INTERNAL_DNS_DOMAIN attributes in the CFG_REQUEST.  If the initiator
+
+
+
+
+
+Pauly & Wouters              Standards Track                    [Page 5]
+
+RFC 8598            Split DNS Configuration for IKEv2           May 2019
+
+
+   includes an INTERNAL_DNSSEC_TA attribute but does not include an
+   INTERNAL_DNS_DOMAIN attribute, the responder MAY still respond with
+   both INTERNAL_DNSSEC_TA and INTERNAL_DNS_DOMAIN attributes.
+
+   An initiator MAY convey its current DNSSEC trust anchors for the
+   domain specified in the INTERNAL_DNS_DOMAIN attribute.  A responder
+   can use this information to determine that it does not need to send a
+   different trust anchor.  If the initiator does not wish to convey
+   this information, it MUST use a length of 0.
+
+   The absence of INTERNAL_DNSSEC_TA attributes in the CFG_REQUEST
+   payload indicates that the initiator does not support or is unwilling
+   to accept the DNSSEC trust anchor configuration.
+
+3.2.  Configuration Reply
+
+   Responders MAY send one or more INTERNAL_DNS_DOMAIN attributes in
+   their CFG_REPLY payload.  If an INTERNAL_DNS_DOMAIN attribute is
+   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
+   CFG_REPLY.  These DNS server configurations are necessary to define
+   which servers can receive queries for hostnames in internal domains.
+   If the CFG_REQUEST included an INTERNAL_DNS_DOMAIN attribute but the
+   CFG_REPLY does not include an INTERNAL_DNS_DOMAIN attribute, the
+   initiator MUST behave as if Split DNS configurations are not
+   supported by the server, unless the initiator has been configured
+   with local policy to define a set of Split DNS domains to use by
+   default.
+
+   Each INTERNAL_DNS_DOMAIN represents a domain that the DNS server
+   addresses listed in INTERNAL_IP4_DNS and INTERNAL_IP6_DNS can
+   resolve.
+
+   If the CFG_REQUEST included INTERNAL_DNS_DOMAIN attributes with non-
+   zero lengths, the content MAY be ignored or be interpreted as a
+   suggestion by the responder.
+
+   For each DNS domain specified in an INTERNAL_DNS_DOMAIN attribute,
+   one or more INTERNAL_DNSSEC_TA attributes MAY be included by the
+   responder.  This attribute lists the corresponding internal DNSSEC
+   trust anchor information of a DS record (see [RFC4034]).  The
+   INTERNAL_DNSSEC_TA attribute MUST immediately follow the
+   INTERNAL_DNS_DOMAIN attribute that it applies to.
+
+
+
+
+
+
+
+
+Pauly & Wouters              Standards Track                    [Page 6]
+
+RFC 8598            Split DNS Configuration for IKEv2           May 2019
+
+
+3.3.  Mapping DNS Servers to Domains
+
+   All DNS servers provided in the CFG_REPLY MUST support resolving
+   hostnames within all INTERNAL_DNS_DOMAIN domains.  In other words,
+   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
+   INTERNAL_IP4_DNS and INTERNAL_IP6_DNS attributes.
+
+3.4.  Example Exchanges
+
+3.4.1.  Simple Case
+
+   In this example exchange, the initiator requests INTERNAL_IP4_DNS,
+   INTERNAL_IP6_DNS, and INTERNAL_DNS_DOMAIN attributes in the
+   CFG_REQUEST but does not specify any value for either.  This
+   indicates that it supports Split DNS but has no preference for which
+   DNS requests will be routed through the tunnel.
+
+   The responder replies with two DNS server addresses and two internal
+   domains, "example.com" and "city.other.test".
+
+   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.
+
+   CP(CFG_REQUEST) =
+     INTERNAL_IP4_ADDRESS()
+     INTERNAL_IP4_DNS()
+     INTERNAL_IP6_ADDRESS()
+     INTERNAL_IP6_DNS()
+     INTERNAL_DNS_DOMAIN()
+
+   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_IP6_ADDRESS(2001:DB8:0:1:2:3:4:5/64)
+     INTERNAL_IP6_DNS(2001:DB8:99:88:77:66:55:44)
+     INTERNAL_DNS_DOMAIN(example.com)
+     INTERNAL_DNS_DOMAIN(city.other.test)
+
+3.4.2.  Requesting Domains and DNSSEC Trust Anchors
+
+   In this example exchange, the initiator requests INTERNAL_IP4_DNS,
+   INTERNAL_IP6_DNS, INTERNAL_DNS_DOMAIN and INTERNAL_DNSSEC_TA
+   attributes in the CFG_REQUEST.
+
+
+
+
+
+
+Pauly & Wouters              Standards Track                    [Page 7]
+
+RFC 8598            Split DNS Configuration for IKEv2           May 2019
+
+
+   Any subsequent DNS queries from the initiator for domains such as
+   "www.example.com" or "city.other.test" 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
+   for the requested domain.  The "example.com" domain has DNSSEC trust
+   anchors that are returned, while the "other.test" domain has no
+   DNSSEC trust anchors.
+
+   CP(CFG_REQUEST) =
+     INTERNAL_IP4_ADDRESS()
+     INTERNAL_IP4_DNS()
+     INTERNAL_IP6_ADDRESS()
+     INTERNAL_IP6_DNS()
+     INTERNAL_DNS_DOMAIN()
+     INTERNAL_DNSSEC_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_IP6_ADDRESS(2001:DB8:0:1:2:3:4:5/64)
+     INTERNAL_IP6_DNS(2001:DB8:99:88:77:66:55:44)
+     INTERNAL_DNS_DOMAIN(example.com)
+     INTERNAL_DNSSEC_TA(43547,8,1,B6225AB2CC613E0DCA7962BDC2342EA4...)
+     INTERNAL_DNSSEC_TA(31406,8,2,F78CF3344F72137235098ECBBD08947C...)
+     INTERNAL_DNS_DOMAIN(city.other.test)
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Pauly & Wouters              Standards Track                    [Page 8]
+
+RFC 8598            Split DNS Configuration for IKEv2           May 2019
+
+
+4.  Payload Formats
+
+   All multi-octet fields representing integers are laid out in big-
+   endian order (also known as "most significant byte first" or "network
+   byte order").
+
+4.1.  INTERNAL_DNS_DOMAIN Configuration Attribute Type Request and Reply
+
+                        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
+   +-+-----------------------------+-------------------------------+
+   |R|         Attribute Type      |            Length             |
+   +-+-----------------------------+-------------------------------+
+   |                                                               |
+   ~             Domain Name in DNS presentation format            ~
+   |                                                               |
+   +---------------------------------------------------------------+
+
+   o  Reserved (1 bit) - Defined in IKEv2 RFC [RFC7296].
+
+   o  Attribute Type (15 bits) - set to value 25 for
+      INTERNAL_DNS_DOMAIN.
+
+   o  Length (2 octets) - Length of 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 format and using an Internationalized Domain Names
+      for Applications (IDNA) A-label [RFC5890].  Implementors need to
+      be careful that this value is not null terminated.
+
+4.2.  INTERNAL_DNSSEC_TA Configuration Attribute
+
+   An INTERNAL_DNSSEC_TA Configuration Attribute can either be empty, or
+   it can contain one trust anchor by containing a non-zero Length with
+   a DNSKEY Key Tag, DNSKEY Algorithm, Digest Type and Digest Data
+   fields.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Pauly & Wouters              Standards Track                    [Page 9]
+
+RFC 8598            Split DNS Configuration for IKEv2           May 2019
+
+
+   An empty INTERNAL_DNSSEC_TA CFG attribute:
+
+                        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
+   +-+-----------------------------+-------------------------------+
+   |R|       Attribute Type        |       Length (set to 0)       |
+   +-+-----------------------------+-------------------------------+
+
+   o  Reserved (1 bit) - Defined in IKEv2 RFC [RFC7296].
+
+   o  Attribute Type (15 bits) - set to value 26 for INTERNAL_DNSSEC_TA.
+
+   o  Length (2 octets) - Set to 0 for an empty attribute.
+
+   A non-empty INTERNAL_DNSSEC_TA CFG attribute:
+
+                        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
+   +-+-----------------------------+-------------------------------+
+   |R|       Attribute Type        |            Length             |
+   +-+-----------------------------+---------------+---------------+
+   |        DNSKEY Key Tag         |  DNSKEY Alg   |  Digest Type  |
+   +-------------------------------+---------------+---------------+
+   |                                                               |
+   ~                         Digest Data                           ~
+   |                                                               |
+   +---------------------------------------------------------------+
+
+   o  Reserved (1 bit) - Defined in IKEv2 RFC [RFC7296].
+
+   o  Attribute Type (15 bits) - set to value 26 for INTERNAL_DNSSEC_TA.
+
+   o  Length (2 octets) - Length of DNSSEC trust anchor data (4 octets
+      plus the length of the Digest Data).
+
+   o  DNSKEY Key Tag (2 octets) - Delegation Signer (DS) Key Tag as
+      specified in Section 5.1 of [RFC4034].
+
+   o  DNSKEY Algorithm (1 octet) - DNSKEY algorithm value from the IANA
+      DNS Security Algorithm Numbers Registry.
+
+   o  Digest Type (1 octet) - DS algorithm value from the IANA
+      Delegation Signer (DS) Resource Record (RR) Type Digest Algorithms
+      Registry.
+
+   o  Digest Data (1 or more octets) - The DNSKEY digest as specified in
+      Section 5.1 of [RFC4034] in presentation format.
+
+
+
+
+Pauly & Wouters              Standards Track                   [Page 10]
+
+RFC 8598            Split DNS Configuration for IKEv2           May 2019
+
+
+   Each INTERNAL_DNSSEC_TA attribute in the CFG_REPLY payload MUST
+   immediately follow a corresponding INTERNAL_DNS_DOMAIN attribute.  As
+   the INTERNAL_DNSSEC_TA format itself does not contain the domain
+   name, it relies on the preceding INTERNAL_DNS_DOMAIN to provide the
+   domain for which it specifies the trust anchor.  Any
+   INTERNAL_DNSSEC_TA attribute that is not immediately preceded by an
+   INTERNAL_DNS_DOMAIN or another INTERNAL_DNSSEC_TA attribute applying
+   to the same domain name MUST be ignored.
+
+5.  INTERNAL_DNS_DOMAIN Usage Guidelines
+
+   If a CFG_REPLY payload contains no INTERNAL_DNS_DOMAIN attributes,
+   the client MAY use the provided INTERNAL_IP4_DNS or INTERNAL_IP6_DNS
+   servers as the default DNS server(s) for all queries.
+
+   If a client is configured by local policy to only accept a limited
+   set of INTERNAL_DNS_DOMAIN values, the client MUST ignore any other
+   INTERNAL_DNS_DOMAIN values.
+
+   For each INTERNAL_DNS_DOMAIN entry in a CFG_REPLY payload that is not
+   prohibited by local policy, the client MUST use the provided
+   INTERNAL_IP4_DNS or INTERNAL_IP6_DNS DNS servers as the only
+   resolvers for the listed domains and its subdomains, and it MUST NOT
+   attempt to resolve the provided DNS domains using its external DNS
+   servers.  Other domain names SHOULD be resolved using some other
+   external DNS resolver(s) that are configured independently from IKE.
+   Queries for these other domains MAY be sent to the internal DNS
+   resolver(s) listed in that CFG_REPLY message, but they have no
+   guarantee of being answered.  For example, if the INTERNAL_DNS_DOMAIN
+   attribute specifies "example.test", then "example.test",
+   "www.example.test", and "mail.eng.example.test" MUST be resolved
+   using the internal DNS resolver(s), but "otherexample.test" and
+   "ple.test" MUST NOT be resolved using the internal resolver and MUST
+   use the system's external DNS resolver(s).
+
+   The initiator SHOULD allow the DNS domains listed in the
+   INTERNAL_DNS_DOMAIN attributes to resolve to special IP address
+   ranges, such as those of [RFC1918], even if the initiator host is
+   otherwise configured to block a DNS answer containing these special
+   IP address ranges.
+
+   When an IKE Security Association (SA) is terminated, the DNS
+   forwarding MUST be unconfigured.  This includes deleting the DNS
+   forwarding rules; flushing all cached data for DNS domains provided
+   by the INTERNAL_DNS_DOMAIN attribute, including negative cache
+   entries; removing any obtained DNSSEC trust anchors from the list of
+   trust anchors; and clearing the outstanding DNS request queue.
+
+
+
+
+Pauly & Wouters              Standards Track                   [Page 11]
+
+RFC 8598            Split DNS Configuration for IKEv2           May 2019
+
+
+   INTERNAL_DNS_DOMAIN attributes SHOULD only be used on split-tunnel
+   configurations where only a subset of traffic is routed into a
+   private remote network using the IPsec connection.  If all traffic is
+   routed over the IPsec connection, the existing global
+   INTERNAL_IP4_DNS and INTERNAL_IP6_DNS can be used without creating
+   specific DNS or DNSSEC exemptions.
+
+6.  INTERNAL_DNSSEC_TA Usage Guidelines
+
+   DNS records can be used to publish specific records containing trust
+   anchors for applications.  The most common record type is the TLSA
+   record specified in [RFC6698].  This DNS record type publishes which
+   Certification Authority (CA) certificate or End Entity (EE)
+   certificate to expect for a certain host name.  These records are
+   protected by DNSSEC and thus are trustable by the application.
+   Whether to trust TLSA records instead of the traditional Web PKI
+   depends on the local policy of the client.  By accepting an
+   INTERNAL_DNSSEC_TA trust anchor via IKE from the remote IKE server,
+   the IPsec client might be allowing the remote IKE server to override
+   the trusted certificates for TLS.  Similar override concerns apply to
+   other public key or fingerprint-based DNS records, such as
+   OPENPGPKEY, SMIMEA, or IPSECKEY records.
+
+   Thus, installing an INTERNAL_DNSSEC_TA trust anchor can be seen as
+   the equivalent of installing an Enterprise CA certificate.  It allows
+   the remote IKE/IPsec server to modify DNS answers, including DNSSEC
+   cryptographic signatures, by overriding existing DNS information with
+   a trust anchor conveyed via IKE and (temporarily) installed on the
+   IKE client.  Of specific concern is the overriding of TLSA records
+   based on [RFC6698], which represents a confirmation or override of an
+   existing Web PKI TLS certificate.  Other DNS record types that convey
+   cryptographic materials (public keys or fingerprints) are OPENPGPKEY,
+   SMIMEA, SSHP, and IPSECKEY records.
+
+   IKE clients willing to accept INTERNAL_DNSSEC_TA attributes MUST use
+   a whitelist of one or more domains that can be updated out of band.
+   IKE clients with an empty whitelist MUST NOT use any
+   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
+   internal or managed domains rather than to generic Internet traffic.
+   The DNS root zone (".") MUST be ignored if it appears in a whitelist.
+   Other generic or public domains, such as Top-Level Domains (TLDs),
+   similarly MUST be ignored if they appear in a whitelist unless the
+   entity actually is the operator of the TLD.  To determine this, an
+
+
+
+Pauly & Wouters              Standards Track                   [Page 12]
+
+RFC 8598            Split DNS Configuration for IKEv2           May 2019
+
+
+   implementation MAY interactively ask the user when a VPN profile is
+   installed or activated to confirm this.  Alternatively, it MAY
+   provide a special override keyword in its provisioning configuration
+   to ensure non-interactive agreement can be achieved only by the party
+   provisioning the VPN client, who presumably is a trusted entity by
+   the end user.  Similarly, an entity might be using a special domain
+   name, such as ".internal", for its internal-only view and might wish
+   to force its provisioning system to accept such a domain in a Split
+   DNS configuration.
+
+   Any updates to this whitelist of domain names MUST happen via
+   explicit human interaction or by a trusted automated provision system
+   to prevent malicious invisible installation of trust anchors in case
+   of an IKE server compromise.
+
+   IKE clients SHOULD accept any INTERNAL_DNSSEC_TA updates for
+   subdomain names of the whitelisted domain names.  For example, if
+   "example.net" is whitelisted, then INTERNAL_DNSSEC_TA received for
+   "antartica.example.net" SHOULD be accepted.
+
+   IKE clients MUST ignore any received INTERNAL_DNSSEC_TA attributes
+   for a Fully Qualified Domain Name (FQDN) for which it did not receive
+   and accept an INTERNAL_DNS_DOMAIN Configuration Payload.
+
+   In most deployment scenarios, the IKE client has an expectation that
+   it is connecting to a specific organization or enterprise using a
+   split-network setup.  A recommended policy would be to only accept
+   INTERNAL_DNSSEC_TA directives from that organization's DNS names.
+   However, this might not be possible in all deployment scenarios, such
+   as one where the IKE server is handing out a number of domains that
+   are not within one parent domain.
+
+7.  IANA Considerations
+
+   This document defines two new IKEv2 Configuration Payload Attribute
+   Types, which are allocated from the "IKEv2 Configuration Payload
+   Attribute Types" namespace.
+
+                                 Multi-
+   Value    Attribute Type       Valued  Length      Reference
+   ------   -------------------  ------  ----------  ---------------
+   25       INTERNAL_DNS_DOMAIN   YES     0 or more  RFC 8598
+   26       INTERNAL_DNSSEC_TA    YES     0 or more  RFC 8598
+
+                                 Figure 1
+
+
+
+
+
+
+Pauly & Wouters              Standards Track                   [Page 13]
+
+RFC 8598            Split DNS Configuration for IKEv2           May 2019
+
+
+8.  Security Considerations
+
+   As stated in Section 2, if the negotiated IPsec connection is not a
+   split-tunnel configuration, the INTERNAL_DNS_DOMAIN and
+   INTERNAL_DNSSEC_TA Configuration Payloads MUST be ignored.
+   Otherwise, generic VPN service providers could maliciously override
+   DNSSEC-based trust anchors of public DNS domains.
+
+   An initiator MUST only accept INTERNAL_DNSSEC_TAs for which it has a
+   whitelist, since this mechanism allows the credential used to
+   authenticate an IKEv2 association to be leveraged into authenticating
+   credentials for other connections.  Initiators should ensure that
+   they have sufficient trust in the responder when using this
+   mechanism.  An initiator MAY treat a received INTERNAL_DNSSEC_TA for
+   a non-whitelisted domain as a signal to update the whitelist via a
+   non-IKE provisioning mechanism.  See Section 6 for additional
+   security considerations for DNSSEC trust anchors.
+
+   The use of Split DNS configurations assigned by an IKEv2 responder is
+   predicated on the trust established during IKE SA authentication.
+   However, if IKEv2 is being negotiated with an anonymous or unknown
+   endpoint (such as for Opportunistic Security [RFC7435]), the
+   initiator MUST ignore Split DNS configurations assigned by the
+   responder.
+
+   If a host connected to an authenticated IKE peer is connecting to
+   another IKE peer that attempts to claim the same domain via the
+   INTERNAL_DNS_DOMAIN attribute, the IKE connection SHOULD only process
+   the DNS information if the two connections are part of the same
+   logical entity.  Otherwise, the client SHOULD refuse the DNS
+   information and potentially warn the end user.  For example, if a VPN
+   profile for "Example Corporation" is installed that provides two
+   IPsec connections, one covering 192.168.100.0/24 and one covering
+   10.13.14.0/24, it could be that both connections negotiate the same
+   INTERNAL_DNS_DOMAIN and INTERNAL_DNSSEC_TA values.  Since these are
+   part of the same remote organization (or provisioning profile), the
+   Configuration Payloads can be used.  However, if a user installs two
+   VPN profiles from two different unrelated independent entities, both
+   could be configured to use the same domain -- for example,
+   ".internal".  These two connections MUST NOT be allowed to be active
+   at the same time.
+
+   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
+
+
+
+
+Pauly & Wouters              Standards Track                   [Page 14]
+
+RFC 8598            Split DNS Configuration for IKEv2           May 2019
+
+
+   public DNS view for which it has not explicitly requested such
+   delegation, i.e., for which it has not used an INTERNAL_DNS_DOMAIN
+   request to specify the domain.
+
+   Deployments that configure INTERNAL_DNS_DOMAIN domains should pay
+   close attention to their use of indirect reference RRtypes in their
+   internal-only domain names.  Examples of such RRtypes are NS, CNAME,
+   DNAME, MX, or SRV records.  For example, if the MX record for
+   "internal.example.com" points to "mx.internal.example.net", then both
+   "internal.example.com" and "internal.example.net" should be sent
+   using an INTERNAL_DNS_DOMAIN Configuration Payload.
+
+   IKE clients MAY want to require whitelisted domains for Top-Level
+   Domains (TLDs) and Second-Level Domains (SLDs) to further prevent
+   malicious DNS redirections for well-known domains.  This prevents
+   users from unknowingly giving DNS queries to third parties.  This is
+   even more important if those well-known domains are not deploying
+   DNSSEC, as the VPN service provider could then even modify the DNS
+   answers without detection.
+
+   The content of INTERNAL_DNS_DOMAIN and INTERNAL_DNSSEC_TA may be
+   passed to another (DNS) program for processing.  As with any network
+   input, the content SHOULD be considered untrusted and handled
+   accordingly.
+
+9.  References
+
+9.1.  Normative References
+
+   [RFC1918]  Rekhter, Y., Moskowitz, B., Karrenberg, D., de Groot, G.,
+              and E. Lear, "Address Allocation for Private Internets",
+              BCP 5, RFC 1918, DOI 10.17487/RFC1918, February 1996,
+              <https://www.rfc-editor.org/info/rfc1918>.
+
+   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
+              Requirement Levels", BCP 14, RFC 2119,
+              DOI 10.17487/RFC2119, March 1997,
+              <https://www.rfc-editor.org/info/rfc2119>.
+
+   [RFC4034]  Arends, R., Austein, R., Larson, M., Massey, D., and S.
+              Rose, "Resource Records for the DNS Security Extensions",
+              RFC 4034, DOI 10.17487/RFC4034, March 2005,
+              <https://www.rfc-editor.org/info/rfc4034>.
+
+   [RFC5890]  Klensin, J., "Internationalized Domain Names for
+              Applications (IDNA): Definitions and Document Framework",
+              RFC 5890, DOI 10.17487/RFC5890, August 2010,
+              <https://www.rfc-editor.org/info/rfc5890>.
+
+
+
+Pauly & Wouters              Standards Track                   [Page 15]
+
+RFC 8598            Split DNS Configuration for IKEv2           May 2019
+
+
+   [RFC6698]  Hoffman, P. and J. Schlyter, "The DNS-Based Authentication
+              of Named Entities (DANE) Transport Layer Security (TLS)
+              Protocol: TLSA", RFC 6698, DOI 10.17487/RFC6698, August
+              2012, <https://www.rfc-editor.org/info/rfc6698>.
+
+   [RFC7296]  Kaufman, C., Hoffman, P., Nir, Y., Eronen, P., and T.
+              Kivinen, "Internet Key Exchange Protocol Version 2
+              (IKEv2)", STD 79, RFC 7296, DOI 10.17487/RFC7296, October
+              2014, <https://www.rfc-editor.org/info/rfc7296>.
+
+   [RFC8174]  Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
+              2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
+              May 2017, <https://www.rfc-editor.org/info/rfc8174>.
+
+9.2.  Informative References
+
+   [RFC2775]  Carpenter, B., "Internet Transparency", RFC 2775,
+              DOI 10.17487/RFC2775, February 2000,
+              <https://www.rfc-editor.org/info/rfc2775>.
+
+   [RFC7435]  Dukhovni, V., "Opportunistic Security: Some Protection
+              Most of the Time", RFC 7435, DOI 10.17487/RFC7435,
+              December 2014, <https://www.rfc-editor.org/info/rfc7435>.
+
+Authors' Addresses
+
+   Tommy Pauly
+   Apple Inc.
+   One Apple Park Way
+   Cupertino, California  95014
+   United States of America
+
+   Email: tpauly@apple.com
+
+
+   Paul Wouters
+   Red Hat
+
+   Email: pwouters@redhat.com
+
+
+
+
+
+
+
+
+
+
+
+
+Pauly & Wouters              Standards Track                   [Page 16]
+