Tunneling TCP inside QUICUCLouvainmaxime.piraux@uclouvain.beUCLouvainolivier.bonaventure@uclouvain.be
Internet Area
Internet Area Working GroupInternet-DraftThis document specifies a new operating mode for a QUIC tunnel to efficiently
convey TCP bytestreams.IntroductionThe recently proposed QUIC tunnel protocol
supports the exchange of IP packets and Ethernet frames over a QUIC connection.
Its two existing operating modes transports plain packets
inside QUIC frames. Their main advantage is that they support any network-layer
protocol. 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 to the IP/UDP/QUIC headers of the QUIC
connection. For TCP connections for instance, the per-packet overhead can be
large.In this document, we propose a new operating mode for the QUIC tunnel protocol,
called the stream mode. It takes advantage of the QUIC streams to efficiently
transport TCP bytestreams over a QUIC connection.
describes this new mode. specifies the
format of the messages introduced by this document. contains
example flows.Conventions and DefinitionsThe 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.The stream modeSince QUIC supports 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 QUIC connection. For this, we base our approach on the 0-RTT
Convert 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.A similar approach is used in the 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 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 actions
and events of the associated QUIC stream, so that a state transition on one
is translated to the other.When sending STOP_SENDING or RESET_STREAM frames in response to the receipt of a
TCP RST, QUIC tunnel peers MUST use the application protocol error code 0x00
(TCP_CONNECTION_RESET).The QUIC stream-level flow control can be tuned to match the receive
window size of the corresponding TCP connection, so that no excessive
data needs to be buffered.Connection establishmentThe support of the stream mode is negotiated during the connection
establishment by including the quic_tunnel_stream_mode transport parameter
(value TBD). The parameter value has no meaning and SHOULD be null.During the connection establishment, the concentrator can control the number of
TCP bytestreams that can be opened initially by setting the
initial_max_streams_bidi QUIC transport parameter as defined in
.Messages formatIn the following sections, we specify the format of each message introduced in
this document. They are encoded using the TLV format described in
.QUIC tunnel stream TLVsWhen using the stream mode, 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
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 request the establishment a TCP connection
by the concentrator towards the final destination. The TCP Connect OK TLV
confirms the establishment of this TCP connection. The Error TLV is
used to indicate any error that occurred during the establishment of a TCP
connection. 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.Future versions of this document may define new TLVs. The End TLV allows a QUIC
tunnel peer to send several TLVs before the start of the bytestream. illustrates an example of use of QUIC tunnel streams TLVs.
In this example, the client opens Stream 0 and sends two TLVs. The
first one requests the concentrator to establish a new TCP connection. The
second TLV marks the end of the series of TLV and the start of the TCP
bytestream.TCP Connect TLVThe 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 on non-self initiated
streams.TCP Connect OK TLVThe TCP Connect OK TLV does not contain a value. Its presence confirms
the successful establishment of the requested TCP connection
to the final destination.
A QUIC peer MUST NOT send a TCP Connect OK TLV on self-initiated streams.Error TLVThe Error TLV indicates out-of-band errors that occurred during the
establishment of the TCP 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 TCP 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.End TLVThe 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 part of
of the tunneled bytestream.Example flowsThis 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.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.Security ConsiderationsDenial of ServiceThere 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.IANA ConsiderationsQUIC tunnel stream TLVsIANA is requested to create a new "QUIC tunnel stream Parameters" registry.The following subsections detail new registries within "QUIC tunnel stream
Parameters" registry.QUIC tunnel stream TLVs TypesIANA 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:QUIC tunnel streams TLVs Error TypesIANA 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:QUIC Transport Parameter RegistryThis document defines a new transport parameter for the negotiation of
the stream mode. The following entry in should be added to
the "QUIC Transport Parameters" registry under the "QUIC Protocol" heading.
Addition to QUIC Transport Parameters Entries
Value
Parameter Name
Specification
TBD
quic_tunnel_stream_mode
ReferencesNormative ReferencesKey words for use in RFCs to Indicate Requirement LevelsIn 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.IP Version 6 Addressing ArchitectureThis 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]Special-Purpose IP Address RegistriesThis 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.Tunneling Internet protocols inside QUICThis document specifies methods for tunneling packets of Internet protocols inside a QUIC connection.Ambiguity of Uppercase vs Lowercase in RFC 2119 Key WordsRFC 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.Informative References0-RTT TCP Convert ProtocolThis document specifies an application proxy, called Transport Converter, to assist the deployment of TCP extensions such as Multipath TCP. A Transport Converter may provide conversion service for one or more TCP extensions. The conversion service is provided by means of the TCP Convert Protocol (Convert). This protocol provides 0-RTT (Zero Round-Trip Time) conversion service since no extra delay is induced by the protocol compared to connections that are not proxied. Also, the Convert Protocol does not require any encapsulation (no tunnels, whatsoever). This specification assumes an explicit model, where the Transport Converter is explicitly configured on hosts. As a sample applicability use case, this document specifies how the Convert Protocol applies for Multipath TCP.QUIC: A UDP-Based Multiplexed and Secure TransportThis 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 (mailto: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.Tunneling Internet protocols inside QUICThis document specifies methods for tunneling Ethernet frames and Internet protocols such as TCP, UDP, IP and QUIC inside a QUIC connection.Guidelines for Writing an IANA Considerations Section in RFCsMany 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.Change LogSince draft-piraux-quic-tunnel-tcp-01
Nits
Since draft-piraux-quic-tunnel-tcp-00
Add the quic_tunnel_stream_mode transport parameter for negotiation
AcknowledgmentsThis documents draws heavily on the initial version of .
Their contributors are thanked again here. This work was partially supported by the MQUIC project.