< draft-kuehlewind-quic-substrate-01.txt		draft-kuehlewind-quic-substrate-02.txt >
	Network Working Group M. Kuehlewind		Network Working Group M. Kuehlewind
	Internet-Draft Z. Sarker		Internet-Draft Z. Sarker
	Intended status: Informational Ericsson		Intended status: Informational Ericsson
	Expires: January 6, 2020 T. Fossati		Expires: May 7, 2020 T. Fossati
	Arm		Arm
	L. Pardue		L. Pardue
	Cloudflare		Cloudflare
	July 05, 2019		November 04, 2019
	Use Cases and Requirements for QUIC as a Substrate		Use Cases and Requirements for QUIC as a Substrate
	draft-kuehlewind-quic-substrate-01		draft-kuehlewind-quic-substrate-02
	Abstract		Abstract
	TCP is often used as a proxying or tunneling protocol. QUIC is a		TCP is often used as a proxying or tunneling protocol. QUIC is a
	new, emerging transport protocol and there is a similar expectation		new, emerging transport protocol and there is a similar expectation
	that it too will be used as a substrate once it is widely deployed.		that it too will be used as a substrate once it is widely deployed.
	Using QUIC instead of TCP in existing scenarios will allow proxying		Using QUIC instead of TCP in existing scenarios will allow proxying
	and tunneling services to maintain the benefits of QUIC natively,		and tunneling services to maintain the benefits of QUIC natively,
	without degrading the performance and security characteristics. QUIC		without degrading the performance and security characteristics. QUIC
	also opens up new opportunities for these services to have lower		also opens up new opportunities for these services to have lower
	skipping to change at page 1, line 43 ¶		skipping to change at page 1, line 43 ¶
	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 6, 2020.		This Internet-Draft will expire on May 7, 2020.
	Copyright Notice		Copyright Notice
	Copyright (c) 2019 IETF Trust and the persons identified as the		Copyright (c) 2019 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 7, line 24 ¶		skipping to change at page 7, line 24 ¶
	TLS [I-D.friel-tls-atls] from the sensors to the cloud together with		TLS [I-D.friel-tls-atls] from the sensors to the cloud together with
	a multiplexed secure tunnel (e.g., using HTTP/2 Websockets [RFC8441],		a multiplexed secure tunnel (e.g., using HTTP/2 Websockets [RFC8441],
	or a proprietary shim) from the gateway to the cloud. In the future,		or a proprietary shim) from the gateway to the cloud. In the future,
	a more homogeneous solution could be provided by QUIC		a more homogeneous solution could be provided by QUIC
	[I-D.ietf-quic-transport] for both the end-to-end and tunneling		[I-D.ietf-quic-transport] for both the end-to-end and tunneling
	services, thus simplifying code dependencies on the gateway nodes.		services, thus simplifying code dependencies on the gateway nodes.
	2.5. Multi-hop Chaining Usage		2.5. Multi-hop Chaining Usage
	Providing a generic approach to use QUIC as a substrate also enables		Providing a generic approach to use QUIC as a substrate also enables
	the combination of multiples of the above use cases. For example,		the combination of multiple of the above use cases. For example,
	employing multiple obfuscating proxies in sequence, where the		employing multiple obfuscating proxies in sequence, where the
	communication with each proxy is individually secured, can enable		communication with each proxy is individually secured, can enable
	onion-like layered security. Each proxy will only know the address		onion-like layered security. Each proxy will only know the address
	of the prior hop and after itself, similar as provided by onion		of the prior hop and after itself, similar as provided by onion
	routing in Tor project [TOR].		routing in Tor project [TOR].
	Further it would also be possible to chain proxies for different		Further it would also be possible to chain proxies for different
	reasons. A client may select proxying support from its access		reasons. A client may select proxying support from its access
	network, while a web service provider may utilize a front-end load		network, while a web service provider may utilize a front-end load
	balancing proxy to provide end-to-end secure communication with the		balancing proxy to provide end-to-end secure communication with the
	skipping to change at page 8, line 5 ¶		skipping to change at page 8, line 5 ¶
	exchange measurement information in order to optimize the QUIC		exchange measurement information in order to optimize the QUIC
	connection over a specific segment.		connection over a specific segment.
	The above examples indicates that a solution likely have to consider		The above examples indicates that a solution likely have to consider
	how to establish a security model so that endpoints can selectively		how to establish a security model so that endpoints can selectively
	choose what connection related information to share with the		choose what connection related information to share with the
	different proxy entities. The possible efficiency should also be		different proxy entities. The possible efficiency should also be
	consider and multiple layers of encapsulation should be avoided when		consider and multiple layers of encapsulation should be avoided when
	the security model allows for it.		the security model allows for it.
			2.5.1. Considerations for Multiple Encryption
			Using QUIC in a multi-hop fashion will generally cause all user data
			to be encrypted multiple times, once for each hop. There are two
			main reasons to encrypt data multiple times in a multi-hop network:
			1. To ensure that no hop can see both the connection metadata of the
			client and the server (thus obfuscating IP addresses and other
			related data that is visible in cleartext in the transport
			protocol headers).
			2. To prevent an attacker from being able to correlate data between
			different hops to identify a particular flow of data as it passes
			through multiple hops.
			However, multiple layers of encryption can have a noticable impact on
			the end-to-end latency of data. When a Tor-like approach is used,
			each piece of user data will be encrypted N times, where N is the
			number of hops. Devices such as IoT devices that do not have
			optimized cryptographic process, or are constrained in terms of
			processing or power usage, could notice a slowdown due to the extra
			overhead.
			Since QUIC is an encrypted transport, it is possible that all packets
			after a handshake is completed are opaque to any attacker. Short-
			header packets, particularly those that have zero-length Connection
			IDs, only send encrypted fields. Thus, for all packets beyond the
			QUIC handshake, encrypting packets multiple times through a multi-hop
			proxy primarily achieves benefit 2 described above, since benefit 1
			is already achieved by QUIC being forwarded without re-encrytion. If
			a deployment is more concerned with benefit 1 than benefit 2, it
			might be preferable to use a solution that forwards QUIC packets
			without re-encrypting once QUIC handshakes are complete.
	3. Requirements		3. Requirements
	To use QUIC as a substrate, it could be beneficial if unreliable		To use QUIC as a substrate, it could be beneficial if unreliable
	transmission is supported as well as having a way to potentially		transmission is supported as well as having a way to potentially
	influence or disable congestion control if the inner tunnel traffic		influence or disable congestion control if the inner tunnel traffic
	is known to be congestion controlled.		is known to be congestion controlled.
	Communication between the client and proxy is more likely to be		Communication between the client and proxy is more likely to be
	realized as a separate protocol on top of QUIC or HTTP. However, a		realized as a separate protocol on top of QUIC or HTTP. However, a
	QUIC extensibility mechanism could be used to indicate to the		QUIC extensibility mechanism could be used to indicate to the
	skipping to change at page 8, line 36 ¶		skipping to change at page 9, line 22 ¶
	example, the Dynamic Host Configuration Protocol). Alternatively,		example, the Dynamic Host Configuration Protocol). Alternatively,
	the client could obtain a white-listed proxy address when making		the client could obtain a white-listed proxy address when making
	first contact with the server (CNAME/IPaddress). In both cases the		first contact with the server (CNAME/IPaddress). In both cases the
	proxy needs to have a routable address and name.		proxy needs to have a routable address and name.
	4. Contributors		4. Contributors
	Magnus Westerlund has contributed two paragraphs on combining		Magnus Westerlund has contributed two paragraphs on combining
	proxies.		proxies.
	5. Acknowledgments		Tommy Pauly has contributed text on multiple layers of encryption,
			and other edits to the use cases.
	Thanks to Tommy Pauly for contributing thoughts and comments on these
	use cases, as well as text edits!
	6. Informative References		5. Informative References
	[I-D.friel-tls-atls]		[I-D.friel-tls-atls]
	Friel, O., Barnes, R., Pritikin, M., Tschofenig, H., and		Friel, O., Barnes, R., Pritikin, M., Tschofenig, H., and
	M. Baugher, "Application-Layer TLS", draft-friel-tls-		M. Baugher, "Application-Layer TLS", draft-friel-tls-
	atls-02 (work in progress), March 2019.		atls-03 (work in progress), July 2019.
	[I-D.ietf-quic-transport]		[I-D.ietf-quic-transport]
	Iyengar, J. and M. Thomson, "QUIC: A UDP-Based Multiplexed		Iyengar, J. and M. Thomson, "QUIC: A UDP-Based Multiplexed
	and Secure Transport", draft-ietf-quic-transport-20 (work		and Secure Transport", draft-ietf-quic-transport-23 (work
	in progress), April 2019.		in progress), September 2019.
	[I-D.ietf-tls-dtls-connection-id]		[I-D.ietf-tls-dtls-connection-id]
	Rescorla, E., Tschofenig, H., and T. Fossati, "Connection		Rescorla, E., Tschofenig, H., and T. Fossati, "Connection
	Identifiers for DTLS 1.2", draft-ietf-tls-dtls-connection-		Identifiers for DTLS 1.2", draft-ietf-tls-dtls-connection-
	id-05 (work in progress), May 2019.		id-07 (work in progress), October 2019.
	[RFC8441] McManus, P., "Bootstrapping WebSockets with HTTP/2",		[RFC8441] McManus, P., "Bootstrapping WebSockets with HTTP/2",
	RFC 8441, DOI 10.17487/RFC8441, September 2018,		RFC 8441, DOI 10.17487/RFC8441, September 2018,
	<https://www.rfc-editor.org/info/rfc8441>.		<https://www.rfc-editor.org/info/rfc8441>.
	[TOR] "TOR Project", June 2019, <https://www.torproject.org/>.		[TOR] "TOR Project", June 2019, <https://www.torproject.org/>.
	Authors' Addresses		Authors' Addresses
	Mirja Kuehlewind		Mirja Kuehlewind
End of changes. 11 change blocks.
	14 lines changed or deleted		46 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/