< draft-ietf-capport-rfc7710bis-09.txt   draft-ietf-capport-rfc7710bis-10.txt >
Network Working Group W. Kumari Network Working Group W. Kumari
Internet-Draft Google Internet-Draft Google
Obsoletes: 7710 (if approved) E. Kline Obsoletes: 7710 (if approved) E. Kline
Updates: 3679 (if approved) Loon Updates: 3679 (if approved) Loon
Intended status: Standards Track June 24, 2020 Intended status: Standards Track July 1, 2020
Expires: December 26, 2020 Expires: January 2, 2021
Captive-Portal Identification in DHCP / RA Captive-Portal Identification in DHCP / RA
draft-ietf-capport-rfc7710bis-09 draft-ietf-capport-rfc7710bis-10
Abstract Abstract
In many environments offering short-term or temporary Internet access In many environments offering short-term or temporary Internet access
(such as coffee shops), it is common to start new connections in a (such as coffee shops), it is common to start new connections in a
captive portal mode. This highly restricts what the user can do captive portal mode. This highly restricts what the user can do
until the user has satified the Captive Portal conditions. until the user has satisfied the captive portal conditions.
This document describes a DHCPv4 and DHCPv6 option and a Router This document describes a DHCPv4 and DHCPv6 option and a Router
Advertisement (RA) option to inform clients that they are behind some Advertisement (RA) option to inform clients that they are behind some
sort of captive-portal enforcement device, and that they will need to sort of captive portal enforcement device, and that they will need to
satify the Captive Portal conditions to get Internet access. It is satify the Captive Portal conditions to get Internet access. It is
not a full solution to address all of the issues that clients may not a full solution to address all of the issues that clients may
have with captive portals; it is designed to be one component of a have with captive portals; it is designed to be one component of a
standardized approach for hosts to interact with such portals. While standardized approach for hosts to interact with such portals. While
this document defines how the network operator may convey the captive this document defines how the network operator may convey the captive
portal API endpoint to hosts, the specific methods of satisfying and portal API endpoint to hosts, the specific methods of satisfying and
interacting with the captive portal are out of scope of this interacting with the captive portal are out of scope of this
document. document.
This document replaces [RFC7710]. [RFC7710] used DHCP code point This document replaces [RFC7710]. [RFC7710] used DHCP code point
160. Due to a conflict, this document specifies 114. Consequently, 160. Due to a conflict, this document specifies 114. Consequently,
this document also updates [RFC3679]. this document also updates [RFC3679].
[ This document is being collaborated on in Github at:
https://github.com/capport-wg/7710bis. The most recent version of
the document, open issues, etc should all be available here. The
authors (gratefully) accept pull requests. Text in square brackets
will be removed before publication. ]
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
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 https://datatracker.ietf.org/drafts/current/. Drafts is at https://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 January 2, 2021.
This Internet-Draft will expire on December 26, 2020.
Copyright Notice Copyright Notice
Copyright (c) 2020 IETF Trust and the persons identified as the Copyright (c) 2020 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
(https://trustee.ietf.org/license-info) in effect on the date of (https://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
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
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 . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1. Requirements Notation . . . . . . . . . . . . . . . . . . 3 1.1. Requirements Notation . . . . . . . . . . . . . . . . . . 3
2. The Captive-Portal Option . . . . . . . . . . . . . . . . . . 3 2. The Captive-Portal Option . . . . . . . . . . . . . . . . . . 3
2.1. IPv4 DHCP Option . . . . . . . . . . . . . . . . . . . . 4 2.1. IPv4 DHCP Option . . . . . . . . . . . . . . . . . . . . 4
2.2. IPv6 DHCP Option . . . . . . . . . . . . . . . . . . . . 5 2.2. IPv6 DHCP Option . . . . . . . . . . . . . . . . . . . . 5
2.3. The Captive-Portal IPv6 RA Option . . . . . . . . . . . . 6 2.3. The Captive-Portal IPv6 RA Option . . . . . . . . . . . . 5
3. Precedence of API URIs . . . . . . . . . . . . . . . . . . . 6 3. Precedence of API URIs . . . . . . . . . . . . . . . . . . . 6
4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6
4.1. Captive Portal Unrestricted Identifier . . . . . . . . . 7 4.1. Captive Portal Unrestricted Identifier . . . . . . . . . 7
4.2. BOOTP Vendor Extensions and DHCP Options Code Change . . 7 4.2. BOOTP Vendor Extensions and DHCP Options Code Change . . 7
4.3. Update DHCPv6 and IPv6 ND Options Registries . . . . . . 8 4.3. Update DHCPv6 and IPv6 ND Options Registries . . . . . . 7
5. Security Considerations . . . . . . . . . . . . . . . . . . . 8 5. Security Considerations . . . . . . . . . . . . . . . . . . . 8
6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 9 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 9
7. References . . . . . . . . . . . . . . . . . . . . . . . . . 9 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 9
7.1. Normative References . . . . . . . . . . . . . . . . . . 9 7.1. Normative References . . . . . . . . . . . . . . . . . . 9
7.2. Informative References . . . . . . . . . . . . . . . . . 11 7.2. Informative References . . . . . . . . . . . . . . . . . 10
Appendix A. Changes / Author Notes. . . . . . . . . . . . . . . 11 Appendix A. Changes / Author Notes. . . . . . . . . . . . . . . 11
Appendix B. Changes from RFC 7710 . . . . . . . . . . . . . . . 12 Appendix B. Changes from RFC 7710 . . . . . . . . . . . . . . . 12
Appendix C. Observations From IETF 106 Network Experiment . . . 12 Appendix C. Observations From IETF 106 Network Experiment . . . 12
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 12 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 12
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 (AUP) and / or provide device and agree to an Acceptable Use Policy (AUP) and / or provide
billing information before they can access the Internet. Regardless billing information before they can access the Internet. Regardless
of how that mechanism operates, this document provides functionality of how that mechanism operates, this document provides functionality
to allow the client to know when it is behind a captive portal and to allow the client to know when it is behind a captive portal and
how to contact it. how to contact it.
In order to present users with the payment or AUP pages, presently a In order to present users with the payment or AUP pages, presently a
captive-portal enforcement device has to intercept the user's captive portal enforcement device has to intercept the user's
connections and redirect the user to a captive portal server, using connections and redirect the user to a captive portal server, using
methods that are very similar to man-in-the-middle (MITM) attacks. methods that are very similar to man-in-the-middle (MITM) attacks.
As increasing focus is placed on security, and end nodes adopt a more As increasing focus is placed on security, and end nodes adopt a more
secure stance, these interception techniques will become less secure stance, these interception techniques will become less
effective and/or more intrusive. effective and/or more intrusive.
This document describes a DHCPv4 [RFC2131] and DHCPv6 [RFC8415] This document describes a DHCPv4 [RFC2131] and DHCPv6 [RFC8415]
option (Captive-Portal) and an IPv6 Router Advertisement (RA) option (Captive-Portal) and an IPv6 Router Advertisement (RA)
[RFC4861] option that informs clients that they are behind a captive- [RFC4861] option that informs clients that they are behind a captive
portal enforcement device and the API endpoint that the host can portal enforcement device and the API endpoint that the host can
contact for more information. contact for more information.
This document replaces RFC 7710 [RFC7710]. This document replaces RFC 7710 [RFC7710].
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", "NOT RECOMMENDED", "MAY", and "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in BCP "OPTIONAL" in this document are to be interpreted as described in BCP
14 [RFC2119] [RFC8174] when, and only when, they appear in all 14 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here. capitals, as shown here.
2. The Captive-Portal Option 2. The Captive-Portal Option
The Captive Portal DHCP / RA Option informs the client that it may be The Captive-Portal DHCP / RA Option informs the client that it may be
behind a captive portal and provides the URI to access an API as behind a captive portal and provides the URI to access an API as
defined by [draft-ietf-capport-api]. This is primarily intended to defined by [draft-ietf-capport-api]. This is primarily intended to
improve the user experience by showing the user the captive portal improve the user experience by showing the user the captive portal
information faster and more reliably. Note that, for the foreseeable information faster and more reliably. Note that, for the foreseeable
future, captive portals will still need to implement interception future, captive portals will still need to implement interception
techniques to serve legacy clients, and clients will need to perform techniques to serve legacy clients, and clients will need to perform
probing to detect captive portals. probing to detect captive portals"; nonetheless, the mechanism
provided by this document provides a more reliable and performant way
to do so, and is therefore the preferred mechanism for captive portal
detection.
Clients that support the Captive Portal DHCP option SHOULD include Clients that support the Captive Portal DHCP option SHOULD include
the option in the Parameter Request List in DHCPREQUEST messages. the option in the Parameter Request List in DHCPREQUEST messages.
DHCP servers MAY send the Captive Portal option without any explicit DHCP servers MAY send the Captive Portal option without any explicit
request. request.
In order to support multiple "classes" of clients (e.g. IPv4 only, In order to support multiple "classes" of clients (e.g. IPv4 only,
IPv6 only with DHCPv6 ([RFC8415]), and IPv6 only with RA) the captive IPv6 only with DHCPv6 ([RFC8415]), and IPv6 only with RA) the captive
network can provision the client with the URI via multiple methods network can provision the client with the URI via multiple methods
(IPv4 DHCP, IPv6 DHCP, and IPv6 RA). The captive portal operator (IPv4 DHCP, IPv6 DHCP, and IPv6 RA). The captive portal operator
skipping to change at page 8, line 52 skipping to change at page 8, line 41
An attacker with the ability to inject DHCP messages or RAs could An attacker with the ability to inject DHCP messages or RAs could
include an option from this document to force users to contact an include an option from this document to force users to contact an
address of his choosing. As an attacker with this capability could address of his choosing. As an attacker with this capability could
simply list themselves as the default gateway (and so intercept all simply list themselves as the default gateway (and so intercept all
the victim's traffic); this does not provide them with significantly the victim's traffic); this does not provide them with significantly
more capabilities, but because this document removes the need for more capabilities, but because this document removes the need for
interception, the attacker may have an easier time performing the interception, the attacker may have an easier time performing the
attack. attack.
However, as the operating systems and application(s) that make use of However, as the operating systems and application(s) that make use of
this information know that they are connecting to a captive-portal this information know that they are connecting to a captive portal
device (as opposed to intercepted connections where the OS/ device (as opposed to intercepted connections where the OS/
application may not know that they are connecting to a captive portal application may not know that they are connecting to a captive portal
or hostile device) they can render the page in a sandboxed or hostile device) they can render the page in a sandboxed
environment and take other precautions, such as clearly labeling the environment and take other precautions, such as clearly labeling the
page as untrusted. The means of sandboxing and user interface page as untrusted. The means of sandboxing and user interface
presenting this information is not covered in this document - by its presenting this information is not covered in this document - by its
nature it is implementation specific and best left to the application nature it is implementation specific and best left to the application
and user interface designers. and user interface designers.
Devices and systems that automatically connect to an open network Devices and systems that automatically connect to an open network
 End of changes. 17 change blocks. 
24 lines changed or deleted 20 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/