<?xml version="1.0" encoding="UTF-8"?>
  <?xml-stylesheet type="text/xsl" href="rfc2629.xslt" ?>
  <!-- generated by https://github.com/cabo/kramdown-rfc2629 version 1.0.30 -->

<!DOCTYPE rfc SYSTEM "../Tools/rfc2629xslt/rfc2629.dtd" [
]>

<?rfc toc="yes"?>
<?rfc tocindent="yes"?>
<?rfc sortrefs="yes"?>
<?rfc symrefs="yes"?>
<?rfc strict="yes"?>
<?rfc compact="yes"?>
<?rfc comments="yes"?>
<?rfc inline="yes"?>

<rfc ipr="trust200902" docName="draft-nottingham-capport-problem-01" category="info">

  <front>
    <title abbrev="CAPPORT Problem Statement">Captive Portals Problem Statement</title>

    <author initials="M." surname="Nottingham" fullname="Mark Nottingham">
      <organization></organization>
      <address>
        <email>mnot@mnot.net</email>
        <uri>https://www.mnot.net/</uri>
      </address>
    </author>

    <date year="2016"/>

    <area>General</area>
    
    <keyword>Internet-Draft</keyword>

    <abstract>


<t>This draft attempts to establish a problem statement for “Captive Portals”, in order to inform discussions of improving their operation.</t>



    </abstract>


    <note title="Note to Readers">


<t>The issues list for this draft can be found at <eref target="https://github.com/mnot/I-D/labels/capport-problem">https://github.com/mnot/I-D/labels/capport-problem</eref>.</t>

<t>The most recent (often, unpublished) draft is at <eref target="https://mnot.github.io/I-D/capport-problem/">https://mnot.github.io/I-D/capport-problem/</eref>.</t>

<t>Recent changes are listed at <eref target="https://github.com/mnot/I-D/commits/gh-pages/capport-problem">https://github.com/mnot/I-D/commits/gh-pages/capport-problem</eref>.</t>


    </note>


  </front>

  <middle>


<section anchor="introduction" title="Introduction">

<t>This draft attempts to establish a problem statement for “Captive Portals”, in order to inform discussions of improving their operation.</t>

<section anchor="notational-conventions" title="Notational Conventions">

<t>The key words “MUST”, “MUST NOT”, “REQUIRED”, “SHALL”, “SHALL NOT”, “SHOULD”, “SHOULD NOT”,
“RECOMMENDED”, “MAY”, and “OPTIONAL” in this document are to be interpreted as described in
<xref target="RFC2119"/>.</t>

</section>
</section>
<section anchor="defining-captive-portals-and-networks" title="Defining Captive Portals and Networks">

<t>A “<spanx style="emph">captive network</spanx>” is a network that employs a captive portal for a variety of purposes; see <xref target="why"/>. A “<spanx style="emph">captive portal</spanx>” is a Web site that captive networks direct users to.</t>

<t>This is achieved by directing requests for “normal” Web access to the captive portal, through variety of techniques, including DNS poisoning, TCP interception, HTTP response modification and/or HTTP redirection.</t>

<t>Once the captive network’s goals are met, the network “remembers” that the user is allowed network access, usually by MAC address, although there is a significant amount of variance between implementations.</t>

<t>Over time, operating systems have developed “<spanx style="emph">captive portal detection</spanx>” processes to discover captive networks, and to assist users through the process of obtaining full network access. They often involve specialised “<spanx style="emph">captive portal browsers</spanx>” which only allow the captive portal to use a subset of the full capabilities of a Web browser, and have a different user experience.</t>

<section anchor="why" title="Why Captive Portals Are Used">

<t>Captive portals are deployed in a variety of situations, but the most common motivations are:</t>

<t><list style="symbols">
  <t><spanx style="strong">Authentication</spanx> - Obtaining user credentials before authorising network access</t>
  <t><spanx style="strong">Payment</spanx> - Obtaining payment for using the network.</t>
  <t><spanx style="strong">Information</spanx> - Presenting information to the user. This might include displaying legal notices, details about the network provider and/or its location, advertisements, policies, etc., and obtaining user consent.</t>
  <t><spanx style="strong">Notifications</spanx> - Some networks use the same mechanisms as captive portals to notify users of account status, network downtime, emergency alerts, etc. See <xref target="RFC6108"/> for an example of one way this is done.</t>
</list></t>

<t>In all of these cases, using a Web browser is attractive, because it gives the network the ability to tailor the user’s interface and experience, as well as the ability to integrate third-party payment, advertising, authentication and other services.</t>

</section>
</section>
<section anchor="issues" title="Issues Caused by Captive Portals">

<t>When a network imposes a captive portal, it can cause a variety of issues, both for applications and end users.</t>

<t><list style="symbols">
  <t><spanx style="strong">False Negatives</spanx> - Because so many different heuristics are used to detect a captive portal, it’s common for an OS or browser to think it’s on an open network, <eref target="https://discussions.apple.com/thread/6251349">when in fact there is a captive portal</eref> in place.</t>
  <t><spanx style="strong">Longevity</spanx> - Often, it’s necessary to <eref target="https://community.aerohive.com/aerohive/topics/ios_7_captive_portal_issues">repeatedly log into a captive portal</eref>, thanks to timeout issues. The effects of this range from annoyance to inability to complete tasks, depending on the timeout and the task at hand.</t>
  <t><spanx style="strong">Interoperability Issues</spanx> - Captive portals often depend on specific operating system and browser capabilities and behaviours. Client systems that do not share those quirks often have difficulty connecting to captive portals.</t>
  <t><spanx style="strong">Confusion</spanx> - Because captive portals are effectively a man-in-the-middle attack, they can confuse users as well as user agents (e.g., caches). For example, when the portal’s TLS certificate doesn’t match that of the requested site, or the captive portal’s /favicon.ico gets used as that of the originally requested site.</t>
  <t><spanx style="strong">DNS</spanx>/<spanx style="strong">DNSSEC</spanx> - When portals respond with forged DNS answers, they confuse DNS resolvers and  interoperate poorly with host-validating DNSSEC resolvers and applications.</t>
  <t><spanx style="strong">TLS</spanx> - Portals that attempt to intercept TLS sessions (HTTPS, IMAPS, or other) can cause certificate error messages on clients, encouraging bad practice to click through such errors.</t>
  <t><spanx style="strong">Unexpected Configuration</spanx> - Some captive portals do not work with clients using unexpected configurations, for example clients using static IP, custom DNS servers, or HTTP proxies.</t>
  <t><spanx style="strong">Stealing Access</spanx> - because captive portals often associate a user with a MAC address, it is possible for an attacker to impersonate an authenticated client (e.g., one that has paid for Internet access). Note that this is specific to open Wifi, and can be prevented by using a secure wireless medium. However, configuration of secure wireless is often deemed to be too complex for captive networks.</t>
  <t><spanx style="strong">Non-Browser Clients</spanx> - It is becoming more common for Internet devices without the ability to run a browser to be used, thanks to the “Internet of Things.” These devices cannot easily use most networks that interpose a captive portal.</t>
  <t><spanx style="strong">Connectivity Interruption</spanx> - For a device with multiple network interfaces (e.g., cellular and WiFi), connecting to a network can require dropping access to alternative network interfaces.  If such a device connects to a network with a captive portal, it can lose network connectivity until the captive portal requirements are satisfied.</t>
</list></t>

</section>
<section anchor="issues-detection" title="Issues Caused by Captive Portal Detection">

<t>Many operating systems attempt to detect when they are on a captive network. Detection aims to minimize the negative effects caused by interposition of captive portals, but can cause different issues, including:</t>

<t><list style="symbols">
  <t><spanx style="strong">False Positives</spanx> - Some networks don’t use a Web browser interface to log in; e.g., they <eref target="http://stackoverflow.com/questions/14606131/using-captive-network-assistant-on-macosx-to-connect-to-vpn">require a VPN to access the network</eref>, so captive portal detection relying on HTTP is counterproductive.</t>
  <t><spanx style="strong">Non-Internet Networks</spanx> - <eref target="http://forum.piratebox.cc/read.php?9,8879">Some applications</eref> and/or networks don’t assume Internet access, but captive portal detection often conflates “network access” with “Internet access”.</t>
  <t><spanx style="strong">Sandboxing</spanx> - When a captive portal is detected, some operating systems access the captive portal in a highly sandboxed captive portal browser.  This might have reduced capabilities, such as limited access to browser APIs.  In addition, this environment is separate from a user’s normal browsing environment and therefore does not include state. While sandboxing seems a good idea to protect user data (particularly on Open WiFi), it is implemented differently on various platforms and often causes a (severely) broken user experience on the captive portal (even when the operator is protecting user data end-to-end with HTTPS). To offer a consistent and rich experience on the captive portal, some operators actively try to defeat operating system captive portal detection.</t>
</list></t>

<section anchor="issues-caused-by-defeating-captive-portal-detection" title="Issues Caused by Defeating Captive Portal Detection">

<t>Many captive portal devices provide optional mechanisms that aim to defeat captive portal detection.</t>

<t>Such defeat mechanisms aim to avoid the problems caused by captive portal detection (see <xref target="issues-detection"/>), with the consequence that they also cause the same problems that detection was intended to avoid (see <xref target="issues"/>).</t>

</section>
</section>
<section anchor="security-considerations" title="Security Considerations">

<t>TBD</t>

</section>


  </middle>

  <back>

    <references title='Normative References'>





<reference  anchor='RFC2119' target='http://www.rfc-editor.org/info/rfc2119'>
<front>
<title>Key words for use in RFCs to Indicate Requirement Levels</title>
<author initials='S.' surname='Bradner' fullname='S. Bradner'><organization /></author>
<date year='1997' month='March' />
<abstract><t>In many standards track documents several words are used to signify the requirements in the specification.  These words are often capitalized. This document defines these words as they should be interpreted in IETF documents.  This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.</t></abstract>
</front>
<seriesInfo name='BCP' value='14'/>
<seriesInfo name='RFC' value='2119'/>
<seriesInfo name='DOI' value='10.17487/RFC2119'/>
</reference>



<reference  anchor='RFC6108' target='http://www.rfc-editor.org/info/rfc6108'>
<front>
<title>Comcast's Web Notification System Design</title>
<author initials='C.' surname='Chung' fullname='C. Chung'><organization /></author>
<author initials='A.' surname='Kasyanov' fullname='A. Kasyanov'><organization /></author>
<author initials='J.' surname='Livingood' fullname='J. Livingood'><organization /></author>
<author initials='N.' surname='Mody' fullname='N. Mody'><organization /></author>
<author initials='B.' surname='Van Lieu' fullname='B. Van Lieu'><organization /></author>
<date year='2011' month='February' />
<abstract><t>The objective of this document is to describe a method of providing critical end-user notifications to web browsers, which has been deployed by Comcast, an Internet Service Provider (ISP).  Such a notification system is being used to provide near-immediate notifications to customers, such as to warn them that their traffic exhibits patterns that are indicative of malware or virus infection. There are other proprietary systems that can perform such notifications, but those systems utilize Deep Packet Inspection (DPI) technology.  In contrast to DPI, this document describes a system that does not rely upon DPI, and is instead based in open IETF standards and open source applications.  This document is not an Internet  Standards Track specification; it is published for informational purposes.</t></abstract>
</front>
<seriesInfo name='RFC' value='6108'/>
<seriesInfo name='DOI' value='10.17487/RFC6108'/>
</reference>




    </references>



<section anchor="acknowledgements" title="Acknowledgements">

<t>This draft was seeded from the <eref target="https://github.com/httpwg/wiki/wiki/Captive-Portals">HTTP Working Group Wiki Page on Captive Portals</eref>; thanks to all who contributed there.</t>

<t>Thanks to Martin Thomson, Yaron Sheffer, David Bird and Jason Livingood for their suggestions.</t>

</section>


  </back>
</rfc>

