idnits 2.17.00 (12 Aug 2021) /tmp/idnits51128/draft-wkumari-dhc-capport-02.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-RFC2606-compliant FQDNs in the document. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (April 16, 2014) is 2957 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: 'RFC2939' is mentioned on line 340, but not defined == Missing Reference: 'TODO' is mentioned on line 348, but not defined == Unused Reference: 'I-D.ietf-sidr-iana-objects' is defined on line 395, but no explicit reference was found in the text == Outdated reference: draft-ietf-sidr-iana-objects has been published as RFC 6491 Summary: 0 errors (**), 0 flaws (~~), 6 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group W. Kumari 3 Internet-Draft Google 4 Intended status: Informational O. Gudmundsson 5 Expires: October 18, 2014 Shinkuro Inc. 6 P. Ebersman 7 Infoblox 8 S. Sheng 9 ICANN 10 April 16, 2014 12 Captive-Portal identification in DHCP / RA 13 draft-wkumari-dhc-capport-02 15 Abstract 17 In many environments (such as hotels, coffee shops and other 18 establishments that offer Internet service to customers), it is 19 common to start new connections in a captive portal mode, i.e. highly 20 restrict what the customer can do until the customer has accepted 21 terms of service, provided payment information or authenticated. 23 This document describes a DHCP option (and an RA extension) to inform 24 clients that they are behind some sort of captive portal device, and 25 that they will need to authenticate to get Internet Access. 27 Status of This Memo 29 This Internet-Draft is submitted in full conformance with the 30 provisions of BCP 78 and BCP 79. 32 Internet-Drafts are working documents of the Internet Engineering 33 Task Force (IETF). Note that other groups may also distribute 34 working documents as Internet-Drafts. The list of current Internet- 35 Drafts is at http://datatracker.ietf.org/drafts/current/. 37 Internet-Drafts are draft documents valid for a maximum of six months 38 and may be updated, replaced, or obsoleted by other documents at any 39 time. It is inappropriate to use Internet-Drafts as reference 40 material or to cite them other than as "work in progress." 42 This Internet-Draft will expire on October 18, 2014. 44 Copyright Notice 46 Copyright (c) 2014 IETF Trust and the persons identified as the 47 document authors. All rights reserved. 49 This document is subject to BCP 78 and the IETF Trust's Legal 50 Provisions Relating to IETF Documents 51 (http://trustee.ietf.org/license-info) in effect on the date of 52 publication of this document. Please review these documents 53 carefully, as they describe your rights and restrictions with respect 54 to this document. Code Components extracted from this document must 55 include Simplified BSD License text as described in Section 4.e of 56 the Trust Legal Provisions and are provided without warranty as 57 described in the Simplified BSD License. 59 Table of Contents 61 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 62 1.1. Requirements notation . . . . . . . . . . . . . . . . . . 3 63 2. Background . . . . . . . . . . . . . . . . . . . . . . . . . 3 64 2.1. DNS Redirection . . . . . . . . . . . . . . . . . . . . . 3 65 2.2. HTTP Redirection . . . . . . . . . . . . . . . . . . . . 4 66 2.3. IP Hijacking . . . . . . . . . . . . . . . . . . . . . . 4 67 3. The Captive-Portal DHCP Option . . . . . . . . . . . . . . . 4 68 4. The Captive-Portal RA Option . . . . . . . . . . . . . . . . 5 69 5. Use of the Captive-Portal Option . . . . . . . . . . . . . . 6 70 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 71 7. Security Considerations . . . . . . . . . . . . . . . . . . . 8 72 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 8 73 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 9 74 9.1. Normative References . . . . . . . . . . . . . . . . . . 9 75 9.2. Informative References . . . . . . . . . . . . . . . . . 9 76 Appendix A. Changes / Author Notes. . . . . . . . . . . . . . . 9 77 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 9 79 1. Introduction 81 In many environments (coffee shops and hotels), users need to connect 82 to a captive portal device and agree to an acceptable use policy or 83 provide billing information before they can access the Internet. 85 In order to present the user with the captive portal web page, many 86 devices perform DNS and / or HTTP and / or IP hijacks. As well as 87 being kludgy hacks, these techniques looks very similar to attacks 88 that DNSSEC and TLS protect against. 90 This document describes a DHCP option (Captive-Portal) that informs 91 DHCP clients that they are behind a captive portal device, and how to 92 contact it. 94 This document neither condones nor condemns captive portals; instead 95 it recognises that they are here to stay, and attempts to improve the 96 user's experience. 98 1.1. Requirements notation 100 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 101 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 102 document are to be interpreted as described in [RFC2119]. 104 2. Background 106 Many Internet Service Providers (ISPs) that offer public Internet 107 access require the user to first accept an Acceptable Use Policy 108 (AUP) and / or provides billing information (such as their last name 109 and / or room number in a hotel, credit card information, etc) 110 through a web interface. 112 In order to meet this requirement, some ISPs implement a captive 113 portal (CP) - a system that intercepts user requests and redirects 114 them to an interstitial login page. 116 Captive portals intercept and redirects user requests in a number of 117 ways, including: 119 o DNS Redirection 121 o IP Redirection 123 o HTTP Redirection 125 o Restricted scope addresses 127 o Traffic blocking (until the user is authenticated) 129 In order to ensure that the user is unable to access the Internet, 130 captive portals usually implement IP based filters, or place the user 131 in to a restricted VLAN or restricted IP range until after they have 132 been authorized. 134 2.1. DNS Redirection 136 The CP either intercepts all DNS traffic or advertises itself (for 137 example using DHCP) as the recursive server for the network. Until 138 the user has authenticated to the captive portal, the CP responds to 139 all DNS requests listing the address of its web portal. Once the 140 user has authenticated the CP returns the "correct" addresses. 142 This technique has many shortcomings. It fails if the client is 143 performing DNSSEC validation, or if the client already has the DNS 144 information cached. 146 2.2. HTTP Redirection 148 In this implementation, the CP acts like a transparent HTTP proxy; 149 but when it sees an HTTP request from an unauthenticated client, it 150 intercepts the request and responds with an HTTP status code 302 to 151 redirect the client to the Captive Portal Login. 153 The issues with this technique include: 155 o It fails if the user is only using HTTPS 157 o It exposes various private user information, such as HTTP Cookies, 158 etc. 160 o It doesn't work if the client has a VPN and / or proxies their web 161 traffic to an external web proxy. 163 2.3. IP Hijacking 165 In this scenario, the captive portal intercepts connections to any IP 166 address. It spoofs the destination IP address and "pretends" to be 167 whatever the user tried to access. 169 This technique has similar issues as the HTTP solution, but may also 170 break other protocols, and may expose more of the users private 171 information, etc. 173 3. The Captive-Portal DHCP Option 175 The Captive Portal DHCP Option (TBA1) informs the DHCP client that it 176 is behind a captive portal and provides the URI to access the 177 authentication page. This is primarily intended to improve the user 178 experiance; for the forseeable future captive portals will still need 179 to implement the interception techniques to serve legacy clinets. 181 This draft is not intended to provide guidance on how to implement a 182 captive portal. As such, it assumes that the captive portal on a 183 dual-stack or IPv6-only network is already capable of intercepting 184 IPv6 traffic. However, in order to support IPv6 with the proposed 185 DHCP option, there are some additional considerations. In a dual- 186 stack network, the network supports both IPv4 and IPv6 protocols 187 simultaneously, but can have a mix of IPv4-only, IPv6-only, and dual- 188 stack devices using the network, meaning that it may be necessary to 189 have parallel notifications via DHCPv4 and DHCPv6. 191 IPv4-only and dual-stack devices can technically both support 192 receiving the option via DHCPv4, but dual-stack implementations would 193 need to ensure that the correct action would be taken for both IPv4 194 and IPv6 traffic despite only receiving an option via IPv4. For 195 devices/networks that only speak IPv6, and to avoid this dependency 196 on the implementation, a DHCPv6 option is necessary. 198 [ED NOTE:] This is complicated by the fact that not all devices 199 support DHCPv6, and thus it may be necessary to investigate other 200 methods to notify IPv6-only devices of a captive portal. Since this 201 option is only intended to help clients gracefully deal with networks 202 that have a captive portal, it may be acceptable to note that if a 203 client does not support DHCPv6, it simply won't be able to take 204 advantage of this optimization, but will otherwise function normally. 205 [/note] 207 The format of the DHCP Captive-Portal DHCP option is identical for 208 both DHCPv4 and DHCPv6 and is shown below. 210 Code Len Data 211 +------+------+------+------+------+-- --+-----+ 212 | code | len | URI ... | 213 +------+------+------+------+------+-- --+-----+ 215 o Code: The Captive-Portal DHCP Option (TBA1 for DHCPv4, TBA2 for 216 DHCPv6) 218 o Len: The length, in octets of the URI. 220 o URI: The URI of the authentication page that the user should 221 connect to. 223 The URI MUST be a URL with an IP-literal for the host portion (to 224 remove the need to allow DNS from unauthenticated clients). The 225 DHCPv4 URI MUST contain an IPv4 address, and the DHCPv6 URI MUST 226 contain an IPv6 address (to account for IPv4 only or IPv6 only 227 capable devices - not everyting is dual stack!) 229 [ED NOTE: Using an address literal is less than ideal, but better 230 than the alternatives. Recommending a DNS name means that the CP 231 would need to allow DNS from unauthenticated clients (as we don't 232 want to force users to use the CP's provided DNS) and some folk would 233 use this to DNS Tunnel out. This would make the CP admin block 234 external recursives).] 236 4. The Captive-Portal RA Option 238 [ Ed: I'm far from an RA expert, but it was suggested that we shold 239 advertize this via RA as well as DHCP. I think there are only 8 bits 240 for Type, is it worth burning an option code on this? I have also 241 specified that the option length should padded to multiples of 8 byte 242 to better align with the examples I've seen (and I'm on a plane so 243 cannot easily search for more!) Is this required / preferred, or is 244 smaller RAs better? ] 246 This section describes the Captive-Portal Router Advertisement 247 option. 249 0 1 2 3 250 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 251 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 252 | Type | Length | URI . 253 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ . 254 . . 255 . . 256 . . 257 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 258 Figure 2: Captive-Portal RA Option Format 260 Type TBA3 262 Length 8-bit unsigned integer. The length of the option (including 263 the Type and Length fields) in units of 8 bytes. 265 URI The URI of the authentication page that the user should connect 266 to. This should be padded with NULL (0x0) to make the total 267 option length (including the Type and Length fields) a mutliple of 268 8 bytes. 270 5. Use of the Captive-Portal Option 272 [ED NOTE: This section is, and probably will remain, fairly hand 273 wavy. This option provides notice to the OS / User applications that 274 there is a CP, but I think that the UI / etc is best designed / 275 handled by the Operating System vendors / Application developers. ] 277 The purpose of the Captive-Portal Option is to inform the operating 278 system and applications that they are behind a captive portal type 279 device and will need to authenticate before getting network access 280 (and how to reach the authentication page). 282 The Captive-Portal Option is defined for IPv6 RAs and IPv6 DHCP and 283 IPv4 DHCP. The URIs in these SHOULD all be the same, but if they are 284 not, the precedence is as follows: 286 1. IPv6 DHCP (most preferred) 288 2. IPv4 DHCP 289 3. IPv6 RA (least preferred) 291 This preference was chosen because an IPv6 capable client machine 292 will first get an IP address (and possibly the Captive-Portal option) 293 via RA, and will then get additional information via DHCP v6. The 294 client is not fully configured until it has completed the DHCP step, 295 and so this is "newer" information. The DHCP v4 preference is in the 296 middle, because it is likely that this will be delpoyed first on many 297 captive portals. Once IPv6 is deployed, we don't want legacy 298 (forgotten!) configuration to override the "newer" configuration 299 information. [Ed: This ordering is somewhat arbritary, as is the 300 justification, but there should be *some* standard and this seemed as 301 good as any! ] 303 The exact method that the interaction with the user occurs is device 304 / operating system / application dependent. The below is simply one 305 option. 307 When the device receives a DHCP response with the Captive-Portal 308 Option it SHOULD: 310 1. Not initiate new IP connections until the CP has been satisfied. 311 Existing connections should be quiesced. This will happen more 312 often than some expect -- you buy 1h of Internet at a cafe and 313 stay there for 3h -- this will "interrupt" you a few times). 315 2. Present a dialog box to the user informing that they are behind a 316 captive portal and ask if they wish to proceed. 318 3. If the user elects to proceed, the device should initiate a 319 connection to the captive portal login page using a web browser 320 configured with a separate cookie store. Some captive portals 321 send the user a cookie when they authenticate (so that the user 322 can re-authenticate more easily in the future - the browser 323 should keep these CP cookies separate from other cookies. 325 4. Once the user has authenticated (how does it know? HTTP 326 response?! Probe (ugh?)) normal IP connectivity should resume. 328 5. The device should (using an OS dependent method) expose to the 329 user / user applications that they have connected though a 330 captive portal (for example by creating a file in /proc/net/ 331 containing the interface and captive portal URI). This should 332 continue until the network changes, or a new DHCP message without 333 the CP is received. 335 6. IANA Considerations 337 This document defines DHCPv4 Captive-Portal option which requires 338 assignment of DHCPv4 option code TBA1 assigned from "Bootp and DHCP 339 options" registry (http://www.iana.org/assignments/ bootp-dhcp- 340 parameters/bootp-dhcp-parameters.xml), as specified in [RFC2939]. 342 The IANA is requested to also assign an option codes for the DHCPv6 343 Captive-Portal (TBA2) option from the "DHCPv6 and DHCPv6 options" 344 registry (http:// www.iana.org/assignments/dhcpv6-parameters/ 345 dhcpv6-parameters.xml). 347 The IANA is also requested at assign an IPv6 RA Type code (TBA3) from 348 the [TODO] registry. Thanks IANA! 350 7. Security Considerations 352 An attacker with the ability to inject DHCP messages could include 353 this option and so force users to contact him. As an attacker with 354 this capability could simply list himself as the default gateway (and 355 so see all the victim's traffic), we do not think this gives them 356 significantly more capabilities. Fake DHCP servers / fake RAs are 357 currently a security concern - this doesn't make them any better or 358 worse. 360 Devices and systems that automatically connect to open network could 361 potentially be tracked using the techniques described in this 362 document (forcing the user to continually authenticate, or exposing 363 their browser fingerprint), but similar tracking could already be 364 performed with the standard captive portal mechanisms, so this 365 doesn't seem to give the attackers more capabilities. 367 By simplifying the interaction with the captive portal systems, and 368 doing away with the need for interception, we think that users will 369 be less likely to disable useful security safeguards like DNSSEC 370 validation, VPNs, etc. 372 8. Acknowledgements 374 The primary author has discussed this idea with a number of folk, and 375 asked them to assist by becoming co-authors. Unfortunately he has 376 forgotten who many of them were; if you were one of them, I 377 apologize. 379 Thanks to Vint Cerf for the initial idea / asking me to write this. 380 Thanks to Wes George for supplying the v6 text. 382 9. References 384 9.1. Normative References 386 [IANA.AS_Numbers] 387 IANA, "Autonomous System (AS) Numbers", 388 . 390 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 391 Requirement Levels", BCP 14, RFC 2119, March 1997. 393 9.2. Informative References 395 [I-D.ietf-sidr-iana-objects] 396 Manderson, T., Vegoda, L., and S. Kent, "RPKI Objects 397 issued by IANA", draft-ietf-sidr-iana-objects-03 (work in 398 progress), May 2011. 400 Appendix A. Changes / Author Notes. 402 [RFC Editor: Please remove this section before publication ] 404 From -01 to 02: 406 o Added the IPv6 RA stuff. 408 From -00 to -01: 410 o Many nits and editorial changes. 412 o Whole bunch of extra text and review from Wes George on v6. 414 From initial to -00. 416 o Nothing changed in the template! 418 Authors' Addresses 420 Warren Kumari 421 Google 422 1600 Amphitheatre Parkway 423 Mountain View, CA 94043 424 US 426 Email: warren@kumari.net 427 Olafur Gudmundsson 428 Shinkuro Inc. 429 4922 Fairmont Av, Suite 250 430 Bethesda, MD 20814 431 USA 433 Email: ogud@ogud.com 435 Paul Ebersman 436 Infoblox 438 Email: ebersman-ietf@dragon.net 440 Steve Sheng 441 Internet Corporation for Assigned Names and Numbers 442 12025 Waterfront Drive, Suite 300 443 Los Angeles 90094 444 United States of America 446 Phone: +1.310.301.5800 447 Email: steve.sheng@icann.org