idnits 2.17.1 draft-piraux-quic-tunnel-03.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 (August 12, 2020) is 1353 days in the past. Is this intentional? Checking references for intended status: Experimental ---------------------------------------------------------------------------- == Missing Reference: 'This-Doc' is mentioned on line 667, but not defined == Unused Reference: 'RFC1701' is defined on line 674, but no explicit reference was found in the text == Outdated reference: A later version (-07) exists of draft-deconinck-quic-multipath-04 == Outdated reference: A later version (-34) exists of draft-ietf-quic-tls-29 == Outdated reference: A later version (-34) exists of draft-ietf-quic-transport-29 -- Obsolete informational reference (is this intentional?): RFC 6824 (Obsoleted by RFC 8684) -- Duplicate reference: RFC1701, mentioned in 'Transparent-Ethernet-Bridging', was also mentioned in 'RFC1701'. Summary: 0 errors (**), 0 flaws (~~), 6 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 QUIC Working Group M. Piraux 3 Internet-Draft O. Bonaventure 4 Intended status: Experimental UCLouvain 5 Expires: February 13, 2021 A. Masputra 6 Apple Inc. 7 August 12, 2020 9 Tunneling Internet protocols inside QUIC 10 draft-piraux-quic-tunnel-03 12 Abstract 14 This document specifies methods for tunneling Ethernet frames and 15 Internet protocols such as TCP, UDP, IP and QUIC inside a QUIC 16 connection. 18 Status of This Memo 20 This Internet-Draft is submitted in full conformance with the 21 provisions of BCP 78 and BCP 79. 23 Internet-Drafts are working documents of the Internet Engineering 24 Task Force (IETF). Note that other groups may also distribute 25 working documents as Internet-Drafts. The list of current Internet- 26 Drafts is at https://datatracker.ietf.org/drafts/current/. 28 Internet-Drafts are draft documents valid for a maximum of six months 29 and may be updated, replaced, or obsoleted by other documents at any 30 time. It is inappropriate to use Internet-Drafts as reference 31 material or to cite them other than as "work in progress." 33 This Internet-Draft will expire on February 13, 2021. 35 Copyright Notice 37 Copyright (c) 2020 IETF Trust and the persons identified as the 38 document authors. All rights reserved. 40 This document is subject to BCP 78 and the IETF Trust's Legal 41 Provisions Relating to IETF Documents 42 (https://trustee.ietf.org/license-info) in effect on the date of 43 publication of this document. Please review these documents 44 carefully, as they describe your rights and restrictions with respect 45 to this document. Code Components extracted from this document must 46 include Simplified BSD License text as described in Section 4.e of 47 the Trust Legal Provisions and are provided without warranty as 48 described in the Simplified BSD License. 50 Table of Contents 52 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 53 2. Conventions and Definitions . . . . . . . . . . . . . . . . . 4 54 3. Reference environment . . . . . . . . . . . . . . . . . . . . 4 55 4. The lightweight mode . . . . . . . . . . . . . . . . . . . . 5 56 5. The datagram mode . . . . . . . . . . . . . . . . . . . . . . 6 57 5.1. Joining a tunneling session . . . . . . . . . . . . . . . 7 58 5.1.1. Coordinate use of the Packet Tag . . . . . . . . . . 8 59 6. Connection establishment . . . . . . . . . . . . . . . . . . 9 60 7. Messages format . . . . . . . . . . . . . . . . . . . . . . . 9 61 7.1. QUIC tunnel control TLVs . . . . . . . . . . . . . . . . 10 62 7.1.1. Access Report TLV . . . . . . . . . . . . . . . . . . 10 63 7.1.2. New Session TLV . . . . . . . . . . . . . . . . . . . 11 64 7.1.3. Session ID TLV . . . . . . . . . . . . . . . . . . . 12 65 7.1.4. Join Session TLV . . . . . . . . . . . . . . . . . . 12 66 8. Security Considerations . . . . . . . . . . . . . . . . . . . 13 67 8.1. Privacy . . . . . . . . . . . . . . . . . . . . . . . . . 13 68 8.2. Ingress Filtering . . . . . . . . . . . . . . . . . . . . 13 69 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 70 9.1. Registration of QUIC tunnel Identification String . . . . 13 71 9.2. QUIC tunnel control TLVs . . . . . . . . . . . . . . . . 14 72 9.2.1. QUIC tunnel control TLVs Types . . . . . . . . . . . 14 73 9.3. QUIC tunnel control Error Codes . . . . . . . . . . . . . 14 74 9.4. QUIC tunnel Access Report Signal Codes . . . . . . . . . 15 75 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 15 76 10.1. Normative References . . . . . . . . . . . . . . . . . . 15 77 10.2. Informative References . . . . . . . . . . . . . . . . . 15 78 Appendix A. Change Log . . . . . . . . . . . . . . . . . . . . . 17 79 A.1. Since draft-piraux-quic-tunnel-02 . . . . . . . . . . . . 17 80 A.2. Since draft-piraux-quic-tunnel-01 . . . . . . . . . . . . 17 81 A.3. Since draft-piraux-quic-tunnel-00 . . . . . . . . . . . . 17 82 Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 17 83 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 18 85 1. Introduction 87 Mobile devices such as laptops, smartphones or tablets have different 88 requirements than the traditional fixed devices. These mobile 89 devices often change their network attachment. They are often 90 attached to trusted networks, but sometimes they need to be connected 91 to untrusted networks where their communications can be eavesdropped, 92 filtered or modified. In these situations, the classical approach is 93 to rely on VPN protocols such as DTLS or IPSec. These VPN protocols 94 provide the encryption and authentication functions to protect those 95 mobile clients from malicious behaviors in untrusted networks. 97 However, some networks have deployed filters that block these VPN 98 protocols. When faced with such filters, users can either switch off 99 their connection or find alternatives, e.g. by using TLS to access 100 some services over TCP port 443. The planned deployment of QUIC 101 [I-D.ietf-quic-transport] [I-D.ietf-quic-tls] opens a new opportunity 102 for such users. Since QUIC will be used to access web sites, it 103 should be less affected by filters than VPN solutions such as IPSec 104 or DTLS. Furthermore, the flexibility of QUIC makes it possible to 105 easily extend the protocol to support VPN services. 107 This document shares some goals with the MASQUE framework 108 [I-D.schinazi-masque]. The proposed QUIC tunnel protocol contributes 109 to the effort of defining a signaling for conveying multiple proxied 110 flows inside a QUIC connection. While this document specifies its 111 own protocol, further work could adapt the mechanisms presented in 112 this proposal to use HTTP/3. 114 On the other hand, today's mobile devices are often multihomed and 115 many expect to be able to perform seamless handovers from one access 116 network to another without breaking the established VPN sessions. In 117 some situations it can also be beneficial to combine two or more 118 access networks together to increase the available host bandwidth. A 119 protocol such as Multipath TCP [RFC6824] supports those handovers and 120 allows aggregating the bandwidth of different access links. It could 121 be combined with single-path VPN protocols to support both seamless 122 handovers and bandwidth aggregation above VPN tunnels. 123 Unfortunately, Multipath TCP is not yet deployed on most Internet 124 servers and thus few applications would benefit from such a use case. 126 In this document, we explore how QUIC could be used to enable multi- 127 homed mobile devices to communicate securely in untrusted networks. 128 The QUIC protocol opens up a new way to find a clean solution to this 129 problem. First, QUIC includes the same encryption and authentication 130 techniques as deployed VPN protocols. Second, QUIC is intended to be 131 widely used to support web-based services, making it unlikely to be 132 filtered in many networks, in contrast with VPN protocols. Third, 133 the QUIC migration mechanism enables handovers between several 134 network interfaces. 136 This document is organized as follows. Section 3 describes our 137 reference environment. Then, we propose two mode of operations, 138 explained in Section 4 and Section 5, that use the recently proposed 139 datagram extension ([I-D.pauly-quic-datagram]) for QUIC to transport 140 plain IP packets over a QUIC connection. Section 6 specifies how a 141 connection is established in this document proposal. Section 7 142 details the format of the messages introduced by this document. 144 2. Conventions and Definitions 146 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 147 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 148 "OPTIONAL" in this document are to be interpreted as described in BCP 149 14 [RFC2119] [RFC8174] when, and only when, they appear in all 150 capitals, as shown here. 152 3. Reference environment 154 Our first scenario is a client that uses a QUIC tunnel to send all 155 its packets to a concentrator. The concentrator decrypts the packets 156 received over the QUIC connection and forwards them to their final 157 destination. It also receives the packets destined to the client and 158 tunnels them through the QUIC connection. 160 +-------------+ 161 +--------+ +--------------+ | Final | 162 | Client | | Concentrator |<===\ ... \===>| destination | 163 +--------+ +--------------+ | server | 164 ^ +---------+ ^ +-------------+ 165 | | Access | | 166 | | network | | Legend: 167 .----| |----. --- QUIC connection 168 +---------+ === TCP/UDP flow 170 Figure 1: A client attached to a concentrator 172 However, there are several situations where the client is attached to 173 two or more access networks. This client can be multihomed, dual- 174 stack, ... This is illustrated in Figure 2, in which a client- 175 initiated flow is tunneled through the concentrator. We also discuss 176 inbound connections in this document in Section 6. 178 +---------+ 179 .----| Access |----. 180 | | network | | 181 | | A | | 182 v +---------- v +-------------+ 183 +--------+ +--------------+ | Final | 184 | Client | | Concentrator |<===\ ... \===>| destination | 185 +--------+ +--------------+ | server | 186 ^ +---------+ ^ +-------------+ 187 | | Access | | 188 | | network | | Legend: 189 .----| B |----. --- QUIC connection 190 +---------+ === TCP/UDP flow 192 Figure 2: Example environment 194 Such a client would like to benefit from the different access 195 networks available to reach the concentrator. These access networks 196 can be used for load-sharing, failover or other purposes. One 197 possibility to efficiently use these two access networks is to rely 198 on the proposed Multipath extensions to QUIC 199 [I-D.deconinck-quic-multipath]. Another approach is to create one 200 QUIC connection using the single-path QUIC protocol 201 [I-D.ietf-quic-transport] over each access network and glue these 202 different sessions together on the concentrator. Given the migration 203 capabilities of QUIC, this approach could support failover with a 204 single active QUIC connection at a time. 206 In a nutshell, the solution proposed in this document works as 207 follows. The client opens a QUIC connection to a concentrator. The 208 concentrator authenticates the client through means that are outside 209 the scope of this document such as client certificates, usernames/ 210 passwords, OAuth, ... If the authentication succeeds, the client can 211 use the tunnel to exchange Ethernet frames and IP packets with the 212 concentrator over the QUIC session. If the client uses IP, then the 213 concentrator can allocate an IP address to the client at the end of 214 the authentication phase. The client can then send packets via the 215 concentrator by tunneling them through the concentrator. The 216 concentrator captures the IP packets destined to the client and 217 tunnels them over the QUIC connection. Our solution is intended to 218 provide a similar service as the one provided by IPSec tunnels or 219 DTLS. 221 4. The lightweight mode 223 Our first mode of operation is very simple. It leverages the 224 recently proposed QUIC datagram extension [I-D.pauly-quic-datagram]. 225 In a nutshell, to send a packet to a remote host, the client simply 226 encodes the entire packet inside a QUIC DATAGRAM frame sent over the 227 QUIC connection established with the concentrator. 229 This QUIC DATAGRAM frame is then encrypted and authenticated in a 230 QUIC packet. This transmission is subject to congestion control, but 231 the frame that contains the packet is not retransmitted in case of 232 losses as specified in [I-D.pauly-quic-datagram]. 234 This mode adds a minimal byte overhead for packet encapsulation in 235 QUIC. It does not define ways of indicating the protocol of the 236 conveyed packets, which can be useful in deployments for which out- 237 of-band signalling can be used. 239 5. The datagram mode 241 Our second mode of operation, called the datagram mode in this 242 document, enables the client and the concentrator to exchange packets 243 of several network protocols through the QUIC tunnel connection at 244 the same time. It also leverages the QUIC datagram extension 245 [I-D.pauly-quic-datagram]. 247 This document specifies the following format for encoding packets in 248 QUIC DATAGRAM frame. It allows encoding packets from several 249 protocols by identifying the corresponding protocol of the packet in 250 each QUIC DATAGRAM frame. Figure 3 describes this encoding. 252 1 2 3 253 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 254 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 255 | Protocol Type (16) | Packet Tag (16) | 256 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 257 | Packet (*) ... 258 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 260 Figure 3: Encoding packets in QUIC DATAGRAM frame 262 This encoding defines three fields. 264 o Protocol Type: The Protocol Type field contains the protocol type 265 of the payload packet. The values for the different protocols are 266 defined as "ETHER TYPES" in [IANA-ETHER-TYPES]. A QUIC tunnel 267 that receives a Protocol Type representing an unsupported protocol 268 MAY drop the associated Packet. QUIC tunnel endpoints willing to 269 exchange Ethernet frames can use the value 0x6558 for 270 [Transparent-Ethernet-Bridging]. 272 o Packet Tag: An opaque 16-bit value. The QUIC tunnel application 273 is free to decide its semantic value. For instance, a QUIC tunnel 274 endpoint MAY encode the sending order of packets in the Packet 275 Tag, e.g. as a timestamp or a sequence number, to allow reordering 276 on the receiver. 278 o Packet: The packet conveyed inside the QUIC tunnel connection. 280 ,->+----------+ 281 | | IP | 282 QUIC packet | +----------+ 283 containing | | UDP | 284 a DATAGRAM | +----------+ 285 frame | | QUIC | 286 | |..........| 287 | | DATAGRAM | 288 | | P. Type | 289 | | P. Tag | 290 | |+--------+|<-. 291 | || IP || | 292 | |+--------+| | Tunneled 293 | || UDP || | UDP packet 294 | |+--------+| | 295 | | .... |<-. 296 `->+----------+ 298 Figure 4: QUIC packet sent by the client when tunneling a UDP packet 300 Figure 4 illustrates how a UDP packet is tunneled using the datagram 301 mode. The main advantage of the datagram mode is that it supports IP 302 and any protocol above the network layer. Any IP packet can be 303 transported using the datagram extension over a QUIC connection. 304 However, this advantage comes with a large per-packet overhead since 305 each packet contains both a network and a transport header. All 306 these headers must be transmitted in addition with the IP/UDP/QUIC 307 headers of the QUIC connection. For TCP connections for instance, 308 the per-packet overhead can be large. 310 5.1. Joining a tunneling session 312 If the client is multihomed, it can use Multipath QUIC 313 [I-D.deconinck-quic-multipath] to efficiently use its different 314 access networks. This version of the document does not elaborate in 315 details on this possibility. If the concentrator does not support 316 Multipath QUIC, then the client creates several QUIC connections and 317 joins them at the application layer. This works as illustrated in 318 figure Figure 5. Each message is exchanged over a dedicated 319 unidirectional QUIC stream. Their format is detailed in Section 7. 320 When the client opens the first QUIC connection with the 321 concentrator, (1) it can request a QUIC tunnel session identifier. 323 (2) The concentrator replies with a variable-length opaque value that 324 identifies the QUIC tunneling session. When opening a QUIC 325 connection over another access network, (3) the client can send this 326 identifier to join the QUIC tunneling session. The concentrator 327 matches the session identifier with the existing session with the 328 client. It can then use both sessions to reach the client and 329 received tunneled packets from the client. 331 1-Req. Sess. ID-> 332 .-----------------------------. 333 | <-Sess. ID.-2 | 334 v v 335 +--------+ +--------------+ 336 | Client | | Concentrator | 337 +--------+ +--------------+ 338 ^ ^ 339 | 3-Join. Sess.-> | Legend: 340 .-----------------------------. --- QUIC connection 342 Figure 5: Creating sessions over different access networks 344 Joining a tunneling session allows grouping several QUIC connections 345 to the concentrator. Each endpoint can then coordinate the use of 346 the Packet Tag across the tunneling session as presented in 347 Section 5.1.1. 349 Both QUIC tunnel endpoints open their first unidirectional stream 350 (i.e. stream 2 and 3), hereafter named the QUIC tunnel control 351 stream, to exchange these messages. A QUIC tunnel endpoint MUST NOT 352 close its unidirectional stream and SHOULD provide enough flow 353 control credit to its peer. 355 The messages format used for this purpose are described in Section 7. 356 The client initiates the procedure and MAY either start a new session 357 or join an existing session. This negotiation MUST NOT take place 358 more than once per QUIC connection. 360 5.1.1. Coordinate use of the Packet Tag 362 When using the datagram mode, each packet is associated with a 16-bit 363 value called Packet Tag. This document leaves defining the meaning of 364 this value to implementations. This section provides some examples 365 on how it can be used to implement packet reordering across several 366 QUIC tunnel connections grouped in a tunneling session. 368 A first simple example of use is to encode the timestamp at which the 369 datagram was sent. Using a millisecond precision and encoding the 16 370 lower bits of the timestamp makes the value wrapping around in a bit 371 more than 65 seconds. 373 Another example of use is to maintain a value counting the datagrams 374 sent over all QUIC tunnel connections of the tunneling session. The 375 16-bit value allows distinguishing at most 32768 packets in flight. 377 The QUIC tunnel receiver can then distinguish, buffer and reorder 378 packets based on this value. Mechanisms for managing the datagram 379 buffer and negotiating the use of the Packet Tag are out of scope of 380 this document. 382 6. Connection establishment 384 During connection establishment, the QUIC tunnel datagram mode (resp. 385 lite mode) support is indicated by setting the ALPN token "qt" (resp. 386 "qt-lite") in the TLS handshake. Draft-version implementations MAY 387 specify a particular draft version by suffixing the token, e.g. "qt- 388 00" (resp. "qt-lite-03") refers to the first (resp. fourth) version 389 of this document. 391 After the QUIC connection is established, the client can start using 392 the datagram or the stream mode. The client may use PCP [RFC6887] to 393 request the concentrator to accept inbound connections on their 394 behalf. After the negotiation of such port mappings, the 395 concentrator can start sending packets containing inbound connections 396 in QUIC DATAGRAM frame. 398 7. Messages format 400 In the following sections, we specify the format of each message 401 introduced in this document. They are encoded as TLVs, i.e. (Type, 402 Length, Value) tuples, as illustrated in Figure 6. All TLV fields 403 are encoded in network-byte order. 405 1 2 3 406 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 407 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 408 | Type (8) | Length (8) | [Value (*)] ... 409 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 411 Figure 6: QUIC tunnel TLV Format 413 The Type field is encoded as a byte and identifies the type of the 414 TLV. The Length field is encoded as a byte and indicate the length 415 of the Value field. A value of zero indicates that no Value field is 416 present. The Value field is a type-specific value whose length is 417 determined by the Length field. 419 7.1. QUIC tunnel control TLVs 421 This document specifies the following QUIC tunnel control TLVs: 423 +------+----------+--------------+----------+-------------------+ 424 | Type | Size | Sender | Mode | Name | 425 +------+----------+--------------+----------+-------------------+ 426 | 0x00 | 4 bytes | Client | all | Access Report TLV | 427 | 0x01 | 2 bytes | Client | datagram | New Session TLV | 428 | 0x02 | Variable | Concentrator | datagram | Session ID TLV | 429 | 0x03 | Variable | Client | datagram | Join Session TLV | 430 +------+----------+--------------+----------+-------------------+ 432 Figure 7: QUIC tunnel control TLVs 434 The Access Report TLV is sent by the client to periodically report on 435 access networks availability. Each Access Report TLV MUST be sent on 436 a separate unidirectional stream. When the datagram mode is in use, 437 this separate stream MUST be other than the QUIC tunnel control 438 stream. 440 The New Session TLV is used by the client to initiate a new tunneling 441 session. The Session ID TLV is used by the concentrator to 442 communicate to the client the Session ID identifying this tunneling 443 session. The Join Session TLV is used to join a given tunneling 444 session, identified by a Session ID. All QUIC these tunnel control 445 TLVs MUST NOT be sent on other streams than the QUIC tunnel control 446 streams. 448 7.1.1. Access Report TLV 450 1 2 3 451 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 452 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 453 | Type (8) | Length (8) | AI (4)| R (4) | Signal (8) | 454 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 456 Figure 8: Access Report TLV 458 The Access Report TLV contains the following: 460 o AI (Access ID) - a four-bit-long field that identifies the access 461 network, e.g., 3GPP (Radio Access Technologies specified by 3GPP) 462 or Non-3GPP (accesses that are not specified by 3GPP) [TS23501]. 463 The value is one of those listed below (all other values are 464 invalid and the TLV that contains it MUST be discarded): 466 +-----------+-----------------------+ 467 | Access ID | Description | 468 +-----------+-----------------------+ 469 | 1 | 3GPP Network | 470 | 2 | Non-3GPP Network | 471 +-----------+-----------------------+ 473 o R (Reserved) - a four-bit-long field that MUST be zeroed on 474 transmission and ignored on receipt. 476 o Signal - a one-octet-long field that identifies the report signal, 477 e.g., available or unavailable. The value is supplied to the QUIC 478 tunnel through some mechanism that is outside the scope of this 479 document. The value is one of those listed in Section 9.4. 481 The client that includes the Access Report TLV sets the value of the 482 Access ID field according to the type of access network it reports 483 on. Also, the client sets the value of the Signal field to reflect 484 the operational state of the access network. The mechanism to 485 determine the state of the access network is outside the scope of 486 this specification. 488 The client MUST be able to cancel the sending of an Access Report TLV 489 that is pending delivery, i.e. by resetting its corresponding 490 unidirectional stream. This can be used when the information 491 contained in the TLV is no longer relevant, e.g. the access network 492 availability has changed. The time of canceling is based on local 493 policies and network environment. 495 Reporting the unavailability an access network to the concentrator 496 can serve as an advisory signal to preventively stop sending packets 497 over this network while maintaining the QUIC tunnel connection. Upon 498 reporting of the availability of this network, the concentrator can 499 quickly resume sending packets over this network. 501 7.1.2. New Session TLV 503 The New Session TLV does not contain a value. It initiates a new 504 tunneling session at the concentrator. The concentrator MUST send a 505 Session ID TLV in response, with the Session ID corresponding to the 506 tunneling session created. After sending a New Session TLV, the 507 client MUST close the QUIC tunnel control stream. 509 The concentrator MUST NOT send New Session TLVs. 511 7.1.3. Session ID TLV 513 1 2 3 514 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 515 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 516 | Type (8) | Length (8) | Session ID (*) ... 517 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 519 Figure 9: Session ID TLV 521 The Session ID TLV contains an opaque value that identifies the 522 current tunneling session. It can be used by the client in 523 subsequent QUIC connections to join them to this tunneling session. 524 The concentrator MUST send a Session ID TLV in response of a New 525 Session TLV, with the Session ID corresponding to the tunneling 526 session created. 528 The client MUST NOT send a Session ID TLV. The concentrator MUST 529 close the QUIC tunnel control stream after sending a Session ID TLV. 531 7.1.4. Join Session TLV 533 1 2 3 534 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 535 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 536 | Type (8) | Length (8) | Session ID (*) ... 537 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 539 Figure 10: Join Session TLV 541 The Join Session TLV contains an opaque value that identifies a 542 tunneling session to join. The client can send a Join Session TLV to 543 join the QUIC connection to a particular tunneling session. The 544 tunneling session is identified by the Session ID. After sending a 545 Join Session TLV, the client MUST close the QUIC tunnel control 546 stream. 548 The concentrator MUST NOT send Join Session TLVs. After receiving a 549 Join Session TLV, the concentrator MUST use the Session ID to join 550 this QUIC connection to the tunneling session. Joining the tunneling 551 session implies merging the state of this QUIC tunnel connection to 552 the session. A successful joining of connection is indicated by the 553 closure of the QUIC tunnel control stream of the concentrator. 555 In cases of failure when joining a tunneling session, the 556 concentrator MUST send a RESET_STREAM with an application error code 557 discerning the cause of the failure. The possible codes are listed 558 below: 560 o UNKNOWN_ERROR (0x0): An unknown error occurred when joining the 561 tunneling session. QUIC tunnel endpoints SHOULD use more specific 562 error codes when applicable. 564 o UNKNOWN_SESSION_ID (0x1): The Session ID used in the Join Session 565 TLV is not a valid ID. It was not issued in a Session ID TLV or 566 refers to an expired tunneling session. 568 o CONFLICTING_STATE (0x2): The current state of the QUIC tunnel 569 connection could not be merged with the tunneling session. 571 8. Security Considerations 573 8.1. Privacy 575 The Concentrator has access to all the packets it processes. It MUST 576 be protected as a core IP router, e.g. as specified in [RFC1812]. 578 8.2. Ingress Filtering 580 Ingress filtering policies MUST be enforced at the network 581 boundaries, i.e. as specified in [RFC2827]. 583 9. IANA Considerations 585 9.1. Registration of QUIC tunnel Identification String 587 This document creates two new registrations for the identification of 588 the QUIC tunnel protocol in the "Application Layer Protocol 589 Negotiation (ALPN) Protocol IDs" registry established in [RFC7301]. 591 The "qt" string identifies the QUIC tunnel protocol datagram mode. 593 Protocol: QUIC Tunnel 595 Identification Sequence: 0x71 0x74 ("qt") 597 Specification: This document 599 The "qt-lite" string identifies the QUIC tunnel protocol lightweight 600 mode. 602 Protocol: QUIC Tunnel lightweight mode 604 Identification Sequence: 0x71 0x74 0x55 0x6c 0x69 0x74 0x65 ("qt- 605 lite") 607 Specification: This document 609 9.2. QUIC tunnel control TLVs 611 IANA is requested to create a new "QUIC tunnel control Parameters" 612 registry. 614 The following subsections detail new registries within "QUIC tunnel 615 control Parameters" registry. 617 9.2.1. QUIC tunnel control TLVs Types 619 IANA is request to create the "QUIC tunnel control TLVs Types" sub- 620 registry. New values are assigned via IETF Review (Section 4.8 of 621 [RFC8126]). 623 The initial values to be assigned at the creation of the registry are 624 as follows: 626 +------+-----------------------+------------+ 627 | Code | Name | Reference | 628 +------+-----------------------+------------+ 629 | 0 | Access Report TLV | [This-Doc] | 630 | 1 | New Session TLV | [This-Doc] | 631 | 2 | Session ID TLV | [This-Doc] | 632 | 3 | Join Session TLV | [This-Doc] | 633 +------+-----------------------+------------+ 635 9.3. QUIC tunnel control Error Codes 637 This document establishes a registry for QUIC tunnel control stream 638 error codes. The "QUIC tunnel control Error Code" registry manages a 639 62-bit space. New values are assigned via IETF Review (Section 4.8 640 of [RFC8126]). 642 The initial values to be assigned at the creation of the registry are 643 as follows: 645 +------+-----------------------+------------+ 646 | Code | Name | Reference | 647 +------+-----------------------+------------+ 648 | 0 | UNKNOWN_ERROR | [This-Doc] | 649 | 1 | UNKNOWN_SESSION_ID | [This-Doc] | 650 | 2 | CONFLICTING_STATE | [This-Doc] | 651 +------+-----------------------+------------+ 653 9.4. QUIC tunnel Access Report Signal Codes 655 This document establishes a registry for QUIC tunnel Access Report 656 Signal codes. The "QUIC tunnel Access Report Signal Code" registry 657 manages a 62-bit space. New values are assigned via IETF Review 658 (Section 4.8 of [RFC8126]). 660 The initial values to be assigned at the creation of the registry are 661 as follows: 663 +------+-----------------------+------------+ 664 | Code | Name | Reference | 665 +------+-----------------------+------------+ 666 | 1 | Access Available | [This-Doc] | 667 | 2 | Access Unavailable | [This-Doc] | 668 +------+-----------------------+------------+ 670 10. References 672 10.1. Normative References 674 [RFC1701] Hanks, S., Li, T., Farinacci, D., and P. Traina, "Generic 675 Routing Encapsulation (GRE)", RFC 1701, 676 DOI 10.17487/RFC1701, October 1994, 677 . 679 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 680 Requirement Levels", BCP 14, RFC 2119, 681 DOI 10.17487/RFC2119, March 1997, 682 . 684 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 685 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 686 May 2017, . 688 [TS23501] 3GPP (3rd Generation Partnership Project), "Technical 689 Specification Group Services and System Aspects; System 690 Architecture for the 5G System; Stage 2 (Release 16)", 691 3GPP TS23501, 2019. 693 10.2. Informative References 695 [I-D.deconinck-quic-multipath] 696 Coninck, Q. and O. Bonaventure, "Multipath Extensions for 697 QUIC (MP-QUIC)", draft-deconinck-quic-multipath-04 (work 698 in progress), March 2020. 700 [I-D.ietf-quic-tls] 701 Thomson, M. and S. Turner, "Using TLS to Secure QUIC", 702 draft-ietf-quic-tls-29 (work in progress), June 2020. 704 [I-D.ietf-quic-transport] 705 Iyengar, J. and M. Thomson, "QUIC: A UDP-Based Multiplexed 706 and Secure Transport", draft-ietf-quic-transport-29 (work 707 in progress), June 2020. 709 [I-D.pauly-quic-datagram] 710 Pauly, T., Kinnear, E., and D. Schinazi, "An Unreliable 711 Datagram Extension to QUIC", draft-pauly-quic-datagram-05 712 (work in progress), November 2019. 714 [I-D.schinazi-masque] 715 Schinazi, D., "The MASQUE Protocol", draft-schinazi- 716 masque-02 (work in progress), January 2020. 718 [IANA-ETHER-TYPES] 719 "IANA ETHER TYPES", https://www.iana.org/assignments/ieee- 720 802-numbers/ieee-802-numbers.txt , n.d.. 722 [RFC1812] Baker, F., Ed., "Requirements for IP Version 4 Routers", 723 RFC 1812, DOI 10.17487/RFC1812, June 1995, 724 . 726 [RFC2827] Ferguson, P. and D. Senie, "Network Ingress Filtering: 727 Defeating Denial of Service Attacks which employ IP Source 728 Address Spoofing", BCP 38, RFC 2827, DOI 10.17487/RFC2827, 729 May 2000, . 731 [RFC6824] Ford, A., Raiciu, C., Handley, M., and O. Bonaventure, 732 "TCP Extensions for Multipath Operation with Multiple 733 Addresses", RFC 6824, DOI 10.17487/RFC6824, January 2013, 734 . 736 [RFC6887] Wing, D., Ed., Cheshire, S., Boucadair, M., Penno, R., and 737 P. Selkirk, "Port Control Protocol (PCP)", RFC 6887, 738 DOI 10.17487/RFC6887, April 2013, 739 . 741 [RFC7301] Friedl, S., Popov, A., Langley, A., and E. Stephan, 742 "Transport Layer Security (TLS) Application-Layer Protocol 743 Negotiation Extension", RFC 7301, DOI 10.17487/RFC7301, 744 July 2014, . 746 [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for 747 Writing an IANA Considerations Section in RFCs", BCP 26, 748 RFC 8126, DOI 10.17487/RFC8126, June 2017, 749 . 751 [Transparent-Ethernet-Bridging] 752 Hanks, S., Li, T., Farinacci, D., and P. Traina, "Generic 753 Routing Encapsulation (GRE)", RFC 1701, 754 DOI 10.17487/RFC1701, October 1994, 755 . 757 Appendix A. Change Log 759 A.1. Since draft-piraux-quic-tunnel-02 761 o Add the lightweight mode 763 A.2. Since draft-piraux-quic-tunnel-01 765 o Add the Access Report TLV for reporting access networks 766 availability 768 o Add a section with examples of use of the Packet Tag 770 A.3. Since draft-piraux-quic-tunnel-00 772 o Separate the document in two and put the stream mode in another 773 document 775 o Remove TCP Extended TLV 777 o Add a mechanism for joining QUIC connections in a QUIC tunneling 778 session 780 o Add a format for encoding any network-layer protocol packets and 781 Ethernet frames in QUIC DATAGRAM frames 783 Acknowledgments 785 Thanks to Quentin De Coninck and Francois Michel for their comments 786 and the proofreading of the first version of this document. Thanks 787 to Gregory Vander Schueren for his comments on the first version of 788 this document. 790 Authors' Addresses 792 Maxime Piraux 793 UCLouvain 795 Email: maxime.piraux@uclouvain.be 797 Olivier Bonaventure 798 UCLouvain 800 Email: olivier.bonaventure@uclouvain.be 802 Adi Masputra 803 Apple Inc. 805 Email: adi@apple.com