idnits 2.17.1 draft-pauly-ipsecme-split-dns-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (September 24, 2015) is 3138 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'TBD IANA' is mentioned on line 278, but not defined == Missing Reference: 'TBD' is mentioned on line 386, but not defined Summary: 0 errors (**), 0 flaws (~~), 3 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network T. Pauly 3 Internet-Draft Apple Inc. 4 Intended status: Standards Track P. Wouters 5 Expires: March 27, 2016 Red Hat 6 September 24, 2015 8 Split-DNS Configuration for IKEv2 9 draft-pauly-ipsecme-split-dns-00 11 Abstract 13 This document defines two new Configuration Payload Attribute Types 14 for the IKEv2 protocol that together define a set of private DNS 15 domains which should be resolved by DNS servers reachable through an 16 IPsec connection, while leaving all other DNS resolution unchanged. 17 This allows for split-DNS views for multiple domains and includes 18 support for private DNSSEC trust anchors. The information obtained 19 via the new attribute types can be used to reconfigure a locally 20 running DNS server with DNS forwarding for specific private domains. 22 Status of This Memo 24 This Internet-Draft is submitted in full conformance with the 25 provisions of BCP 78 and BCP 79. 27 Internet-Drafts are working documents of the Internet Engineering 28 Task Force (IETF). Note that other groups may also distribute 29 working documents as Internet-Drafts. The list of current Internet- 30 Drafts is at http://datatracker.ietf.org/drafts/current/. 32 Internet-Drafts are draft documents valid for a maximum of six months 33 and may be updated, replaced, or obsoleted by other documents at any 34 time. It is inappropriate to use Internet-Drafts as reference 35 material or to cite them other than as "work in progress." 37 This Internet-Draft will expire on March 27, 2016. 39 Copyright Notice 41 Copyright (c) 2015 IETF Trust and the persons identified as the 42 document authors. All rights reserved. 44 This document is subject to BCP 78 and the IETF Trust's Legal 45 Provisions Relating to IETF Documents 46 (http://trustee.ietf.org/license-info) in effect on the date of 47 publication of this document. Please review these documents 48 carefully, as they describe your rights and restrictions with respect 49 to this document. Code Components extracted from this document must 50 include Simplified BSD License text as described in Section 4.e of 51 the Trust Legal Provisions and are provided without warranty as 52 described in the Simplified BSD License. 54 Table of Contents 56 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 57 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3 58 2. Background . . . . . . . . . . . . . . . . . . . . . . . . . 3 59 3. Protocol Exchange . . . . . . . . . . . . . . . . . . . . . . 3 60 3.1. Configuration Request . . . . . . . . . . . . . . . . . . 3 61 3.2. Configuration Reply . . . . . . . . . . . . . . . . . . . 4 62 3.3. Mapping DNS Servers to Domains . . . . . . . . . . . . . 4 63 3.4. Example Exchanges . . . . . . . . . . . . . . . . . . . . 4 64 3.4.1. Simple Case . . . . . . . . . . . . . . . . . . . . . 4 65 3.4.2. Requesting Limited Domains . . . . . . . . . . . . . 5 66 4. Payload Formats . . . . . . . . . . . . . . . . . . . . . . . 6 67 4.1. INTERNAL_DNS_DOMAIN Configuration Attribute Type . . . . 6 68 4.2. INTERNAL_DNSSEC_TA Configuration Attribute . . . . . . . 6 69 5. Split-DNS Usage Guidelines . . . . . . . . . . . . . . . . . 7 70 6. Security Considerations . . . . . . . . . . . . . . . . . . . 8 71 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 72 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 9 73 8.1. Normative References . . . . . . . . . . . . . . . . . . 9 74 8.2. Informative References . . . . . . . . . . . . . . . . . 9 75 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 10 77 1. Introduction 79 The Internet Key Exchange protocol version 2 [RFC7296] negotiates 80 configuration parameters using Configuration Payload Attribute Types. 81 This document adds two new Configuration Payload Attribute Types to 82 support trusted split-DNS domains. The INTERNAL_DNS_DOMAIN attribute 83 type is used to convey one or more local DNS domains. The 84 INTERNAL_DNSSEC_TA attribute type is used to convey DNSSEC trust 85 anchors for those domains. When only a subset of traffic is routed 86 into a private network using an IPSec SA, this Configuration Payload 87 option can be used to define which private domains should be resolved 88 through the IPSec connection without affecting the client's global 89 DNS resolution. For the purposes of this document, DNS servers 90 accessible through an IPsec connection will be referred to as 91 "internal DNS servers", and other DNS servers will be referred to as 92 "external DNS servers". 94 A client using these configuration payloads will be able to request 95 and receive split-DNS configurations using the INTERNAL_DNS_DOMAIN 96 and INTERNAL_DNSSEC_TA configuration attributes. The client can use 97 the internal DNS server(s) for any DNS queries within the assigned 98 domains, while routing other DNS queries to its regular external DNS 99 server. 101 1.1. Requirements Language 103 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 104 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 105 document are to be interpreted as described in RFC 2119 [RFC2119]. 107 2. Background 109 Split-DNS is a common configuration for enterprise VPN deployments, 110 in which only one or a few private DNS domains are accessible and 111 resolvable via an IPsec based VPN connection. 113 Other tunnel-establishment protocols already support the assignment 114 of split-DNS domains. For example, there are proprietary extensions 115 to IKEv1 that allow a server to assign split-DNS domains to a client. 116 However, the IKEv2 standard does not include a method to configure 117 this option. This document defines a standard way to negotiate this 118 option for IKEv2. 120 3. Protocol Exchange 122 3.1. Configuration Request 124 To indicate support for split-DNS, initiators sending a CFG_REQUEST 125 payload MAY include one or more of the INTERNAL_DNS_DOMAIN 126 configuration attribute in their configuration payloads. See 127 Section 4 for details on the payload format. If an 128 INTERNAL_DNS_DOMAIN attribute is included in the CFG_REQUEST, the 129 initiator SHOULD also include one or both of the INTERNAL_IP4_DNS and 130 INTERNAL_IP6_DNS attributes in its CFG_REQUEST. 132 If the attribute length is zero, then the initiator is only 133 requesting that the attribute be assigned, without restricting the 134 subdomains that it will accept. 136 If the attribute length is non-zero, it contains a single DNS domain 137 . The initiator is indicating that it will allow this domain and its 138 sub-domains to be resolved over the IPsec connection. The list of 139 INTERNAL_DNS_DOMAIN attributes in the CFG_REQUEST defines the full 140 set of domains the intiator is willing to resolve over the tunnel. 142 3.2. Configuration Reply 144 Responders MAY send one or more INTERNAL_DNS_DOMAIN configuration 145 attributes in their CFG_REPLY payload if the CFG_REQUEST contained at 146 least one INTERNAL_DNS_DOMAIN configuration attribute. If the 147 CFG_REQUEST did not contain an INTERNAL_DNS_DOMAIN configuration 148 attribute, the responder MUST NOT include an INTERNAL_DNS_DOMAIN 149 configuration attribute in the CFG_REPLY. If an INTERNAL_DNS_DOMAIN 150 configuration attribute is included in the CFG_REPLY, the responder 151 SHOULD also include one or both of the INTERNAL_IP4_DNS and 152 INTERNAL_IP6_DNS configuration attributes in its CFG_REPLY. If the 153 CFG_REQUEST included an INTERNAL_DNS_DOMAIN configuration attribute, 154 but the CFG_REPLY does include an INTERNAL_DNS_DOMAIN attribute, the 155 initiator should behave as if split-DNS configurations are not 156 supported by the server. 158 Each INTERNAL_DNS_DOMAIN represents a domain that the DNS servers 159 address listed in INTERNAL_IP4_DNS and INTERNAL_IP6_DNS can resolve. 161 If the CFG_REQUEST included INTERNAL_DNS_DOMAIN attributes with non- 162 zero lengths, the CFG_REPLY MUST NOT assign any domains in its 163 INTERNAL_DNS_DOMAIN attributes that are not contained within the 164 requested domains. The initiator SHOULD ignore any domains beyond 165 its requested list. 167 For each DNS domain specified in an INTERNAL_DNS_DOMAIN configuration 168 attribute, an INTERNAL_DNSSEC_TA configuration attribute may be 169 included by the responder. This attribute lists the corresponding 170 DSSNEC trust anchor in the presentation format of a DS record as 171 specified in [RFC4034]. 173 3.3. Mapping DNS Servers to Domains 175 All DNS servers provided in the CFG_REPLY MUST support all domains. 176 The INTERNAL_DNS_DOMAIN attributes in a CFG_REPLY payload form a 177 single list of split-DNS domains, that apply to the entire list of 178 INTERNAL_IP4_DNS and INTERNAL_IP6_DNS attributes. 180 3.4. Example Exchanges 182 3.4.1. Simple Case 184 In this example exchange, the initiator requests INTERNAL_IP4_DNS and 185 INTERNAL_DNS_DOMAIN attributes in its CFG_REQUEST, but does not 186 specify any value for either. This indicates that it supports split- 187 DNS, but has no preference for which DNS requests should be routed 188 through the tunnel. 190 The responder replies with two DNS server addresses, and one internal 191 domain, "example.com". 193 Any subsequent DNS queries from the initiator for domains such as 194 "www.example.com" should use 198.51.100.2 or 198.51.100.4 to resolve. 196 CP(CFG_REQUEST) = 197 INTERNAL_IP4_ADDRESS() 198 INTERNAL_IP4_DNS() 199 INTERNAL_DNS_DOMAIN() 201 CP(CFG_REPLY) = 202 INTERNAL_IP4_ADDRESS(198.51.100.234) 203 INTERNAL_IP4_DNS(198.51.100.2) 204 INTERNAL_IP4_DNS(198.51.100.4) 205 INTERNAL_DNS_DOMAIN(example.com) 207 3.4.2. Requesting Limited Domains 209 In this example exchange, the initiator requests INTERNAL_IP4_DNS and 210 INTERNAL_DNS_DOMAIN attributes in its CFG_REQUEST, specifically 211 requesting only "example.com" and "other.com". The responder replies 212 with two DNS server addresses, 198.51.100.2 and 198.51.100.4, and two 213 domains, "example.com" and "city.other.com". Note that one of the 214 domains in the CFG_REPLY, "city.other.com", is a subset of the 215 requested domain, "other.com". This indicates that hosts within 216 "other.com" that are not within "city.other.com" should be resolved 217 using an external DNS server. The CFG_REPLY would not be allowed to 218 respond with "com" or "example.net", however, since these were 219 contained within the limited set of requested domains. 221 Any subsequent DNS queries from the initiator for domains such as 222 "www.example.com" or "city.other.com" should use 198.51.100.2 or 223 198.51.100.4 to resolve. 225 CP(CFG_REQUEST) = 226 INTERNAL_IP4_ADDRESS() 227 INTERNAL_IP4_DNS() 228 INTERNAL_DNS_DOMAIN(example.com) 229 INTERNAL_DNS_DOMAIN(other.com) 231 CP(CFG_REPLY) = 232 INTERNAL_IP4_ADDRESS(198.51.100.234) 233 INTERNAL_IP4_DNS(198.51.100.2) 234 INTERNAL_IP4_DNS(198.51.100.4) 235 INTERNAL_DNS_DOMAIN(example.com) 236 INTERNAL_DNS_DOMAIN(city.other.com) 238 4. Payload Formats 240 4.1. INTERNAL_DNS_DOMAIN Configuration Attribute Type 242 1 2 3 243 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 244 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 245 |R| Attribute Type | Length | 246 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 247 | | 248 ~ Domain Name ~ 249 | | 250 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 252 o Reserved (1 bit) - Defined in IKEv2 RFC [RFC7296]. 254 o Attribute Type (15 bits) [TBD IANA] - INTERNAL_DNS_DOMAIN. 256 o Length (2 octets, unsigned integer) - Length of domain name. 258 o Domain Name (0 or more octets) - A domain or subdomain used for 259 split-DNS rules, such as example.com. This is a string of ASCII 260 characters with labels separated by dots, with no trailing dot, 261 using IDNA [RFC5890] for non-ASCII DNS domains. The value is NOT 262 null-terminated. 264 4.2. INTERNAL_DNSSEC_TA Configuration Attribute 266 1 2 3 267 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 268 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 269 |R| Attribute Type | Length | 270 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 271 | | 272 ~ DNSSEC TRUST ANCHOR ~ 273 | | 274 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 276 o Reserved (1 bit) - Defined in IKEv2 RFC [RFC7296]. 278 o Attribute Type (15 bits) [TBD IANA] - INTERNAL_DNSSEC_TA. 280 o Length (2 octets, unsigned integer) - Length of DNSSEC Trust 281 Anchor data. 283 o DNSSEC Trust anchor (multiple octets) - The presentation format of 284 one DS record as specified in [RFC4034]. The TTL value MAY be 285 omited and when present MUST be ignored. The domain name is 286 specified as a Fully Qualified Domain Name (FQDN) - irrespective 287 of the presence of a trailing dot, and consits of a string of 288 ASCII characters with labels separated by dots and uses IDNA 289 [RFC5890] for non-ASCII DNS domains. The value is NOT null- 290 terminated. 292 5. Split-DNS Usage Guidelines 294 If a CFG_REPLY payload contains no INTERNAL_DNS_DOMAIN configuration 295 attributes, the client MAY use the provided INTERNAL_IP4_DNS or 296 INTERNAL_IP6_DNS servers as the default DNS server(s) for all 297 queries. 299 For each INTERNAL_DNS_DOMAIN entry in a CFG_REPLY payload, the client 300 SHOULD use the provided INTERNAL_IP4_DNS or INTERNAL_IP6_DNS DNS 301 servers as the only resolvers for the listed domains and its sub- 302 domains and it SHOULD NOT attempt to resolve the provided DNS domains 303 using its external DNS servers. 305 If the initiator host is configured to block DNS answers containing 306 IP addresses from special IP address ranges such as those of 307 [RFC1918], the initiator SHOULD allow the DNS domains listed in the 308 INTERNAL_DNS_DOMAIN configuration attributes to contain these IP 309 addresses. 311 If a CFG_REPLY contains one or more INTERNAL_DNS_DOMAIN configuration 312 attributes, the client SHOULD configure its DNS resolver to resolve 313 those domains and all their subdomains using only the DNS resolver(s) 314 listed in that CFG_REPLY message. If those resolvers fail, those 315 names SHOULD NOT be resolved using any other DNS resolvers. All 316 other domain names SHOULD be resolved using some other external DNS 317 resolver(s), configured independently, and SHOULD NOT be sent to the 318 internal DNS resolver(s) listed in that CFG_REPLY message. For 319 example, if the INTERNAL_DNS_DOMAIN configuration attribute specifies 320 "example.com", then "example.com", "www.example.com" and 321 "mail.eng.example.com" SHOULD be resolved using the internal DNS 322 resolver(s), but "anotherexample.com" and "ample.com" SHOULD be 323 resolved using the system's external DNS resolver(s). 325 An initiator MAY ignore INTERNAL_DNS_DOMAIN configuration attributes 326 containing domains that are designated Special Use Domain Names in 327 [RFC6761], such as "local", "localhost", "invalid", etc. Although it 328 may explicitly wish to support some Special Use Domain Names, for 329 example "onion" [I-D.ietf-dnsop-onion-tld]. 331 When an IPsec connection is terminated, the DNS forwarding must be 332 unconfigured. The DNS forwarding itself MUST be be deleted. All 333 cached data of the INTERNAL_DNS_DOMAIN provided DNS domainis MUST be 334 flushed. This includes negative cache entries. Obtained DNSSEC 335 trust anchors MUST be removed from the list of trust anchors. The 336 outstanding DNS request queue MAY be cleared. 338 A domain that is served via INTERNAL_DNS_DOMAIN MUST NOT have 339 indirect references to DNS records that point to other split-DNS 340 domains that are not served via INTERNAL_DNS_DOMAIN configuration 341 attributes. Indirect reference resource record types include CNAME, 342 DNAME, MX and SRV resource records. 344 INTERNAL_DNS_DOMAIN and INTERNAL_DNSSEC_TA configuration attributes 345 should only be used on split-tunnel configurations where only a 346 subset of traffic is routed into a private remote network using the 347 IPSec connection. If all traffic is routed over the IPsec 348 connection, the existing global INTERNAL_IP4_DNS and INTERNAL_IP6_DNS 349 can be used without creating specific DNS excemptions. 351 6. Security Considerations 353 The use of split-DNS configurations assigned by an IKEv2 responder is 354 predicated on the trust established during IKE SA authentication. 355 However, if IKEv2 is being negotiated with an anonymous or unknown 356 endpoint (such as for Opportunistic Security [RFC7435]), the 357 initiator MUST ignore split-DNS configurations assigned by the 358 responder. 360 If a host connected to an authenticated IKE peer is connecting to 361 another IKE peer that attempts to claim the same domain via the 362 INTERNAL_DNS_DOMAIN configuration attribute, the IKE connection 363 should be terminated. 365 If the IP address value of the received INTERNAL_IP4_DNS or 366 INTERNAL_IP6_DNS configuration attribute is not covered by the 367 proposed IPsec connection, then the local DNS should not be 368 reconfigured until a CREATE_CHILD Exchange is receiver that covers 369 these IP addresses. 371 INTERNAL_DNSSEC_TA directives MUST have an accompanying 372 INTERNAL_DNS_DOMAIN directive. This prevents the insertion of rogue 373 DNSSEC trust anchors for domains that have not been yielded to the 374 IPsec connection. 376 7. IANA Considerations 378 This document defines two new IKEv2 Configuration Payload Attribute 379 Types, which are allocated from the "IKEv2 Configuration Payload 380 Attribute Types" namespace. 382 Multi- 383 Value Attribute Type Valued Length Reference 384 ------ ------------------- ------ ---------- --------------- 385 [TBD] INTERNAL_DNS_DOMAIN YES 0 or more [this document] 386 [TBD] INTERNAL_DNSSEC_TA YES 0 or more [this document] 388 Figure 1 390 8. References 392 8.1. Normative References 394 [RFC1918] Rekhter, Y., Moskowitz, B., Karrenberg, D., de Groot, G., 395 and E. Lear, "Address Allocation for Private Internets", 396 BCP 5, RFC 1918, DOI 10.17487/RFC1918, February 1996, 397 . 399 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 400 Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/ 401 RFC2119, March 1997, 402 . 404 [RFC4034] Arends, R., Austein, R., Larson, M., Massey, D., and S. 405 Rose, "Resource Records for the DNS Security Extensions", 406 RFC 4034, DOI 10.17487/RFC4034, March 2005, 407 . 409 [RFC5890] Klensin, J., "Internationalized Domain Names for 410 Applications (IDNA): Definitions and Document Framework", 411 RFC 5890, DOI 10.17487/RFC5890, August 2010, 412 . 414 [RFC7296] Kaufman, C., Hoffman, P., Nir, Y., Eronen, P., and T. 415 Kivinen, "Internet Key Exchange Protocol Version 2 416 (IKEv2)", STD 79, RFC 7296, DOI 10.17487/RFC7296, October 417 2014, . 419 8.2. Informative References 421 [I-D.ietf-dnsop-onion-tld] 422 Appelbaum, J. and A. Muffett, "The .onion Special-Use 423 Domain Name", draft-ietf-dnsop-onion-tld-01 (work in 424 progress), September 2015. 426 [RFC6761] Cheshire, S. and M. Krochmal, "Special-Use Domain Names", 427 RFC 6761, DOI 10.17487/RFC6761, February 2013, 428 . 430 [RFC7435] Dukhovni, V., "Opportunistic Security: Some Protection 431 Most of the Time", RFC 7435, DOI 10.17487/RFC7435, 432 December 2014, . 434 Authors' Addresses 436 Tommy Pauly 437 Apple Inc. 438 1 Infinite Loop 439 Cupertino, California 95014 440 US 442 Email: tpauly@apple.com 444 Paul Wouters 445 Red Hat 447 Email: pwouters@redhat.com