|Internet-Draft||QUIC Tunnel||November 2020|
|Piraux, et al.||Expires 6 May 2021||[Page]|
- Internet Area Working Group
- Intended Status:
Tunneling Internet protocols inside QUIC
This document specifies methods for tunneling packets of Internet protocols inside a QUIC connection.¶
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 (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.¶
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.¶
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.¶
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.¶
7.1. QUIC tunnel control TLVs
This 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.¶
7.1.1. Access Report TLV
The 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) [TS23501]. The value is one of those listed below (all other values are invalid and the TLV that contains it MUST be discarded):¶
+-----------+-----------------------+ | Access ID | Description | +-----------+-----------------------+ | 1 | 3GPP Network | | 2 | Non-3GPP Network | +-----------+-----------------------+¶
- 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 Section 9.3.¶
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.¶
8. Security Considerations
The Concentrator has access to all the packets it processes. It MUST be protected as a core IP router, e.g. as specified in [RFC1812].¶
8.2. Ingress Filtering
Ingress filtering policies MUST be enforced at the network boundaries, i.e. as specified in [RFC2827].¶
9. IANA Considerations
9.1. Registration of QUIC tunnel Identification String
This 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 [RFC7301].¶
The "qt" string identifies the QUIC tunnel protocol datagram mode.¶
9.2. QUIC tunnel control TLVs
IANA is requested to create a new "QUIC tunnel control Parameters" registry.¶
The following subsections detail new registries within "QUIC tunnel control Parameters" registry.¶
9.2.1. QUIC tunnel control TLVs Types
IANA is request to create the "QUIC tunnel control TLVs Types" sub-registry. New values are assigned via IETF Review (Section 4.8 of [RFC8126]).¶
The initial values to be assigned at the creation of the registry are as follows:¶
+------+-----------------------+------------+ | Code | Name | Reference | +------+-----------------------+------------+ | 0 | Access Report TLV | [This-Doc] | +------+-----------------------+------------+¶
9.3. QUIC tunnel Access Report Signal Codes
This 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 [RFC8126]).¶
The initial values to be assigned at the creation of the registry are as follows:¶
+------+-----------------------+------------+ | Code | Name | Reference | +------+-----------------------+------------+ | 1 | Access Available | [This-Doc] | | 2 | Access Unavailable | [This-Doc] | +------+-----------------------+------------+¶
10.1. Normative References
- Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, , <https://www.rfc-editor.org/info/rfc2119>.
- 3GPP (3rd Generation Partnership Project), "Technical Specification Group Services and System Aspects; System Architecture for the 5G System; Stage 2 (Release 16)", 3GPP TS23501, .
- Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, , <https://www.rfc-editor.org/info/rfc8174>.
10.2. Informative References
- Pauly, T., Kinnear, E., and D. Schinazi, "An Unreliable Datagram Extension to QUIC", Work in Progress, Internet-Draft, draft-pauly-quic-datagram-05, , <http://www.ietf.org/internet-drafts/draft-pauly-quic-datagram-05.txt>.
- Iyengar, J. and M. Thomson, "QUIC: A UDP-Based Multiplexed and Secure Transport", Work in Progress, Internet-Draft, draft-ietf-quic-transport-32, , <http://www.ietf.org/internet-drafts/draft-ietf-quic-transport-32.txt>.
- Thomson, M. and S. Turner, "Using TLS to Secure QUIC", Work in Progress, Internet-Draft, draft-ietf-quic-tls-32, , <http://www.ietf.org/internet-drafts/draft-ietf-quic-tls-32.txt>.
- Baker, F., Ed., "Requirements for IP Version 4 Routers", RFC 1812, DOI 10.17487/RFC1812, , <https://www.rfc-editor.org/info/rfc1812>.
- Ferguson, P. and D. Senie, "Network Ingress Filtering: Defeating Denial of Service Attacks which employ IP Source Address Spoofing", BCP 38, RFC 2827, DOI 10.17487/RFC2827, , <https://www.rfc-editor.org/info/rfc2827>.
- Wing, D., Ed., Cheshire, S., Boucadair, M., Penno, R., and P. Selkirk, "Port Control Protocol (PCP)", RFC 6887, DOI 10.17487/RFC6887, , <https://www.rfc-editor.org/info/rfc6887>.
- Friedl, S., Popov, A., Langley, A., and E. Stephan, "Transport Layer Security (TLS) Application-Layer Protocol Negotiation Extension", RFC 7301, DOI 10.17487/RFC7301, , <https://www.rfc-editor.org/info/rfc7301>.
- Cotton, M., Leiba, B., and T. Narten, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 8126, DOI 10.17487/RFC8126, , <https://www.rfc-editor.org/info/rfc8126>.
Appendix A. Change Log
A.1. Since draft-piraux-quic-tunnel-03
A.2. Since draft-piraux-quic-tunnel-02
- Add the lightweight mode¶
A.3. Since draft-piraux-quic-tunnel-01
A.4. Since draft-piraux-quic-tunnel-00
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.¶