Skip to main content

Use Cases and Requirements for QUIC as a Substrate

The information below is for an old version of the document.
Document Type
This is an older version of an Internet-Draft whose latest revision state is "Replaced".
Authors Mirja Kühlewind , Zaheduzzaman Sarker , Thomas Fossati
Last updated 2019-06-07
Replaced by draft-kuehlewind-masque-quic-substrate
RFC stream (None)
Stream Stream state (No stream defined)
Consensus boilerplate Unknown
RFC Editor Note (None)
IESG IESG state I-D Exists
Telechat date (None)
Responsible AD (None)
Send notices to (None)
Network Working Group                                      M. Kuehlewind
Internet-Draft                                                 Z. Sarker
Intended status: Informational                                  Ericsson
Expires: December 9, 2019                                     T. Fossati
                                                           June 07, 2019

           Use Cases and Requirements for QUIC as a Substrate


   TCP is often used as a proxying or tunneling protocol.  QUIC is a
   new, emerging transport protocol and there is a similar expectation
   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
   and tunneling services to maintain the benefits of QUIC natively,
   without degrading the performance and security characteristics.  QUIC
   also opens up new opportunities for these services to have lower
   latency and better multistreaming support.  This document summarizes
   current and future usage scenarios to derive requirements for QUIC
   and to provide additional protocol considerations.

Status of This Memo

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list of current Internet-
   Drafts is at

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   This Internet-Draft will expire on December 9, 2019.

Copyright Notice

   Copyright (c) 2019 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents

Kuehlewind, et al.      Expires December 9, 2019                [Page 1]
Internet-Draft               QUIC Substrate                    June 2019

   ( in effect on the date of
   publication of this document.  Please review these documents
   carefully, as they describe your rights and restrictions with respect
   to this document.  Code Components extracted from this document must
   include Simplified BSD License text as described in Section 4.e of
   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.

1.  Introduction

   QUIC is a new transport protocol that was initially developed as a
   way to optimize HTTP traffic by supporting multiplexing without head-
   of-line-blocking and integrating security directly into the
   transport.  This tight integration of security allows the transport
   and security handshakes to be combined into a single round-trip
   exchange, after which both the transport connection and authenticated
   encryption keys are ready.

   Based on the expectation that QUIC will be widely used for HTTP, it
   follows that there will also be a need to enable the use of QUIC for
   HTTP proxy services.

   Beyond HTTP, however, QUIC provides a general-purpose transport
   protocol that can be used for many other kinds of traffic, whenever
   the features provided by QUIC (compared to existing options, like
   TCP) are beneficial to the high-layer service.  Specifically, QUIC's
   ability to multiplex, encrypt data, and migrate between network paths
   makes it ideal for solutions that need to tunnel or proxy traffic.

   Existing proxies that are not based on QUIC are often transparent.
   That is, they do not require the cooperation of the ultimate
   connection endpoints, and are often not visible to one or both of the
   endpoints.  If QUIC provides the basis for future tunneling and
   proxying solutions, it is expected that this relationship will
   change.  At least one of the endpoints will be aware of the proxy and
   explicitly coordinate with it.  This allows client hosts to make
   explicit decisions about the services they request from proxies (for
   example, simple forward or more advance performance-optimizing
   services), and to do so using a secure communication channel between
   themselves and the proxy.

   This document describes some of the use cases for using QUIC for
   proxying and tunneling, and explains the protocol impacts and
   tradeoffs of such deployments.

Kuehlewind, et al.      Expires December 9, 2019                [Page 2]
Internet-Draft               QUIC Substrate                    June 2019

2.  Usage Scenarios

2.1.  Obfuscation via Tunneling

   Tunnels are used in many scenarios within the core of the network as
   well as from a client endpoint to a proxy middlepoint on the way
   towards the server.  In many cases, when the client explicitly
   decides to use the support of a proxy in order to connect to a
   server, it does so because a direct connection may be blocked or
   impaired.  This can either be the case in e.g. enterprise network
   where traffic is firewalled and web traffic needs to be routed over
   an explicitly provided HTTP proxy, or other reasons for blocking of
   certain services e.g. due to censorship, data exfiltration
   protection, etc.

   In this usage scenario the client knows the proxy's address and
   explicitly selects to connect to the proxy in order to instruct the
   proxy to forward its traffic to a specific server.  At a minimum, the
   client needs to communicate directly with the proxy to provide the
   address of the server it wants to connect to, e.g. using HTTP

   Tunneling through a proxy server can provide various benefits,
   particularly when using a proxy that has a secure multiplexed channel
   like QUIC:

   o  Obfuscating the end server's IP address from the observers between
      the client and the proxy, which protects the identity of a private
      server's address or circumvents local firewall rules.

   o  Obfuscating the client's IP address from the perspective of
      observers after the proxy, to the end server itself.  This allows
      the client to select content as if it has the address or location
      of the proxy.

   o  Obfuscating the traffic patterns of the traffic from the
      perspective of observers between the client and the proxy.  If the
      content of connections to many end servers can be coalesced as one
      flow, it becomes increasingly difficult for observers to detect
      how many inner connections are being used, or what the content of
      those connections are.

   Such a setup can also be realized with the use of an outer tunnel
   which would additionally obfuscate the content of the tunnel traffic
   to any observer between the client and the proxy.  Usually the server
   is not aware of the proxy in the middle, so the proxy needs to re-
   write the IP address of any traffic inside the tunnel to ensure that
   the return traffic is also routed back to the proxy.  This is also

Kuehlewind, et al.      Expires December 9, 2019                [Page 3]
Internet-Draft               QUIC Substrate                    June 2019

   often used to conceal the address/location of the client to the
   server, e.g. to access local content that would not be accessible by
   the client at its current location otherwise.

   In any of these tunneling scenarios, including those deployed today,
   the client explicitly decides to make use of a proxy service while
   being fully transparent for the server, or even with the intention to
   hide the client's identity from the server.  This is explicitly part
   of the design as these services are targeting an impaired or
   otherwise constrained network setup.  Therefore, an explicit
   communication channel between client and proxy is needed to at least
   communicate the information about the target server's address, and
   potentially other information needed to inform the behaviour of the

2.2.  Advanced Support of User Agents

   Depending on the traffic that is sent "over" the proxy, it is also
   possible that the proxy can perform additional support services if
   requested by the client.  Today, Performance Enhancing Proxies (PEPs)
   usually work transparently by either fully or partially terminating
   the transport connection or even intercepting the end-to-end
   encryption.  For many of these support services termination is
   actually not needed and may even be problematic.  However, it is
   often the only, or at least easiest, solution if no direct
   communication with the client is available.  Enabling these services
   based on an explicit tunnel setup between the client and the proxy
   provides such a communication channel and makes it possible to
   exchange information in a private and authenticated way.

   It is expected that in-network functions are usually provided close
   to the client e.g. hosted by the access network provider.  Having
   this direct relation between the endpoint and the network service is
   also necessary in order to discover the service, as the assumption is
   that a client knows how to address the proxy service and which
   service is offered (besides forwarding).  Such a setup is especially
   valuable in access networks with challenging link environments such
   as satellite or cellular networks.  While end-to-end functions need
   to be designed to handle all kind of network conditions, direct
   support from the network can help to optimize for the specific
   characteristics of the access network such as use of link-specific
   congestion control or local repair mechanisms.

   Further, if not provided by the server directly, a network support
   function can also assist the client to adapt the traffic based on
   device characteristics and capabilities or user preferences.  Again,
   especially if the access network is constrained, this can benefit
   both the network provider to save resources and the client to receive

Kuehlewind, et al.      Expires December 9, 2019                [Page 4]
Internet-Draft               QUIC Substrate                    June 2019

   the desired service quicker or less impaired.  Such a service could
   even be extended to include caching or pre-fetching depending on the
   trust relationship between the client and the proxy.

   Depending on the function provided, the proxy may need to access or
   alter the traffic or content.  Alternatively, if the information
   provided by the client or proxy can be trusted, it might in some
   cases also be possible for each of the entities to act based on this
   information without the need to access the content or some of the
   traffic metadata directly.  Especially transport layer optimizations
   do not need access to the actual user content.  Network functions
   should generally minimize dependencies to higher layer
   characteristics as those may change frequently.

   Similar as in the previous usage scenario, in this setup the client
   explicitly selects the proxy and specifies the requested support
   function.  Often the server may not need to be aware of it, however,
   depending on the optimization function, server cooperation could be
   beneficial as well.  However, the client and the proxy need a direct
   and secured communication channel in order to request and configure a
   service and exchange or expose the needed information and metadata.

2.3.  Frontend Support for Load Balancing and Migration/Mobility

   In this usage scenario the application service provider aims for
   flexibility in server selection, therefore the client communicates
   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
   for mobility support, of both the server or client, where a frontend
   proxy can redirect the traffic to a different backend server.  Today
   this is realized fully transparent to the client and the client is
   not aware of the network setup behind the proxy.  However, such a
   setup may as well benefit in future from an explicit tunneling or
   proxying approach.

   In this usage scenario the client interact with a proxy that is
   located close to the server and potentially even under the same
   administrative domain or at least has some trust relationship with
   the application service provider.  The server is aware of this setup
   and may have an own communication channel with the proxy or tunnel

Kuehlewind, et al.      Expires December 9, 2019                [Page 5]
Internet-Draft               QUIC Substrate                    June 2019

   endpoint as well, in order to advise it about server selection.
   However, the client is usually not aware of any specifics about the
   setup behind the substrate endpoint.

2.4.  IoT Gateways

   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
   parent cloud service to provide sensor readings or receive firmware
   updates.  When end-to-end IP connectivity is not possible or
   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
   sensor traffic to the cloud and vice-versa.  In other scenarios, a
   less constrained node - sometimes called a "smart gateway" - can
   assume the forwarding role permanently.  In both cases, the gateway
   node routes messages based on client's session identifiers, which
   need to be unique among all the active participants so that the
   gateway can route unambiguously.  The access network attachment is
   expected to change over time but the end-to-end communication
   (especially the security association) needs to persist for as long as
   possible.  A strong requirement for these deployments is privacy:
   data on the public Internet (i.e., from the gateway to the cloud
   service) needs to be made as opaque as possible to passive observers,
   possibly hiding the natural traffic patterns associated with the
   sensor network.  A mechanism to provide discovery of the proxy node
   to the rest of the piconet is also typically necessary.

   Today, the above requirements can be met by composing an end-to-end
   secure channel (e.g., based on DTLS sessions with client-chosen
   connection IDs [I-D.ietf-tls-dtls-connection-id] or application layer
   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],
   or a proprietary shim) from the gateway to the cloud.  In the future,
   a more homogeneous solution could be provided by QUIC
   [I-D.ietf-quic-transport] for both the end-to-end and tunneling
   services, thus simplifying code dependencies on the gateway nodes.

2.5.  Multi-hop Chaining Usage

   Providing a generic approach to use QUIC as a substrate also enables
   the combination of multiples of the above use cases.  For example,
   employing multiple obfuscating proxies in sequence, where the
   communication with each proxy is individually secured, can enable
   onion-like layered security.  Each proxy will only know the address
   of the prior hop and after itself, similar as provided by onion
   routing in Tor project [TOR].

Kuehlewind, et al.      Expires December 9, 2019                [Page 6]
Internet-Draft               QUIC Substrate                    June 2019

   Further it would also be possible to chain proxies for different
   reasons.  A client may select proxying support from its access
   network, while a web service provider may utilize a front-end load
   balancing proxy to provide end-to-end secure communication with the
   applications components servers.  Here the proxy and the load
   balancer have different tasks.  The access network proxy optimizes
   the aggregated data transport.  The load balancer needs to route
   different set of end-to-end protected data that it aggregates.  A
   third example would be multiple proxies to cooperate and maybe
   exchange measurement information in order to optimize the QUIC
   connection over a specific segment.

   The above examples indicates that a solution likely have to consider
   how to establish a security model so that endpoints can selectively
   choose what connection related information to share with the
   different proxy entities.  The possible efficiency should also be
   consider and multiple layers of encapsulation should be avoided when
   the security model allows for it.

3.  Requirements

   To use QUIC as a substrate, it could be beneficial if unreliable
   transmission is supported as well as having a way to potentially
   influence or disable congestion control if the inner tunnel traffic
   is known to be congestion controlled.

   Communication between the client and proxy is more likely to be
   realized as a separate protocol on top of QUIC or HTTP.  However, a
   QUIC extensibility mechanism could be used to indicate to the
   receiver that QUIC is used as a substrate and potentially additional
   information about which protocol is used for communication between
   these entities.  A similar mechanism could be realized in HTTP
   instead.  In both cases it is important that the QUIC connection
   cannot be identified as a substrate by an observer on the path.

   As existing proxying functions cannot be perform transparently the
   QUIC is used, the discovery of a proxy on path need to be explicit.
   In the simplest form of such discovery could include pre-
   configuration or via out-of-band signaling.  The proxy can advertise
   it's existence when a client is connected to a network (DHCP), the
   client can get a white-listed proxy address when making first contact
   with the server (CNAME/IPaddress).  In both cases the proxy need to
   have a routable address and name.

Kuehlewind, et al.      Expires December 9, 2019                [Page 7]
Internet-Draft               QUIC Substrate                    June 2019

4.  Contributors

   Magnus Westerlund have contributed two paragraphs on combining

5.  Acknowledgments

   Thanks to Tommy Pauly, and Lucas Pardue for contributing thoughts and
   comments on these use cases, as well as text edits!

6.  Informative References

              Friel, O., Barnes, R., Pritikin, M., Tschofenig, H., and
              M. Baugher, "Application-Layer TLS", draft-friel-tls-
              atls-02 (work in progress), March 2019.

              Iyengar, J. and M. Thomson, "QUIC: A UDP-Based Multiplexed
              and Secure Transport", draft-ietf-quic-transport-20 (work
              in progress), April 2019.

              Rescorla, E., Tschofenig, H., and T. Fossati, "Connection
              Identifiers for DTLS 1.2", draft-ietf-tls-dtls-connection-
              id-05 (work in progress), May 2019.

   [RFC8441]  McManus, P., "Bootstrapping WebSockets with HTTP/2",
              RFC 8441, DOI 10.17487/RFC8441, September 2018,

   [TOR]      "TOR Project", June 2019, <>.

Authors' Addresses

   Mirja Kuehlewind


   Zaheduzzaman Sarker


Kuehlewind, et al.      Expires December 9, 2019                [Page 8]
Internet-Draft               QUIC Substrate                    June 2019

   Thomas Fossati


Kuehlewind, et al.      Expires December 9, 2019                [Page 9]