idnits 2.17.1 draft-piraux-quic-tunnel-02.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 (July 13, 2020) is 1383 days in the past. Is this intentional? Checking references for intended status: Experimental ---------------------------------------------------------------------------- == Missing Reference: 'This-Doc' is mentioned on line 641, but not defined == Unused Reference: 'RFC1701' is defined on line 648, 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: January 14, 2021 A. Masputra 6 Apple Inc. 7 July 13, 2020 9 Tunneling Internet protocols inside QUIC 10 draft-piraux-quic-tunnel-02 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 January 14, 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 datagram mode . . . . . . . . . . . . . . . . . . . . . . 6 56 5. Connection establishment . . . . . . . . . . . . . . . . . . 8 57 6. Joining a tunneling session . . . . . . . . . . . . . . . . . 8 58 6.1. Coordinate use of the Packet Tag in datagram mode . . . . 8 59 7. Messages format . . . . . . . . . . . . . . . . . . . . . . . 9 60 7.1. QUIC tunnel control TLVs . . . . . . . . . . . . . . . . 9 61 7.1.1. New Session TLV . . . . . . . . . . . . . . . . . . . 10 62 7.1.2. Session ID TLV . . . . . . . . . . . . . . . . . . . 10 63 7.1.3. Join Session TLV . . . . . . . . . . . . . . . . . . 11 64 7.1.4. Access Report TLV . . . . . . . . . . . . . . . . . . 12 65 8. Security Considerations . . . . . . . . . . . . . . . . . . . 13 66 8.1. Privacy . . . . . . . . . . . . . . . . . . . . . . . . . 13 67 8.2. Ingress Filtering . . . . . . . . . . . . . . . . . . . . 13 68 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 69 9.1. Registration of QUIC tunnel Identification String . . . . 13 70 9.2. QUIC tunnel control TLVs . . . . . . . . . . . . . . . . 13 71 9.2.1. QUIC tunnel control TLVs Types . . . . . . . . . . . 13 72 9.3. QUIC tunnel control Error Codes . . . . . . . . . . . . . 14 73 9.4. QUIC tunnel Access Report Signal Codes . . . . . . . . . 14 74 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 15 75 10.1. Normative References . . . . . . . . . . . . . . . . . . 15 76 10.2. Informative References . . . . . . . . . . . . . . . . . 15 77 Appendix A. Change Log . . . . . . . . . . . . . . . . . . . . . 16 78 A.1. Since draft-piraux-quic-tunnel-01 . . . . . . . . . . . . 16 79 A.2. Since draft-piraux-quic-tunnel-00 . . . . . . . . . . . . 17 80 Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 17 81 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 17 83 1. Introduction 85 Mobile devices such as laptops, smartphones or tablets have different 86 requirements than the traditional fixed devices. These mobile 87 devices often change their network attachment. They are often 88 attached to trusted networks, but sometimes they need to be connected 89 to untrusted networks where their communications can be eavesdropped, 90 filtered or modified. In these situations, the classical approach is 91 to rely on VPN protocols such as DTLS or IPSec. These VPN protocols 92 provide the encryption and authentication functions to protect those 93 mobile clients from malicious behaviors in untrusted networks. 95 However, some networks have deployed filters that block these VPN 96 protocols. When faced with such filters, users can either switch off 97 their connection or find alternatives, e.g. by using TLS to access 98 some services over TCP port 443. The planned deployment of QUIC 99 [I-D.ietf-quic-transport] [I-D.ietf-quic-tls] opens a new opportunity 100 for such users. Since QUIC will be used to access web sites, it 101 should be less affected by filters than VPN solutions such as IPSec 102 or DTLS. Furthermore, the flexibility of QUIC makes it possible to 103 easily extend the protocol to support VPN services. 105 This document shares some goals with the MASQUE framework 106 [I-D.schinazi-masque]. The proposed QUIC tunnel protocol contributes 107 to the effort of defining a signaling for conveying multiple proxied 108 flows inside a QUIC connection. While this document specifies its 109 own protocol, further work could adapt the mechanisms presented in 110 this proposal to use HTTP/3. 112 On the other hand, today's mobile devices are often multihomed and 113 many expect to be able to perform seamless handovers from one access 114 network to another without breaking the established VPN sessions. In 115 some situations it can also be beneficial to combine two or more 116 access networks together to increase the available host bandwidth. A 117 protocol such as Multipath TCP [RFC6824] supports those handovers and 118 allows aggregating the bandwidth of different access links. It could 119 be combined with single-path VPN protocols to support both seamless 120 handovers and bandwidth aggregation above VPN tunnels. 121 Unfortunately, Multipath TCP is not yet deployed on most Internet 122 servers and thus few applications would benefit from such a use case. 124 In this document, we explore how QUIC could be used to enable multi- 125 homed mobile devices to communicate securely in untrusted networks. 126 The QUIC protocol opens up a new way to find a clean solution to this 127 problem. First, QUIC includes the same encryption and authentication 128 techniques as deployed VPN protocols. Second, QUIC is intended to be 129 widely used to support web-based services, making it unlikely to be 130 filtered in many networks, in contrast with VPN protocols. Third, 131 the QUIC migration mechanism enables handovers between several 132 network interfaces. 134 This document is organized as follows. Section 3 describes our 135 reference environment. Then, we propose a first mode of operation, 136 explained in Section 4, that uses the recently proposed datagram 137 extension ([I-D.pauly-quic-datagram]) for QUIC to transport plain IP 138 packets over a QUIC connection. Section 5 specifies how a connection 139 is established in this document proposal. Section 7 details the 140 format of the messages introduced by this document. 142 2. Conventions and Definitions 144 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 145 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 146 "OPTIONAL" in this document are to be interpreted as described in BCP 147 14 [RFC2119] [RFC8174] when, and only when, they appear in all 148 capitals, as shown here. 150 3. Reference environment 152 Our first scenario is a client that uses a QUIC tunnel to send all 153 its packets to a concentrator. The concentrator decrypts the packets 154 received over the QUIC connection and forwards them to their final 155 destination. It also receives the packets destined to the client and 156 tunnels them through the QUIC connection. 158 +-------------+ 159 +--------+ +--------------+ | Final | 160 | Client | | Concentrator |<===\ ... \===>| destination | 161 +--------+ +--------------+ | server | 162 ^ +---------+ ^ +-------------+ 163 | | Access | | 164 | | network | | Legend: 165 .----| |----. --- QUIC connection 166 +---------+ === TCP/UDP flow 168 Figure 1: A client attached to a concentrator 170 However, there are several situations where the client is attached to 171 two or more access networks. This client can be multihomed, dual- 172 stack, ... This is illustrated in Figure 2, in which a client- 173 initiated flow is tunneled through the concentrator. We also discuss 174 inbound connections in this document in Section 5. 176 +---------+ 177 .----| Access |----. 178 | | network | | 179 | | A | | 180 v +---------- v +-------------+ 181 +--------+ +--------------+ | Final | 182 | Client | | Concentrator |<===\ ... \===>| destination | 183 +--------+ +--------------+ | server | 184 ^ +---------+ ^ +-------------+ 185 | | Access | | 186 | | network | | Legend: 187 .----| B |----. --- QUIC connection 188 +---------+ === TCP/UDP flow 190 Figure 2: Example environment 192 Such a client would like to benefit from the different access 193 networks available to reach the concentrator. These access networks 194 can be used for load-sharing, failover or other purposes. One 195 possibility to efficiently use these two access networks is to rely 196 on the proposed Multipath extensions to QUIC 197 [I-D.deconinck-quic-multipath]. Another approach is to create one 198 QUIC connection using the single-path QUIC protocol 199 [I-D.ietf-quic-transport] over each access network and glue these 200 different sessions together on the concentrator. Given the migration 201 capabilities of QUIC, this approach could support failover with a 202 single active QUIC connection at a time. 204 In a nutshell, the solution proposed in this document works as 205 follows. The client opens a QUIC connection to a concentrator. The 206 concentrator authenticates the client through means that are outside 207 the scope of this document such as client certificates, usernames/ 208 passwords, OAuth, ... If the authentication succeeds, the client can 209 use the tunnel to exchange Ethernet frames or IP packets with the 210 concentrator over the QUIC session. If the client uses IP, then the 211 concentrator can allocate an IP address to the client at the end of 212 the authentication phase. The client can then send packets via the 213 concentrator by tunneling them through the concentrator. The 214 concentrator captures the IP packets destined to the client and 215 tunnels them over the QUIC connection. 217 If the client is multihomed, it can use Multipath QUIC 218 [I-D.deconinck-quic-multipath] to efficiently use its different 219 access networks. This version of the document does not elaborate in 220 details on this possibility. If the concentrator does not support 221 Multipath QUIC, then the client creates several QUIC connections and 222 joins them at the application layer. This works as illustrated in 223 figure Figure 3. Each message is exchanged over a dedicated 224 unidirectional QUIC stream. Their format is detailed in Section 7. 225 When the client opens the first QUIC connection with the 226 concentrator, (1) it can request a QUIC tunnel session identifier. 227 (2) The concentrator replies with a variable-length opaque value that 228 identifies the QUIC tunneling session. When opening a QUIC 229 connection over another access network, (3) the client can send this 230 identifier to join the QUIC tunneling session. The concentrator 231 matches the session identifier with the existing session with the 232 client. It can then use both sessions to reach the client and 233 received tunneled packets from the client. 235 1-Req. Sess. ID-> 236 .-----------------------------. 237 | <-Sess. ID.-2 | 238 v v 239 +--------+ +--------------+ 240 | Client | | Concentrator | 241 +--------+ +--------------+ 242 ^ ^ 243 | 3-Join. Sess.-> | Legend: 244 .-----------------------------. --- QUIC connection 246 Figure 3: Creating sessions over different access networks 248 4. The datagram mode 250 Our first mode of operation, called the datagram mode in this 251 document, enables the client and the concentrator to exchange raw 252 packets through the QUIC connection. This is done by using the 253 recently proposed QUIC datagram extension [I-D.pauly-quic-datagram]. 254 In a nutshell, to send a packet to a remote host, the client simply 255 passes the entire packet as a datagram to the QUIC connection 256 established with the concentrator. 258 This document specifies the following format for encoding packets in 259 QUIC DATAGRAM frame. It allows encoding packets from several 260 protocols by identifying the corresponding protocol of the packet in 261 each QUIC DATAGRAM frame. Figure 4 describes this encoding. 263 1 2 3 264 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 265 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 266 | Protocol Type (16) | Packet Tag (16) | 267 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 268 | Packet (*) ... 269 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 271 Figure 4: Encoding packets in QUIC DATAGRAM frame 273 This encoding defines three fields. 275 o Protocol Type: The Protocol Type field contains the protocol type 276 of the payload packet. The values for the different protocols are 277 defined as "ETHER TYPES" in [IANA-ETHER-TYPES]. A QUIC tunnel 278 that receives a Protocol Type representing an unsupported protocol 279 MAY drop the associated Packet. QUIC tunnel endpoints willing to 280 exchange Ethernet frames can use the value 0x6558 for 281 [Transparent-Ethernet-Bridging]. 283 o Packet Tag: An opaque 16-bit value. The QUIC tunnel application 284 is free to decide its semantic value. For instance, a QUIC tunnel 285 endpoint MAY encode the sending order of packets in the Packet 286 Tag, e.g. as a timestamp or a sequence number, to allow reordering 287 on the receiver. 289 o Packet: The packet conveyed inside the QUIC tunnel connection. 291 This encoding is sent inside a QUIC DATAGRAM frame, which is then 292 encrypted and authenticated in a QUIC packet. This transmission is 293 subject to congestion control, but the frame that contains the packet 294 is not retransmitted in case of losses as specified in 295 [I-D.pauly-quic-datagram]. The datagram mode is intended to provide 296 a similar service as the one provided by IPSec tunnels or DTLS. 298 ,->+----------+ 299 | | IP | 300 QUIC packet | +----------+ 301 containing | | UDP | 302 a DATAGRAM | +----------+ 303 frame | | QUIC | 304 | |..........| 305 | | DATAGRAM | 306 | | P. Type | 307 | | P. Tag | 308 | |+--------+|<-. 309 | || IP || | 310 | |+--------+| | Tunneled 311 | || UDP || | UDP packet 312 | |+--------+| | 313 | | .... |<-. 314 `->+----------+ 316 Figure 5: QUIC packet sent by the client when tunneling a UDP packet 318 Figure 5 illustrates how a UDP packet is tunneled using the datagram 319 mode. The main advantage of the datagram mode is that it supports IP 320 and any protocol above the network layer. Any IP packet can be 321 transported using the datagram extension over a QUIC connection. 322 However, this advantage comes with a large per-packet overhead since 323 each packet contains both a network and a transport header. All 324 these headers must be transmitted in addition with the IP/UDP/QUIC 325 headers of the QUIC connection. For TCP connections for instance, 326 the per-packet overhead can be large. 328 5. Connection establishment 330 During connection establishment, the QUIC tunnel support is indicated 331 by setting the ALPN token "qt" in the TLS handshake. Draft-version 332 implementations MAY specify a particular draft version by suffixing 333 the token, e.g. "qt-00" refers to the first version of this document. 335 After the QUIC connection is established, the client can start using 336 the datagram or the stream mode. The client may use PCP [RFC6887] to 337 request the concentrator to accept inbound connections on their 338 behalf. After the negotiation of such port mappings, the 339 concentrator can start sending packets containing inbound connections 340 in QUIC DATAGRAM frame. 342 Both QUIC tunnel endpoints open their first unidirectional stream 343 (i.e. stream 2 and 3), hereafter named the QUIC tunnel control 344 stream. A QUIC tunnel endpoint MUST NOT close its unidirectional 345 stream and SHOULD provide enough flow control credit to its peer. 347 6. Joining a tunneling session 349 Joining a tunneling session allows grouping several QUIC connections 350 to the concentrator. Each endpoint can then coordinate the use of 351 the Packet Tag across the tunneling session as presented in 352 Section 6.1. 354 The messages used for this purpose are described in Section 7. The 355 QUIC tunnel control stream is used to convey these messages and 356 establish the negotiation of a tunneling session. The client 357 initiates the procedure and MAY either start a new session or join an 358 existing session. This negotiation MUST NOT take place more than 359 once per QUIC connection. 361 6.1. Coordinate use of the Packet Tag in datagram mode 363 When using the datagram mode, each packet is associated with a 16-bit 364 value called Packet Tag. This document leaves defining the meaning of 365 this value to implementations. This section provides some examples 366 on how it can be used to implement packet reordering across several 367 QUIC tunnel connections grouped in a tunneling session. 369 A first simple example of use is to encode the timestamp at which the 370 datagram was sent. Using a millisecond precision and encoding the 16 371 lower bits of the timestamp makes the value wrapping around in a bit 372 more than 65 seconds. 374 Another example of use is to maintain a value counting the datagrams 375 sent over all QUIC tunnel connections of the tunneling session. The 376 16-bit value allows distinguishing at most 32768 packets in flight. 378 The QUIC tunnel receiver can then distinguish, buffer and reorder 379 packets based on this value. Mechanisms for managing the datagram 380 buffer and negotiating the use of the Packet Tag are out of scope of 381 this document. 383 7. Messages format 385 In the following sections, we specify the format of each message 386 introduced in this document. They are encoded as TLVs, i.e. (Type, 387 Length, Value) tuples, as illustrated in Figure 6. All TLV fields 388 are encoded in network-byte order. 390 1 2 3 391 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 392 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 393 | Type (8) | Length (8) | [Value (*)] ... 394 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 396 Figure 6: QUIC tunnel TLV Format 398 The Type field is encoded as a byte and identifies the type of the 399 TLV. The Length field is encoded as a byte and indicate the length 400 of the Value field. A value of zero indicates that no Value field is 401 present. The Value field is a type-specific value whose length is 402 determined by the Length field. 404 7.1. QUIC tunnel control TLVs 406 This document specifies the following QUIC tunnel control TLVs: 408 +------+----------+--------------+-------------------+ 409 | Type | Size | Sender | Name | 410 +------+----------+--------------+-------------------+ 411 | 0x00 | 2 bytes | Client | New Session TLV | 412 | 0x01 | Variable | Concentrator | Session ID TLV | 413 | 0x02 | Variable | Client | Join Session TLV | 414 | 0x03 | 4 bytes | Client | Access Report TLV | 415 +------+----------+--------------+-------------------+ 417 Figure 7: QUIC tunnel control TLVs 419 The New Session TLV is used by the client to initiate a new tunneling 420 session. The Session ID TLV is used by the concentrator to 421 communicate to the client the Session ID identifying this tunneling 422 session. The Join Session TLV is used to join a given tunneling 423 session, identified by a Session ID. All QUIC these tunnel control 424 TLVs MUST NOT be sent on other streams than the QUIC tunnel control 425 streams. 427 The Access Report TLV is sent by the client to periodically report on 428 access networks availability. Each Access Report TLV MUST be sent on 429 a separate unidirectional stream, other than the QUIC tunnel control 430 streams. 432 7.1.1. New Session TLV 434 The New Session TLV does not contain a value. It initiates a new 435 tunneling session at the concentrator. The concentrator MUST send a 436 Session ID TLV in response, with the Session ID corresponding to the 437 tunneling session created. After sending a New Session TLV, the 438 client MUST close the QUIC tunnel control stream. 440 The concentrator MUST NOT send New Session TLVs. 442 7.1.2. Session ID TLV 444 1 2 3 445 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 446 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 447 | Type (8) | Length (8) | Session ID (*) ... 448 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 450 Figure 8: Session ID TLV 452 The Session ID TLV contains an opaque value that identifies the 453 current tunneling session. It can be used by the client in 454 subsequent QUIC connections to join them to this tunneling session. 455 The concentrator MUST send a Session ID TLV in response of a New 456 Session TLV, with the Session ID corresponding to the tunneling 457 session created. 459 The client MUST NOT send a Session ID TLV. The concentrator MUST 460 close the QUIC tunnel control stream after sending a Session ID TLV. 462 7.1.3. Join Session TLV 464 1 2 3 465 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 466 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 467 | Type (8) | Length (8) | Session ID (*) ... 468 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 470 Figure 9: Join Session TLV 472 The Join Session TLV contains an opaque value that identifies a 473 tunneling session to join. The client can send a Join Session TLV to 474 join the QUIC connection to a particular tunneling session. The 475 tunneling session is identified by the Session ID. After sending a 476 Join Session TLV, the client MUST close the QUIC tunnel control 477 stream. 479 The concentrator MUST NOT send Join Session TLVs. After receiving a 480 Join Session TLV, the concentrator MUST use the Session ID to join 481 this QUIC connection to the tunneling session. Joining the tunneling 482 session implies merging the state of this QUIC tunnel connection to 483 the session. A successful joining of connection is indicated by the 484 closure of the QUIC tunnel control stream of the concentrator. 486 In cases of failure when joining a tunneling session, the 487 concentrator MUST send a RESET_STREAM with an application error code 488 discerning the cause of the failure. The possible codes are listed 489 below: 491 o UNKNOWN_ERROR (0x0): An unknown error occurred when joining the 492 tunneling session. QUIC tunnel endpoints SHOULD use more specific 493 error codes when applicable. 495 o UNKNOWN_SESSION_ID (0x1): The Session ID used in the Join Session 496 TLV is not a valid ID. It was not issued in a Session ID TLV or 497 refers to an expired tunneling session. 499 o CONFLICTING_STATE (0x2): The current state of the QUIC tunnel 500 connection could not be merged with the tunneling session. 502 7.1.4. Access Report TLV 504 1 2 3 505 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 506 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 507 | Type (8) | Length (8) | AI (4)| R (4) | Signal (8) | 508 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 510 Figure 10: Access Report TLV 512 The Access Report TLV contains the following: 514 o AI (Access ID) - a four-bit-long field that identifies the access 515 network, e.g., 3GPP (Radio Access Technologies specified by 3GPP) 516 or Non-3GPP (accesses that are not specified by 3GPP) [TS23501]. 517 The value is one of those listed below (all other values are 518 invalid and the TLV that contains it MUST be discarded): 520 +-----------+-----------------------+ 521 | Access ID | Description | 522 +-----------+-----------------------+ 523 | 1 | 3GPP Network | 524 | 2 | Non-3GPP Network | 525 +-----------+-----------------------+ 527 o R (Reserved) - a four-bit-long field that MUST be zeroed on 528 transmission and ignored on receipt. 530 o Signal - a one-octet-long field that identifies the report signal, 531 e.g., available or unavailable. The value is supplied to the QUIC 532 tunnel through some mechanism that is outside the scope of this 533 document. The value is one of those listed in Section 9.4. 535 The client that includes the Access Report TLV sets the value of the 536 Access ID field according to the type of access network it reports 537 on. Also, the client sets the value of the Signal field to reflect 538 the operational state of the access network. The mechanism to 539 determine the state of the access network is outside the scope of 540 this specification. 542 The client MUST be able to cancel the sending of an Access Report TLV 543 that is pending delivery, i.e. by resetting its corresponding 544 unidirectional stream. This can be used when the information 545 contained in the TLV is no longer relevant, e.g. the access network 546 availability has changed. The time of canceling is based on local 547 policies and network environment. 549 Reporting the unavailability an access network to the concentrator 550 can serve as an advisory signal to preventively stop sending packets 551 over this network while maintaining the QUIC tunnel connection. Upon 552 reporting of the availability of this network, the concentrator can 553 quickly resume sending packets over this network. 555 8. Security Considerations 557 8.1. Privacy 559 The Concentrator has access to all the packets it processes. It MUST 560 be protected as a core IP router, e.g. as specified in [RFC1812]. 562 8.2. Ingress Filtering 564 Ingress filtering policies MUST be enforced at the network 565 boundaries, i.e. as specified in [RFC2827]. 567 9. IANA Considerations 569 9.1. Registration of QUIC tunnel Identification String 571 This document creates a new registration for the identification of 572 the QUIC tunnel protocol in the "Application Layer Protocol 573 Negotiation (ALPN) Protocol IDs" registry established in [RFC7301]. 575 The "qt" string identifies the QUIC tunnel protocol. 577 Protocol: QUIC tunnel 579 Identification Sequence: 0x71 0x74 ("qt") 581 Specification: This document 583 9.2. QUIC tunnel control TLVs 585 IANA is requested to create a new "QUIC tunnel control Parameters" 586 registry. 588 The following subsections detail new registries within "QUIC tunnel 589 control Parameters" registry. 591 9.2.1. QUIC tunnel control TLVs Types 593 IANA is request to create the "QUIC tunnel control TLVs Types" sub- 594 registry. New values are assigned via IETF Review (Section 4.8 of 595 [RFC8126]). 597 The initial values to be assigned at the creation of the registry are 598 as follows: 600 +------+-----------------------+------------+ 601 | Code | Name | Reference | 602 +------+-----------------------+------------+ 603 | 0 | New Session TLV | [This-Doc] | 604 | 1 | Session ID TLV | [This-Doc] | 605 | 2 | Join Session TLV | [This-Doc] | 606 | 3 | Access Report TLV | [This-Doc] | 607 +------+-----------------------+------------+ 609 9.3. QUIC tunnel control Error Codes 611 This document establishes a registry for QUIC tunnel control stream 612 error codes. The "QUIC tunnel control Error Code" registry manages a 613 62-bit space. New values are assigned via IETF Review (Section 4.8 614 of [RFC8126]). 616 The initial values to be assigned at the creation of the registry are 617 as follows: 619 +------+-----------------------+------------+ 620 | Code | Name | Reference | 621 +------+-----------------------+------------+ 622 | 0 | UNKNOWN_ERROR | [This-Doc] | 623 | 1 | UNKNOWN_SESSION_ID | [This-Doc] | 624 | 2 | CONFLICTING_STATE | [This-Doc] | 625 +------+-----------------------+------------+ 627 9.4. QUIC tunnel Access Report Signal Codes 629 This document establishes a registry for QUIC tunnel Access Report 630 Signal codes. The "QUIC tunnel Access Report Signal Code" registry 631 manages a 62-bit space. New values are assigned via IETF Review 632 (Section 4.8 of [RFC8126]). 634 The initial values to be assigned at the creation of the registry are 635 as follows: 637 +------+-----------------------+------------+ 638 | Code | Name | Reference | 639 +------+-----------------------+------------+ 640 | 1 | Access Available | [This-Doc] | 641 | 2 | Access Unavailable | [This-Doc] | 642 +------+-----------------------+------------+ 644 10. References 646 10.1. Normative References 648 [RFC1701] Hanks, S., Li, T., Farinacci, D., and P. Traina, "Generic 649 Routing Encapsulation (GRE)", RFC 1701, 650 DOI 10.17487/RFC1701, October 1994, 651 . 653 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 654 Requirement Levels", BCP 14, RFC 2119, 655 DOI 10.17487/RFC2119, March 1997, 656 . 658 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 659 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 660 May 2017, . 662 [TS23501] 3GPP (3rd Generation Partnership Project), "Technical 663 Specification Group Services and System Aspects; System 664 Architecture for the 5G System; Stage 2 (Release 16)", 665 3GPP TS23501, 2019. 667 10.2. Informative References 669 [I-D.deconinck-quic-multipath] 670 Coninck, Q. and O. Bonaventure, "Multipath Extensions for 671 QUIC (MP-QUIC)", draft-deconinck-quic-multipath-04 (work 672 in progress), March 2020. 674 [I-D.ietf-quic-tls] 675 Thomson, M. and S. Turner, "Using TLS to Secure QUIC", 676 draft-ietf-quic-tls-29 (work in progress), June 2020. 678 [I-D.ietf-quic-transport] 679 Iyengar, J. and M. Thomson, "QUIC: A UDP-Based Multiplexed 680 and Secure Transport", draft-ietf-quic-transport-29 (work 681 in progress), June 2020. 683 [I-D.pauly-quic-datagram] 684 Pauly, T., Kinnear, E., and D. Schinazi, "An Unreliable 685 Datagram Extension to QUIC", draft-pauly-quic-datagram-05 686 (work in progress), November 2019. 688 [I-D.schinazi-masque] 689 Schinazi, D., "The MASQUE Protocol", draft-schinazi- 690 masque-02 (work in progress), January 2020. 692 [IANA-ETHER-TYPES] 693 "IANA ETHER TYPES", https://www.iana.org/assignments/ieee- 694 802-numbers/ieee-802-numbers.txt , n.d.. 696 [RFC1812] Baker, F., Ed., "Requirements for IP Version 4 Routers", 697 RFC 1812, DOI 10.17487/RFC1812, June 1995, 698 . 700 [RFC2827] Ferguson, P. and D. Senie, "Network Ingress Filtering: 701 Defeating Denial of Service Attacks which employ IP Source 702 Address Spoofing", BCP 38, RFC 2827, DOI 10.17487/RFC2827, 703 May 2000, . 705 [RFC6824] Ford, A., Raiciu, C., Handley, M., and O. Bonaventure, 706 "TCP Extensions for Multipath Operation with Multiple 707 Addresses", RFC 6824, DOI 10.17487/RFC6824, January 2013, 708 . 710 [RFC6887] Wing, D., Ed., Cheshire, S., Boucadair, M., Penno, R., and 711 P. Selkirk, "Port Control Protocol (PCP)", RFC 6887, 712 DOI 10.17487/RFC6887, April 2013, 713 . 715 [RFC7301] Friedl, S., Popov, A., Langley, A., and E. Stephan, 716 "Transport Layer Security (TLS) Application-Layer Protocol 717 Negotiation Extension", RFC 7301, DOI 10.17487/RFC7301, 718 July 2014, . 720 [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for 721 Writing an IANA Considerations Section in RFCs", BCP 26, 722 RFC 8126, DOI 10.17487/RFC8126, June 2017, 723 . 725 [Transparent-Ethernet-Bridging] 726 Hanks, S., Li, T., Farinacci, D., and P. Traina, "Generic 727 Routing Encapsulation (GRE)", RFC 1701, 728 DOI 10.17487/RFC1701, October 1994, 729 . 731 Appendix A. Change Log 733 A.1. Since draft-piraux-quic-tunnel-01 735 o Adds the Access Report TLV for reporting access networks 736 availability 738 o Adds a section with examples of use of the Packet Tag 740 A.2. Since draft-piraux-quic-tunnel-00 742 o Separate the document in two and put the stream mode in another 743 document 745 o Remove TCP Extended TLV 747 o Add a mechanism for joining QUIC connections in a QUIC tunneling 748 session 750 o Add a format for encoding any network-layer protocol packets and 751 Ethernet frames in QUIC DATAGRAM frames 753 Acknowledgments 755 Thanks to Quentin De Coninck and Francois Michel for their comments 756 and the proofreading of the first version of this document. Thanks 757 to Gregory Vander Schueren for his comments on the first version of 758 this document. 760 Authors' Addresses 762 Maxime Piraux 763 UCLouvain 765 Email: maxime.piraux@uclouvain.be 767 Olivier Bonaventure 768 UCLouvain 770 Email: olivier.bonaventure@uclouvain.be 772 Adi Masputra 773 Apple Inc. 775 Email: adi@apple.com