idnits 2.17.1 draft-piraux-quic-plugins-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (9 March 2020) is 1508 days in the past. Is this intentional? Checking references for intended status: Experimental ---------------------------------------------------------------------------- == Outdated reference: A later version (-34) exists of draft-ietf-quic-transport-27 -- Obsolete informational reference (is this intentional?): RFC 6962 (Obsoleted by RFC 9162) -- Obsolete informational reference (is this intentional?): RFC 7540 (Obsoleted by RFC 9113) -- Obsolete informational reference (is this intentional?): RFC 6824 (Obsoleted by RFC 8684) == Outdated reference: A later version (-04) exists of draft-fairhurst-quic-ack-scaling-01 == Outdated reference: A later version (-02) exists of draft-iyengar-quic-delayed-ack-00 == Outdated reference: A later version (-07) exists of draft-deconinck-quic-multipath-04 == Outdated reference: A later version (-26) exists of draft-ietf-taps-interface-05 == Outdated reference: A later version (-06) exists of draft-scharf-tcpm-yang-tcp-04 Summary: 0 errors (**), 0 flaws (~~), 7 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 QUIC Working Group M. Piraux 3 Internet-Draft Q. De Coninck 4 Intended status: Experimental F. Michel 5 Expires: 10 September 2020 F. Rochet 6 O. Bonaventure 7 UCLouvain 8 9 March 2020 10 QUIC Plugins 11 draft-piraux-quic-plugins-00 13 Abstract 15 The extensibility of Internet protocols is a key factor to their 16 success. Yet, their implementations are often not designed with 17 agility in mind. In this document, we leverage the features of the 18 QUIC protocol and propose a solution to dynamically extend QUIC 19 implementations. Our solution relies on QUIC Plugins that allow 20 tuning and extending the QUIC protocol on a per-connection basis. 21 These platform-independent plugins are executed inside a sandboxed 22 environment which can be included in QUIC implementations. We 23 describe how such plugins can be used in different use cases. 25 This document is a straw-man proposal. It aims at sparking 26 discussions on the proposed approach. 28 Note to Readers 30 Discussion of this document takes place on the QUIC Working Group 31 mailing list (quic@ietf.org), which is archived at 32 https://mailarchive.ietf.org/arch/browse/quic/ 33 (https://mailarchive.ietf.org/arch/browse/quic/). 35 Source for this draft and an issue tracker can be found at 36 https://github.com/mpiraux/draft-piraux-quic-plugins 37 (https://github.com/mpiraux/draft-piraux-quic-plugins). 39 Status of This Memo 41 This Internet-Draft is submitted in full conformance with the 42 provisions of BCP 78 and BCP 79. 44 Internet-Drafts are working documents of the Internet Engineering 45 Task Force (IETF). Note that other groups may also distribute 46 working documents as Internet-Drafts. The list of current Internet- 47 Drafts is at https://datatracker.ietf.org/drafts/current/. 49 Internet-Drafts are draft documents valid for a maximum of six months 50 and may be updated, replaced, or obsoleted by other documents at any 51 time. It is inappropriate to use Internet-Drafts as reference 52 material or to cite them other than as "work in progress." 54 This Internet-Draft will expire on 10 September 2020. 56 Copyright Notice 58 Copyright (c) 2020 IETF Trust and the persons identified as the 59 document authors. All rights reserved. 61 This document is subject to BCP 78 and the IETF Trust's Legal 62 Provisions Relating to IETF Documents (https://trustee.ietf.org/ 63 license-info) in effect on the date of publication of this document. 64 Please review these documents carefully, as they describe your rights 65 and restrictions with respect to this document. Code Components 66 extracted from this document must include Simplified BSD License text 67 as described in Section 4.e of the Trust Legal Provisions and are 68 provided without warranty as described in the Simplified BSD License. 70 Table of Contents 72 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 73 2. Dynamically extensible protocol implementations . . . . . . . 6 74 2.1. Requirements . . . . . . . . . . . . . . . . . . . . . . 8 75 3. Pluginizing QUIC . . . . . . . . . . . . . . . . . . . . . . 9 76 4. Exchanging QUIC Plugins . . . . . . . . . . . . . . . . . . . 10 77 5. Examples of use-cases . . . . . . . . . . . . . . . . . . . . 11 78 5.1. Tunable acknowledgments policy . . . . . . . . . . . . . 11 79 5.2. Pluggable congestion controller . . . . . . . . . . . . . 11 80 5.3. Application-driven stream scheduling . . . . . . . . . . 12 81 5.4. More advanced QUIC extensions . . . . . . . . . . . . . . 12 82 6. QUIC Plugins Authenticity . . . . . . . . . . . . . . . . . . 12 83 6.1. Central Authorities . . . . . . . . . . . . . . . . . . . 13 84 6.2. Plugin Transparency . . . . . . . . . . . . . . . . . . . 13 85 6.3. Comparing Certificate Transparency and Plugin 86 Transparency . . . . . . . . . . . . . . . . . . . . . . 13 87 7. Security Considerations . . . . . . . . . . . . . . . . . . . 14 88 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 89 9. Informative References . . . . . . . . . . . . . . . . . . . 14 90 Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 18 91 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 18 93 1. Introduction 95 Internet hosts rely on protocols to efficiently exchange information. 96 Most protocols are designed assuming a layered model. In such a 97 layered protocol model, a protocol implementation is often 98 represented as a black-box that uses the service provided by the 99 underlying layer to offer an enhanced Application Programming 100 Interface (API) to the upper layer. This is illustrated in Figure 1. 102 Layer N+1 103 ---------- +----------- API -----------+ 104 Management | | 105 Protocol | | 106 <--------->| Protocol implementation | 107 | | 108 +---------------------------+ 109 || /\ 110 \/ || 111 ----------------------------------- 112 Layer N-1 114 Figure 1: A protocol implementation exposes an API to the upper layer 116 Different protocols expose different APIs. In the transport layer, 117 the socket API is the most popular one. It was originally defined 118 with the TCP and UDP protocols in mind, but has been extended to 119 support SCTP [RFC6458] and Multipath TCP [RFC6897]. The TAPS working 120 group is currently defining new APIs for the transport services 121 [I-D.ietf-taps-interface]. 123 An important benefit of having standardized APIs is that if two 124 implementations expose the same API, it is possible to replace one by 125 the other without changing anything in the upper layers. 127 Besides exposing an API to the layer above, many protocol 128 implementations also expose an API to management protocols such as 129 SNMP, IPFIX or NETCONF. For example, a TCP implementation exposes 130 the variables and tables defined in the TCP part of the MIB-2 131 [RFC1213][RFC4022]. There is ongoing work in developing a YANG model 132 for TCP implementations [I-D.scharf-tcpm-yang-tcp]. This is 133 illustrated in the left part of Figure 1. 135 These management APIs expose abstract configuration parameters and 136 statistics about the key operations performed by a protocol 137 implementation to offer more control to the upper layer. They have 138 been useful in configuring and operating a wide range of protocol 139 implementations. As different implementations expose the same 140 abstraction, it becomes possible for operators to configure and 141 manage different implementations by using the same tool in a unified 142 manner. 144 A protocol implementation exchanges messages with other 145 implementations by leveraging the service provided by the underlying 146 layer. For example, a TCP implementation interacts through the 147 socket API and exchanges TCP segments with remote hosts through the 148 underlying IP protocol. Protocol designers usually define transport 149 and application protocols in two parts: 151 * a series of messages that are encoded using a specific format. 153 * a Finite State Machine that defines how hosts react to commands 154 from the layer above or to the reception of a specific message. 156 This model has been used to represent a wide range of Internet 157 protocols. Typically, the Finite State Machine and the syntax of the 158 messages are described in a single or a series of documents that are 159 heavily discussed within IETF working groups before reaching a 160 consensus and getting a final specification. The ongoing work on the 161 finalization of the first version of the QUIC specification is a 162 recent example of such efforts [I-D.ietf-quic-transport]. 164 Once the first stable version of the specification of a protocol has 165 been approved, IETF working groups typically observe the deployment 166 of the protocol and improve it based on the received feedback. If 167 the protocol is successful, it often triggers suggestions for 168 extensions or improvements. These extensions are important for these 169 successful protocols, but they often take a lot of time to be 170 deployed. Experience with TCP shows that extensions, such as 171 selective acknowledgments [RFC2018], support for large windows and 172 timestamps [RFC7323] or more recently Multipath TCP [RFC6824] took 173 more than a decade to be widely deployed. There are several 174 considerations that can explain the difficulty of deploying TCP 175 extensions, ranging from the fact that TCP is often part of operating 176 system kernels, which evolve at a slower pace than applications, to 177 middlebox interference. 179 Looking at other IETF protocols, we rarely observe successful 180 protocols that have not been extended over the years. Thus, the need 181 for extensibility could be seen as an invariant for a successful 182 Internet protocol. In addition to the extensions that were accepted 183 by the IETF and eventually deployed, there are many other extensions 184 that correspond to specific applications or more restricted use 185 cases. These extensions would be very valuable in specific 186 environments, but their proponents never managed to convince the 187 relevant IETF working group and implementers of their benefits. 189 Besides the protocol extensions, we also observe that there are some 190 protocol behaviors that can be difficult to precisely express using a 191 set of parameters that are exchanged inside a message. Here are two 192 recent examples that illustrate this difficulty. 194 A first example is the transmission of acknowledgments in reliable 195 transport protocols. There is a trade-off between the feedback 196 provided by the acknowledgments and the resources (bandwidth and CPU) 197 required to generate and process them. Various heuristics have been 198 proposed in TCP to generate these ACKs 199 [RFC1122],[RFC5681],[RFC3449],[RFC5690]. These heuristics are 200 deployed independently on receivers, but for some of them the senders 201 need to adapt by at least taking into account the fact that some 202 acknowledgments were delayed while measuring the round-trip-time. A 203 similar discussion has started for QUIC. Given the flexibility of 204 QUIC, researchers have proposed to define an acknowledgment strategy 205 as a set of parameters that are exchanged in a new QUIC frame over 206 each connection 207 [I-D.fairhurst-quic-ack-scaling],[I-D.iyengar-quic-delayed-ack]. 208 This brings more flexibility than in TCP where the limited size of 209 the header made it impossible to exchange such information. 211 A second example in the application layer is the support for stream 212 priorities in HTTP/2 [RFC7540]. Since HTTP/2 provides parallel 213 streams, some application developers have expressed their need for 214 prioritizing some streams over others. The HTTP/2 protocol defines 215 such priorities, but they are not widely used and some have proposed 216 to deprecate them [I-D.peon-httpbis-h2-priority-one-less]. In spite 217 of this, a proposal for stream prioritization for HTTP/3 already 218 exists [I-D.kazuho-httpbis-priority]. [LNBIP2020] evaluates stream 219 scheduling for HTTP/3 and claims that performances are heavily 220 impacted by the adopted stream scheduling. 222 These examples illustrate the difficulty of precisely expressing 223 complex behaviors in a few parameters that are exchanged inside 224 packets. 226 In this document, we propose a different approach to specify and 227 implement protocols to better address the extensibility requirement. 228 We focus on the QUIC protocol in this document, but similar ideas 229 could be applied to other IETF protocols or networking systems. We 230 leverage the recent results in extending operating system kernels 231 [eBPF] or web-browsers [WebAssembly] with virtual machines that 232 execute bytecodes to propose a new approach to define complex 233 behaviors inside protocols. We first describe the general 234 architecture of the proposed approach in Section 2. We then provide 235 a few examples showing how such an approach could be applied to the 236 next version of the QUIC protocol in Section 3. 238 2. Dynamically extensible protocol implementations 240 Experience with successful Internet protocols shows that once a 241 protocol gets (widely) deployed, it attracts new use cases and 242 proposals to extend and improve it. Most of the key Internet 243 protocols, including IP, TCP, HTTP, DNS, BGP, OSPF, IS-IS, ... have 244 been improved over the years. Today, the developer of an 245 implementation of any of these protocols need to consult dozens of 246 RFCs to find their complete specification. 248 Despite the importance of extensions to those key Internet protocols, 249 we still do not design them under the assumption that they will 250 evolve over decades and that their implementations should be made 251 agile. In this document, we propose a new organization for protocol 252 implementations. Instead of trying to pack as many features as 253 possible inside a protocol implementation that is considered as a 254 blackbox, we consider a protocol implementation as an open system 255 which can be extended to support new features in a safe and agile 256 manner. Our vision is that such an implementation exposes an 257 internal Plugin API which can be leveraged by code extensions that we 258 call Plugins in this document. This is illustrated in Figure 2. 260 Layer N+1 261 ---------- +----------- API -----------+ 262 Management | ( ) ( ) (x)<------ Plugin_A 263 Protocol | | 264 <--------->| Protocol implementation | 265 | ( ) (x)<--------- Plugin_B 266 +---------------------------+ 267 || /\ 268 \/ || Legend: 269 --------------------------------------- ( ) Part of the Plugin API 270 Layer N-1 (x) Plugin injected 272 Figure 2: A pluginized protocol implementation exposes a Plugin 273 API that enables plugins to dynamically extend its operation 275 These Plugins extend the protocol by modifying its messages or its 276 Finite State Machine. Consider Figure 3 as an example which 277 illustrates a simple receiver with three states, i.e. Receiving, Data 278 rcvd and Ack needed. This receiver waits until either two data 279 packets have been received or 10 milliseconds have passed after 280 receiving a data packet before sending an acknowledgment. Its 281 implementation consists of three actions, receive(), send_ack() and 282 wait(). 284 An application using this receiver could benefit from tuning this 285 acknowledgment policy. For instance, another state could be chained 286 between Data rcvd and Ack needed, so that acknowledgments can be 287 batched for more than two data packets. Similarly, a more advanced 288 heuristic could be added to generate acknowledgments, e.g. taking 289 into account the size of data packets to detect transmission tails. 291 +-----------+ receive() +-----------+ 292 | Receiving |>----------->| Data rcvd | 293 +-----------+ +-v-------v-+ 294 ^ | | 295 | wait(10) | | receive() 296 | | | 297 | | | 298 | send_ack() +--v-------v-+ 299 \-------------<| Ack needed | 300 +------------+ 302 Figure 3: Finite State Machine of a simple receiver 304 Using this Plugin API, a protocol can be extended to add new messages 305 and to modify its Finite State Machine, i.e. modify its states and 306 transitions. This document defines such protocol as a pluginized 307 protocol. Figure 4 illustrates how this simple receiver could be 308 extended. In this example a new state is added so that a single 309 acknowledgment can be sent for three received data packets. 311 +-----------+ receive() +-----------+ receive() *+++++++++++++* 312 | Receiving |>----------->| Data rcvd |>+++++++++++>| Data rcvd 2 | 313 +-----------+ +-v---------+ *+v+++++++++v+* 314 ^ | ! ! 315 | wait(10) | wait(5) ! ! 316 | | /+++++++++++++++++/ ! 317 | | ! ! 318 | send_ack() +--v-------v-+ receive() ! 319 \-------------<| Ack needed |<++++++++++++++++++++++++/ 320 +------------+ 321 Legend: 322 >+++> Transition added by a Plugin 323 *+++* 324 | S | State added by a Plugin 325 *+++* 327 Figure 4: Extended Finite State Machine of a pluginized receiver 329 Due to space constraints, the case of adding a new action is not 330 depicted in Figure 4. In this example, a new action data_not_full() 331 could be added by a Plugin. This action could be taken whenever the 332 last received data packet is not full, indicating the end of a series 333 of packets. Transitions from the states Data rcvd and Data rcvd 2 to 334 the state Ack needed with this action could be added by this Plugin. 336 2.1. Requirements 338 There are different ways of implementing the idea of dynamically 339 extending protocols by using plugins. We list here some requirements 340 that any solution should support: 342 REQ1: Different implementations should expose the same Plugin API, 343 e.g. as different implementations expose the same SNMP MIB. 345 REQ2: It should be possible to dynamically attach a plugin to one 346 instance of an implementation. For instance, for a connection- 347 oriented protocol, it should be possible to associate a plugin to 348 a given connection. Different connections could have different 349 sets of plugins. 351 REQ3: It should be possible to execute the same plugin on different 352 interoperable implementations of the same protocol. 354 REQ4: It should be possible for a protocol implementation to 355 restrict the operations that a given plugin can execute. 357 REQ5: Plugins should be sandboxed and the application should be safe 358 using them, for instance regarding memory corruption and runtime 359 traps. 361 One possible way to realize this new architecture is to include a 362 virtual machine inside each protocol implementation and expose a 363 small Plugin API accessible through the virtual machine. Several 364 efficient virtual machines have been proposed and used in related 365 environments [eBPF] [WebAssembly]. They provide a sandbox 366 controlling the operations a plugin can execute and the memory that 367 it can access. Since the same virtual machine can be provided on 368 different platforms, it becomes possible to execute the same plugin 369 on different implementations of a given protocol exposing the same 370 Plugin API. 372 The idea of extending protocols through plugins can be applied to 373 different Internet protocols. In this document, we focus on adding 374 plugins to QUIC since it is a recent and flexible protocol that 375 includes useful security features. A similar approach has been 376 applied to OSPF and BGP [ICNP] and partially to TCP 377 [TCP-Options-BPF]. Other networking systems, such as the Tor network 378 [FAN] or Cryptocurrency networks, may also benefit from extending 379 their protocols through plugins. In some cases, the extensibility 380 through plugins may help to solve fundamental security issues 382 [DROPPING] linked to both compliance to the Postel principle and slow 383 deployment processes. 385 3. Pluginizing QUIC 387 Conceptually, we break down a QUIC implementation execution flow into 388 generic subroutines. These are specified functions called protocol 389 operations. These protocol operations implement a given part of the 390 QUIC protocol, for example the acknowledgment generation or the 391 computation of the round-trip-time. Some are generic and depend on a 392 parameter, for instance parsing a QUIC frame is a generic operation 393 that depends on the type of QUIC frame. This version of the document 394 does not elaborate exhaustively on the protocol operations composing 395 a Pluginized QUIC implementation. The next versions of this document 396 will work on defining a set of protocol operations. 398 A QUIC Plugin consists of platform-independent bytecode which 399 modifies or extends the behavior of a QUIC implementation. Adding 400 the functionality of a QUIC Plugin consists in adding or replacing a 401 set of protocol operations implemented by this bytecode. This action 402 of adding a QUIC Plugin to a QUIC connection is referred to as 403 injecting a QUIC Plugin. Injecting a plugin is limited to a given 404 QUIC connection. 406 Its bytecode is run inside a sandboxed execution environment. It has 407 restricted access to the state of a QUIC connection through the 408 Plugin API. 410 The scope of a QUIC Plugin is restricted by both the limitations of 411 this execution environment, e.g. in terms of instruction set and 412 quantity, and by the surface exposed by the Plugin API, e.g. the 413 quantity of state that can be read from or written to by a plugin. 414 The Plugin API also defines a set of protocol operations to which 415 QUIC Plugins can be injected. For instance, a QUIC implementation 416 might restrict QUIC Plugins injection to its acknowledgment 417 generation policy, e.g. the protocol operation deciding whether 418 sending an ACK frame is needed. 420 A QUIC Plugin can be injected by several means. The application can 421 inject plugins to tune its underlying QUIC connection. QUIC peers 422 can exchange and inject plugins over a QUIC connection, as described 423 in Section 4. Users can set a default configuration injecting 424 plugins on their devices. 426 Considering again Figure 3 applied to QUIC Plugins, the actions are 427 the protocol operations. The states of the FSM are defined by the 428 QUIC connection state, which can be modified and extended during the 429 execution of a protocol operation through the Plugin API. The 430 transitions are calls to protocol operations. 432 4. Exchanging QUIC Plugins 434 Injecting QUIC Plugins locally allows the application to tune the 435 underlying QUIC implementation to its needs. But some use-cases 436 requires adapting the peer behavior. In those cases, being able to 437 exchange plugins helps to fill this gap. 439 QUIC offers both data multiplexing and encryption. Using those 440 mechanisms, the QUIC Plugins used for a given connection could be 441 safely transferred over this connection in a new dedicated stream, 442 akin to the crypto stream. This does not impact the application data 443 transfer, as illustrated in Figure 5. In this example, an HTTP/3 444 request is interleaved with the transfer from the server to the 445 client of a QUIC Plugin controlling the acknowledgment policy. 447 Client Server 448 | (QUIC connection handshake) | 449 | | 450 | STREAM[0, "HTTP/3 GET"] | 451 |------------------------------------>| 452 | | 453 | STREAM[0, "200 OK..."] | 454 |<------------------------------------| 455 | | 456 | PLUGIN["ack_delay", bytecode] | 457 |<------------------------------------| 458 | | 459 | STREAM[0, "...", FIN] | 460 |<------------------------------------| 462 Figure 5: Interleaving a QUIC Plugin transfer over a QUIC connection 464 A local policy could restrict the type of plugins that can be 465 exchanged and injected, e.g. in terms of connection state accessed 466 and in terms of protocol operations affected. This version of 467 document does not describe further how the negotiation of QUIC 468 Plugins takes place. 470 QUIC Plugins could also be transferred out of band. The application 471 using QUIC can then inject these plugins locally. 473 5. Examples of use-cases 475 There exist several cases in which being able to modify the behavior 476 of a QUIC peer, either locally or remotely, is beneficial. This 477 first version of the document focus on enabling the extension of 478 simple QUIC mechanisms. Three of them are documented in this 479 section. Contributions to this document regarding new uses-cases are 480 welcomed. 482 5.1. Tunable acknowledgments policy 484 The large diversity of Internet paths also counts networks involving 485 a significant path asymmetry. Those paths require the receiver to 486 adapt its feedback rate to the sender. The performance of transport 487 protocols such as TCP on those paths has been studied in depth and 488 reported in [RFC3449]. A method for controlling the rate of receiver 489 feedback of TCP, i.e. the rate of ACKs, has been proposed in 490 [RFC5690]. 492 Proposals for controlling the acknowledgment policy of QUIC already 493 exist. [I-D.fairhurst-quic-ack-scaling] proposes a change to the 494 default policy for asymmetric paths. [I-D.iyengar-quic-delayed-ack] 495 describes a QUIC extension enabling a QUIC endpoint to control the 496 acknowledgment policy of its peer. For that purpose, they model the 497 acknowledgment policy depending on a few parameters and introduce a 498 new QUIC frame to signal new values for those parameters. 500 A QUIC Plugin could allow implementing a new acknowledgment with a 501 fine granularity. For example, in the case of an application that 502 generates bursty traffic, such as a real-time video streaming 503 application, a QUIC Plugin allows embedding application knowledge, 504 i.e. the characteristics of such bursts, inside the acknowledgment 505 generation policy. Exchanging and injecting this plugin allows 506 controlling the other peer behavior. 508 5.2. Pluggable congestion controller 510 There exists many congestion control algorithms. Each of them has 511 been designed for a given context, i.e. a range of applications and a 512 range of Internet paths. For instance, NewReno [RFC6582] has been 513 designed for optimizing the web use-case on common Internet paths. 514 Westwood [Westwood] is a modification of NewReno to better 515 accommodate Internet paths with a high bandwidth-delay product, such 516 as satellite links. 518 Efforts to restructure congestion controllers within a common 519 framework have been presented in past works such as [CCP]. Such a 520 framework eases the development and maintenance of those algorithms. 521 It also enables rapid prototyping and A/B testing. 523 [TCP-Options-BPF] proposes a new TCP Option, leveraging the TCP-BPF 524 framework, to negotiate the congestion controller to use. The QUIC 525 specification does not specify a similar mechanism. Negotiating the 526 congestion controller used allows one endpoint to tune the other, 527 provided that it implements the algorithm. QUIC Plugins could allow 528 the application to directly plug the required congestion controller 529 and to exchange it with the other peer. This flexibility allows the 530 application to choose the best congestion controller for its 531 requirements. 533 5.3. Application-driven stream scheduling 535 QUIC streams allow the application to multiplex several bytestreams 536 over a single QUIC connection. Yet, the QUIC specification does not 537 provide a mechanism for exchanging prioritization information nor for 538 indicating the relative priority of streams. As described in 539 Section 2.3 of [I-D.ietf-quic-transport], "A QUIC implementation 540 should provide ways in which an application can indicate the relative 541 priority of streams". A QUIC implementation could allow QUIC Plugins 542 to extend or override its stream scheduler. 544 For other applications using QUIC with a broad range of requirements, 545 a flexible approach for defining the stream scheduling policy is key 546 to best fit their needs. QUIC Plugin offer a flexible way to embed 547 application knowledge inside the QUIC implementation. 549 5.4. More advanced QUIC extensions 551 Exposing more protocol operations through the API proposed to plugins 552 by the QUIC implementation allows implementing more advanced QUIC 553 Plugins. Each protocol operation offers flexibility over the QUIC 554 implementation. [PQUIC] demonstrates how this approach can be used 555 to implement Multipath QUIC [I-D.deconinck-quic-multipath] and 556 [QUIC-FEC] entirely using plugins. 558 6. QUIC Plugins Authenticity 560 When exchanging and injecting QUIC Plugins, guaranteeing there 561 authenticity and safety is important. This section describes two 562 possible approaches for this purpose, the first guarantees the 563 authenticity of the QUIC Plugins, the second guarantee both their 564 authenticity and an open set of security properties with regard to 565 QUIC Plugins. 567 6.1. Central Authorities 569 This first approach leverages the central authorities commonly used 570 to secure HTTPS. In this approach, each QUIC Plugin could be 571 associated to some level of trust regarding its origin. A QUIC 572 Plugin may be authenticated using a certificate, itself certified by 573 a central authority. Consequently, a QUIC implementation supporting 574 QUIC plugins may restrict their exchange and only accept plugins 575 authenticated using the same certificate used for establishing the 576 QUIC connection. This approach only guarantees the authenticity of a 577 QUIC Plugin. 579 6.2. Plugin Transparency 581 This second approach is presented in the [PQUIC] research paper, and 582 suggests going beyond the restrictive approach of a centralized trust 583 model. The centralized trust model obliges the server to update 584 manually their list of supported plugins. It also prevents the 585 client from injecting a plugin that the server has not marked as 586 supported, e.g. because the server is unaware of its existence, or 587 because its list has not been updated. 589 The suggested design, called Plugin Transparency, proposes a 590 methodology to transparently distribute plugins created by 591 independent developers and verified by freely selected plugin 592 validators. Those validators endorse verifying some publicly known 593 safety or security properties. A QUIC endpoint can announce a set of 594 conditions to accept a plugin as a first order logic formula bound to 595 plugin validators. Whenever the other peer is willing to inject a 596 plugin, it sends a (unforgeable) proof fulfilling the requirements 597 expressed by this logic formula. If the requirements are met, then 598 the endpoint may safely accept the plugin and could update its list 599 of supported plugin. Compared to the central authority approach, 600 supported plugins are updated as part of the protocol design or as a 601 consequence of any change to the default logic formula bound to 602 plugin acceptance. 604 6.3. Comparing Certificate Transparency and Plugin Transparency 606 Certificate Transparency (CT) [RFC6962] is an attempt to address the 607 structural issues hidden within the central trust assumption and 608 prevent mistakes, rogue certificates and rogue authorities from 609 weakening the system. Plugin Transparency bears similarities to 610 Certificate Transparency. First, its motivations are drawn from the 611 same conclusions regarding the danger of central trust models. 612 Second, similar to CT, it is based on distributing trust assumptions 613 to secure the system. However, Plugin Transparency offers stronger 614 properties and eliminates the independent monitoring entities which 615 hold the resource endowment to continuously monitor the CT log on the 616 behalf of certificate owners. Indeed, our design offers the 617 independent developers checking for spurious plugins in O(log(N)) 618 with N the size of the log (instead of O(N) in CT's design). Our 619 design also offers secure human-readable plugin names that 620 unambiguously authenticate them and non-equivocation from rogue 621 plugin validators. Our design is more resilient to failure by 622 offering several validators that can be trusted within the logic 623 formula. For example, a QUIC peer may request a proof bound to any 624 combination of plugin validators. The detail of Plugin Transparency, 625 including performance considerations and security proofs are 626 available in [PQUIC]. 628 7. Security Considerations 630 The next versions of this document will elaborate on security 631 considerations following the guidelines of [RFC3552]. Moreover, this 632 document will consider privacy as part of those considerations. 634 8. IANA Considerations 636 This document has no IANA actions. 638 9. Informative References 640 [PQUIC] De Coninck, Q., Michel, F., Piraux, M., Rochet, F., Given- 641 Wilson, T., Legay, A., Pereira, O., and O. Bonaventure, 642 "Pluginizing QUIC", Proceedings of SIGCOMM'19 , August 643 2019, . 645 [I-D.kazuho-httpbis-priority] 646 Oku, K. and L. Pardue, "Extensible Prioritization Scheme 647 for HTTP", Work in Progress, Internet-Draft, draft-kazuho- 648 httpbis-priority-04, 20 November 2019, 649 . 652 [LNBIP2020] 653 Marx, R., De Decker, T., Quax, P., and W. Lamotte, 654 "Resource Multiplexing and Prioritization in HTTP/2 over 655 TCP versus HTTP/3 over QUIC", 2020. 657 [CCP] Narayan, A., Cangialosi, F., Raghavan, D., Goyal, P., 658 Narayana, S., Mittal, R., Alizadeh, M., and H. 659 Balakrishnan, "Restructuring Endpoint Congestion Control", 660 Proc. SIGCOMM 2018 , August 2018. 662 [I-D.ietf-quic-transport] 663 Iyengar, J. and M. Thomson, "QUIC: A UDP-Based Multiplexed 664 and Secure Transport", Work in Progress, Internet-Draft, 665 draft-ietf-quic-transport-27, 21 February 2020, 666 . 669 [RFC1122] Braden, R., Ed., "Requirements for Internet Hosts - 670 Communication Layers", STD 3, RFC 1122, 671 DOI 10.17487/RFC1122, October 1989, 672 . 674 [RFC1213] McCloghrie, K. and M. Rose, "Management Information Base 675 for Network Management of TCP/IP-based internets: MIB-II", 676 STD 17, RFC 1213, DOI 10.17487/RFC1213, March 1991, 677 . 679 [RFC4022] Raghunarayan, R., Ed., "Management Information Base for 680 the Transmission Control Protocol (TCP)", RFC 4022, 681 DOI 10.17487/RFC4022, March 2005, 682 . 684 [RFC5681] Allman, M., Paxson, V., and E. Blanton, "TCP Congestion 685 Control", RFC 5681, DOI 10.17487/RFC5681, September 2009, 686 . 688 [RFC3449] Balakrishnan, H., Padmanabhan, V., Fairhurst, G., and M. 689 Sooriyabandara, "TCP Performance Implications of Network 690 Path Asymmetry", BCP 69, RFC 3449, DOI 10.17487/RFC3449, 691 December 2002, . 693 [RFC5690] Floyd, S., Arcia, A., Ros, D., and J. Iyengar, "Adding 694 Acknowledgement Congestion Control to TCP", RFC 5690, 695 DOI 10.17487/RFC5690, February 2010, 696 . 698 [RFC6962] Laurie, B., Langley, A., and E. Kasper, "Certificate 699 Transparency", RFC 6962, DOI 10.17487/RFC6962, June 2013, 700 . 702 [RFC7540] Belshe, M., Peon, R., and M. Thomson, Ed., "Hypertext 703 Transfer Protocol Version 2 (HTTP/2)", RFC 7540, 704 DOI 10.17487/RFC7540, May 2015, 705 . 707 [RFC6897] Scharf, M. and A. Ford, "Multipath TCP (MPTCP) Application 708 Interface Considerations", RFC 6897, DOI 10.17487/RFC6897, 709 March 2013, . 711 [RFC6824] Ford, A., Raiciu, C., Handley, M., and O. Bonaventure, 712 "TCP Extensions for Multipath Operation with Multiple 713 Addresses", RFC 6824, DOI 10.17487/RFC6824, January 2013, 714 . 716 [RFC7323] Borman, D., Braden, B., Jacobson, V., and R. 717 Scheffenegger, Ed., "TCP Extensions for High Performance", 718 RFC 7323, DOI 10.17487/RFC7323, September 2014, 719 . 721 [RFC2018] Mathis, M., Mahdavi, J., Floyd, S., and A. Romanow, "TCP 722 Selective Acknowledgment Options", RFC 2018, 723 DOI 10.17487/RFC2018, October 1996, 724 . 726 [RFC6458] Stewart, R., Tuexen, M., Poon, K., Lei, P., and V. 727 Yasevich, "Sockets API Extensions for the Stream Control 728 Transmission Protocol (SCTP)", RFC 6458, 729 DOI 10.17487/RFC6458, December 2011, 730 . 732 [RFC6582] Henderson, T., Floyd, S., Gurtov, A., and Y. Nishida, "The 733 NewReno Modification to TCP's Fast Recovery Algorithm", 734 RFC 6582, DOI 10.17487/RFC6582, April 2012, 735 . 737 [RFC3552] Rescorla, E. and B. Korver, "Guidelines for Writing RFC 738 Text on Security Considerations", BCP 72, RFC 3552, 739 DOI 10.17487/RFC3552, July 2003, 740 . 742 [I-D.fairhurst-quic-ack-scaling] 743 Fairhurst, G., Custura, A., and T. Jones, "Changing the 744 Default QUIC ACK Policy", Work in Progress, Internet- 745 Draft, draft-fairhurst-quic-ack-scaling-01, 5 March 2020, 746 . 749 [I-D.iyengar-quic-delayed-ack] 750 Iyengar, J. and I. Swett, "Sender Control of 751 Acknowledgement Delays in QUIC", Work in Progress, 752 Internet-Draft, draft-iyengar-quic-delayed-ack-00, 23 753 January 2020, . 756 [I-D.deconinck-quic-multipath] 757 Coninck, Q. and O. Bonaventure, "Multipath Extensions for 758 QUIC (MP-QUIC)", Work in Progress, Internet-Draft, draft- 759 deconinck-quic-multipath-04, 5 March 2020, 760 . 763 [I-D.peon-httpbis-h2-priority-one-less] 764 Thomson, M. and R. Peon, "Deprecation of HTTP/2 Priority 765 Signaling Hints", Work in Progress, Internet-Draft, draft- 766 peon-httpbis-h2-priority-one-less-00, 25 July 2019, 767 . 770 [I-D.ietf-taps-interface] 771 Trammell, B., Welzl, M., Enghardt, T., Fairhurst, G., 772 Kuehlewind, M., Perkins, C., Tiesel, P., Wood, C., and T. 773 Pauly, "An Abstract Application Layer Interface to 774 Transport Services", Work in Progress, Internet-Draft, 775 draft-ietf-taps-interface-05, 4 November 2019, 776 . 779 [I-D.scharf-tcpm-yang-tcp] 780 Scharf, M., Murgai, V., and M. Jethanandani, "YANG Model 781 for Transmission Control Protocol (TCP) Configuration", 782 Work in Progress, Internet-Draft, draft-scharf-tcpm-yang- 783 tcp-04, 24 February 2020, . 786 [QUIC-FEC] Michel, F., De Coninck, Q., and O. Bonaventure, "QUIC-FEC: 787 Bringing the benefits of Forward Erasure Correction to 788 QUIC", IFIP Networking 2019 , May 2019. 790 [TCP-Options-BPF] 791 Tran, VH. and O. Bonaventure, "Beyond socket options: 792 making the Linux TCP stack truly extensible", IFIP 793 Networking 2019 , May 2019. 795 [eBPF] Matt Fleming, ., "A thorough introduction to eBPF", Linux 796 Weekly News , December 2017, 797 . 799 [Westwood] Casetti, C., Gerla, M., Mascolo, S., Sanadidi, M.Y., and 800 R. Wang, "TCP Westwood: End-to-End Congestion Control for 801 Wired/Wireless Networks", Wireless Networks 8 , 2002. 803 [WebAssembly] 804 Haas, A., Rossberg, A., Schuff, D.L., Titzer, B.L., 805 Holman, M., Gohman, D., Wagner, L., Zakai, A., and J.F. 806 Bastien, "Bringing the web up to speed with WebAssembly", 807 Proceedings of the 38th ACM SIGPLAN Conference on 808 Programming Language Design and Implementation , June 809 2017. 811 [ICNP] Wirtgen, T., Denos, C., De Coninck, Q., Jadin, M., and O. 812 Bonaventure, "The Case for Pluginized Routing Protocols", 813 2019 IEEE 27th International Conference on Network 814 Protocols (ICNP) , October 2019. 816 [FAN] Rochet, F., Bonaventure, O., and O. Pereira, "Flexible 817 Anonymous Network", HotPETs , July 2019. 819 [DROPPING] Rochet, F. and O. Pereira, "Dropping on the Edge: 820 Flexibility and Traffic Confirmation in Onion Routing 821 Protocols", Proceedings on Privacy Enhancing 822 Technologies , July 2018. 824 Acknowledgments 826 The authors of Pluginizing QUIC are thanked again for their work that 827 initiated this proposal. This work was partially supported by the 828 MQUIC project. 830 Authors' Addresses 832 Maxime Piraux 833 UCLouvain 835 Email: maxime.piraux@uclouvain.be 837 Quentin De Coninck 838 UCLouvain 840 Email: quentin.deconinck@uclouvain.be 842 Francois Michel 843 UCLouvain 845 Email: francois.michel@uclouvain.be 847 Florentin Rochet 848 UCLouvain 850 Email: florentin.rochet@uclouvain.be 851 Olivier Bonaventure 852 UCLouvain 854 Email: olivier.bonaventure@uclouvain.be