< draft-wkumari-dhc-capport-05.txt   draft-wkumari-dhc-capport-06.txt >
Network Working Group W. Kumari Network Working Group W. Kumari
Internet-Draft Google Internet-Draft Google
Intended status: Informational O. Gudmundsson Intended status: Informational O. Gudmundsson
Expires: March 12, 2015 Shinkuro Inc. Expires: June 5, 2015 Shinkuro Inc.
P. Ebersman P. Ebersman
Comcast Comcast
S. Sheng S. Sheng
ICANN ICANN
September 8, 2014 December 2, 2014
Captive-Portal identification in DHCP / RA Captive-Portal identification in DHCP / RA
draft-wkumari-dhc-capport-05 draft-wkumari-dhc-capport-06
Abstract Abstract
In many environments (such as hotels, coffee shops and other In many environments (such as hotels, coffee shops and other
establishments that offer Internet service to customers), it is establishments that offer Internet service to customers), it is
common to start new connections in a captive portal mode, i.e. highly common to start new connections in a captive portal mode, i.e. highly
restrict what the customer can do until the customer has accepted restrict what the customer can do until the customer has accepted
terms of service, provided payment information and / or terms of service, provided payment information and / or
authenticated. authenticated.
skipping to change at page 1, line 44 skipping to change at page 1, line 44
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on March 12, 2015. This Internet-Draft will expire on June 5, 2015.
Copyright Notice Copyright Notice
Copyright (c) 2014 IETF Trust and the persons identified as the Copyright (c) 2014 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 2, line 27 skipping to change at page 2, line 27
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1. Requirements notation . . . . . . . . . . . . . . . . . . 3 1.1. Requirements notation . . . . . . . . . . . . . . . . . . 3
2. Background . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Background . . . . . . . . . . . . . . . . . . . . . . . . . 3
2.1. DNS Redirection . . . . . . . . . . . . . . . . . . . . . 4 2.1. DNS Redirection . . . . . . . . . . . . . . . . . . . . . 4
2.2. HTTP Redirection . . . . . . . . . . . . . . . . . . . . 4 2.2. HTTP Redirection . . . . . . . . . . . . . . . . . . . . 4
2.3. IP Hijacking . . . . . . . . . . . . . . . . . . . . . . 4 2.3. IP Hijacking . . . . . . . . . . . . . . . . . . . . . . 5
3. The Captive-Portal DHCP Option . . . . . . . . . . . . . . . 5 3. The Captive-Portal DHCP Option . . . . . . . . . . . . . . . 5
4. The Captive-Portal RA Option . . . . . . . . . . . . . . . . 5 4. The Captive-Portal RA Option . . . . . . . . . . . . . . . . 6
5. Use of the Captive-Portal Option . . . . . . . . . . . . . . 6 5. Use of the Captive-Portal Option . . . . . . . . . . . . . . 6
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8
7. Security Considerations . . . . . . . . . . . . . . . . . . . 8 7. Security Considerations . . . . . . . . . . . . . . . . . . . 8
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 8 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 8
9. Normative References . . . . . . . . . . . . . . . . . . . . 8 9. Normative References . . . . . . . . . . . . . . . . . . . . 9
Appendix A. Changes / Author Notes. . . . . . . . . . . . . . . 9 Appendix A. Changes / Author Notes. . . . . . . . . . . . . . . 9
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 10 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 10
1. Introduction 1. Introduction
In many environments, users need to connect to a captive portal In many environments, users need to connect to a captive portal
device and agree to an acceptable use policy and / or provide billing device and agree to an acceptable use policy and / or provide billing
information before they can access the Internet. information before they can access the Internet.
In order to present the user with the captive portal web page, many In order to present the user with the captive portal web page, many
devices perform DNS and / or HTTP and / or IP hijacks. As well as devices perform DNS and / or HTTP and / or IP hijacks. In addition
being kludgy hacks, these techniques looks very similar to attacks to being kludgy hacks, these techniques resemble attacks that DNSSEC
that DNSSEC and TLS protect against, which makes the user experience and TLS are intended to protect against. In an attempt to discourage
sub-optimal. the deliberate subversion of basic security tools, this document
describes a DHCP option (Captive-Portal) and an IPv6 Router
Advertisement (RA) extension that informs clients that they are
behind a captive portal device, and how to contact it.
This document describes a DHCP option (Captive-Portal) and an IPv6 document describes a DHCP option (Captive-Portal) and an IPv6 Router
Router Advertisement (RA) extension that informs clients that they Advertisement (RA) extension that informs clients that they are
are behind a captive portal device, and how to contact it. behind a captive portal device, and how to contact it.
This document neither condones nor condemns captive portals; instead, This document neither condones nor condemns the use captive portals;
it recognises that they are here to stay, and attempts to improve the instead, it recognises that their apparent necessity, and attempts to
user experience. improve the user experience.
The technique described in this document mainly improve the user The technique described in this document mainly improve the user
experience when first connecting to a network behind a captive experience when first connecting to a network behind a captive
portal. It may also help if the captive portal access times out portal. It may also help if the captive portal access times out
after connecting, but this is less reliable. after connecting, but this is less reliable.
1.1. Requirements notation 1.1. Requirements notation
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
skipping to change at page 4, line 13 skipping to change at page 4, line 18
VPNs, DNSSEC, TLS) are designed to protect against. The interaction VPNs, DNSSEC, TLS) are designed to protect against. The interaction
of the these protections and the interception leads to poor user of the these protections and the interception leads to poor user
experiences, such as long timeouts, inability to reach the captive experiences, such as long timeouts, inability to reach the captive
portal web page, etc. The interception may also leak user portal web page, etc. The interception may also leak user
information (for example, if the captive portal intercepts and logs information (for example, if the captive portal intercepts and logs
an HTTP Cookie, or URL of the form http://fred:password@example.com). an HTTP Cookie, or URL of the form http://fred:password@example.com).
The user is often unaware of what is causing the issue (their browser The user is often unaware of what is causing the issue (their browser
appears to hang, saying something like "Downloading Proxy Script", or appears to hang, saying something like "Downloading Proxy Script", or
simply "The Internet doesn't work"), and they become frustrated. simply "The Internet doesn't work"), and they become frustrated.
This may results in them not purchasing the Internet access provided This may results in them not purchasing the Internet access provided
by the captive portal. by the captive portal. The connectivity attempts may also facilitate
OS fingerprinting even before a client attempts to connect to the
portal itself.
2.1. DNS Redirection 2.1. DNS Redirection
The CP either intercepts all DNS traffic or advertises itself (for The CP either intercepts all DNS traffic or advertises itself (for
example using DHCP) as the recursive server for the network. Until example using DHCP) as the recursive server for the network. Until
the user has authenticated to the captive portal, the CP responds to the user has authenticated to the captive portal, the CP responds to
all DNS requests listing the address of its web portal. Once the all DNS requests listing the address of its web portal. Once the
user has authenticated the CP returns the "correct" addresses. user has authenticated the CP returns the "correct" addresses.
This technique has many shortcomings. It fails if the client is This technique has many shortcomings. It fails if the client is
skipping to change at page 8, line 30 skipping to change at page 8, line 37
document (forcing the user to continually authenticate, or exposing document (forcing the user to continually authenticate, or exposing
their browser fingerprint.) However, similar tracking can already be their browser fingerprint.) However, similar tracking can already be
performed with the standard captive portal mechanisms, so this performed with the standard captive portal mechanisms, so this
technique does not give the attackers more capabilities. technique does not give the attackers more capabilities.
By simplifying the interaction with the captive portal systems, and By simplifying the interaction with the captive portal systems, and
doing away with the need for interception, we think that users will doing away with the need for interception, we think that users will
be less likely to disable useful security safeguards like DNSSEC be less likely to disable useful security safeguards like DNSSEC
validation, VPNs, etc. In addition, because the system knows that it validation, VPNs, etc. In addition, because the system knows that it
is behind a captive portal, it can know not to send cookies, is behind a captive portal, it can know not to send cookies,
credentials, etc. credentials, etc. Redirection to a portal where TLS can be used
without hijacking can ameliorate some of the implications of
connecting to a potentially malicious captive portal.
8. Acknowledgements 8. Acknowledgements
The primary author has discussed this idea with a number of folk, and The primary author has discussed this idea with a number of folk, and
asked them to assist by becoming co-authors. Unfortunately he has asked them to assist by becoming co-authors. Unfortunately he has
forgotten who many of them were; if you were one of them, I forgotten who many of them were; if you were one of them, I
apologize. apologize.
Thanks to Vint Cerf for the initial idea / asking me to write this. Thanks to Vint Cerf for the initial idea / asking me to write this.
Thanks to Wes George for supplying the IPv6 text. Thanks to Lorenzo Thanks to Wes George for supplying the IPv6 text. Thanks to Lorenzo
and Erik for the V6 RA kick in the pants. and Erik for the V6 RA kick in the pants.
Thanks for Fred Baker for detailed review and comments. Thanks for Fred Baker for detailed review and comments. Also great
thanks to Joel Jaeggli for providing feedback and text.
9. Normative References 9. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
Appendix A. Changes / Author Notes. Appendix A. Changes / Author Notes.
[RFC Editor: Please remove this section before publication ] [RFC Editor: Please remove this section before publication ]
From 05 to 06:
o Integrated comments from Joel, as below
o Better introduction text, around the "kludgy hacks" section.
o Better "neither condones nor condems" text
o Fingerprint text.
o Some discussions on the v4 literal stuff.
o More Security Consideration text.
From 04 to 05: From 04 to 05:
o Integrated comments, primarily from Fred Baker. o Integrated comments, primarily from Fred Baker.
From 03 to 04: From 03 to 04:
o Some text cleanup for readability. o Some text cleanup for readability.
o Some disclaimers about it working better on initial connection o Some disclaimers about it working better on initial connection
versus CP timeout. versus CP timeout.
 End of changes. 15 change blocks. 
21 lines changed or deleted 43 lines changed or added

This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/