--- 1/draft-ietf-ipsecme-split-dns-09.txt 2018-07-18 14:13:08.682648669 -0700 +++ 2/draft-ietf-ipsecme-split-dns-10.txt 2018-07-18 14:13:08.714649446 -0700 @@ -1,54 +1,54 @@ Network T. Pauly Internet-Draft Apple Inc. Intended status: Standards Track P. Wouters Expires: January 19, 2019 Red Hat July 18, 2018 Split DNS Configuration for IKEv2 - draft-ietf-ipsecme-split-dns-09 + draft-ietf-ipsecme-split-dns-10 Abstract This document defines two Configuration Payload Attribute Types for the IKEv2 protocol that add support for private DNS domains. These domains are intended to be resolved using DNS servers reachable through an IPsec connection, while leaving all other DNS resolution unchanged. This approach of resolving a subset of domains using non- public DNS servers is referred to as "Split DNS". Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute 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 and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on January 19, 2019. Copyright Notice Copyright (c) 2018 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 - (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 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 . . . . . . . . . . . . . . . . . . . . . . . . 2 @@ -429,24 +429,30 @@ certificate. It allows the remote IKE/IPsec server to modify DNS answers including its DNSSEC cryptographic signatures by overriding existing DNS information with trust anchor conveyed via IKE and (temporarilly) installed on the IKE client. Of specific concern is the overriding of [RFC6698] based TLSA records, which represent a confirmation or override of an existing WebPKI TLS certificate. Other DNS record types that convey cryptographic materials (public keys or fingerprints) are OPENPGPKEY, SMIMEA, SSHP and IPSECKEY records. - IKE clients MUST use a preconfigured whitelist of domain names for - which it will allow INTERNAL_DNSSEC_TA updates. + IKE clients MUST use a preconfigured whitelist of one or more domain + 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 explicit human interaction to prevent invisible installation of trust anchors. 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. @@ -520,22 +526,22 @@ 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, . [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, - DOI 10.17487/RFC2119, March 1997, . + DOI 10.17487/RFC2119, March 1997, + . [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, . [RFC5890] Klensin, J., "Internationalized Domain Names for Applications (IDNA): Definitions and Document Framework", RFC 5890, DOI 10.17487/RFC5890, August 2010, . @@ -550,22 +556,22 @@ (IKEv2)", STD 79, RFC 7296, DOI 10.17487/RFC7296, October 2014, . [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, . 9.2. Informative References [RFC2775] Carpenter, B., "Internet Transparency", RFC 2775, - DOI 10.17487/RFC2775, February 2000, . + DOI 10.17487/RFC2775, February 2000, + . [RFC7435] Dukhovni, V., "Opportunistic Security: Some Protection Most of the Time", RFC 7435, DOI 10.17487/RFC7435, December 2014, . Authors' Addresses Tommy Pauly Apple Inc. One Apple Park Way