draft-ietf-capport-rfc7710bis-04.txt   draft-ietf-capport-rfc7710bis-05.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: October 30, 2020 April 28, 2020 Expires: November 14, 2020 May 13, 2020
Captive-Portal Identification in DHCP / RA Captive-Portal Identification in DHCP / RA
draft-ietf-capport-rfc7710bis-04 draft-ietf-capport-rfc7710bis-05
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
skipping to change at page 2, line 7 skipping to change at page 2, line 7
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 October 30, 2020. This Internet-Draft will expire on November 14, 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
skipping to change at page 2, line 37 skipping to change at page 2, line 37
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 . . . . . . . . . . . . 5 2.3. The Captive-Portal IPv6 RA Option . . . . . . . . . . . . 5
3. Precedence of API URIs . . . . . . . . . . . . . . . . . . . 6 3. Precedence of API URIs . . . . . . . . . . . . . . . . . . . 6
4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6 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
5. Security Considerations . . . . . . . . . . . . . . . . . . . 8 5. Security Considerations . . . . . . . . . . . . . . . . . . . 8
6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 8 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 9
7. References . . . . . . . . . . . . . . . . . . . . . . . . . 9 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 9
7.1. Normative References . . . . . . . . . . . . . . . . . . 9 7.1. Normative References . . . . . . . . . . . . . . . . . . 9
7.2. Informative References . . . . . . . . . . . . . . . . . 10 7.2. Informative References . . . . . . . . . . . . . . . . . 10
Appendix A. Changes / Author Notes. . . . . . . . . . . . . . . 10 Appendix A. Changes / Author Notes. . . . . . . . . . . . . . . 11
Appendix B. Changes from RFC 7710 . . . . . . . . . . . . . . . 11 Appendix B. Changes from RFC 7710 . . . . . . . . . . . . . . . 11
Appendix C. Observations From IETF 106 Network Experiment . . . 11 Appendix C. Observations From IETF 106 Network Experiment . . . 11
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 11 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.
skipping to change at page 8, line 17 skipping to change at page 8, line 17
By removing or reducing the need for captive portals to perform MITM By removing or reducing the need for captive portals to perform MITM
hijacking, this mechanism improves security by making the portal and hijacking, this mechanism improves security by making the portal and
its actions visible, rather than hidden, and reduces the likelihood its actions visible, rather than hidden, and reduces the likelihood
that users will disable useful security safeguards like DNSSEC that users will 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 which is protected with TLS, credentials, etc. By handing out a URI which is protected with TLS,
the captive portal operator can attempt to reassure the user that the the captive portal operator can attempt to reassure the user that the
captive portal is not malicious. captive portal is not malicious.
Each of the options described in this document is presented to a node
using the same protocols used to provision other information critical
to the node's successful configuration on a network. The security
considerations applicable to each of these provisioning mechanisms
also apply when the node is attempting to learn the information
conveyed in these options. In the absence of security measures like
RA Guard ([RFC6105], [RFC7113]) or DHCP Shield [RFC7610], an attacker
could inject, modify, or block DHCP messages or RAs.
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 himself as the default gateway (and so intercept all the simply list themselves as the default gateway (and so intercept all
victim's traffic); this does not provide them with significantly more the victim's traffic); this does not provide them with significantly
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. As the operating systems and application that make use of attack.
However, as the operating systems and application 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) they can render the device (as opposed to intercepted connections) they can render the
page in a sandboxed environment and take other precautions, such as page in a sandboxed environment and take other precautions, such as
clearly labeling the page as untrusted. The means of sandboxing and clearly labeling the page as untrusted. The means of sandboxing and
user interface presenting this information is not covered in this user interface presenting this information is not covered in this
document - by its nature it is implementation specific and best left document - by its nature it is implementation specific and best left
to the application and user interface designers. to the application and user interface designers.
Devices and systems that automatically connect to an open network Devices and systems that automatically connect to an open network
could potentially be tracked using the techniques described in this could potentially be tracked using the techniques described in this
skipping to change at page 10, line 22 skipping to change at page 10, line 32
May 2017, <https://www.rfc-editor.org/info/rfc8174>. May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[RFC8415] Mrugalski, T., Siodelski, M., Volz, B., Yourtchenko, A., [RFC8415] Mrugalski, T., Siodelski, M., Volz, B., Yourtchenko, A.,
Richardson, M., Jiang, S., Lemon, T., and T. Winters, Richardson, M., Jiang, S., Lemon, T., and T. Winters,
"Dynamic Host Configuration Protocol for IPv6 (DHCPv6)", "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)",
RFC 8415, DOI 10.17487/RFC8415, November 2018, RFC 8415, DOI 10.17487/RFC8415, November 2018,
<https://www.rfc-editor.org/info/rfc8415>. <https://www.rfc-editor.org/info/rfc8415>.
7.2. Informative References 7.2. Informative References
[RFC6105] Levy-Abegnoli, E., Van de Velde, G., Popoviciu, C., and J.
Mohacsi, "IPv6 Router Advertisement Guard", RFC 6105,
DOI 10.17487/RFC6105, February 2011,
<https://www.rfc-editor.org/info/rfc6105>.
[RFC7113] Gont, F., "Implementation Advice for IPv6 Router
Advertisement Guard (RA-Guard)", RFC 7113,
DOI 10.17487/RFC7113, February 2014,
<https://www.rfc-editor.org/info/rfc7113>.
[RFC7610] Gont, F., Liu, W., and G. Van de Velde, "DHCPv6-Shield:
Protecting against Rogue DHCPv6 Servers", BCP 199,
RFC 7610, DOI 10.17487/RFC7610, August 2015,
<https://www.rfc-editor.org/info/rfc7610>.
[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>.
7.3. URIs 7.3. URIs
[1] https://tickets.meeting.ietf.org/wiki/IETF106network#Experiments [1] https://tickets.meeting.ietf.org/wiki/IETF106network#Experiments
[2] https://tickets.meeting.ietf.org/wiki/CAPPORT [2] https://tickets.meeting.ietf.org/wiki/CAPPORT
 End of changes. 10 change blocks. 
10 lines changed or deleted 36 lines changed or added

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