Tunneling Internet protocols inside QUIC

Status of This Memo

This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.¶

Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at https://datatracker.ietf.org/drafts/current/.¶

Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."¶

This Internet-Draft will expire on 6 May 2021.¶

Copyright Notice

Copyright (c) 2020 IETF Trust and the persons identified as the document authors. All rights reserved.¶

This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.¶

Table of Contents

1. Introduction

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 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 [I-D.ietf-quic-transport] [I-D.ietf-quic-tls] 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. Section 3 describes the reference environment. Then, we propose a first mode of operation, explained in Section 4, that use the recently proposed datagram extension ([I-D.pauly-quic-datagram]) for QUIC to transport plain packets over a QUIC connection. Section 5 specifies how a connection is established in this document proposal. Section 7 details the format of the messages introduced by this document.¶

2. Conventions and Definitions

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 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.¶

3. Reference environment

The 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.¶

                                                       +-------------+
+--------+              +--------------+               | Final       |
| Client |              | Concentrator |<===\ ... \===>| destination |
+--------+              +--------------+               | server      |
       ^    +---------+    ^                           +-------------+
       |    | Access  |    |            Legend:
       .----| network |----.              --- QUIC connection
            +---------+                   === Tunneled flow

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.¶

4. The tunnel mode

The "tunnel mode" of operation leverages the recently proposed QUIC datagram extension [I-D.pauly-quic-datagram]. 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 [I-D.pauly-quic-datagram].¶

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.¶

5. Connection establishment

During 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 [RFC6887] 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.¶

6. Reporting access networks availability

When 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 Section 7 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.¶

7. Messages format

In 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 Figure 2. All TLV fields are encoded in network-byte order.¶

                     1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|    Type (8)   |   Length (8)  |          [Value (*)]        ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

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.¶

+------+----------+--------+------+-------------------+
| Type |     Size | Sender | Mode | Name              |
+------+----------+--------+------+-------------------+
| 0x00 |  4 bytes | Client |  all | Access Report TLV |
+------+----------+--------+------+-------------------+

                     1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|  Type = 0x00  | Length = 0x02 | AI (4)| R (4) |   Signal (8)  |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

+-----------+-----------------------+
| Access ID | Description           |
+-----------+-----------------------+
|      1    | 3GPP Network          |
|      2    | Non-3GPP Network      |
+-----------+-----------------------+

8. Security Considerations

9. IANA Considerations

+------+-----------------------+------------+
| Code | Name                  | Reference  |
+------+-----------------------+------------+
|    0 | Access Report TLV     | [This-Doc] |
+------+-----------------------+------------+

+------+-----------------------+------------+
| Code | Name                  | Reference  |
+------+-----------------------+------------+
|    1 | Access Available      | [This-Doc] |
|    2 | Access Unavailable    | [This-Doc] |
+------+-----------------------+------------+

Appendix A. Change Log

Acknowledgments

Thanks 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.¶

Authors' Addresses