[Docs] [txt|pdf|xml|html] [Tracker] [Email] [Nits]

Versions: 00

QUIC Working Group                                             M. Piraux
Internet-Draft                                             Q. De Coninck
Intended status: Experimental                                  F. Michel
Expires: 10 September 2020                                     F. Rochet
                                                          O. Bonaventure
                                                            9 March 2020

                              QUIC Plugins


   The extensibility of Internet protocols is a key factor to their
   success.  Yet, their implementations are often not designed with
   agility in mind.  In this document, we leverage the features of the
   QUIC protocol and propose a solution to dynamically extend QUIC
   implementations.  Our solution relies on QUIC Plugins that allow
   tuning and extending the QUIC protocol on a per-connection basis.
   These platform-independent plugins are executed inside a sandboxed
   environment which can be included in QUIC implementations.  We
   describe how such plugins can be used in different use cases.

   This document is a straw-man proposal.  It aims at sparking
   discussions on the proposed approach.

Note to Readers

   Discussion of this document takes place on the QUIC Working Group
   mailing list (quic@ietf.org), which is archived at

   Source for this draft and an issue tracker can be found at

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 https://datatracker.ietf.org/drafts/current/.

Piraux, et al.          Expires 10 September 2020               [Page 1]

Internet-Draft                QUIC Plugins                    March 2020

   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 10 September 2020.

Copyright Notice

   Copyright (c) 2020 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 (https://trustee.ietf.org/
   license-info) 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.

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   3
   2.  Dynamically extensible protocol implementations . . . . . . .   6
     2.1.  Requirements  . . . . . . . . . . . . . . . . . . . . . .   8
   3.  Pluginizing QUIC  . . . . . . . . . . . . . . . . . . . . . .   9
   4.  Exchanging QUIC Plugins . . . . . . . . . . . . . . . . . . .  10
   5.  Examples of use-cases . . . . . . . . . . . . . . . . . . . .  11
     5.1.  Tunable acknowledgments policy  . . . . . . . . . . . . .  11
     5.2.  Pluggable congestion controller . . . . . . . . . . . . .  11
     5.3.  Application-driven stream scheduling  . . . . . . . . . .  12
     5.4.  More advanced QUIC extensions . . . . . . . . . . . . . .  12
   6.  QUIC Plugins Authenticity . . . . . . . . . . . . . . . . . .  12
     6.1.  Central Authorities . . . . . . . . . . . . . . . . . . .  13
     6.2.  Plugin Transparency . . . . . . . . . . . . . . . . . . .  13
     6.3.  Comparing Certificate Transparency and Plugin
           Transparency  . . . . . . . . . . . . . . . . . . . . . .  13
   7.  Security Considerations . . . . . . . . . . . . . . . . . . .  14
   8.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .  14
   9.  Informative References  . . . . . . . . . . . . . . . . . . .  14
   Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . .  18
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  18

Piraux, et al.          Expires 10 September 2020               [Page 2]

Internet-Draft                QUIC Plugins                    March 2020

1.  Introduction

   Internet hosts rely on protocols to efficiently exchange information.
   Most protocols are designed assuming a layered model.  In such a
   layered protocol model, a protocol implementation is often
   represented as a black-box that uses the service provided by the
   underlying layer to offer an enhanced Application Programming
   Interface (API) to the upper layer.  This is illustrated in Figure 1.

   Layer N+1
   ---------- +----------- API -----------+
   Management |                           |
   Protocol   |                           |
   <--------->|  Protocol implementation  |
              |                           |
                    ||         /\
                    \/         ||
   Layer N-1

   Figure 1: A protocol implementation exposes an API to the upper layer

   Different protocols expose different APIs.  In the transport layer,
   the socket API is the most popular one.  It was originally defined
   with the TCP and UDP protocols in mind, but has been extended to
   support SCTP [RFC6458] and Multipath TCP [RFC6897].  The TAPS working
   group is currently defining new APIs for the transport services

   An important benefit of having standardized APIs is that if two
   implementations expose the same API, it is possible to replace one by
   the other without changing anything in the upper layers.

   Besides exposing an API to the layer above, many protocol
   implementations also expose an API to management protocols such as
   SNMP, IPFIX or NETCONF.  For example, a TCP implementation exposes
   the variables and tables defined in the TCP part of the MIB-2
   [RFC1213][RFC4022].  There is ongoing work in developing a YANG model
   for TCP implementations [I-D.scharf-tcpm-yang-tcp].  This is
   illustrated in the left part of Figure 1.

   These management APIs expose abstract configuration parameters and
   statistics about the key operations performed by a protocol
   implementation to offer more control to the upper layer.  They have
   been useful in configuring and operating a wide range of protocol
   implementations.  As different implementations expose the same
   abstraction, it becomes possible for operators to configure and

Piraux, et al.          Expires 10 September 2020               [Page 3]

Internet-Draft                QUIC Plugins                    March 2020

   manage different implementations by using the same tool in a unified

   A protocol implementation exchanges messages with other
   implementations by leveraging the service provided by the underlying
   layer.  For example, a TCP implementation interacts through the
   socket API and exchanges TCP segments with remote hosts through the
   underlying IP protocol.  Protocol designers usually define transport
   and application protocols in two parts:

   *  a series of messages that are encoded using a specific format.

   *  a Finite State Machine that defines how hosts react to commands
      from the layer above or to the reception of a specific message.

   This model has been used to represent a wide range of Internet
   protocols.  Typically, the Finite State Machine and the syntax of the
   messages are described in a single or a series of documents that are
   heavily discussed within IETF working groups before reaching a
   consensus and getting a final specification.  The ongoing work on the
   finalization of the first version of the QUIC specification is a
   recent example of such efforts [I-D.ietf-quic-transport].

   Once the first stable version of the specification of a protocol has
   been approved, IETF working groups typically observe the deployment
   of the protocol and improve it based on the received feedback.  If
   the protocol is successful, it often triggers suggestions for
   extensions or improvements.  These extensions are important for these
   successful protocols, but they often take a lot of time to be
   deployed.  Experience with TCP shows that extensions, such as
   selective acknowledgments [RFC2018], support for large windows and
   timestamps [RFC7323] or more recently Multipath TCP [RFC6824] took
   more than a decade to be widely deployed.  There are several
   considerations that can explain the difficulty of deploying TCP
   extensions, ranging from the fact that TCP is often part of operating
   system kernels, which evolve at a slower pace than applications, to
   middlebox interference.

   Looking at other IETF protocols, we rarely observe successful
   protocols that have not been extended over the years.  Thus, the need
   for extensibility could be seen as an invariant for a successful
   Internet protocol.  In addition to the extensions that were accepted
   by the IETF and eventually deployed, there are many other extensions
   that correspond to specific applications or more restricted use
   cases.  These extensions would be very valuable in specific
   environments, but their proponents never managed to convince the
   relevant IETF working group and implementers of their benefits.

Piraux, et al.          Expires 10 September 2020               [Page 4]

Internet-Draft                QUIC Plugins                    March 2020

   Besides the protocol extensions, we also observe that there are some
   protocol behaviors that can be difficult to precisely express using a
   set of parameters that are exchanged inside a message.  Here are two
   recent examples that illustrate this difficulty.

   A first example is the transmission of acknowledgments in reliable
   transport protocols.  There is a trade-off between the feedback
   provided by the acknowledgments and the resources (bandwidth and CPU)
   required to generate and process them.  Various heuristics have been
   proposed in TCP to generate these ACKs
   [RFC1122],[RFC5681],[RFC3449],[RFC5690].  These heuristics are
   deployed independently on receivers, but for some of them the senders
   need to adapt by at least taking into account the fact that some
   acknowledgments were delayed while measuring the round-trip-time.  A
   similar discussion has started for QUIC.  Given the flexibility of
   QUIC, researchers have proposed to define an acknowledgment strategy
   as a set of parameters that are exchanged in a new QUIC frame over
   each connection
   This brings more flexibility than in TCP where the limited size of
   the header made it impossible to exchange such information.

   A second example in the application layer is the support for stream
   priorities in HTTP/2 [RFC7540].  Since HTTP/2 provides parallel
   streams, some application developers have expressed their need for
   prioritizing some streams over others.  The HTTP/2 protocol defines
   such priorities, but they are not widely used and some have proposed
   to deprecate them [I-D.peon-httpbis-h2-priority-one-less].  In spite
   of this, a proposal for stream prioritization for HTTP/3 already
   exists [I-D.kazuho-httpbis-priority].  [LNBIP2020] evaluates stream
   scheduling for HTTP/3 and claims that performances are heavily
   impacted by the adopted stream scheduling.

   These examples illustrate the difficulty of precisely expressing
   complex behaviors in a few parameters that are exchanged inside

   In this document, we propose a different approach to specify and
   implement protocols to better address the extensibility requirement.
   We focus on the QUIC protocol in this document, but similar ideas
   could be applied to other IETF protocols or networking systems.  We
   leverage the recent results in extending operating system kernels
   [eBPF] or web-browsers [WebAssembly] with virtual machines that
   execute bytecodes to propose a new approach to define complex
   behaviors inside protocols.  We first describe the general
   architecture of the proposed approach in Section 2.  We then provide
   a few examples showing how such an approach could be applied to the
   next version of the QUIC protocol in Section 3.

Piraux, et al.          Expires 10 September 2020               [Page 5]

Internet-Draft                QUIC Plugins                    March 2020

2.  Dynamically extensible protocol implementations

   Experience with successful Internet protocols shows that once a
   protocol gets (widely) deployed, it attracts new use cases and
   proposals to extend and improve it.  Most of the key Internet
   protocols, including IP, TCP, HTTP, DNS, BGP, OSPF, IS-IS, ... have
   been improved over the years.  Today, the developer of an
   implementation of any of these protocols need to consult dozens of
   RFCs to find their complete specification.

   Despite the importance of extensions to those key Internet protocols,
   we still do not design them under the assumption that they will
   evolve over decades and that their implementations should be made
   agile.  In this document, we propose a new organization for protocol
   implementations.  Instead of trying to pack as many features as
   possible inside a protocol implementation that is considered as a
   blackbox, we consider a protocol implementation as an open system
   which can be extended to support new features in a safe and agile
   manner.  Our vision is that such an implementation exposes an
   internal Plugin API which can be leveraged by code extensions that we
   call Plugins in this document.  This is illustrated in Figure 2.

   Layer N+1
   ---------- +----------- API -----------+
   Management |  ( )       ( )       (x)<------ Plugin_A
   Protocol   |                           |
   <--------->|  Protocol implementation  |
              |       ( )       (x)<--------- Plugin_B
                    ||         /\
                    \/         ||          Legend:
   ---------------------------------------    ( ) Part of the Plugin API
   Layer N-1                                  (x) Plugin injected

      Figure 2: A pluginized protocol implementation exposes a Plugin
        API that enables plugins to dynamically extend its operation

   These Plugins extend the protocol by modifying its messages or its
   Finite State Machine.  Consider Figure 3 as an example which
   illustrates a simple receiver with three states, i.e. Receiving, Data
   rcvd and Ack needed.  This receiver waits until either two data
   packets have been received or 10 milliseconds have passed after
   receiving a data packet before sending an acknowledgment.  Its
   implementation consists of three actions, receive(), send_ack() and

   An application using this receiver could benefit from tuning this
   acknowledgment policy.  For instance, another state could be chained

Piraux, et al.          Expires 10 September 2020               [Page 6]

Internet-Draft                QUIC Plugins                    March 2020

   between Data rcvd and Ack needed, so that acknowledgments can be
   batched for more than two data packets.  Similarly, a more advanced
   heuristic could be added to generate acknowledgments, e.g. taking
   into account the size of data packets to detect transmission tails.

   +-----------+  receive()  +-----------+
   | Receiving |>----------->| Data rcvd |
   +-----------+             +-v-------v-+
             ^                 |       |
             |        wait(10) |       | receive()
             |                 |       |
             |                 |       |
             |  send_ack()  +--v-------v-+
             \-------------<| Ack needed |

            Figure 3: Finite State Machine of a simple receiver

   Using this Plugin API, a protocol can be extended to add new messages
   and to modify its Finite State Machine, i.e. modify its states and
   transitions.  This document defines such protocol as a pluginized
   protocol.  Figure 4 illustrates how this simple receiver could be
   extended.  In this example a new state is added so that a single
   acknowledgment can be sent for three received data packets.

   +-----------+  receive()  +-----------+  receive()  *+++++++++++++*
   | Receiving |>----------->| Data rcvd |>+++++++++++>| Data rcvd 2 |
   +-----------+             +-v---------+             *+v+++++++++v+*
             ^                 |                         !         !
             |        wait(10) |                wait(5)  !         !
             |                 |       /+++++++++++++++++/         !
             |                 |       !                           !
             |  send_ack()  +--v-------v-+        receive()        !
             \-------------<| Ack needed |<++++++++++++++++++++++++/
     >+++> Transition added by a Plugin
     | S | State added by a Plugin

      Figure 4: Extended Finite State Machine of a pluginized receiver

   Due to space constraints, the case of adding a new action is not
   depicted in Figure 4.  In this example, a new action data_not_full()
   could be added by a Plugin.  This action could be taken whenever the
   last received data packet is not full, indicating the end of a series

Piraux, et al.          Expires 10 September 2020               [Page 7]

Internet-Draft                QUIC Plugins                    March 2020

   of packets.  Transitions from the states Data rcvd and Data rcvd 2 to
   the state Ack needed with this action could be added by this Plugin.

2.1.  Requirements

   There are different ways of implementing the idea of dynamically
   extending protocols by using plugins.  We list here some requirements
   that any solution should support:

   REQ1:  Different implementations should expose the same Plugin API,
      e.g. as different implementations expose the same SNMP MIB.

   REQ2:  It should be possible to dynamically attach a plugin to one
      instance of an implementation.  For instance, for a connection-
      oriented protocol, it should be possible to associate a plugin to
      a given connection.  Different connections could have different
      sets of plugins.

   REQ3:  It should be possible to execute the same plugin on different
      interoperable implementations of the same protocol.

   REQ4:  It should be possible for a protocol implementation to
      restrict the operations that a given plugin can execute.

   REQ5:  Plugins should be sandboxed and the application should be safe
      using them, for instance regarding memory corruption and runtime

   One possible way to realize this new architecture is to include a
   virtual machine inside each protocol implementation and expose a
   small Plugin API accessible through the virtual machine.  Several
   efficient virtual machines have been proposed and used in related
   environments [eBPF] [WebAssembly].  They provide a sandbox
   controlling the operations a plugin can execute and the memory that
   it can access.  Since the same virtual machine can be provided on
   different platforms, it becomes possible to execute the same plugin
   on different implementations of a given protocol exposing the same
   Plugin API.

   The idea of extending protocols through plugins can be applied to
   different Internet protocols.  In this document, we focus on adding
   plugins to QUIC since it is a recent and flexible protocol that
   includes useful security features.  A similar approach has been
   applied to OSPF and BGP [ICNP] and partially to TCP
   [TCP-Options-BPF].  Other networking systems, such as the Tor network
   [FAN] or Cryptocurrency networks, may also benefit from extending
   their protocols through plugins.  In some cases, the extensibility
   through plugins may help to solve fundamental security issues

Piraux, et al.          Expires 10 September 2020               [Page 8]

Internet-Draft                QUIC Plugins                    March 2020

   [DROPPING] linked to both compliance to the Postel principle and slow
   deployment processes.

3.  Pluginizing QUIC

   Conceptually, we break down a QUIC implementation execution flow into
   generic subroutines.  These are specified functions called protocol
   operations.  These protocol operations implement a given part of the
   QUIC protocol, for example the acknowledgment generation or the
   computation of the round-trip-time.  Some are generic and depend on a
   parameter, for instance parsing a QUIC frame is a generic operation
   that depends on the type of QUIC frame.  This version of the document
   does not elaborate exhaustively on the protocol operations composing
   a Pluginized QUIC implementation.  The next versions of this document
   will work on defining a set of protocol operations.

   A QUIC Plugin consists of platform-independent bytecode which
   modifies or extends the behavior of a QUIC implementation.  Adding
   the functionality of a QUIC Plugin consists in adding or replacing a
   set of protocol operations implemented by this bytecode.  This action
   of adding a QUIC Plugin to a QUIC connection is referred to as
   injecting a QUIC Plugin.  Injecting a plugin is limited to a given
   QUIC connection.

   Its bytecode is run inside a sandboxed execution environment.  It has
   restricted access to the state of a QUIC connection through the
   Plugin API.

   The scope of a QUIC Plugin is restricted by both the limitations of
   this execution environment, e.g. in terms of instruction set and
   quantity, and by the surface exposed by the Plugin API, e.g. the
   quantity of state that can be read from or written to by a plugin.
   The Plugin API also defines a set of protocol operations to which
   QUIC Plugins can be injected.  For instance, a QUIC implementation
   might restrict QUIC Plugins injection to its acknowledgment
   generation policy, e.g. the protocol operation deciding whether
   sending an ACK frame is needed.

   A QUIC Plugin can be injected by several means.  The application can
   inject plugins to tune its underlying QUIC connection.  QUIC peers
   can exchange and inject plugins over a QUIC connection, as described
   in Section 4.  Users can set a default configuration injecting
   plugins on their devices.

   Considering again Figure 3 applied to QUIC Plugins, the actions are
   the protocol operations.  The states of the FSM are defined by the
   QUIC connection state, which can be modified and extended during the

Piraux, et al.          Expires 10 September 2020               [Page 9]

Internet-Draft                QUIC Plugins                    March 2020

   execution of a protocol operation through the Plugin API.  The
   transitions are calls to protocol operations.

4.  Exchanging QUIC Plugins

   Injecting QUIC Plugins locally allows the application to tune the
   underlying QUIC implementation to its needs.  But some use-cases
   requires adapting the peer behavior.  In those cases, being able to
   exchange plugins helps to fill this gap.

   QUIC offers both data multiplexing and encryption.  Using those
   mechanisms, the QUIC Plugins used for a given connection could be
   safely transferred over this connection in a new dedicated stream,
   akin to the crypto stream.  This does not impact the application data
   transfer, as illustrated in Figure 5.  In this example, an HTTP/3
   request is interleaved with the transfer from the server to the
   client of a QUIC Plugin controlling the acknowledgment policy.

    Client                             Server
     |     (QUIC connection handshake)     |
     |                                     |
     |       STREAM[0, "HTTP/3 GET"]       |
     |                                     |
     |       STREAM[0, "200 OK..."]        |
     |                                     |
     |    PLUGIN["ack_delay", bytecode]    |
     |                                     |
     |       STREAM[0, "...", FIN]         |

    Figure 5: Interleaving a QUIC Plugin transfer over a QUIC connection

   A local policy could restrict the type of plugins that can be
   exchanged and injected, e.g. in terms of connection state accessed
   and in terms of protocol operations affected.  This version of
   document does not describe further how the negotiation of QUIC
   Plugins takes place.

   QUIC Plugins could also be transferred out of band.  The application
   using QUIC can then inject these plugins locally.

Piraux, et al.          Expires 10 September 2020              [Page 10]

Internet-Draft                QUIC Plugins                    March 2020

5.  Examples of use-cases

   There exist several cases in which being able to modify the behavior
   of a QUIC peer, either locally or remotely, is beneficial.  This
   first version of the document focus on enabling the extension of
   simple QUIC mechanisms.  Three of them are documented in this
   section.  Contributions to this document regarding new uses-cases are

5.1.  Tunable acknowledgments policy

   The large diversity of Internet paths also counts networks involving
   a significant path asymmetry.  Those paths require the receiver to
   adapt its feedback rate to the sender.  The performance of transport
   protocols such as TCP on those paths has been studied in depth and
   reported in [RFC3449].  A method for controlling the rate of receiver
   feedback of TCP, i.e. the rate of ACKs, has been proposed in

   Proposals for controlling the acknowledgment policy of QUIC already
   exist.  [I-D.fairhurst-quic-ack-scaling] proposes a change to the
   default policy for asymmetric paths.  [I-D.iyengar-quic-delayed-ack]
   describes a QUIC extension enabling a QUIC endpoint to control the
   acknowledgment policy of its peer.  For that purpose, they model the
   acknowledgment policy depending on a few parameters and introduce a
   new QUIC frame to signal new values for those parameters.

   A QUIC Plugin could allow implementing a new acknowledgment with a
   fine granularity.  For example, in the case of an application that
   generates bursty traffic, such as a real-time video streaming
   application, a QUIC Plugin allows embedding application knowledge,
   i.e. the characteristics of such bursts, inside the acknowledgment
   generation policy.  Exchanging and injecting this plugin allows
   controlling the other peer behavior.

5.2.  Pluggable congestion controller

   There exists many congestion control algorithms.  Each of them has
   been designed for a given context, i.e. a range of applications and a
   range of Internet paths.  For instance, NewReno [RFC6582] has been
   designed for optimizing the web use-case on common Internet paths.
   Westwood [Westwood] is a modification of NewReno to better
   accommodate Internet paths with a high bandwidth-delay product, such
   as satellite links.

   Efforts to restructure congestion controllers within a common
   framework have been presented in past works such as [CCP].  Such a

Piraux, et al.          Expires 10 September 2020              [Page 11]

Internet-Draft                QUIC Plugins                    March 2020

   framework eases the development and maintenance of those algorithms.
   It also enables rapid prototyping and A/B testing.

   [TCP-Options-BPF] proposes a new TCP Option, leveraging the TCP-BPF
   framework, to negotiate the congestion controller to use.  The QUIC
   specification does not specify a similar mechanism.  Negotiating the
   congestion controller used allows one endpoint to tune the other,
   provided that it implements the algorithm.  QUIC Plugins could allow
   the application to directly plug the required congestion controller
   and to exchange it with the other peer.  This flexibility allows the
   application to choose the best congestion controller for its

5.3.  Application-driven stream scheduling

   QUIC streams allow the application to multiplex several bytestreams
   over a single QUIC connection.  Yet, the QUIC specification does not
   provide a mechanism for exchanging prioritization information nor for
   indicating the relative priority of streams.  As described in
   Section 2.3 of [I-D.ietf-quic-transport], "A QUIC implementation
   should provide ways in which an application can indicate the relative
   priority of streams".  A QUIC implementation could allow QUIC Plugins
   to extend or override its stream scheduler.

   For other applications using QUIC with a broad range of requirements,
   a flexible approach for defining the stream scheduling policy is key
   to best fit their needs.  QUIC Plugin offer a flexible way to embed
   application knowledge inside the QUIC implementation.

5.4.  More advanced QUIC extensions

   Exposing more protocol operations through the API proposed to plugins
   by the QUIC implementation allows implementing more advanced QUIC
   Plugins.  Each protocol operation offers flexibility over the QUIC
   implementation.  [PQUIC] demonstrates how this approach can be used
   to implement Multipath QUIC [I-D.deconinck-quic-multipath] and
   [QUIC-FEC] entirely using plugins.

6.  QUIC Plugins Authenticity

   When exchanging and injecting QUIC Plugins, guaranteeing there
   authenticity and safety is important.  This section describes two
   possible approaches for this purpose, the first guarantees the
   authenticity of the QUIC Plugins, the second guarantee both their
   authenticity and an open set of security properties with regard to
   QUIC Plugins.

Piraux, et al.          Expires 10 September 2020              [Page 12]

Internet-Draft                QUIC Plugins                    March 2020

6.1.  Central Authorities

   This first approach leverages the central authorities commonly used
   to secure HTTPS.  In this approach, each QUIC Plugin could be
   associated to some level of trust regarding its origin.  A QUIC
   Plugin may be authenticated using a certificate, itself certified by
   a central authority.  Consequently, a QUIC implementation supporting
   QUIC plugins may restrict their exchange and only accept plugins
   authenticated using the same certificate used for establishing the
   QUIC connection.  This approach only guarantees the authenticity of a
   QUIC Plugin.

6.2.  Plugin Transparency

   This second approach is presented in the [PQUIC] research paper, and
   suggests going beyond the restrictive approach of a centralized trust
   model.  The centralized trust model obliges the server to update
   manually their list of supported plugins.  It also prevents the
   client from injecting a plugin that the server has not marked as
   supported, e.g. because the server is unaware of its existence, or
   because its list has not been updated.

   The suggested design, called Plugin Transparency, proposes a
   methodology to transparently distribute plugins created by
   independent developers and verified by freely selected plugin
   validators.  Those validators endorse verifying some publicly known
   safety or security properties.  A QUIC endpoint can announce a set of
   conditions to accept a plugin as a first order logic formula bound to
   plugin validators.  Whenever the other peer is willing to inject a
   plugin, it sends a (unforgeable) proof fulfilling the requirements
   expressed by this logic formula.  If the requirements are met, then
   the endpoint may safely accept the plugin and could update its list
   of supported plugin.  Compared to the central authority approach,
   supported plugins are updated as part of the protocol design or as a
   consequence of any change to the default logic formula bound to
   plugin acceptance.

6.3.  Comparing Certificate Transparency and Plugin Transparency

   Certificate Transparency (CT) [RFC6962] is an attempt to address the
   structural issues hidden within the central trust assumption and
   prevent mistakes, rogue certificates and rogue authorities from
   weakening the system.  Plugin Transparency bears similarities to
   Certificate Transparency.  First, its motivations are drawn from the
   same conclusions regarding the danger of central trust models.
   Second, similar to CT, it is based on distributing trust assumptions
   to secure the system.  However, Plugin Transparency offers stronger
   properties and eliminates the independent monitoring entities which

Piraux, et al.          Expires 10 September 2020              [Page 13]

Internet-Draft                QUIC Plugins                    March 2020

   hold the resource endowment to continuously monitor the CT log on the
   behalf of certificate owners.  Indeed, our design offers the
   independent developers checking for spurious plugins in O(log(N))
   with N the size of the log (instead of O(N) in CT's design).  Our
   design also offers secure human-readable plugin names that
   unambiguously authenticate them and non-equivocation from rogue
   plugin validators.  Our design is more resilient to failure by
   offering several validators that can be trusted within the logic
   formula.  For example, a QUIC peer may request a proof bound to any
   combination of plugin validators.  The detail of Plugin Transparency,
   including performance considerations and security proofs are
   available in [PQUIC].

7.  Security Considerations

   The next versions of this document will elaborate on security
   considerations following the guidelines of [RFC3552].  Moreover, this
   document will consider privacy as part of those considerations.

8.  IANA Considerations

   This document has no IANA actions.

9.  Informative References

   [PQUIC]    De Coninck, Q., Michel, F., Piraux, M., Rochet, F., Given-
              Wilson, T., Legay, A., Pereira, O., and O. Bonaventure,
              "Pluginizing QUIC", Proceedings of SIGCOMM'19 , August
              2019, <https://pquic.org>.

              Oku, K. and L. Pardue, "Extensible Prioritization Scheme
              for HTTP", Work in Progress, Internet-Draft, draft-kazuho-
              httpbis-priority-04, 20 November 2019,

              Marx, R., De Decker, T., Quax, P., and W. Lamotte,
              "Resource Multiplexing and Prioritization in HTTP/2 over
              TCP versus HTTP/3 over QUIC", 2020.

   [CCP]      Narayan, A., Cangialosi, F., Raghavan, D., Goyal, P.,
              Narayana, S., Mittal, R., Alizadeh, M., and H.
              Balakrishnan, "Restructuring Endpoint Congestion Control",
              Proc. SIGCOMM 2018 , August 2018.

Piraux, et al.          Expires 10 September 2020              [Page 14]

Internet-Draft                QUIC Plugins                    March 2020

              Iyengar, J. and M. Thomson, "QUIC: A UDP-Based Multiplexed
              and Secure Transport", Work in Progress, Internet-Draft,
              draft-ietf-quic-transport-27, 21 February 2020,

   [RFC1122]  Braden, R., Ed., "Requirements for Internet Hosts -
              Communication Layers", STD 3, RFC 1122,
              DOI 10.17487/RFC1122, October 1989,

   [RFC1213]  McCloghrie, K. and M. Rose, "Management Information Base
              for Network Management of TCP/IP-based internets: MIB-II",
              STD 17, RFC 1213, DOI 10.17487/RFC1213, March 1991,

   [RFC4022]  Raghunarayan, R., Ed., "Management Information Base for
              the Transmission Control Protocol (TCP)", RFC 4022,
              DOI 10.17487/RFC4022, March 2005,

   [RFC5681]  Allman, M., Paxson, V., and E. Blanton, "TCP Congestion
              Control", RFC 5681, DOI 10.17487/RFC5681, September 2009,

   [RFC3449]  Balakrishnan, H., Padmanabhan, V., Fairhurst, G., and M.
              Sooriyabandara, "TCP Performance Implications of Network
              Path Asymmetry", BCP 69, RFC 3449, DOI 10.17487/RFC3449,
              December 2002, <https://www.rfc-editor.org/info/rfc3449>.

   [RFC5690]  Floyd, S., Arcia, A., Ros, D., and J. Iyengar, "Adding
              Acknowledgement Congestion Control to TCP", RFC 5690,
              DOI 10.17487/RFC5690, February 2010,

   [RFC6962]  Laurie, B., Langley, A., and E. Kasper, "Certificate
              Transparency", RFC 6962, DOI 10.17487/RFC6962, June 2013,

   [RFC7540]  Belshe, M., Peon, R., and M. Thomson, Ed., "Hypertext
              Transfer Protocol Version 2 (HTTP/2)", RFC 7540,
              DOI 10.17487/RFC7540, May 2015,

   [RFC6897]  Scharf, M. and A. Ford, "Multipath TCP (MPTCP) Application
              Interface Considerations", RFC 6897, DOI 10.17487/RFC6897,
              March 2013, <https://www.rfc-editor.org/info/rfc6897>.

Piraux, et al.          Expires 10 September 2020              [Page 15]

Internet-Draft                QUIC Plugins                    March 2020

   [RFC6824]  Ford, A., Raiciu, C., Handley, M., and O. Bonaventure,
              "TCP Extensions for Multipath Operation with Multiple
              Addresses", RFC 6824, DOI 10.17487/RFC6824, January 2013,

   [RFC7323]  Borman, D., Braden, B., Jacobson, V., and R.
              Scheffenegger, Ed., "TCP Extensions for High Performance",
              RFC 7323, DOI 10.17487/RFC7323, September 2014,

   [RFC2018]  Mathis, M., Mahdavi, J., Floyd, S., and A. Romanow, "TCP
              Selective Acknowledgment Options", RFC 2018,
              DOI 10.17487/RFC2018, October 1996,

   [RFC6458]  Stewart, R., Tuexen, M., Poon, K., Lei, P., and V.
              Yasevich, "Sockets API Extensions for the Stream Control
              Transmission Protocol (SCTP)", RFC 6458,
              DOI 10.17487/RFC6458, December 2011,

   [RFC6582]  Henderson, T., Floyd, S., Gurtov, A., and Y. Nishida, "The
              NewReno Modification to TCP's Fast Recovery Algorithm",
              RFC 6582, DOI 10.17487/RFC6582, April 2012,

   [RFC3552]  Rescorla, E. and B. Korver, "Guidelines for Writing RFC
              Text on Security Considerations", BCP 72, RFC 3552,
              DOI 10.17487/RFC3552, July 2003,

              Fairhurst, G., Custura, A., and T. Jones, "Changing the
              Default QUIC ACK Policy", Work in Progress, Internet-
              Draft, draft-fairhurst-quic-ack-scaling-01, 5 March 2020,

              Iyengar, J. and I. Swett, "Sender Control of
              Acknowledgement Delays in QUIC", Work in Progress,
              Internet-Draft, draft-iyengar-quic-delayed-ack-00, 23
              January 2020, <http://www.ietf.org/internet-drafts/draft-

              Coninck, Q. and O. Bonaventure, "Multipath Extensions for
              QUIC (MP-QUIC)", Work in Progress, Internet-Draft, draft-

Piraux, et al.          Expires 10 September 2020              [Page 16]

Internet-Draft                QUIC Plugins                    March 2020

              deconinck-quic-multipath-04, 5 March 2020,

              Thomson, M. and R. Peon, "Deprecation of HTTP/2 Priority
              Signaling Hints", Work in Progress, Internet-Draft, draft-
              peon-httpbis-h2-priority-one-less-00, 25 July 2019,

              Trammell, B., Welzl, M., Enghardt, T., Fairhurst, G.,
              Kuehlewind, M., Perkins, C., Tiesel, P., Wood, C., and T.
              Pauly, "An Abstract Application Layer Interface to
              Transport Services", Work in Progress, Internet-Draft,
              draft-ietf-taps-interface-05, 4 November 2019,

              Scharf, M., Murgai, V., and M. Jethanandani, "YANG Model
              for Transmission Control Protocol (TCP) Configuration",
              Work in Progress, Internet-Draft, draft-scharf-tcpm-yang-
              tcp-04, 24 February 2020, <http://www.ietf.org/internet-

   [QUIC-FEC] Michel, F., De Coninck, Q., and O. Bonaventure, "QUIC-FEC:
              Bringing the benefits of Forward Erasure Correction to
              QUIC", IFIP Networking 2019 , May 2019.

              Tran, VH. and O. Bonaventure, "Beyond socket options:
              making the Linux TCP stack truly extensible", IFIP
              Networking 2019 , May 2019.

   [eBPF]     Matt Fleming, ., "A thorough introduction to eBPF", Linux
              Weekly News , December 2017,

   [Westwood] Casetti, C., Gerla, M., Mascolo, S., Sanadidi, M.Y., and
              R. Wang, "TCP Westwood: End-to-End Congestion Control for
              Wired/Wireless Networks", Wireless Networks 8 , 2002.

              Haas, A., Rossberg, A., Schuff, D.L., Titzer, B.L.,
              Holman, M., Gohman, D., Wagner, L., Zakai, A., and J.F.
              Bastien, "Bringing the web up to speed with WebAssembly",

Piraux, et al.          Expires 10 September 2020              [Page 17]

Internet-Draft                QUIC Plugins                    March 2020

              Proceedings of the 38th ACM SIGPLAN Conference on
              Programming Language Design and Implementation , June

   [ICNP]     Wirtgen, T., Denos, C., De Coninck, Q., Jadin, M., and O.
              Bonaventure, "The Case for Pluginized Routing Protocols",
              2019 IEEE 27th International Conference on Network
              Protocols (ICNP) , October 2019.

   [FAN]      Rochet, F., Bonaventure, O., and O. Pereira, "Flexible
              Anonymous Network", HotPETs , July 2019.

   [DROPPING] Rochet, F. and O. Pereira, "Dropping on the Edge:
              Flexibility and Traffic Confirmation in Onion Routing
              Protocols", Proceedings on Privacy Enhancing
              Technologies , July 2018.


   The authors of Pluginizing QUIC are thanked again for their work that
   initiated this proposal.  This work was partially supported by the
   MQUIC project.

Authors' Addresses

   Maxime Piraux

   Email: maxime.piraux@uclouvain.be

   Quentin De Coninck

   Email: quentin.deconinck@uclouvain.be

   Francois Michel

   Email: francois.michel@uclouvain.be

   Florentin Rochet

   Email: florentin.rochet@uclouvain.be

Piraux, et al.          Expires 10 September 2020              [Page 18]

Internet-Draft                QUIC Plugins                    March 2020

   Olivier Bonaventure

   Email: olivier.bonaventure@uclouvain.be

Piraux, et al.          Expires 10 September 2020              [Page 19]

Html markup produced by rfcmarkup 1.129d, available from https://tools.ietf.org/tools/rfcmarkup/