idnits 2.17.1 draft-piraux-intarea-quic-tunnel-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (2 November 2020) is 1270 days in the past. Is this intentional? Checking references for intended status: Experimental ---------------------------------------------------------------------------- == Missing Reference: 'This-Doc' is mentioned on line 363, but not defined == Outdated reference: A later version (-34) exists of draft-ietf-quic-transport-32 == Outdated reference: A later version (-34) exists of draft-ietf-quic-tls-32 Summary: 0 errors (**), 0 flaws (~~), 4 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Area Working Group M. Piraux 3 Internet-Draft O. Bonaventure 4 Intended status: Experimental UCLouvain 5 Expires: 6 May 2021 A. Masputra 6 Apple Inc. 7 2 November 2020 9 Tunneling Internet protocols inside QUIC 10 draft-piraux-intarea-quic-tunnel-00 12 Abstract 14 This document specifies methods for tunneling packets of Internet 15 protocols inside a QUIC connection. 17 Status of This Memo 19 This Internet-Draft is submitted in full conformance with the 20 provisions of BCP 78 and BCP 79. 22 Internet-Drafts are working documents of the Internet Engineering 23 Task Force (IETF). Note that other groups may also distribute 24 working documents as Internet-Drafts. The list of current Internet- 25 Drafts is at https://datatracker.ietf.org/drafts/current/. 27 Internet-Drafts are draft documents valid for a maximum of six months 28 and may be updated, replaced, or obsoleted by other documents at any 29 time. It is inappropriate to use Internet-Drafts as reference 30 material or to cite them other than as "work in progress." 32 This Internet-Draft will expire on 6 May 2021. 34 Copyright Notice 36 Copyright (c) 2020 IETF Trust and the persons identified as the 37 document authors. All rights reserved. 39 This document is subject to BCP 78 and the IETF Trust's Legal 40 Provisions Relating to IETF Documents (https://trustee.ietf.org/ 41 license-info) in effect on the date of publication of this document. 42 Please review these documents carefully, as they describe your rights 43 and restrictions with respect to this document. Code Components 44 extracted from this document must include Simplified BSD License text 45 as described in Section 4.e of the Trust Legal Provisions and are 46 provided without warranty as described in the Simplified BSD License. 48 Table of Contents 50 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 51 2. Conventions and Definitions . . . . . . . . . . . . . . . . . 3 52 3. Reference environment . . . . . . . . . . . . . . . . . . . . 3 53 4. The tunnel mode . . . . . . . . . . . . . . . . . . . . . . . 4 54 5. Connection establishment . . . . . . . . . . . . . . . . . . 4 55 6. Reporting access networks availability . . . . . . . . . . . 5 56 7. Messages format . . . . . . . . . . . . . . . . . . . . . . . 5 57 7.1. QUIC tunnel control TLVs . . . . . . . . . . . . . . . . 5 58 7.1.1. Access Report TLV . . . . . . . . . . . . . . . . . . 6 59 8. Security Considerations . . . . . . . . . . . . . . . . . . . 7 60 8.1. Privacy . . . . . . . . . . . . . . . . . . . . . . . . . 7 61 8.2. Ingress Filtering . . . . . . . . . . . . . . . . . . . . 7 62 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 63 9.1. Registration of QUIC tunnel Identification String . . . . 7 64 9.2. QUIC tunnel control TLVs . . . . . . . . . . . . . . . . 7 65 9.2.1. QUIC tunnel control TLVs Types . . . . . . . . . . . 8 66 9.3. QUIC tunnel Access Report Signal Codes . . . . . . . . . 8 67 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 8 68 10.1. Normative References . . . . . . . . . . . . . . . . . . 8 69 10.2. Informative References . . . . . . . . . . . . . . . . . 9 70 Appendix A. Change Log . . . . . . . . . . . . . . . . . . . . . 10 71 A.1. Since draft-piraux-quic-tunnel-03 . . . . . . . . . . . . 10 72 A.2. Since draft-piraux-quic-tunnel-02 . . . . . . . . . . . . 10 73 A.3. Since draft-piraux-quic-tunnel-01 . . . . . . . . . . . . 10 74 A.4. Since draft-piraux-quic-tunnel-00 . . . . . . . . . . . . 10 75 Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 10 76 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 10 78 1. Introduction 80 Mobile devices such as laptops, smartphones or tablets have different 81 requirements than the traditional fixed devices. These mobile 82 devices often change their network attachment. They are often 83 attached to trusted networks, but sometimes they need to be connected 84 to untrusted networks where their communications can be eavesdropped, 85 filtered or modified. In these situations, the classical approach is 86 to rely on VPN protocols such as DTLS or IPSec. These VPN protocols 87 provide the encryption and authentication functions to protect those 88 mobile clients from malicious behaviors in untrusted networks. 90 However, some networks have deployed filters that block these VPN 91 protocols. When faced with such filters, users can either switch off 92 their connection or find alternatives, e.g. by using TLS to access 93 some services over TCP port 443. The planned deployment of QUIC 94 [I-D.ietf-quic-transport] [I-D.ietf-quic-tls] opens a new opportunity 95 for such users. Since QUIC will be used to access web sites, it 96 should be less affected by filters than VPN solutions such as IPSec 97 or DTLS. Furthermore, the flexibility of QUIC makes it possible to 98 easily extend the protocol to support VPN services. 100 This document explores how QUIC could be used to enable devices to 101 communicate securely in untrusted networks. The QUIC protocol opens 102 up a new way to find a clean solution to this problem. First, QUIC 103 includes the same encryption and authentication techniques as 104 deployed VPN protocols. Second, QUIC is intended to be widely used 105 to support web-based services, making it unlikely to be filtered in 106 many networks, in contrast with VPN protocols. Third, the QUIC 107 migration mechanism enables handovers between several network 108 interfaces. 110 This document is organized as follows. Section 3 describes the 111 reference environment. Then, we propose a first mode of operation, 112 explained in Section 4, that use the recently proposed datagram 113 extension ([I-D.pauly-quic-datagram]) for QUIC to transport plain 114 packets over a QUIC connection. Section 5 specifies how a connection 115 is established in this document proposal. Section 7 details the 116 format of the messages introduced by this document. 118 2. Conventions and Definitions 120 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 121 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 122 "OPTIONAL" in this document are to be interpreted as described in BCP 123 14 [RFC2119] [RFC8174] when, and only when, they appear in all 124 capitals, as shown here. 126 3. Reference environment 128 The reference scenario is a client that uses a QUIC tunnel to send 129 all its packets to a concentrator. The concentrator processes the 130 packets received from the client over the QUIC connection and 131 forwards them to their final destination. It also receives the 132 packets destined to the client and tunnels them through the QUIC 133 connection. 135 +-------------+ 136 +--------+ +--------------+ | Final | 137 | Client | | Concentrator |<===\ ... \===>| destination | 138 +--------+ +--------------+ | server | 139 ^ +---------+ ^ +-------------+ 140 | | Access | | Legend: 141 .----| network |----. --- QUIC connection 142 +---------+ === Tunneled flow 143 Figure 1: A client attached to a concentrator 145 In a nutshell, the solution proposed in this document works as 146 follows. The client opens a QUIC connection to a concentrator. The 147 concentrator authenticates the client through means that are outside 148 the scope of this document such as client certificates, usernames/ 149 passwords, OAuth, ... If the authentication succeeds, the client can 150 send packets via the concentrator by tunneling them through the 151 concentrator. 153 The concentrator captures the packets destined to the client and 154 tunnels them over the QUIC connection. This solution is intended to 155 provide a similar service as the one provided by IPSec tunnels or 156 DTLS. This document leaves address assignment mechanisms out of 157 scope, deployments can rely on out-of-band configurations for that 158 purpose. 160 4. The tunnel mode 162 The "tunnel mode" of operation leverages the recently proposed QUIC 163 datagram extension [I-D.pauly-quic-datagram]. In a nutshell, to send 164 a packet to a remote host, the client simply encapsulates the entire 165 packet inside a QUIC DATAGRAM frame sent over the QUIC connection 166 established with the concentrator. 168 The frame transmission is subject to congestion control, but the 169 frame that contains the packet is not retransmitted in case of loss 170 as specified in [I-D.pauly-quic-datagram]. 172 This mode adds a minimal byte overhead for packet encapsulation in 173 QUIC. It does not define ways of indicating the protocol of the 174 conveyed packets, which can be useful in deployments for which out- 175 of-band signaling may be used. 177 5. Connection establishment 179 During QUIC connection establishment, the "tunnel mode" of operation 180 support is indicated by setting the ALPN token "qt" in the TLS 181 handshake. Draft-version implementations MAY specify a particular 182 draft version by suffixing the token, e.g. "qt-00" refers to the 183 first version of this document. 185 After the QUIC connection is established, the client can start using 186 the "tunnel mode". The client may use PCP [RFC6887] to request the 187 concentrator to accept inbound connections on their behalf. After 188 the negotiation of such port mappings, the concentrator can start 189 sending packets containing inbound connections in QUIC DATAGRAM 190 frame. 192 6. Reporting access networks availability 194 When the access network is unstable or its performance is degrading, 195 for instance due to signal loss, being able to report its 196 availability to the concentrator can help reduce the amount of 197 packets sent over unstable or unavailable paths. It can also resume 198 quickly the sending of packets over a previously unavailable access 199 network. 201 To do so, we define in Section 7 a message called Access Report TLV. 202 The message can be sent by the client to the concentrator. It 203 identifies the type of access network reported and its associated 204 status. This message is sent over the QUIC connection in a separate 205 unidirectional stream. 207 7. Messages format 209 In the following sections, we specify the format of each message 210 introduced in this document. The messages are encoded as TLVs, i.e. 211 (Type, Length, Value) tuples, as illustrated in Figure 2. All TLV 212 fields are encoded in network-byte order. 214 1 2 3 215 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 216 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 217 | Type (8) | Length (8) | [Value (*)] ... 218 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 220 Figure 2: QUIC tunnel TLV Format 222 The Type field is encoded as a byte and identifies the type of the 223 TLV. The Length field is encoded as a byte and indicate the length 224 in bytes of the Value field. A value of zero indicates that no Value 225 field is present. The Value field is a type-specific value whose 226 length is determined by the Length field. 228 7.1. QUIC tunnel control TLVs 230 This document specifies the following QUIC tunnel control TLVs: 232 +------+----------+--------+------+-------------------+ 233 | Type | Size | Sender | Mode | Name | 234 +------+----------+--------+------+-------------------+ 235 | 0x00 | 4 bytes | Client | all | Access Report TLV | 236 +------+----------+--------+------+-------------------+ 238 Figure 3: QUIC tunnel control TLVs 240 The Access Report TLV is sent by the client to periodically report on 241 access networks availability. Each Access Report TLV MUST be sent on 242 a separate unidirectional stream. The stream FIN bit MUST be set 243 following the end of the TLV. 245 7.1.1. Access Report TLV 247 1 2 3 248 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 249 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 250 | Type = 0x00 | Length = 0x02 | AI (4)| R (4) | Signal (8) | 251 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 253 Figure 4: Access Report TLV 255 The Access Report TLV contains the following: 257 * AI (Access ID) - a four-bit-long field that identifies the access 258 network, e.g., 3GPP (Radio Access Technologies specified by 3GPP) 259 or Non-3GPP (accesses that are not specified by 3GPP) [TS23501]. 260 The value is one of those listed below (all other values are 261 invalid and the TLV that contains it MUST be discarded): 263 +-----------+-----------------------+ 264 | Access ID | Description | 265 +-----------+-----------------------+ 266 | 1 | 3GPP Network | 267 | 2 | Non-3GPP Network | 268 +-----------+-----------------------+ 270 * R (Reserved) - a four-bit-long field that MUST be zeroed on 271 transmission and ignored on receipt. 273 * Signal - a one-octet-long field that identifies the report signal, 274 e.g., available or unavailable. The value is supplied to the QUIC 275 tunnel through some mechanism that is outside the scope of this 276 document. The value is one of those listed in Section 9.3. 278 The client that includes the Access Report TLV sets the value of the 279 Access ID field according to the type of access network it reports 280 on. Also, the client sets the value of the Signal field to reflect 281 the operational state of the access network. The mechanism to 282 determine the state of the access network is outside the scope of 283 this specification. 285 The client MUST be able to cancel the sending of an Access Report TLV 286 that is pending delivery, i.e. by resetting its corresponding 287 unidirectional stream. This can be used when the information 288 contained in the TLV is no longer relevant, e.g. the access network 289 availability has changed. The time of canceling is based on local 290 policies and network environment. 292 Reporting the unavailability of an access network to the concentrator 293 can serve as an indication to stop sending packets over this network 294 while maintaining the QUIC tunnel connection. Upon reporting of the 295 availability of this network, the concentrator can quickly resume 296 sending packets over this network. 298 8. Security Considerations 300 8.1. Privacy 302 The Concentrator has access to all the packets it processes. It MUST 303 be protected as a core IP router, e.g. as specified in [RFC1812]. 305 8.2. Ingress Filtering 307 Ingress filtering policies MUST be enforced at the network 308 boundaries, i.e. as specified in [RFC2827]. 310 9. IANA Considerations 312 9.1. Registration of QUIC tunnel Identification String 314 This document creates one new registration for the identification of 315 the QUIC tunnel protocol in the "Application Layer Protocol 316 Negotiation (ALPN) Protocol IDs" registry established in [RFC7301]. 318 The "qt" string identifies the QUIC tunnel protocol datagram mode. 320 Protocol: QUIC Tunnel 322 Identification Sequence: 0x71 0x74 ("qt") 324 Specification: This document 326 9.2. QUIC tunnel control TLVs 328 IANA is requested to create a new "QUIC tunnel control Parameters" 329 registry. 331 The following subsections detail new registries within "QUIC tunnel 332 control Parameters" registry. 334 9.2.1. QUIC tunnel control TLVs Types 336 IANA is request to create the "QUIC tunnel control TLVs Types" sub- 337 registry. New values are assigned via IETF Review (Section 4.8 of 338 [RFC8126]). 340 The initial values to be assigned at the creation of the registry are 341 as follows: 343 +------+-----------------------+------------+ 344 | Code | Name | Reference | 345 +------+-----------------------+------------+ 346 | 0 | Access Report TLV | [This-Doc] | 347 +------+-----------------------+------------+ 349 9.3. QUIC tunnel Access Report Signal Codes 351 This document establishes a registry for QUIC tunnel Access Report 352 Signal codes. The "QUIC tunnel Access Report Signal Code" registry 353 manages a 62-bit space. New values are assigned via IETF Review 354 (Section 4.8 of [RFC8126]). 356 The initial values to be assigned at the creation of the registry are 357 as follows: 359 +------+-----------------------+------------+ 360 | Code | Name | Reference | 361 +------+-----------------------+------------+ 362 | 1 | Access Available | [This-Doc] | 363 | 2 | Access Unavailable | [This-Doc] | 364 +------+-----------------------+------------+ 366 10. References 368 10.1. Normative References 370 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 371 Requirement Levels", BCP 14, RFC 2119, 372 DOI 10.17487/RFC2119, March 1997, 373 . 375 [TS23501] 3GPP (3rd Generation Partnership Project), "Technical 376 Specification Group Services and System Aspects; System 377 Architecture for the 5G System; Stage 2 (Release 16)", 378 3GPP TS23501, 2019. 380 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 381 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 382 May 2017, . 384 10.2. Informative References 386 [I-D.pauly-quic-datagram] 387 Pauly, T., Kinnear, E., and D. Schinazi, "An Unreliable 388 Datagram Extension to QUIC", Work in Progress, Internet- 389 Draft, draft-pauly-quic-datagram-05, 4 November 2019, 390 . 393 [I-D.ietf-quic-transport] 394 Iyengar, J. and M. Thomson, "QUIC: A UDP-Based Multiplexed 395 and Secure Transport", Work in Progress, Internet-Draft, 396 draft-ietf-quic-transport-32, 20 October 2020, 397 . 400 [I-D.ietf-quic-tls] 401 Thomson, M. and S. Turner, "Using TLS to Secure QUIC", 402 Work in Progress, Internet-Draft, draft-ietf-quic-tls-32, 403 20 October 2020, . 406 [RFC1812] Baker, F., Ed., "Requirements for IP Version 4 Routers", 407 RFC 1812, DOI 10.17487/RFC1812, June 1995, 408 . 410 [RFC2827] Ferguson, P. and D. Senie, "Network Ingress Filtering: 411 Defeating Denial of Service Attacks which employ IP Source 412 Address Spoofing", BCP 38, RFC 2827, DOI 10.17487/RFC2827, 413 May 2000, . 415 [RFC6887] Wing, D., Ed., Cheshire, S., Boucadair, M., Penno, R., and 416 P. Selkirk, "Port Control Protocol (PCP)", RFC 6887, 417 DOI 10.17487/RFC6887, April 2013, 418 . 420 [RFC7301] Friedl, S., Popov, A., Langley, A., and E. Stephan, 421 "Transport Layer Security (TLS) Application-Layer Protocol 422 Negotiation Extension", RFC 7301, DOI 10.17487/RFC7301, 423 July 2014, . 425 [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for 426 Writing an IANA Considerations Section in RFCs", BCP 26, 427 RFC 8126, DOI 10.17487/RFC8126, June 2017, 428 . 430 Appendix A. Change Log 432 A.1. Since draft-piraux-quic-tunnel-03 434 * Make the lightweight mode the default "tunnel mode" 436 * Rename the datagram mode as tunnel session mode in draft-piraux- 437 intarea-quic-tunnel-session 439 A.2. Since draft-piraux-quic-tunnel-02 441 * Add the lightweight mode 443 A.3. Since draft-piraux-quic-tunnel-01 445 * Add the Access Report TLV for reporting access networks 446 availability 448 * Add a section with examples of use of the Packet Tag 450 A.4. Since draft-piraux-quic-tunnel-00 452 * Separate the document in two and put the stream mode in another 453 document 455 * Remove TCP Extended TLV 457 * Add a mechanism for joining QUIC connections in a QUIC tunneling 458 session 460 * Add a format for encoding any network-layer protocol packets and 461 Ethernet frames in QUIC DATAGRAM frames 463 Acknowledgments 465 Thanks to Quentin De Coninck and Francois Michel for their comments 466 and the proofreading of the first version of draft-piraux-quic- 467 tunnel. Thanks to Gregory Vander Schueren for his comments on the 468 first version of draft-piraux-quic-tunnel. Thanks to Florin Baboescu 469 for his comments on the first version of this document. 471 Authors' Addresses 472 Maxime Piraux 473 UCLouvain 475 Email: maxime.piraux@uclouvain.be 477 Olivier Bonaventure 478 UCLouvain 480 Email: olivier.bonaventure@uclouvain.be 482 Adi Masputra 483 Apple Inc. 485 Email: adi@apple.com