Tunneling Internet protocols inside QUICUCLouvainmaxime.piraux@uclouvain.beUCLouvainolivier.bonaventure@uclouvain.beApple Inc.adi@apple.com
Internet Area
Internet Area Working GroupInternet-DraftThis document specifies methods for tunneling packets of Internet protocols
inside a QUIC connection.IntroductionMobile 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 or IPSec. These VPN protocols provide the
encryption and authentication functions to protect those mobile clients
from malicious behaviors in untrusted networks.However, some networks have deployed filters that block these VPN
protocols. When faced with such filters, users can either switch off
their connection or find alternatives, e.g. by using TLS to access
some services over TCP port 443. The planned deployment of QUIC
opens a new
opportunity for such users. Since QUIC will be used to access web
sites, it should be less affected by filters than VPN solutions such
as IPSec or DTLS. Furthermore, the flexibility of QUIC makes it
possible to easily extend the protocol to support VPN services.This document explores how QUIC could be used to
enable devices to communicate securely in untrusted
networks. 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
QUIC migration mechanism enables handovers between several network interfaces.This document is organized as follows.
describes the reference environment. Then, we propose
a first mode of operation, explained in , that use the
recently proposed datagram extension
() for QUIC to transport plain packets over a
QUIC connection. specifies how a connection
is established in this document proposal. details the format
of the messages introduced by this document.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.Reference environmentThe reference scenario is a client that uses a QUIC tunnel to send all
its packets to a concentrator. The concentrator processes the
packets received from the client over the QUIC connection and
forwards them to their final destination.
It also receives the packets destined to the client and tunnels them through
the QUIC connection.In a nutshell, the solution proposed in this document works as
follows. The client opens a QUIC connection to a concentrator. The
concentrator authenticates the client through
means that are outside the scope of this document such as client
certificates, usernames/passwords, OAuth, ... If the authentication
succeeds, the client can send packets via the concentrator by tunneling
them through the concentrator.The concentrator captures the packets destined to the client and tunnels them
over the QUIC connection. This solution is intended to provide a similar service
as the one provided by IPSec tunnels or DTLS. This document leaves address
assignment mechanisms out of scope, deployments can rely on out-of-band
configurations for that purpose.The tunnel modeThe "tunnel mode" of operation leverages the recently proposed
QUIC datagram extension . In a nutshell, to send a
packet to a remote host, the client simply encapsulates the entire packet inside
a QUIC DATAGRAM frame sent over the QUIC connection established with the
concentrator.The frame transmission is subject to congestion
control, but the frame that contains the packet is not retransmitted in case
of loss as specified in .This mode adds a minimal byte overhead for packet encapsulation in QUIC. It
does not define ways of indicating the protocol of the conveyed packets, which
can be useful in deployments for which out-of-band signaling may be used.Connection establishmentDuring QUIC connection establishment, the "tunnel mode" of operation
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.After the QUIC connection is established, the client can start using the
"tunnel 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 sending
packets containing inbound connections in QUIC DATAGRAM frame.Reporting access networks availabilityWhen the access network is unstable or its performance is degrading, for instance
due to signal loss, being able to report its availability to the concentrator
can help reduce the amount of packets sent over unstable or unavailable paths.
It can also resume quickly the sending of packets over a previously unavailable
access network.To do so, we define in a message called Access Report TLV.
The message can be sent by the client to the concentrator. It identifies the
type of access network reported and its associated status. This message is sent
over the QUIC connection in a separate unidirectional stream.Messages formatIn the following sections, we specify the format of each message introduced in
this document. The messages 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 in bytes 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.QUIC tunnel control TLVsThis document specifies the following QUIC tunnel control TLVs:The Access Report TLV is sent by the client to periodically report on access
networks availability. Each Access Report TLV MUST be sent on a separate
unidirectional stream. The stream FIN bit MUST be set following the end of the
TLV.Access Report TLVThe Access Report TLV contains the following:
AI (Access ID) - a four-bit-long field that identifies the access network,
e.g., 3GPP (Radio Access Technologies specified by 3GPP) or Non-3GPP
(accesses that are not specified by 3GPP) . The value is one
of those listed below (all other values are invalid and the TLV that
contains it MUST be discarded):
R (Reserved) - a four-bit-long field that MUST be zeroed on transmission and
ignored on receipt.
Signal - a one-octet-long field that identifies the report signal, e.g.,
available or unavailable. The value is supplied to the QUIC tunnel through
some mechanism that is outside the scope of this document. The value is one
of those listed in .
The client that includes the Access Report TLV sets the value of the Access ID
field according to the type of access network it reports on. Also, the client
sets the value of the Signal field to reflect the operational state of the access
network. The mechanism to determine the state of the access network is outside
the scope of this specification.The client MUST be able to cancel the sending of an Access Report TLV that is
pending delivery, i.e. by resetting its corresponding unidirectional stream.
This can be used when the information contained in the TLV is no longer
relevant, e.g. the access network availability has changed. The time of
canceling is based on local policies and network environment.Reporting the unavailability of an access network to the concentrator can serve as
an indication to stop sending packets over this network while
maintaining the QUIC tunnel connection. Upon reporting of the availability of
this network, the concentrator can quickly resume sending packets over this
network.Security ConsiderationsPrivacyThe Concentrator has access to all the packets it processes. It MUST be
protected as a core IP router, e.g. as specified in .Ingress FilteringIngress filtering policies MUST be enforced at the network boundaries, i.e. as
specified in .IANA ConsiderationsRegistration of QUIC tunnel Identification StringThis document creates one 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 datagram mode.
Protocol:
QUIC Tunnel
Identification Sequence:
0x71 0x74 ("qt")
Specification:
This document
QUIC tunnel control TLVsIANA is requested to create a new "QUIC tunnel control Parameters" registry.The following subsections detail new registries within "QUIC tunnel control
Parameters" registry.QUIC tunnel control TLVs TypesIANA is request to create the "QUIC tunnel control 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 Access Report Signal CodesThis document establishes a registry for QUIC tunnel Access Report Signal codes.
The "QUIC tunnel Access Report Signal Code" registry manages a 62-bit space.
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: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.Technical Specification Group Services and System Aspects; System Architecture for the 5G System; Stage 2 (Release 16)3GPP (3rd Generation Partnership Project)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 ReferencesAn Unreliable Datagram Extension to QUICThis document defines an extension to the QUIC transport protocol to add support for sending and receiving unreliable datagrams over a QUIC connection. Discussion of this work is encouraged to happen on the QUIC IETF mailing list quic@ietf.org [1] or on the GitHub repository which contains the draft: https://github.com/tfpauly/draft-pauly-quic- datagram [2].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.Using TLS to Secure QUICThis document describes how Transport Layer Security (TLS) is used to secure QUIC. 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/-tls.Requirements for IP Version 4 RoutersThis memo defines and discusses requirements for devices that perform the network layer forwarding function of the Internet protocol suite. [STANDARDS-TRACK]Network Ingress Filtering: Defeating Denial of Service Attacks which employ IP Source Address SpoofingThis 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.Port Control Protocol (PCP)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.Transport Layer Security (TLS) Application-Layer Protocol Negotiation ExtensionThis 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.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-03
Make the lightweight mode the default "tunnel mode"
Rename the datagram mode as tunnel session mode in
draft-piraux-intarea-quic-tunnel-session
Since draft-piraux-quic-tunnel-02
Add the lightweight mode
Since draft-piraux-quic-tunnel-01
Add the Access Report TLV for reporting access networks availability
Add a section with examples of use of the Packet Tag
Since draft-piraux-quic-tunnel-00
Separate the document in two and put the stream mode in another document
Remove TCP Extended TLV
Add a mechanism for joining QUIC connections in a QUIC tunneling session
Add a format for encoding any network-layer protocol packets and Ethernet
frames in QUIC DATAGRAM frames
AcknowledgmentsThanks to Quentin De Coninck and Francois Michel for their comments and
the proofreading of the first version of draft-piraux-quic-tunnel.
Thanks to Gregory Vander Schueren for his comments on the first version of
draft-piraux-quic-tunnel.
Thanks to Florin Baboescu for his comments on the first version of this document.