< draft-ietf-capport-rfc7710bis-01.txt   draft-ietf-capport-rfc7710bis-02.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
Intended status: Standards Track Loon Intended status: Standards Track Loon
Expires: July 15, 2020 January 12, 2020 Expires: September 8, 2020 March 7, 2020
Captive-Portal Identification in DHCP / RA Captive-Portal Identification in DHCP / RA
draft-ietf-capport-rfc7710bis-01 draft-ietf-capport-rfc7710bis-02
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 customer can do captive portal mode. This highly restricts what the customer can do
until the customer has authenticated. until the customer has authenticated.
This document describes a DHCP option (and a Router Advertisement This document describes a DHCP option (and a Router Advertisement
(RA) extension) to inform clients that they are behind some sort of (RA) extension) to inform clients that they are behind some sort of
captive-portal device, and that they will need to authenticate to get captive-portal device, and that they will need to authenticate to get
Internet access. It is not a full solution to address all of the Internet access. It is not a full solution to address all of the
issues that clients may have with captive portals; it is designed to issues that clients may have with captive portals; it is designed to
be used in larger solutions. The method of authenticating to, and be used in larger solutions. The method of authenticating to, and
interacting with the captive portal is out of scope of this document. interacting with the captive portal is out of scope of this document.
RFC7710 used DHCP code point 160. Due to a conflict, this document
specifies TBD.
[ This document is being collaborated on in Github at: [ This document is being collaborated on in Github at:
https://github.com/wkumari/draft-ekwk-capport-rfc7710bis. The most https://github.com/capport-wg/7710bis. The most recent version of
recent version of the document, open issues, etc should all be the document, open issues, etc should all be available here. The
available here. The authors (gratefully) accept pull requests. Text authors (gratefully) accept pull requests. Text in square brackets
in square brackets will be removed before publication. ] 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 http://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 September 8, 2020.
This Internet-Draft will expire on July 15, 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
(http://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 . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
skipping to change at page 2, line 45 skipping to change at page 2, line 46
7. Normative References . . . . . . . . . . . . . . . . . . . . 8 7. Normative References . . . . . . . . . . . . . . . . . . . . 8
Appendix A. Changes / Author Notes. . . . . . . . . . . . . . . 10 Appendix A. Changes / Author Notes. . . . . . . . . . . . . . . 10
Appendix B. Changes from RFC 7710 . . . . . . . . . . . . . . . 10 Appendix B. Changes from RFC 7710 . . . . . . . . . . . . . . . 10
Appendix C. Observations From IETF 106 Network Experiment . . . 10 Appendix C. Observations From IETF 106 Network Experiment . . . 10
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 11 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 11
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. It is billing information before they can access the Internet. Regardless
anticipated that the IETF will work on a more fully featured protocol of how that mechanism operates, this document provides functionality
at some point, to ease interaction with Captive Portals. Regardless to allow the client to know when it is behind a captive portal and
of how that protocol operates, it is expected that this document will how to contact it.
provide needed functionality because the client will need to know
when it is behind a captive portal and how to contact it.
In order to present users with the payment or AUP pages, the captive- In order to present users with the payment or AUP pages, the captive-
portal device has to intercept the user's connections and redirect portal device has to intercept the user's connections and redirect
the user to the captive portal, using methods that are very similar the user to the captive portal, using methods that are very similar
to man-in-the-middle (MITM) attacks. As increasing focus is placed to man-in-the-middle (MITM) attacks. As increasing focus is placed
on security, and end nodes adopt a more secure stance, these on security, and end nodes adopt a more secure stance, these
interception techniques will become less effective and/or more interception techniques will become less effective and/or more
intrusive. intrusive.
This document describes a DHCP ([RFC2131]) option (Captive-Portal) This document describes a DHCP ([RFC2131]) option (Captive-Portal)
skipping to change at page 4, line 41 skipping to change at page 4, line 41
2.1. IPv4 DHCP Option 2.1. IPv4 DHCP Option
The format of the IPv4 Captive-Portal DHCP option is shown below. The format of the IPv4 Captive-Portal DHCP option is shown below.
Code Len Data Code Len Data
+------+------+------+------+------+-- --+-----+ +------+------+------+------+------+-- --+-----+
| code | len | URI ... | | code | len | URI ... |
+------+------+------+------+------+-- --+-----+ +------+------+------+------+------+-- --+-----+
o Code: The Captive-Portal DHCPv4 Option (160) (one octet) o Code: The Captive-Portal DHCPv4 Option (TBD) (one octet)
o Len: The length, in octets of the URI. o Len: The length, in octets of the URI.
o URI: The URI for the captive portal API endpoint to which the user o URI: The URI for the captive portal API endpoint to which the user
should connect (encoded following the rules in [RFC3986]). should connect (encoded following the rules in [RFC3986]).
2.2. IPv6 DHCP Option 2.2. IPv6 DHCP Option
The format of the IPv6 Captive-Portal DHCP option is shown below. The format of the IPv6 Captive-Portal DHCP option is shown below.
skipping to change at page 6, line 20 skipping to change at page 6, line 20
However, if the URIs learned are not in fact all identical the However, if the URIs learned are not in fact all identical the
captive device MUST prioritize URIs learned from network provisioning captive device MUST prioritize URIs learned from network provisioning
or configuration mechanisms before all other URIs. Specifically, or configuration mechanisms before all other URIs. Specifically,
URIs learned via any of the options in Section 2 should take URIs learned via any of the options in Section 2 should take
precedence over any URI learned via some other mechanism, such as a precedence over any URI learned via some other mechanism, such as a
redirect. redirect.
If the URIs learned via more than one option described in Section 2 If the URIs learned via more than one option described in Section 2
are not all identical, this condition should be logged for the device are not all identical, this condition should be logged for the device
owner or administrator. URI precedence in this situation is not owner or administrator. Implementations can select their own
specified by this document. precedence order.
4. IANA Considerations 4. IANA Considerations
This document requests two new IETF URN protocol parameter This document requests one new IETF URN protocol parameter
([RFC3553]) entries. This document also requests a reallocation of ([RFC3553]) entry. This document also requests a reallocation of
DHCPv4 option codes (see Appendix C for background). DHCPv4 option codes (see Appendix C for background).
Thanks IANA! Thanks IANA!
4.1. IETF params Registration 4.1. IETF params Registration
4.1.1. Registry name: Captive Portal Unrestricted Identifier 4.1.1. Registry name: Captive Portal Unrestricted Identifier
Registry name: Captive Portal Unrestricted Identifier Registry name: Captive Portal Unrestricted Identifier
skipping to change at page 8, line 17 skipping to change at page 8, line 17
DHCP or RA option is a cleaner technique, and reduces user DHCP or RA option is a cleaner technique, and reduces user
expectations of being hijacked - this may improve security by making expectations of being hijacked - this may improve security by making
users more reluctant to accept TLS hijacking, which can be performed users more reluctant to accept TLS hijacking, which can be performed
from beyond the network associated with the captive portal. from beyond the network associated with the captive portal.
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. By handing out a URI using which is protected with credentials, etc. By handing out a URI which is protected with TLS,
TLS, the captive portal operator can attempt to reassure the user the captive portal operator can attempt to reassure the user that the
that the captive portal is not malicious. captive portal is not malicious.
Operating systems should conduct all interactions with the API in a
sand-boxed environment and with a configuration that minimizes
tracking risks.
6. Acknowledgements 6. Acknowledgements
This document is a -bis of RFC7710. Thanks to all of the original This document is a -bis of RFC7710. Thanks to all of the original
authors (Warren Kumari, Olafur Gudmundsson, Paul Ebersman, Steve authors (Warren Kumari, Olafur Gudmundsson, Paul Ebersman, Steve
Sheng), and original contributors. Sheng), and original contributors.
Also thanks to the CAPPORT WG for all of the discussion and Also thanks to the CAPPORT WG for all of the discussion and
improvements including contributions and review from Lorenzo Colitti, improvements including contributions and review from Joe Clarke,
Remi Nguyen Van, and Tommy Pauly. Lorenzo Colitti, Dave Dolson, Hans Kuhn, Kyle Larose, Clemens
Schimpe, Martin Thompson, Michael Richardson, Remi Nguyen Van, Bernie
Volz, and Tommy Pauly.
7. References 7. References
7.1. Normative References 7.1. 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, Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997, <https://www.rfc- DOI 10.17487/RFC2119, March 1997,
editor.org/info/rfc2119>. <https://www.rfc-editor.org/info/rfc2119>.
[RFC2131] Droms, R., "Dynamic Host Configuration Protocol", [RFC2131] Droms, R., "Dynamic Host Configuration Protocol",
RFC 2131, DOI 10.17487/RFC2131, March 1997, RFC 2131, DOI 10.17487/RFC2131, March 1997,
<https://www.rfc-editor.org/info/rfc2131>. <https://www.rfc-editor.org/info/rfc2131>.
[RFC3315] Droms, R., Ed., Bound, J., Volz, B., Lemon, T., Perkins, [RFC3315] Droms, R., Ed., Bound, J., Volz, B., Lemon, T., Perkins,
C., and M. Carney, "Dynamic Host Configuration Protocol C., and M. Carney, "Dynamic Host Configuration Protocol
for IPv6 (DHCPv6)", RFC 3315, DOI 10.17487/RFC3315, July for IPv6 (DHCPv6)", RFC 3315, DOI 10.17487/RFC3315, July
2003, <https://www.rfc-editor.org/info/rfc3315>. 2003, <https://www.rfc-editor.org/info/rfc3315>.
skipping to change at page 9, line 17 skipping to change at page 9, line 17
Parameters", BCP 73, RFC 3553, DOI 10.17487/RFC3553, June Parameters", BCP 73, RFC 3553, DOI 10.17487/RFC3553, June
2003, <https://www.rfc-editor.org/info/rfc3553>. 2003, <https://www.rfc-editor.org/info/rfc3553>.
[RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
Resource Identifier (URI): Generic Syntax", STD 66, Resource Identifier (URI): Generic Syntax", STD 66,
RFC 3986, DOI 10.17487/RFC3986, January 2005, RFC 3986, DOI 10.17487/RFC3986, January 2005,
<https://www.rfc-editor.org/info/rfc3986>. <https://www.rfc-editor.org/info/rfc3986>.
[RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman,
"Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861,
DOI 10.17487/RFC4861, September 2007, <https://www.rfc- DOI 10.17487/RFC4861, September 2007,
editor.org/info/rfc4861>. <https://www.rfc-editor.org/info/rfc4861>.
[RFC7227] Hankins, D., Mrugalski, T., Siodelski, M., Jiang, S., and [RFC7227] Hankins, D., Mrugalski, T., Siodelski, M., Jiang, S., and
S. Krishnan, "Guidelines for Creating New DHCPv6 Options", S. Krishnan, "Guidelines for Creating New DHCPv6 Options",
BCP 187, RFC 7227, DOI 10.17487/RFC7227, May 2014, BCP 187, RFC 7227, DOI 10.17487/RFC7227, May 2014,
<https://www.rfc-editor.org/info/rfc7227>. <https://www.rfc-editor.org/info/rfc7227>.
[RFC7231] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer [RFC7231] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer
Protocol (HTTP/1.1): Semantics and Content", RFC 7231, Protocol (HTTP/1.1): Semantics and Content", RFC 7231,
DOI 10.17487/RFC7231, June 2014, <https://www.rfc- DOI 10.17487/RFC7231, June 2014,
editor.org/info/rfc7231>. <https://www.rfc-editor.org/info/rfc7231>.
[RFC7234] Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke, [RFC7234] Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke,
Ed., "Hypertext Transfer Protocol (HTTP/1.1): Caching", Ed., "Hypertext Transfer Protocol (HTTP/1.1): Caching",
RFC 7234, DOI 10.17487/RFC7234, June 2014, RFC 7234, DOI 10.17487/RFC7234, June 2014,
<https://www.rfc-editor.org/info/rfc7234>. <https://www.rfc-editor.org/info/rfc7234>.
[RFC7710] Kumari, W., Gudmundsson, O., Ebersman, P., and S. Sheng, [RFC7710] Kumari, W., Gudmundsson, O., Ebersman, P., and S. Sheng,
"Captive-Portal Identification Using DHCP or Router "Captive-Portal Identification Using DHCP or Router
Advertisements (RAs)", RFC 7710, DOI 10.17487/RFC7710, Advertisements (RAs)", RFC 7710, DOI 10.17487/RFC7710,
December 2015, <https://www.rfc-editor.org/info/rfc7710>. December 2015, <https://www.rfc-editor.org/info/rfc7710>.
skipping to change at page 10, line 37 skipping to change at page 10, line 37
2. Clarify that the option URI SHOULD be that of the captive portal 2. Clarify that the option URI SHOULD be that of the captive portal
API endpoint. API endpoint.
3. Clarify that captive portals MAY do content negotiation. 3. Clarify that captive portals MAY do content negotiation.
4. Added text about Captive Portal API URI precedence in the event 4. Added text about Captive Portal API URI precedence in the event
of a network configuration error. of a network configuration error.
5. Added urn:ietf:params:capport-unrestricted URN. 5. Added urn:ietf:params:capport-unrestricted URN.
6. Notes that the DHCP Code changed from 160 to 114.
Appendix C. Observations From IETF 106 Network Experiment Appendix C. Observations From IETF 106 Network Experiment
During IETF 106 in Singapore an experiment [1] enabling Captive During IETF 106 in Singapore an experiment [1] enabling Captive
Portal API compatible clients to discover a venue-info-url (see Portal API compatible clients to discover a venue-info-url (see
experiment description [2] for more detail) revealed that some experiment description [2] for more detail) revealed that some
Polycom devices on the same network made use of DHCPv4 option code Polycom devices on the same network made use of DHCPv4 option code
160 for other purposes [3]. 160 for other purposes [3].
The presence of DHCPv4 Option code 160 holding a value indicating the The presence of DHCPv4 Option code 160 holding a value indicating the
Captive Portal API URL caused these devices to not function as Captive Portal API URL caused these devices to not function as
 End of changes. 17 change blocks. 
36 lines changed or deleted 36 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/