UCLouvain

maxime.piraux@uclouvain.be

UCLouvain

olivier.bonaventure@uclouvain.be

Transport QUIC Working Group Internet-Draft This document specifies methods for tunneling Internet protocols such as TCP, UDP, IP and QUIC inside a QUIC connection.

Mobile devices such as laptops, smartphones or tablets have different requirements than the traditional fixed devices. These mobile devices often change their network attachment. They are often attached to trusted networks, but sometimes they need to be connected to untrusted networks where their communications can be eavesdropped, filtered or modified. In these situations, the classical approach is to rely on VPN protocols such as DTLS, TLS or IPSec. These VPN protocols provide the encryption and authentication functions to protect those mobile clients from malicious behaviors in untrusted networks. On the other hand, these devices are often multihomed and many expect to be able to perform seamless handovers from one access network to another without breaking the established VPN sessions. In some situations it can also be beneficial to combine two or more access networks together to increase the available host bandwidth. A protocol such as Multipath TCP supports those handovers and allows aggregating the bandwidth of different access links. It could be combined with single-path VPN protocols to support both seamless handovers and bandwidth aggregation above VPN tunnels. Unfortunately, Multipath TCP is not yet deployed on most Internet servers and thus few applications would benefit from such a use case. The QUIC protocol opens up a new way to find a clean solution to this problem. First, QUIC includes the same encryption and authentication techniques as deployed VPN protocols. Second, QUIC is intended to be widely used to support web-based services, making it unlikely to be filtered in many networks, in contrast with VPN protocols. Third, the multipath extensions proposed for QUIC enable it to efficiently support both seamless handovers and bandwidth aggregation. In this document, we explore how (Multipath) QUIC could be used to enable multi-homed mobile devices to communicate securely in untrusted networks. describes the reference environment of this document. Then, we explore and compare two different designs. The first, explained in , uses the recently proposed datagram extension () for QUIC to transport plain IP packets over a Multipath QUIC connection. The second, explained in , uses the QUIC streams to transport TCP bytestreams over a Multipath QUIC connection. specifies how a connection is established in this document proposal. specifies the format of the messages introduced by this document. contains example flows. Our starting point for this work is Multipath QUIC that was initially proposed in . A detailed specification of Multipath QUIC may be found in . Two implementations of different versions of this protocol are available , .

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 when, and only when, they appear in all capitals, as shown here.

We consider a multihomed client that is attached to one or several access networks. It establishes a Multipath QUIC connection to a concentrator. This MPQUIC connection is used to carry the UDP and TCP packets sent by the client. Thanks to the security mechanisms used by the Multipath QUIC connection, the client data is protected against attacks in one or both of the access networks. The client trusts the concentrator. The concentrator decrypts the QUIC packets exchanged over the Multipath QUIC connection and interacts with the remote hosts as a VPN concentrator would do.

| destination | | client | +--------------+ | server | +--------+ +---------+ ^ +-------------+ ^ | Access | | | | network | | Legend: .----| B |----. --- Multipath QUIC subflow +---------+ === TCP/UDP flow ]]>

illustrates a client-initiated flow. We also discuss inbound connections in this document in .

Our first mode of operation, called the datagram mode in this document, enables the client and the concentrator to exchange raw IP packets through the Multipath QUIC connection. This is done by using the recently proposed QUIC datagram extension . In a nutshell, to send an IP packet to a remote host, the client simply passes the entire packet as a datagram to the Multipath QUIC connection established with the concentrator. The IP packet is encoded in a QUIC DATAGRAM frame, then encrypted and authenticated in a QUIC packet. This transmission is subject to congestion control, but the datagram that contains the packet is not retransmitted in case of losses as specified in . The datagram mode is intended to provide a similar service as the one provided by IPSec tunnels or DTLS.

+----------+ | | IP | QUIC packet | +----------+ containing | | UDP | a DATAGRAM | +----------+ frame | | QUIC | | |..........| | | DATAGRAM | | |+--------+|<-. | || IP || | | |+--------+| | Tunneled | || UDP || | UDP packet | |+--------+| | | | .... |<-. `->+----------+ ]]>

illustrates how a UDP packet is tunneled using the datagram mode. The main advantage of the datagram mode is that it supports IP and any protocol above the network layer. Any IP packet can be transported using the datagram extension over a Multipath QUIC connection. However, this advantage comes with a large per-packet overhead since each packet contains both a network and a transport header. All these headers must be transmitted in addition with the IP/UDP/QUIC headers of the Multipath QUIC connection. For TCP connections for instance, the per-packet overhead can be large.

Since QUIC support multiple streams, another possibility to carry the data exchanged over TCP connections between the client and the concentrator is to transport the bytestream of each TCP connection as one of the bidirectional streams of the Multipath QUIC connection. For this, we base our approach on the 0-RTT Converter protocol that was proposed to ease the deployment of TCP extensions. In a nutshell, it is an application proxy that converts TCP connections, allowing the use of new TCP extensions through an intermediate relay. We use a similar approach in our stream mode. When a client opens a stream, it sends at the beginning of the bytestream one or more TLV messages indicating the IP address and port number of the remote destination of the bytestream. Their format is detailed in section . Upon reception of such a TLV message, the concentrator opens a TCP connection towards the specified destination and connects the incoming bytestream of the Multipath QUIC connection to the bytestream of the new TCP connection (and similarly in the opposite direction). summarizes how the new TCP connection is mapped to the QUIC stream. Actions and events of a TCP connection are translated to action and events of a QUIC stream, so that a state transition of one is translated to the other.

The QUIC stream-level flow control can be tuned to match the receive window size of the corresponding TCP, so that no excessive data needs to be buffered.

The client MUST establish a connection using the Multipath Extensions defined in . During connection establishment, the QUIC tunnel support is indicated by setting the ALPN token "qt" in the TLS handshake. Draft-version implementations MAY specify a particular draft version by suffixing the token, e.g. "qt-00" refers to the first version of this document. The concentrator can control the number of connections bytestreams that can be opened initially by setting the initial_max_streams_bidi QUIC transport parameter as defined in . After the QUIC connection is established, the client can start using the datagram or the stream mode. The client may use PCP to request the concentrator to accept inbound connections on their behalf. After the negotiation of such port mappings, the concentrator can start opening bidirectional streams to forward inbound connections as well as sending IP packets containing inbound UDP connections in QUIC datagrams.

In the following sections, we specify the format of each message introduced in this document. They are encoded as TLVs, i.e. (Type, Length, Value) tuples, as illustrated in . All TLV fields are encoded in network-byte order.

The Type field is encoded as a byte and identifies the type of the TLV. The Length field is encoded as a byte and indicate the length of the Value field. A value of zero indicates that no Value field is present. The Value field is a type-specific value whose length is determined by the Length field.

When using the stream mode, a one or more messages are used to trigger and confirm the establishment of a connection towards the final destination for a given stream. Those messages are exchanged on this given QUIC stream before the TCP connection bytestream. This section describes the format of these messages. This document specifies the following QUIC tunnel stream TLVs:

The TCP Connect TLV is used to establish a TCP connection through the tunnel towards the final destination. The TCP Extended Connect TLV allows indicating more information in the establishment request. The TCP Connect OK TLV confirms the establishment of this TCP connection. The Error TLV is used to indicate any out-of-band error that occurred during the TCP connection establishment associated to the QUIC stream. Finally, the End TLV marks the end of the series of TLVs and the start of the bytestream on a given QUIC stream. These TLVs are detailed in the following sections.

The TCP Connect TLV indicates the final destination of the TCP connection associated to a given QUIC stream. The fields Remote Peer Port and Remote Peer IP Address contain the destination port number and IP address of the final destination. The Remote Peer IP Address MUST be encoded as an IPv6 address. IPv4 addresses MUST be encoded using the IPv4-Mapped IPv6 Address format defined in . Further, the Remote Peer IP address field MUST NOT include multicast, broadcast, and host loopback addresses . A QUIC tunnel peer MUST NOT send more than one TCP Connect TLV per QUIC stream. A QUIC tunnel peer MUST NOT send a TCP Connect TLV if a TCP Extended Connect TLV was previously sent on a given stream. A QUIC tunnel peer MUST NOT send a TCP Connect TLV on non-self initiated streams.

The TCP Extended Connect TLV is an extended version of the TCP Connect TLV. It also indicates the source of the TCP connection. The fields Remote Peer Port and Remote Peer IP Address contain the destination port number and IP address of the final destination. The fields Local Peer Port and Local Peer IP Address contain the source port number and IP address of the source of the TCP connection. The Remote (resp. Local) Peer IP Address MUST be encoded as an IPv6 address. IPv4 addresses MUST be encoded using the IPv4-Mapped IPv6 Address format defined in . Further, the Remote (resp. Local) Peer IP address field MUST NOT include multicast, broadcast, and host loopback addresses . A QUIC tunnel peer MUST NOT send more than one TCP Extended Connect TLV per QUIC stream. A QUIC tunnel peer MUST NOT send a TCP Extended Connect TLV if a TCP Connect TLV was previously sent on a given stream. A QUIC tunnel peer MUST NOT send a TCP Extended Connect TLV on non-self initiated streams.

The TCP Connect OK TLV does not contain a value. Its presence confirms the successful establishment of connection to the final destination. A QUIC peer MUST NOT send a TCP Connect OK TLV on self-initiated streams.

The Error TLV indicates out-of-band errors that occurred during the establishment of the connection to the final destination. These errors can be ICMP Destination Unreachable messages for instance. In this case the ICMP packet received by the concentrator is copied inside the Error Payload field.

The following bytestream-level error codes are defined in this document:

Protocol Violation (0x0): A general error code for all non-conforming behaviors encountered. A QUIC tunnel peer SHOULD use a more specific error code when possible. ICMP Packet Received (0x1): This code indicates that the concentrator received an ICMP packet while trying to create the associated TCP connection. The Error Payload contains the packet. Malformed TLV (0x2): This code indicates that a received TLV was not successfully parsed or formed. A peer receiving a Connect TLV with an invalid IP address MUST send an Error TLV with this error code. Network Failure (0x3): This codes indicates that a network failure prevented the establishment of the connection. After sending one or more Error TLVs, the sender MUST send an End TLV and terminate the stream, i.e. set the FIN bit after the End TLV.

The End TLV does not contain a value. Its existence signals the end of the series of TLVs. The next byte in the QUIC stream after this TLV is the start of the tunneled bytestream.

This section illustrates the different messages described previously and how they are used in a QUIC tunnel connection. For QUIC STREAM frames, we use the following syntax: STREAM[ID, Stream Data [, FIN]]. The first element is the Stream ID, the second is the Stream Data contained in the frame and the last one is optional and indicates that the FIN bit is set.

|| SYN | | ||==============================>| | || SYN+ACK | |STREAM[0,"TCP Connect OK, End"]||<==============================| |<------------------------------|| | | STREAM[0, "bytestream data"] || | |------------------------------>|| bytestream data, ACK | | ||==============================>| | || bytestream data, ACK | | STREAM[0, "bytestream data"] ||<==============================| |<------------------------------|| FIN | | STREAM[0, "", FIN] ||<==============================| |<------------------------------|| ACK | | STREAM[0, "", FIN] ||==============================>| |------------------------------>|| FIN | | ||==============================>| | || ACK | | ||<==============================| Legend: --- Multipath QUIC connection === TCP connection ]]>

On , the Client is initiating a TCP connection in stream mode to the Final Destination. A request and a response are exchanged, then the connection is torn down gracefully. A remote-initiated connection accepted by the concentrator on behalf of the client would have the order and the direction of all messages reversed.

The Concentrator has access to all the packets it processes. It MUST be protected as a core IP router, e.g. as specified in .

Ingress filtering policies MUST be enforced at the network boundaries, i.e. as specified in .

There is a risk of an amplification attack when the Concentrator sends a TCP SYN in response of a TCP Connect TLV. When a TCP SYN is larger than the client request, the Concentrator amplifies the client traffic. To mitigate such attacks, the Concentrator SHOULD rate limit the number of pending TCP Connect from a given client.

This document creates a new registration for the identification of the QUIC tunnel protocol in the "Application Layer Protocol Negotiation (ALPN) Protocol IDs" registry established in . The "qt" string identifies the QUIC tunnel protocol. Protocol: QUIC tunnel Identification Sequence: 0x71 0x74 ("qt") Specification: This document

IANA is requested to create a new "QUIC tunnel stream Parameters" registry. The following subsections detail new registries within "QUIC tunnel stream Parameters" registry.

IANA is request to create the "QUIC tunnel stream TLVs Types" sub-registry. New values are assigned via IETF Review (Section 4.8 of ). The initial values to be assigned at the creation of the registry are as follows:

IANA is request to create the "QUIC tunnel stream TLVs Error Types" sub-registry. New values are assigned via IETF Review (Section 4.8 of ). The initial values to be assigned at the creation of the registry are as follows:

In many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. This specification defines the addressing architecture of the IP Version 6 (IPv6) protocol. The document includes the IPv6 addressing model, text representations of IPv6 addresses, definition of IPv6 unicast addresses, anycast addresses, and multicast addresses, and an IPv6 node's required addresses.This document obsoletes RFC 3513, "IP Version 6 Addressing Architecture". [STANDARDS-TRACK] This memo reiterates the assignment of an IPv4 address block (192.0.0.0/24) to IANA. It also instructs IANA to restructure its IPv4 and IPv6 Special-Purpose Address Registries. Upon restructuring, the aforementioned registries will record all special-purpose address blocks, maintaining a common set of information regarding each address block. RFC 2119 specifies common key words that may be used in protocol specifications. This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the defined special meanings. This document defines the Static Context Header Compression (SCHC) framework, which provides both header compression and fragmentation functionalities. SCHC has been designed for Low Power Wide Area Networks (LPWAN). SCHC compression is based on a common static context stored both in the LPWAN device and in the network infrastructure side. This document defines a header compression mechanism and its application to compress IPv6/UDP headers. This document also specifies a fragmentation and reassembly mechanism that is used to support the IPv6 MTU requirement over the LPWAN technologies. Fragmentation is needed for IPv6 datagrams that, after SCHC compression or when such compression was not possible, still exceed the layer-2 maximum payload size. The SCHC header compression and fragmentation mechanisms are independent of the specific LPWAN technology over which they are used. This document defines generic functionalities and offers flexibility with regard to parameter settings and mechanism choices. This document standardizes the exchange over the LPWAN between two SCHC entities. Settings and choices specific to a technology or a product are expected to be grouped into profiles, which are specified in other documents. Data models for the context and profiles are out of scope. This document defines an extension to the QUIC transport protocol to add support for sending and receiving unreliable datagrams over a QUIC connection. This document specifies extensions to the QUIC protocol to enable, other than connection migration, simultaneous usage of multiple paths for a single connection. Those extensions remain compliant with the current single-path QUIC design. They allow devices to benefit from multiple network paths while preserving the privacy features of QUIC. This document specifies an application proxy, called Transport Converter, to assist the deployment of TCP extensions such as Multipath TCP. This proxy is designed to avoid inducing extra delay when involved in a network-assisted connection (that is, 0-RTT). This specification assumes an explicit model, where the proxy is explicitly configured on hosts. -- Editorial Note (To be removed by RFC Editor) Please update these statements with the RFC number to be assigned to this document: [This-RFC] Please update TBA statements with the port number to be assigned to the 0-RTT TCP Convert Protocol. This document defines the core of the QUIC transport protocol. Accompanying documents describe QUIC's loss detection and congestion control and the use of TLS for key negotiation. Note to Readers Discussion of this draft takes place on the QUIC working group mailing list (quic@ietf.org), which is archived at <https://mailarchive.ietf.org/arch/search/?email_list=quic>. Working Group information can be found at <https://github.com/ quicwg>; source code and issues list for this draft can be found at <https://github.com/quicwg/base-drafts/labels/-transport>. This memo defines and discusses requirements for devices that perform the network layer forwarding function of the Internet protocol suite. [STANDARDS-TRACK] This paper discusses a simple, effective, and straightforward method for using ingress traffic filtering to prohibit DoS (Denial of Service) attacks which use forged IP addresses to be propagated from 'behind' an Internet Service Provider's (ISP) aggregation point. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. This document specifies a highly robust and efficient header compression scheme for RTP/UDP/IP (Real-Time Transport Protocol, User Datagram Protocol, Internet Protocol), UDP/IP, and ESP/IP (Encapsulating Security Payload) headers. [STANDARDS-TRACK] The original RObust Header Compression (ROHC) RFC (RFC 3095) defines a framework for header compression, along with compression protocols (profiles) for IP/UDP/RTP, IP/ESP (Encapsulating Security Payload), IP/UDP, and also a profile for uncompressed packet streams. However, no profile was defined for compression of IP only, which has been identified as a missing piece in RFC 3095. This document defines a ROHC compression profile for IP, similar to the IP/UDP profile defined by RFC 3095, but simplified to exclude UDP, and enhanced to compress IP header chains of arbitrary length. [STANDARDS-TRACK] This document defines Robust Header Compression (ROHC) profiles for compression of Real-Time Transport Protocol, User Datagram Protocol-Lite, and Internet Protocol (RTP/UDP-Lite/IP) packets and UDP-Lite/IP. These profiles are defined based on their differences with the profiles for UDP as specified in RFC 3095. [STANDARDS-TRACK] RFC 3095 defines the RObust Header Compression (ROHC) framework and profiles for IP (Internet Protocol), UDP (User Datagram Protocol), RTP (Real-Time Transport Protocol), and ESP (Encapsulating Security Payload). Some parts of the specification are unclear or contain errors that may lead to misinterpretations that may impair interoperability between different implementations. This document provides corrections, additions, and clarifications to RFC 3095; this document thus updates RFC 3095. In addition, other clarifications related to RFC 3241 (ROHC over PPP), RFC 3843 (ROHC IP profile) and RFC 4109 (ROHC UDP-Lite profiles) are also provided. [STANDARDS-TRACK] This document specifies a RObust Header Compression (ROHC) profile for compression of TCP/IP packets. The profile, called ROHC-TCP, provides efficient and robust compression of TCP headers, including frequently used TCP options such as selective acknowledgments (SACKs) and Timestamps.ROHC-TCP works well when used over links with significant error rates and long round-trip times. For many bandwidth-limited links where header compression is essential, such characteristics are common.This specification obsoletes RFC 4996. It fixes a technical issue with the SACK compression and clarifies other compression methods used. [STANDARDS-TRACK] The Port Control Protocol allows an IPv6 or IPv4 host to control how incoming IPv6 or IPv4 packets are translated and forwarded by a Network Address Translator (NAT) or simple firewall, and also allows a host to optimize its outgoing NAT keepalive messages. This document describes a Transport Layer Security (TLS) extension for application-layer protocol negotiation within the TLS handshake. For instances in which multiple application protocols are supported on the same TCP or UDP port, this extension allows the application layer to negotiate which protocol will be used within the TLS connection. Many protocols make use of points of extensibility that use constants to identify various protocol parameters. To ensure that the values in these fields do not have conflicting uses and to promote interoperability, their allocations are often coordinated by a central record keeper. For IETF protocols, that role is filled by the Internet Assigned Numbers Authority (IANA).To make assignments in a given registry prudently, guidance describing the conditions under which new values should be assigned, as well as when and how modifications to existing values can be made, is needed. This document defines a framework for the documentation of these guidelines by specification authors, in order to assure that the provided guidance for the IANA Considerations is clear and addresses the various issues that are likely in the operation of a registry.This is the third edition of this document; it obsoletes RFC 5226.

Thanks to Quentin De Coninck and Francois Michel for their comments and the proofreading of the first version of this document. Thanks to Gregory Vander Schueren for his comments on the first version of this document.