< 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.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/