idnits 2.17.1 draft-richardson-homenet-secret-gardens-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 (November 6, 2012) is 4181 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- No issues found here. Summary: 0 errors (**), 0 flaws (~~), 1 warning (==), 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 6, 2012 5 Expires: May 10, 2013 7 Secret Gardens are Better than Walled Gardens 8 draft-richardson-homenet-secret-gardens-00 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 10, 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 5. Security Considerations . . . . . . . . . . . . . . . . . . . 9 63 6. Other Related Protocols . . . . . . . . . . . . . . . . . . . 10 64 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 65 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 12 66 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13 67 9.1. Informative References . . . . . . . . . . . . . . . . . . 13 68 9.2. Normative References . . . . . . . . . . . . . . . . . . . 13 69 10. Normative references . . . . . . . . . . . . . . . . . . . . . 14 70 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 15 72 1. Introduction: A brief history of split-horizon DNS 74 DNS settings have been a regular concern since the very early 1990s, 75 when the first firewalls began to partition the Internet. In the 76 earliest works, Cheswick and Bellovin describe the use of split-DNS 77 in an enterprise: all internal machines (including the inside 78 interface of the firewall, and possibly machines on the DMZ/ 79 Service-Network) would use an internal recursive DNS server for 80 names, and if the name was external, the internal recursive DNS 81 server would ask the world. 83 The above split-horizon configuration survives to today, but it has 84 become very complicated. The first complication was remote access 85 (VPN) to the enterprise. For the computer at home to be able access 86 things, the internal DNS server had to be used. Often short internal 87 names ("smtp", "web", "wiki","printer") would be used, depending upon 88 the fact that all internal machines had the same search path. As the 89 VPN could go on, and off, if it was off, and the end user entered the 90 word "wiki" on the browser, instead of going to the internal resource 91 (which in IPv4 space, had an RFC1918 address), it would either go to 92 an external resource, or cause a search. 94 Worse, some computer systems originally needed to be rebooted in 95 order to change their DNS settings, as this was really the only way 96 to convince all application to flush name to IP address mappings that 97 they had cached. 99 Particularly gruesome is the case of the contractor or consulting, 100 who works at enterprise A, and then visits enterprise B. While on the 101 network of Enterprise B (where they may be located for some months), 102 in order to do simple things like reach the printer (using the name 103 "printer"), they need to use the DNS settings for Enterprise B. But, 104 in order to fetch their email, they must have the DNS settings (and 105 VPN) for their home base, Enterprise A. There have been regular 106 reports in the VPN/Remote Access community of situations where a 107 worker needs to have VPNs up with two remote locations, while 108 residing at a third. 110 The VPN situation is tragic for the technical user, for the non- 111 technical user, it is impossible. For the technical user, typing in 112 longer names, setting up multiple search paths, and running a local 113 recursive name server are possible. For the less technical user, 114 typing in IP addresses rather than names works as long as HTTP 115 Virtual Hosting is not involved (for which the name is important). 116 But the degree to which these things occur has been limited in part 117 due to the inevitable conflict of RFC1918 addresses, which means, 118 that, even if one uses IP addresses, the routing doesn't work. 120 DNSSEC has put a new twist into things: the best way to run DNSSEC is 121 to have a secure recursive resolver. Now, this recursive resolver 122 needs to be taught about split-horizon names, to talk to the internal 123 name server when it is reachable (and probably to trust it), and to 124 talk directly to the Internet when not reachable. A second problem 125 is that the local recursive name server may not always get flushed. 126 If a query for "smtp.example.com" should result in the internal mail 127 relay when at the office, or connected via VPN, but the same name 128 should resolve in the external address when not connected (possibly, 129 the same machine with multiple interfaces, but not always), then the 130 caching presents a problem. This problem is acute if one tries to 131 run a caching name server on a mobile, multiple-interface devices, 132 such as a stock smartphone that has 3G and wifi interfaces, which may 133 operate concurrently. 135 Some organizations, where there are multiple data centres, and the 136 network is distinctly non-convex, have solved the caching problem by 137 dispensing with a true split-horizon DNS, and have simply put all 138 external names under "example.com", with internal names under 139 "internal.example.com". Whether or not externally made requests for 140 foo.internal.example.com are resolved by externally facing 141 authoritative name servers is now a security policy question, rather 142 than a routing or caching concern. 144 There have been further abuses of split-horizon DNS. One of these is 145 by hotels and other places with "captive portals". In order to 146 authenticate the user using a web interface, they must make the 147 portal visible to the user. This involves making the user "captive": 148 no packets may leave the local network until the user has 149 sufficiently authenticated (possibly, involving a financial 150 transaction). Some captive portals have decided that they will 151 intercept all DNS requests, and no matter what the user asks for, 152 they will answer with their own name. This can fail for three 153 reasons: 1) the user does not use the DNS servers provided, instead 154 uses their own (perhaps intending to be reached through a VPN) or or 155 the root name servers directly (perhaps in order to do DNSSEC), 2) 156 the names used in the web interfaces are unqualified ones, and the 157 user has not accepted the search path from the DHCP offer (ref: some 158 BCP on this), 3) even if all of this goes well, the user's browser 159 has now cached an incorrect mapping for the desired web site. 161 1.1. Requirements Language 163 (RFC2119 reference) 165 2. Use Cases 167 This section lists a few use cases which homenet believes are within 168 scope. Only the business goals are listed. 170 2.1. IPv6 TV 172 A seperate internet connection is provided by the IP TV provider. 173 This can be on a seperate physical wire, or a seperate logical wire. 174 Historically, only the TV set itself is placed on this network, the 175 home owner may be unaware that the wires are other than analog cable 176 TV wires. 178 The TV set does DNS lookups for the content servers, and is expected 179 to receive answers that are within the IP TV provider's network. The 180 TV set can access the provider's servers as long as it originates 181 connections from the IPv6 prefix that the IP TV provider provided. 183 The provider does not publish the addresses of the servers 184 publically, and does not want to. Even if the servers can be 185 accessed from the Internet by IP address, they will not serve any TV 186 content that way. It is more likely that the content servers are 187 completely inaccessible from the Internet via firewall rules and/or 188 routing horizons. 190 2.2. Corporate VPN 192 The corporate VPN use case involves an employee of an enterprise 193 connecting to the enterprise's network via an IP over IP tunnel. 194 IPsec is a typical technology, and there are various kinds of SSL 195 VPNs, but this use case concerns itself with scenarios where IPv6 196 pakets will be routed through the tunnel. (Some SSL VPNs provide 197 TCP, usually HTTP-only services. They are not relevant) 199 As described in the introduction, the Corporate VPN is almost the 200 original walled garden: there is a seperate routing domain (RFC1918 201 in IPv4, End-User Assigned IPv6, Non-Connected Network or ULA for 202 IPv6), and there is an addition a desire to have an island of DNS. 204 Some corporate VPNs have a policy that all traffic from the 205 employees' computing device must go through the tunnel, even traffic 206 not addressed to the Enterprise. (That is, the default route on the 207 laptop must point through the tunnel. A host route for the VPN 208 tunnel end point is usually created to permit the encapsulated 209 traffic to travel, or another kind of source-address sensitive policy 210 route is used to create multiple routing tables). These types of 211 VPNs are sometimes called an extruded IP VPN: if the enterprise' 212 network is thought of as a fungible sponge, then the laptop user at 213 home as an IP address, from the corporate cloud/sponge, extruded, 214 rather like a sea urchin (??) extends a pseudopod. 216 It is not unusual for the networks of enterprises to grow to be very 217 complex: multiple sites with multiple (sometimes overlapping IPv4 218 RFC1918) address spaces. With IPv6, enterprises are likely to have 219 fewer blocks of addresses, and none will overlap, but due to 220 acquisitions the number of blocks will still be greater than one. 222 Frequent teleworkers often have an entire home office connected to 223 the enterprise network. This can include a selection of desktop 224 computers, laptops, tablets, and smartphones (on wifi). The home 225 office network might have several subnets (at least one wired and one 226 wireless). These teleworkers usually have a VPN router as their home 227 gateway, and often these devices are controlled by the Enterprise IT. 228 Just the same, access to the rest of the homenet is desired such that 229 the home worker(s) can share things like printers, talk to home 230 automation from their desk, and to avoid having large-bandwidth cross 231 the corporate network unnecessarily. 233 More about DNS expectations of enterprises. ActiveDirectory is 234 relevant here. 236 2.3. Multi-homed to 3G/LTE 238 There is a problem here: so far it sounds like it's just IP TV over 239 again. 241 3. Walled Garden DNS 243 There have been proposals for each ISP/connectivity provider to 244 provide a suffix, such as "mytv.example." or even unregistered names 245 like ".internal" (common with ActiveDirectory) into the homenet. 247 Along with suffix would be one or more DNS servers, accessible via 248 the semi-private connection, which would resolve names in that zone. 250 The proposal is for the suffix/server extensions/appendages/ 251 ?-needs-name-? to be made visible up to near the application. At 252 least, if there is a local recursive name server, then it could be 253 the one point which gets updated (this is what some VPN clients do), 254 or it may require applications to be aware, and to use alternative 255 resolver libraries. 257 4. Using Secret-Gardens to accomplish goals 258 5. Security Considerations 259 6. Other Related Protocols 260 7. IANA Considerations 261 8. Acknowledgements 262 9. References 264 9.1. Informative References 266 9.2. Normative References 267 10. Normative references 268 Author's Address 270 Michael C. Richardson 271 Sandelman Software Works 272 470 Dawson Avenue 273 Ottawa, ON K1Z 5V7 274 CA 276 Email: mcr+ietf@sandelman.ca 277 URI: http://www.sandelman.ca/