--- 1/draft-ietf-ipsecme-split-dns-02.txt 2017-11-11 23:13:20.534549921 -0800 +++ 2/draft-ietf-ipsecme-split-dns-03.txt 2017-11-11 23:13:20.558550485 -0800 @@ -1,19 +1,19 @@ Network T. Pauly Internet-Draft Apple Inc. Intended status: Standards Track P. Wouters -Expires: January 30, 2018 Red Hat - July 29, 2017 +Expires: May 16, 2018 Red Hat + November 12, 2017 Split DNS Configuration for IKEv2 - draft-ietf-ipsecme-split-dns-02 + draft-ietf-ipsecme-split-dns-03 Abstract This document defines two Configuration Payload Attribute Types for the IKEv2 protocol that add support for private DNS domains. These domains should 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". @@ -25,21 +25,21 @@ 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/. 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 30, 2018. + This Internet-Draft will expire on May 16, 2018. Copyright Notice Copyright (c) 2017 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 publication of this document. Please review these documents @@ -137,46 +137,45 @@ 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 existing 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 more - 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 SHOULD also include one or - more INTERNAL_IP4_DNS and INTERNAL_IP6_DNS attributes in the - CFG_REQUEST. + 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 SHOULD also include one or more + INTERNAL_IP4_DNS and 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 Split DNS configuration. To indicate support for DNSSEC, an initiator includes one or more - INTERNAL_DNS_TA attributes as defined in Section 4 as part of the - CFG_REQUEST payload. If an INTERNAL_DNS_TA attriute is included in - the CFG_REQUEST, the initiator SHOULD also include one or more + INTERNAL_DNSSEC_TA attributes as defined in Section 4 as part of the + CFG_REQUEST payload. If an INTERNAL_DNSSEC_TA attriute is included + in the CFG_REQUEST, the initiator SHOULD also include one or more INTERNAL_DNS_DOMAIN attributes in the CFG_REQUEST. An initiator MAY convey its current DNSSEC trust anchors for the domain specified in the INTERNAL_DNS_DOMAIN attribute. If it does not wish to convey this information, it MUST use a length of 0. - The absence of INTERNAL_DNS_TA attributes in the CFG_REQUEST payload - indicates that the initiator does not support or is unwilling to - accept DNSSEC trust anchor configuration. + The absence of INTERNAL_DNSSEC_TA attributes in the CFG_REQUEST + payload indicates that the initiator does not support or is unwilling + to accept 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 should receive queries for hostnames in internal domains. If the CFG_REQUEST included an INTERNAL_DNS_DOMAIN @@ -231,45 +230,45 @@ 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_DNS_DOMAIN(example.com) INTERNAL_DNS_DOMAIN(city.other.com) 3.4.2. Requesting Domains and DNSSEC trust anchors In this example exchange, the initiator requests INTERNAL_IP4_DNS, - INTERNAL_DNS_DOMAIN and INTERNAL_DNS_TA attributess in the + INTERNAL_DNS_DOMAIN and INTERNAL_DNSSEC_TA attributess in the CFG_REQUEST Any subsequent DNS queries from the initiator for domains such as "www.example.com" or "city.other.com" 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 would the requested domain. the "example.com" dommain has DNSSEC trust anchors that are returned, while the "other.com" domain has no DNSSEC trust anchors CP(CFG_REQUEST) = INTERNAL_IP4_ADDRESS() INTERNAL_IP4_DNS() INTERNAL_DNS_DOMAIN() - INTERNAL_DNS_TA() + 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_DNS_DOMAIN(example.com) - INTERNAL_DNS_TA(43547,8,1,B6225AB2CC613E0DCA7962BDC2342EA4F1B56083) - INTERNAL_DNS_TA(31406,8,2,F78CF3344F72137235098ECBBD08947C2C90....) + INTERNAL_DNSSEC_TA(43547,8,1,B6225AB2CC613E0DCA7962BDC2342EA4F1B56083) + INTERNAL_DNSSEC_TA(31406,8,2,F78CF3344F72137235098ECBBD08947C2C90....) INTERNAL_DNS_DOMAIN(city.other.com) 4. Payload Formats 4.1. INTERNAL_DNS_DOMAIN Configuration Attribute Type 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 | @@ -281,21 +280,22 @@ o Reserved (1 bit) - Defined in IKEv2 RFC [RFC7296]. o Attribute Type (15 bits) 25 - INTERNAL_DNS_DOMAIN. o Length (2 octets, unsigned integer) - 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 optionally using IDNA [RFC5890] for Internationalized - Domain Names. The value is NOT null-terminated. + Domain Names. Implementors need to be careful that this value is + not null-terminated. 4.2. INTERNAL_DNSSEC_TA Configuration 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 | +-+-----------------------------+---------------+---------------+ | Key Tag | Algorithm | Digest Type | +-------------------------------+---------------+---------------+ @@ -307,28 +307,29 @@ o Reserved (1 bit) - Defined in IKEv2 RFC [RFC7296]. o Attribute Type (15 bits) [TBD IANA] - INTERNAL_DNSSEC_TA. o Length (2 octets, unsigned integer) - Length of DNSSEC Trust Anchor data. o Key Tag value (0 or 2 octets, unsigned integer) - Key Tag as specified in [RFC4034] Section 5.1 - o DNSKEY algorithm (0 or 1 octet) - Value from the IANA DNS Security - Algorithm Numbers Registry + o Algorithm (0 or 1 octet) - DNSKEY algorithm value from the IANA + DNS Security Algorithm Numbers Registry - o DS algorithm (0 or 1 octet) - Value from the IANA Delegation - Signer (DS) Resource Record (RR) Type Digest Algorithms Registry + o DS algorithm (0 or 1 octet) - DS algorithm value from the IANA + Delegation Signer (DS) Resource Record (RR) Type Digest Algorithms + Registry - o Digest (0 or more octets) - The digest as specified in [RFC4034] - Section 5.1 in presentation format. + o Digest (0 or more octets) - The DNSKEY digest as specified in + [RFC4034] Section 5.1 in presentation format. 5. Split DNS 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 number of INTERNAL_DNS_DOMAIN values, the client MUST ignore any other INTERNAL_DNS_DOMAIN values. @@ -389,23 +390,23 @@ 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 enduser. - INTERNAL_DNSSEC_TA directives MUST immediately follow an - INTERNAL_DNS_DOMAIN directive. As the INTERNAL_DNSSEC_TA format - itself does not contain the domain name, it relies on the preceding + INTERNAL_DNSSEC_TA payloads MUST immediately follow an + INTERNAL_DNS_DOMAIN payload. 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. 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 public DNS view, for which it has not explicitely requested such deletation by specifying the domain specifically using a @@ -439,55 +440,55 @@ Figure 1 8. References 8.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, - . + . [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, . + 2014, . 8.2. Informative References [RFC2775] Carpenter, B., "Internet Transparency", RFC 2775, - DOI 10.17487/RFC2775, February 2000, - . + DOI 10.17487/RFC2775, February 2000, . [RFC6761] Cheshire, S. and M. Krochmal, "Special-Use Domain Names", RFC 6761, DOI 10.17487/RFC6761, February 2013, - . + . [RFC7435] Dukhovni, V., "Opportunistic Security: Some Protection Most of the Time", RFC 7435, DOI 10.17487/RFC7435, - December 2014, . + December 2014, . Authors' Addresses Tommy Pauly Apple Inc. 1 Infinite Loop Cupertino, California 95014 US Email: tpauly@apple.com