< draft-kuehlewind-quic-substrate-00.txt   draft-kuehlewind-quic-substrate-01.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: December 9, 2019 T. Fossati Expires: January 6, 2020 T. Fossati
Arm Arm
June 07, 2019 L. Pardue
Cloudflare
July 05, 2019
Use Cases and Requirements for QUIC as a Substrate Use Cases and Requirements for QUIC as a Substrate
draft-kuehlewind-quic-substrate-00 draft-kuehlewind-quic-substrate-01
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 41 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 December 9, 2019. This Internet-Draft will expire on January 6, 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 5, line 26 skipping to change at page 5, line 26
characteristics as those may change frequently. characteristics as those may change frequently.
Similar as in the previous usage scenario, in this setup the client Similar as in the previous usage scenario, in this setup the client
explicitly selects the proxy and specifies the requested support explicitly selects the proxy and specifies the requested support
function. Often the server may not need to be aware of it, however, function. Often the server may not need to be aware of it, however,
depending on the optimization function, server cooperation could be depending on the optimization function, server cooperation could be
beneficial as well. However, the client and the proxy need a direct beneficial as well. However, the client and the proxy need a direct
and secured communication channel in order to request and configure a and secured communication channel in order to request and configure a
service and exchange or expose the needed information and metadata. service and exchange or expose the needed information and metadata.
2.2.1. Security and Access Policy Enforcement
Some deployment models may wish to enforce security or access
policies on traffic flowing between domains (physical, logical,
administrative, security etc.). To support this, endpoints
coordinate through a gateway that can require information about the
transport layer, application layer and application content. Policy
is generally configured out-of-band, either statically or through
some independent control plane.
In one use case, the enforcement function controls egress traffic; a
client connects to a proxy, typically inside the same domain, in
order to cross the domain boundary. In another use case, the
enforcement function controls ingress traffic; a client connects to a
proxy that controls access to the ultimate destination. This may be
deployed inside the target domain, near it, or further away as a part
of a third-party security service. Clients are usually remote and
diverse, and use connections that have crossed several other domains
(with or without tunnels).
Enforcement functions typically require some form of client
authentication such as username, password or certificate.
Authentication is enforced at the earliest stage of communication.
Enforcement rules might require access to transport characteristics
of the ultimate endpoints (such as client source IP address). This
might change as traffic moves between domains, whether tunneling is
used or not. Therefore, it can be desireable to encapsulate original
information in form accessible to the enforcement function.
2.3. Frontend Support for Load Balancing and Migration/Mobility 2.3. Frontend Support for Load Balancing and Migration/Mobility
In this usage scenario the application service provider aims for Application service providers aiming to improve access flexibility
flexibility in server selection, therefore the client communicates might use proxies in front of their services.
with a reverse proxy that may or may not be under the authority of
the service provider. Such a proxy assists the client to access and
select the content requested. Today reverse proxies terminate the
connection, including the security association, and as such appear as
the communication endpoint to the client. Terminating not only the
transport connection but also the security association is especially
problematic if the proxy provider is not under the direct authority
of the actual service provider but a contracted third party.
A similar setup may be used to perform load balancing or migration In one usage scenario the client communicates with a reverse proxy
for mobility support, of both the server or client, where a frontend that assists with access to and selection of the content requested.
proxy can redirect the traffic to a different backend server. Today This proxy that may or may not be under the authority of the service
this is realized fully transparent to the client and the client is provider. Today such reverse proxies terminate the connection,
not aware of the network setup behind the proxy. However, such a including the security association, and as such appear as the
setup may as well benefit in future from an explicit tunneling or communication endpoint to the client. Terminating both transport and
proxying approach. security may be problematic if the proxy provider is not under the
direct authority of the actual service provider (e.g. a contracted
third party).
In this usage scenario the client interact with a proxy that is In another usage scenario the client communicates with a frontend
located close to the server and potentially even under the same proxy that manages traffic steering to assist with load balancing or
administrative domain or at least has some trust relationship with migration for mobility support of server or client. This proxy is
the application service provider. The server is aware of this setup more likely to be located close to the server and under the same
and may have an own communication channel with the proxy or tunnel administrative domain, or at least has some trust relationship with
endpoint as well, in order to advise it about server selection. the application service provider. The server may have its own
However, the client is usually not aware of any specifics about the communication channel with the proxy or tunnel endpoint in order to
setup behind the substrate endpoint. provide data that is used for decision making. Meanwhile, the client
is usually not aware of any specifics of the setup behind the
substrate endpoint. However, improving visibility may benefit future
explicit tunneling or proxying approaches.
2.4. IoT Gateways 2.4. IoT Gateways
A number of IoT devices are connected via a low-power wireless A number of IoT devices are connected via a low-power wireless
network (e.g., a Bluetooth LE piconet) and need to talk to their network (e.g., a Bluetooth LE piconet) and need to talk to their
parent cloud service to provide sensor readings or receive firmware parent cloud service to provide sensor readings or receive firmware
updates. When end-to-end IP connectivity is not possible or updates. When end-to-end IP connectivity is not possible or
desirable for at least some of the devices, one or more IP capable desirable for at least some of the devices, one or more IP capable
nodes in the piconet can be designated as ad-hoc gateways to forward nodes in the piconet can be designated as ad-hoc gateways to forward
sensor traffic to the cloud and vice-versa. In other scenarios, a sensor traffic to the cloud and vice-versa. In other scenarios, a
skipping to change at page 7, line 40 skipping to change at page 8, line 21
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
receiver that QUIC is used as a substrate and potentially additional receiver that QUIC is used as a substrate and potentially additional
information about which protocol is used for communication between information about which protocol is used for communication between
these entities. A similar mechanism could be realized in HTTP these entities. A similar mechanism could be realized in HTTP
instead. In both cases it is important that the QUIC connection instead. In both cases it is important that the QUIC connection
cannot be identified as a substrate by an observer on the path. cannot be identified as a substrate by an observer on the path.
As existing proxying functions cannot be perform transparently the With QUIC, the use of proxying functions cannot be done
QUIC is used, the discovery of a proxy on path need to be explicit. transparently. Instead, proxies needs to be explicity discoverable.
In the simplest form of such discovery could include pre- The simplest form of such discovery could include pre-configuration
configuration or via out-of-band signaling. The proxy can advertise or via out-of-band signaling. The proxy could also be discovered
it's existence when a client is connected to a network (DHCP), the through advertisement when a client is connected to a network (for
client can get a white-listed proxy address when making first contact example, the Dynamic Host Configuration Protocol). Alternatively,
with the server (CNAME/IPaddress). In both cases the proxy need to the client could obtain a white-listed proxy address when making
have a routable address and name. first contact with the server (CNAME/IPaddress). In both cases the
proxy needs to have a routable address and name.
4. Contributors 4. Contributors
Magnus Westerlund have contributed two paragraphs on combining Magnus Westerlund has contributed two paragraphs on combining
proxies. proxies.
5. Acknowledgments 5. Acknowledgments
Thanks to Tommy Pauly, and Lucas Pardue for contributing thoughts and Thanks to Tommy Pauly for contributing thoughts and comments on these
comments on these use cases, as well as text edits! use cases, as well as text edits!
6. Informative References 6. 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-02 (work in progress), March 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
skipping to change at page 9, line 4 skipping to change at page 9, line 27
Mirja Kuehlewind Mirja Kuehlewind
Ericsson Ericsson
Email: mirja.kuehlewind@ericsson.com Email: mirja.kuehlewind@ericsson.com
Zaheduzzaman Sarker Zaheduzzaman Sarker
Ericsson Ericsson
Email: zaheduzzaman.sarker@ericsson.com Email: zaheduzzaman.sarker@ericsson.com
Thomas Fossati Thomas Fossati
Arm Arm
Email: thomas.fossati@arm.com Email: thomas.fossati@arm.com
Lucas Pardue
Cloudflare
Email: lucaspardue.24.7@gmail.com
 End of changes. 13 change blocks. 
40 lines changed or deleted 71 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/