Use Cases and Requirements for QUIC as a Substrate

Document Type Active Internet-Draft (individual)
Last updated 2019-06-07
Stream (None)
Intended RFC status (None)
Formats plain text xml pdf html bibtex
Stream Stream state (No stream defined)
Consensus Boilerplate Unknown
RFC Editor Note (None)
IESG IESG state I-D Exists
Telechat date
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
Show full document text