idnits 2.17.1 draft-richardson-homenet-secret-gardens-01.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 : ---------------------------------------------------------------------------- == There are 1 instance of lines with non-RFC3849-compliant IPv6 addresses in the document. If these are example addresses, they should be changed. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (November 14, 2012) is 4180 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: 'SERVER-SELECTION' is mentioned on line 274, but not defined == Missing Reference: 'RFC1034' is mentioned on line 275, but not defined == Missing Reference: 'DNSSEC' is mentioned on line 276, but not defined Summary: 0 errors (**), 0 flaws (~~), 5 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group M. Richardson 3 Internet-Draft SSW 4 Intended status: Informational November 14, 2012 5 Expires: May 18, 2013 7 Secret Gardens are Better than Walled Gardens 8 draft-richardson-homenet-secret-gardens-01 10 Abstract 12 This document explains a few use cases where operators would like to 13 introduce so-called "walled gardens" into home-networks, including 14 distribution of new DNS anchors. This document proposes an 15 alternative solution involving DNS delegations to access controlled 16 DNS servers. The results are much more scalable, and can be deployed 17 today, using existing operating systems and existing DNS 18 infrastructure. 20 Status of this Memo 22 This Internet-Draft is submitted in full conformance with the 23 provisions of BCP 78 and BCP 79. 25 Internet-Drafts are working documents of the Internet Engineering 26 Task Force (IETF). Note that other groups may also distribute 27 working documents as Internet-Drafts. The list of current Internet- 28 Drafts is at http://datatracker.ietf.org/drafts/current/. 30 Internet-Drafts are draft documents valid for a maximum of six months 31 and may be updated, replaced, or obsoleted by other documents at any 32 time. It is inappropriate to use Internet-Drafts as reference 33 material or to cite them other than as "work in progress." 35 This Internet-Draft will expire on May 18, 2013. 37 Copyright Notice 39 Copyright (c) 2012 IETF Trust and the persons identified as the 40 document authors. All rights reserved. 42 This document is subject to BCP 78 and the IETF Trust's Legal 43 Provisions Relating to IETF Documents 44 (http://trustee.ietf.org/license-info) in effect on the date of 45 publication of this document. Please review these documents 46 carefully, as they describe your rights and restrictions with respect 47 to this document. Code Components extracted from this document must 48 include Simplified BSD License text as described in Section 4.e of 49 the Trust Legal Provisions and are provided without warranty as 50 described in the Simplified BSD License. 52 Table of Contents 54 1. Introduction: A brief history of split-horizon DNS . . . . . . 3 55 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 4 56 2. Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . . 5 57 2.1. IPv6 TV . . . . . . . . . . . . . . . . . . . . . . . . . 5 58 2.2. Corporate VPN . . . . . . . . . . . . . . . . . . . . . . 5 59 2.3. Multi-homed to 3G/LTE . . . . . . . . . . . . . . . . . . 6 60 3. Walled Garden DNS . . . . . . . . . . . . . . . . . . . . . . 7 61 4. Using Secret-Gardens to accomplish goals . . . . . . . . . . . 8 62 4.1. Example 1: Corporate VPN . . . . . . . . . . . . . . . . . 8 63 5. How does this differ from SERVER-SELECTION? . . . . . . . . . 11 64 6. Security Considerations . . . . . . . . . . . . . . . . . . . 12 65 7. Other Related Protocols . . . . . . . . . . . . . . . . . . . 13 66 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 67 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 15 68 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 16 69 10.1. Informative References . . . . . . . . . . . . . . . . . . 16 70 10.2. Normative References . . . . . . . . . . . . . . . . . . . 16 71 11. Normative references . . . . . . . . . . . . . . . . . . . . . 17 72 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 18 74 1. Introduction: A brief history of split-horizon DNS 76 DNS settings have been a regular concern since the very early 1990s, 77 when the first firewalls began to partition the Internet. In the 78 earliest works, Cheswick and Bellovin describe the use of split-DNS 79 in an enterprise: all internal machines (including the inside 80 interface of the firewall, and possibly machines on the DMZ/ 81 Service-Network) would use an internal recursive DNS server for 82 names, and if the name was external, the internal recursive DNS 83 server would ask the world. 85 The above split-horizon configuration survives to today, but it has 86 become very complicated. The first complication was remote access 87 (VPN) to the enterprise. For the computer at home to be able access 88 things, the internal DNS server had to be used. Often short internal 89 names ("smtp", "web", "wiki","printer") would be used, depending upon 90 the fact that all internal machines had the same search path. As the 91 VPN could go on, and off, if it was off, and the end user entered the 92 word "wiki" on the browser, instead of going to the internal resource 93 (which in IPv4 space, had an RFC1918 address), it would either go to 94 an external resource, or cause a search. 96 Worse, some computer systems originally needed to be rebooted in 97 order to change their DNS settings, as this was really the only way 98 to convince all application to flush name to IP address mappings that 99 they had cached. 101 Particularly gruesome is the case of the contractor or consulting, 102 who works at enterprise A, and then visits enterprise B. While on the 103 network of Enterprise B (where they may be located for some months), 104 in order to do simple things like reach the printer (using the name 105 "printer"), they need to use the DNS settings for Enterprise B. But, 106 in order to fetch their email, they must have the DNS settings (and 107 VPN) for their home base, Enterprise A. There have been regular 108 reports in the VPN/Remote Access community of situations where a 109 worker needs to have VPNs up with two remote locations, while 110 residing at a third. 112 The VPN situation is tragic for the technical user, for the non- 113 technical user, it is impossible. For the technical user, typing in 114 longer names, setting up multiple search paths, and running a local 115 recursive name server are possible. For the less technical user, 116 typing in IP addresses rather than names works as long as HTTP 117 Virtual Hosting is not involved (for which the name is important). 118 But the degree to which these things occur has been limited in part 119 due to the inevitable conflict of RFC1918 addresses, which means, 120 that, even if one uses IP addresses, the routing doesn't work. 122 DNSSEC has put a new twist into things: the best way to run DNSSEC is 123 to have a secure recursive resolver. Now, this recursive resolver 124 needs to be taught about split-horizon names, to talk to the internal 125 name server when it is reachable (and probably to trust it), and to 126 talk directly to the Internet when not reachable. A second problem 127 is that the local recursive name server may not always get flushed. 128 If a query for "smtp.example.com" should result in the internal mail 129 relay when at the office, or connected via VPN, but the same name 130 should resolve in the external address when not connected (possibly, 131 the same machine with multiple interfaces, but not always), then the 132 caching presents a problem. This problem is acute if one tries to 133 run a caching name server on a mobile, multiple-interface devices, 134 such as a stock smartphone that has 3G and wifi interfaces, which may 135 operate concurrently. 137 Some organizations, where there are multiple data centres, and the 138 network is distinctly non-convex, have solved the caching problem by 139 dispensing with a true split-horizon DNS, and have simply put all 140 external names under "example.com", with internal names under 141 "internal.example.com". Whether or not externally made requests for 142 foo.internal.example.com are resolved by externally facing 143 authoritative name servers is now a security policy question, rather 144 than a routing or caching concern. 146 There have been further abuses of split-horizon DNS. One of these is 147 by hotels and other places with "captive portals". In order to 148 authenticate the user using a web interface, they must make the 149 portal visible to the user. This involves making the user "captive": 150 no packets may leave the local network until the user has 151 sufficiently authenticated (possibly, involving a financial 152 transaction). Some captive portals have decided that they will 153 intercept all DNS requests, and no matter what the user asks for, 154 they will answer with their own IP. This can fail for three reasons: 155 1) the user does not use the DNS servers provided, instead uses their 156 own (perhaps intending to be reached through a VPN) or or the root 157 name servers directly (perhaps in order to do DNSSEC), 2) the names 158 used in the web interfaces are unqualified ones, and the user has not 159 accepted the search path from the DHCP offer (ref: some BCP on this), 160 3) even if all of this goes well, the user's browser has now cached 161 an incorrect mapping for the desired web site. 163 1.1. Requirements Language 165 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 166 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 167 document are to be interpreted as described in RFC 2119 [RFC2119]. 169 2. Use Cases 171 This section lists a few use cases which homenet believes are within 172 scope. Only the business goals are listed of the use cases. 174 2.1. IPv6 TV 176 [SERVER-SELECTION] Section 3.1 "CPU Deployment Scenario" describes a 177 similar situation to the IPv6 TV below. 179 A seperate internet connection is provided by the IP TV provider. 180 This can be on a seperate physical wire, or a seperate logical wire. 181 Historically, only the TV set itself is placed on this network, the 182 home owner may be unaware that the wires are other than analog cable 183 TV wires. 185 The TV set does DNS lookups for the content servers, and is expected 186 to receive answers that are within the IP TV provider's network. The 187 TV set can access the provider's servers as long as it originates 188 connections from the IPv6 prefix that the IP TV provider provided. 190 The provider does not publish the addresses of the servers 191 publically, and does not want to. Even if the servers can be 192 accessed from the Internet by IP address, they will not serve any TV 193 content that way. It is more likely that the content servers are 194 completely inaccessible from the Internet via firewall rules and/or 195 routing horizons. 197 2.2. Corporate VPN 199 [SERVER-SELECTION] Section 3.2 "Cellular Network Scenario" provides 200 more details. 202 The corporate VPN use case involves an employee of an enterprise 203 connecting to the enterprise's network via an IP over IP tunnel. 204 IPsec is a typical technology, and there are various kinds of SSL 205 VPNs, but this use case concerns itself with scenarios where IPv6 206 pakets will be routed through the tunnel. (Some SSL VPNs provide 207 TCP, usually HTTP-only services. They are not relevant) 209 As described in the introduction, the Corporate VPN is almost the 210 original walled garden: there is a seperate routing domain (RFC1918 211 in IPv4, End-User Assigned IPv6, Non-Connected Network or ULA for 212 IPv6), and there is an addition a desire to have an island of DNS. 214 Some corporate VPNs have a policy that all traffic from the 215 employees' computing device must go through the tunnel, even traffic 216 not addressed to the Enterprise. (That is, the default route on the 217 laptop must point through the tunnel. A host route for the VPN 218 tunnel end point is usually created to permit the encapsulated 219 traffic to travel, or another kind of source-address sensitive policy 220 route is used to create multiple routing tables). These types of 221 VPNs are sometimes called an extruded IP VPN: if the enterprise' 222 network is thought of as a fungible sponge, then the laptop user at 223 home as an IP address, from the corporate cloud/sponge, extruded, 224 rather like a sea urchin (??) extends a pseudopod. 226 It is not unusual for the networks of enterprises to grow to be very 227 complex: multiple sites with multiple (sometimes overlapping IPv4 228 RFC1918) address spaces. With IPv6, enterprises are likely to have 229 fewer blocks of addresses, and none will overlap, but due to 230 acquisitions the number of blocks will still be greater than one. 232 Frequent teleworkers often have an entire home office connected to 233 the enterprise network. This can include a selection of desktop 234 computers, laptops, tablets, and smartphones (on wifi). The home 235 office network might have several subnets (at least one wired and one 236 wireless). These teleworkers usually have a VPN router as their home 237 gateway, and often these devices are controlled by the Enterprise IT. 238 Just the same, access to the rest of the homenet is desired such that 239 the home worker(s) can share things like printers, talk to home 240 automation from their desk, and to avoid having large-bandwidth cross 241 the corporate network unnecessarily. 243 More about DNS expectations of enterprises. ActiveDirectory is 244 relevant here. 246 2.3. Multi-homed to 3G/LTE 248 [SERVER-SELECTION] Section 3.2 "Cellular Network Scenario" provides 249 more details. 251 There is a problem here: so far it sounds like it's just IP TV over 252 again. 254 3. Walled Garden DNS 256 [SERVER-SELECTION] proposes a solution where ISP/connectivity 257 providers provide a suffix, such as "mytv.example." or even 258 unregistered names like ".internal" (common with ActiveDirectory) 259 into the homenet. 261 Along with suffix are provided one or more DNS servers, accessible 262 via the semi-private connection, which would resolve names in that 263 zone. 265 4. Using Secret-Gardens to accomplish goals 267 As [SERVER-SELECTION] essentially mandates that DNSSEC be done, it 268 has essentially mandated that a recursive cacheing validating name 269 server be run on each host. Many have suggested that, as the days of 270 20Mhz, 8MB workstations are long gone, that having a caching, 271 validating name server on every host is not a problem. Once one 272 assumes this, new solutions become possible. 274 The fundamental problem that [SERVER-SELECTION] tries to solve is 275 that of mapping DNS suffixes to name servers. [RFC1034] provides a 276 way to do this: the NS resource record. [DNSSEC] provides a way to 277 do this securely by adding the DS resource record. 279 So what was stopping enterprises such as IP TV, or corporate VPNs 280 from putting in-accessible IP addresses into a reachable DNS server? 281 Usually two things: the perception that the security through 282 obscurity benefit of split-horizon DNS provided was greater than the 283 operational complexity and inconvenience of using a single namespace. 284 The second thing was that putting RFC1918 addresses in a publically 285 visible DNS would be confusing. 287 IPv6 addresses removes both problems. First, since almost every 288 walled-garden situation insists that any machine talking to it use an 289 address in the prefix that the walled-garden provides. This means 290 that if one puts the DNS servers for the walled garden names in the 291 walled gareden then can be queried only from machines that are 292 already in the garden. 294 Second: since IPv6 addresses are all unique, there is no confusion 295 when an IPv6 address is listed. It is therefore possible to 296 unambiguously indicate in an NS that that mytv.example.com is 297 reachable via DOCPREFIX:1234:0001. Just because the entire Internet 298 can see the (possibly secure) delegation doesn't meant that they can 299 query it. 301 4.1. Example 1: Corporate VPN 303 A company EXAMPLE has been given the assignment 2001:DB8:0F00:/48. 304 It has the forward name example.com. In addition, due to an 305 acquisition, it also owns example.org and assignment 2001:DB8: 306 0123:/48. Further, assume the VPN concentrator for example.com gives 307 /128 tunnel addresses to clients from the 2001:DB8:0F00:ff91::/64 308 range. In this example, the client has been assigned 2001:DB8:0F00: 309 ff91::1234. 311 Routes are established through the VPN tunnel for the above two 312 prefixes: 314 % netstat -rn -f inet6 315 Routing tables 317 Internet6: 318 Destination Gateway Flags Interface 319 ... 320 2001:db8:0f00::/48 2001:db8:0f00:ff91::1 UGRS ipsec0 321 2001:db8:0123::/48 2001:db8:0f00:ff91::1 UGRS ipsec0 322 ... 324 Figure 1 326 Rather than create a split-horizon DNS server on the inside that 327 answers (differently) for example.com, the enterprise instead creates 328 a new zone internal.example.com: 330 % dig internal.example.com. ns 331 ;; QUESTION SECTION: 332 ;internal.example.com. IN NS 334 ;; ANSWER SECTION: 335 internal.example.com. 7200 IN NS ns1.internal.example.com. 336 internal.example.com. 7200 IN NS ns2.internal.example.com. 338 ;; ADDITIONAL SECTION: 339 ns1.internal.example.com. 7200 IN AAAA 2001:db8:0f00:0001::8888 340 ns2.internal.example.com. 7200 IN AAAA 2001:db8:0f00:0002::8888 342 Figure 2 344 Note that these records are in the public example.com zone, and are 345 visible to the Internet. 347 The ns1 and ns2 servers SHOULD be configured such that they will not 348 answer queries for internal.example.com, unless the query comes from 349 2001:db8:0f00::/48. 351 What is the effect here? A host with it's VPN active performs a 352 query for thing.internal.example.com. The local recursive DNS server 353 chases the NS pointers from the root, and it gets the above NS 354 records. It then performs a query to ns1.internal.example.com for 355 the name thing.internal.example.com. Since the route for this IP 356 address goes through the ipsec0 device, the source address for the 357 packet will be 2001:DB8:0F00:ff91::1234. That source address fits 358 into the policy for the ns1 server, so it answers. 360 There are a number of other affects: 1) the result of this lookup is 361 cacheable, and does not need to be flushed if the node moves. 2) if 362 the VPN is not active, then the result of performing the lookup for 363 thing.internal.example.com causes a packet to be sent to the 2001: 364 db8:0f00::/48 network. If policies are setup right, then this packet 365 may well cause the VPN to be started (or even restarted, if it 366 failed). 368 5. How does this differ from SERVER-SELECTION? 370 run through use cases, show how this is equivalent or better. 372 6. Security Considerations 373 7. Other Related Protocols 374 8. IANA Considerations 375 9. Acknowledgements 376 10. References 378 10.1. Informative References 380 10.2. Normative References 381 11. Normative references 383 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 384 Requirement Levels", BCP 14, RFC 2119, March 1997. 386 Author's Address 388 Michael C. Richardson 389 Sandelman Software Works 390 470 Dawson Avenue 391 Ottawa, ON K1Z 5V7 392 CA 394 Email: mcr+ietf@sandelman.ca 395 URI: http://www.sandelman.ca/