[Docs] [txt|pdf|xml|html] [Tracker] [Email] [Diff1] [Diff2] [Nits]

Versions: (draft-piraux-quic-tunnel) 00

Internet Area Working Group                                    M. Piraux
Internet-Draft                                            O. Bonaventure
Intended status: Experimental                                  UCLouvain
Expires: 6 May 2021                                          A. Masputra
                                                              Apple Inc.
                                                         2 November 2020


                Tunneling Internet protocols inside QUIC
                  draft-piraux-intarea-quic-tunnel-00

Abstract

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





Piraux, et al.             Expires 6 May 2021                   [Page 1]


Internet-Draft                 QUIC Tunnel                 November 2020


Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
   2.  Conventions and Definitions . . . . . . . . . . . . . . . . .   3
   3.  Reference environment . . . . . . . . . . . . . . . . . . . .   3
   4.  The tunnel mode . . . . . . . . . . . . . . . . . . . . . . .   4
   5.  Connection establishment  . . . . . . . . . . . . . . . . . .   4
   6.  Reporting access networks availability  . . . . . . . . . . .   5
   7.  Messages format . . . . . . . . . . . . . . . . . . . . . . .   5
     7.1.  QUIC tunnel control TLVs  . . . . . . . . . . . . . . . .   5
       7.1.1.  Access Report TLV . . . . . . . . . . . . . . . . . .   6
   8.  Security Considerations . . . . . . . . . . . . . . . . . . .   7
     8.1.  Privacy . . . . . . . . . . . . . . . . . . . . . . . . .   7
     8.2.  Ingress Filtering . . . . . . . . . . . . . . . . . . . .   7
   9.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   7
     9.1.  Registration of QUIC tunnel Identification String . . . .   7
     9.2.  QUIC tunnel control TLVs  . . . . . . . . . . . . . . . .   7
       9.2.1.  QUIC tunnel control TLVs Types  . . . . . . . . . . .   8
     9.3.  QUIC tunnel Access Report Signal Codes  . . . . . . . . .   8
   10. References  . . . . . . . . . . . . . . . . . . . . . . . . .   8
     10.1.  Normative References . . . . . . . . . . . . . . . . . .   8
     10.2.  Informative References . . . . . . . . . . . . . . . . .   9
   Appendix A.  Change Log . . . . . . . . . . . . . . . . . . . . .  10
     A.1.  Since draft-piraux-quic-tunnel-03 . . . . . . . . . . . .  10
     A.2.  Since draft-piraux-quic-tunnel-02 . . . . . . . . . . . .  10
     A.3.  Since draft-piraux-quic-tunnel-01 . . . . . . . . . . . .  10
     A.4.  Since draft-piraux-quic-tunnel-00 . . . . . . . . . . . .  10
   Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . .  10
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  10

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



Piraux, et al.             Expires 6 May 2021                   [Page 2]


Internet-Draft                 QUIC Tunnel                 November 2020


   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




Piraux, et al.             Expires 6 May 2021                   [Page 3]


Internet-Draft                 QUIC Tunnel                 November 2020


              Figure 1: A client attached to a concentrator

   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.



Piraux, et al.             Expires 6 May 2021                   [Page 4]


Internet-Draft                 QUIC Tunnel                 November 2020


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 (*)]        ...
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                      Figure 2: QUIC tunnel TLV Format

   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:

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

                     Figure 3: QUIC tunnel control TLVs




Piraux, et al.             Expires 6 May 2021                   [Page 5]


Internet-Draft                 QUIC Tunnel                 November 2020


   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

                        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)  |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                        Figure 4: 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



Piraux, et al.             Expires 6 May 2021                   [Page 6]


Internet-Draft                 QUIC Tunnel                 November 2020


   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

8.1.  Privacy

   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.

   Protocol:  QUIC Tunnel

   Identification Sequence:  0x71 0x74 ("qt")

   Specification:  This document

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.






Piraux, et al.             Expires 6 May 2021                   [Page 7]


Internet-Draft                 QUIC Tunnel                 November 2020


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

10.1.  Normative References

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119,
              DOI 10.17487/RFC2119, March 1997,
              <https://www.rfc-editor.org/info/rfc2119>.

   [TS23501]  3GPP (3rd Generation Partnership Project), "Technical
              Specification Group Services and System Aspects; System
              Architecture for the 5G System; Stage 2 (Release 16)",
              3GPP TS23501, 2019.






Piraux, et al.             Expires 6 May 2021                   [Page 8]


Internet-Draft                 QUIC Tunnel                 November 2020


   [RFC8174]  Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
              2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
              May 2017, <https://www.rfc-editor.org/info/rfc8174>.

10.2.  Informative References

   [I-D.pauly-quic-datagram]
              Pauly, T., Kinnear, E., and D. Schinazi, "An Unreliable
              Datagram Extension to QUIC", Work in Progress, Internet-
              Draft, draft-pauly-quic-datagram-05, 4 November 2019,
              <http://www.ietf.org/internet-drafts/draft-pauly-quic-
              datagram-05.txt>.

   [I-D.ietf-quic-transport]
              Iyengar, J. and M. Thomson, "QUIC: A UDP-Based Multiplexed
              and Secure Transport", Work in Progress, Internet-Draft,
              draft-ietf-quic-transport-32, 20 October 2020,
              <http://www.ietf.org/internet-drafts/draft-ietf-quic-
              transport-32.txt>.

   [I-D.ietf-quic-tls]
              Thomson, M. and S. Turner, "Using TLS to Secure QUIC",
              Work in Progress, Internet-Draft, draft-ietf-quic-tls-32,
              20 October 2020, <http://www.ietf.org/internet-drafts/
              draft-ietf-quic-tls-32.txt>.

   [RFC1812]  Baker, F., Ed., "Requirements for IP Version 4 Routers",
              RFC 1812, DOI 10.17487/RFC1812, June 1995,
              <https://www.rfc-editor.org/info/rfc1812>.

   [RFC2827]  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,
              May 2000, <https://www.rfc-editor.org/info/rfc2827>.

   [RFC6887]  Wing, D., Ed., Cheshire, S., Boucadair, M., Penno, R., and
              P. Selkirk, "Port Control Protocol (PCP)", RFC 6887,
              DOI 10.17487/RFC6887, April 2013,
              <https://www.rfc-editor.org/info/rfc6887>.

   [RFC7301]  Friedl, S., Popov, A., Langley, A., and E. Stephan,
              "Transport Layer Security (TLS) Application-Layer Protocol
              Negotiation Extension", RFC 7301, DOI 10.17487/RFC7301,
              July 2014, <https://www.rfc-editor.org/info/rfc7301>.







Piraux, et al.             Expires 6 May 2021                   [Page 9]


Internet-Draft                 QUIC Tunnel                 November 2020


   [RFC8126]  Cotton, M., Leiba, B., and T. Narten, "Guidelines for
              Writing an IANA Considerations Section in RFCs", BCP 26,
              RFC 8126, DOI 10.17487/RFC8126, June 2017,
              <https://www.rfc-editor.org/info/rfc8126>.

Appendix A.  Change Log

A.1.  Since 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

A.2.  Since draft-piraux-quic-tunnel-02

   *  Add the lightweight mode

A.3.  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

A.4.  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

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




Piraux, et al.             Expires 6 May 2021                  [Page 10]


Internet-Draft                 QUIC Tunnel                 November 2020


   Maxime Piraux
   UCLouvain

   Email: maxime.piraux@uclouvain.be


   Olivier Bonaventure
   UCLouvain

   Email: olivier.bonaventure@uclouvain.be


   Adi Masputra
   Apple Inc.

   Email: adi@apple.com



































Piraux, et al.             Expires 6 May 2021                  [Page 11]


Html markup produced by rfcmarkup 1.129d, available from https://tools.ietf.org/tools/rfcmarkup/