idnits 2.17.1 draft-piraux-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 (November 04, 2019) is 1633 days in the past. Is this intentional? Checking references for intended status: Experimental ---------------------------------------------------------------------------- == Missing Reference: 'This-Doc' is mentioned on line 609, but not defined == Unused Reference: 'I-D.ietf-lpwan-ipv6-static-context-hc' is defined on line 646, but no explicit reference was found in the text == Unused Reference: 'RFC3095' is defined on line 677, but no explicit reference was found in the text == Unused Reference: 'RFC3843' is defined on line 685, but no explicit reference was found in the text == Unused Reference: 'RFC4019' is defined on line 690, but no explicit reference was found in the text == Unused Reference: 'RFC4815' is defined on line 695, but no explicit reference was found in the text == Unused Reference: 'RFC6846' is defined on line 701, but no explicit reference was found in the text == Outdated reference: A later version (-07) exists of draft-deconinck-quic-multipath-03 == Outdated reference: A later version (-24) exists of draft-ietf-lpwan-ipv6-static-context-hc-22 == Outdated reference: A later version (-34) exists of draft-ietf-quic-transport-23 == Outdated reference: A later version (-19) exists of draft-ietf-tcpm-converters-13 == Outdated reference: A later version (-05) exists of draft-pauly-quic-datagram-04 Summary: 0 errors (**), 0 flaws (~~), 13 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 QUIC Working Group M. Piraux, Ed. 3 Internet-Draft O. Bonaventure 4 Intended status: Experimental UCLouvain 5 Expires: May 7, 2020 November 04, 2019 7 Tunneling Internet protocols inside QUIC 8 draft-piraux-quic-tunnel-00 10 Abstract 12 This document specifies methods for tunneling Internet protocols such 13 as TCP, UDP, IP and QUIC inside a QUIC connection. 15 Status of This Memo 17 This Internet-Draft is submitted in full conformance with the 18 provisions of BCP 78 and BCP 79. 20 Internet-Drafts are working documents of the Internet Engineering 21 Task Force (IETF). Note that other groups may also distribute 22 working documents as Internet-Drafts. The list of current Internet- 23 Drafts is at https://datatracker.ietf.org/drafts/current/. 25 Internet-Drafts are draft documents valid for a maximum of six months 26 and may be updated, replaced, or obsoleted by other documents at any 27 time. It is inappropriate to use Internet-Drafts as reference 28 material or to cite them other than as "work in progress." 30 This Internet-Draft will expire on May 7, 2020. 32 Copyright Notice 34 Copyright (c) 2019 IETF Trust and the persons identified as the 35 document authors. All rights reserved. 37 This document is subject to BCP 78 and the IETF Trust's Legal 38 Provisions Relating to IETF Documents 39 (https://trustee.ietf.org/license-info) in effect on the date of 40 publication of this document. Please review these documents 41 carefully, as they describe your rights and restrictions with respect 42 to this document. Code Components extracted from this document must 43 include Simplified BSD License text as described in Section 4.e of 44 the Trust Legal Provisions and are provided without warranty as 45 described in the Simplified BSD License. 47 Table of Contents 49 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 50 2. Conventions and Definitions . . . . . . . . . . . . . . . . . 3 51 3. Reference environment . . . . . . . . . . . . . . . . . . . . 4 52 4. The datagram mode . . . . . . . . . . . . . . . . . . . . . . 4 53 5. The stream mode . . . . . . . . . . . . . . . . . . . . . . . 5 54 6. Connection establishment . . . . . . . . . . . . . . . . . . 6 55 7. Messages format . . . . . . . . . . . . . . . . . . . . . . . 7 56 7.1. QUIC tunnel stream TLVs . . . . . . . . . . . . . . . . . 7 57 7.1.1. TCP Connect TLV . . . . . . . . . . . . . . . . . . . 8 58 7.1.2. TCP Extended Connect TLV . . . . . . . . . . . . . . 9 59 7.1.3. TCP Connect OK TLV . . . . . . . . . . . . . . . . . 10 60 7.1.4. Error TLV . . . . . . . . . . . . . . . . . . . . . . 10 61 7.1.5. End TLV . . . . . . . . . . . . . . . . . . . . . . . 11 62 8. Example flows . . . . . . . . . . . . . . . . . . . . . . . . 11 63 9. Security Considerations . . . . . . . . . . . . . . . . . . . 12 64 9.1. Privacy . . . . . . . . . . . . . . . . . . . . . . . . . 12 65 9.2. Ingress Filtering . . . . . . . . . . . . . . . . . . . . 12 66 9.3. Denial of Service . . . . . . . . . . . . . . . . . . . . 13 67 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 68 10.1. Registration of QUIC tunnel Identification String . . . 13 69 10.2. QUIC tunnel stream TLVs . . . . . . . . . . . . . . . . 13 70 10.2.1. QUIC tunnel stream TLVs Types . . . . . . . . . . . 13 71 10.2.2. QUIC tunnel streams TLVs Error Types . . . . . . . . 14 72 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 14 73 11.1. Normative References . . . . . . . . . . . . . . . . . . 14 74 11.2. Informative References . . . . . . . . . . . . . . . . . 15 75 Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 17 76 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 17 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, TLS or IPSec. These VPN 87 protocols provide the encryption and authentication functions to 88 protect those mobile clients from malicious behaviors in untrusted 89 networks. 91 On the other hand, these devices are often multihomed and many expect 92 to be able to perform seamless handovers from one access network to 93 another without breaking the established VPN sessions. In some 94 situations it can also be beneficial to combine two or more access 95 networks together to increase the available host bandwidth. A 96 protocol such as Multipath TCP supports those handovers and allows 97 aggregating the bandwidth of different access links. It could be 98 combined with single-path VPN protocols to support both seamless 99 handovers and bandwidth aggregation above VPN tunnels. 100 Unfortunately, Multipath TCP is not yet deployed on most Internet 101 servers and thus few applications would benefit from such a use case. 103 The QUIC protocol opens up a new way to find a clean solution to this 104 problem. First, QUIC includes the same encryption and authentication 105 techniques as deployed VPN protocols. Second, QUIC is intended to be 106 widely used to support web-based services, making it unlikely to be 107 filtered in many networks, in contrast with VPN protocols. Third, 108 the multipath extensions proposed for QUIC enable it to efficiently 109 support both seamless handovers and bandwidth aggregation. 111 In this document, we explore how (Multipath) QUIC could be used to 112 enable multi-homed mobile devices to communicate securely in 113 untrusted networks. Section 3 describes the reference environment of 114 this document. Then, we explore and compare two different designs. 115 The first, explained in Section 4, uses the recently proposed 116 datagram extension ([I-D.pauly-quic-datagram]) for QUIC to transport 117 plain IP packets over a Multipath QUIC connection. The second, 118 explained in Section 5, uses the QUIC streams to transport TCP 119 bytestreams over a Multipath QUIC connection. 121 Section 6 specifies how a connection is established in this document 122 proposal. Section 7 specifies the format of the messages introduced 123 by this document. Section 8 contains example flows. 125 Our starting point for this work is Multipath QUIC that was initially 126 proposed in [CoNEXT]. A detailed specification of Multipath QUIC may 127 be found in [I-D.deconinck-quic-multipath]. Two implementations of 128 different versions of this protocol are available [CoNEXT], 129 [SIGCOMM19]. 131 2. Conventions and Definitions 133 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 134 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 135 "OPTIONAL" in this document are to be interpreted as described in BCP 136 14 [RFC2119] [RFC8174] when, and only when, they appear in all 137 capitals, as shown here. 139 3. Reference environment 141 We consider a multihomed client that is attached to one or several 142 access networks. It establishes a Multipath QUIC connection to a 143 concentrator. This MPQUIC connection is used to carry the UDP and 144 TCP packets sent by the client. Thanks to the security mechanisms 145 used by the Multipath QUIC connection, the client data is protected 146 against attacks in one or both of the access networks. The client 147 trusts the concentrator. The concentrator decrypts the QUIC packets 148 exchanged over the Multipath QUIC connection and interacts with the 149 remote hosts as a VPN concentrator would do. 151 +---------+ 152 .----| Access |----. 153 | | network | | 154 v | A | | 155 +--------+ +---------- v +-------------+ 156 | Multi | +--------------+ | Final | 157 | homed | | Concentrator |<===\ ... \===>| destination | 158 | client | +--------------+ | server | 159 +--------+ +---------+ ^ +-------------+ 160 ^ | Access | | 161 | | network | | Legend: 162 .----| B |----. --- Multipath QUIC subflow 163 +---------+ === TCP/UDP flow 165 Figure 1: Example environment 167 Figure 1 illustrates a client-initiated flow. We also discuss 168 inbound connections in this document in Section 6. 170 4. The datagram mode 172 Our first mode of operation, called the datagram mode in this 173 document, enables the client and the concentrator to exchange raw IP 174 packets through the Multipath QUIC connection. This is done by using 175 the recently proposed QUIC datagram extension 176 [I-D.pauly-quic-datagram]. In a nutshell, to send an IP packet to a 177 remote host, the client simply passes the entire packet as a datagram 178 to the Multipath QUIC connection established with the concentrator. 179 The IP packet is encoded in a QUIC DATAGRAM frame, then encrypted and 180 authenticated in a QUIC packet. This transmission is subject to 181 congestion control, but the datagram that contains the packet is not 182 retransmitted in case of losses as specified in 183 [I-D.pauly-quic-datagram]. The datagram mode is intended to provide 184 a similar service as the one provided by IPSec tunnels or DTLS. 186 ,->+----------+ 187 | | IP | 188 QUIC packet | +----------+ 189 containing | | UDP | 190 a DATAGRAM | +----------+ 191 frame | | QUIC | 192 | |..........| 193 | | DATAGRAM | 194 | |+--------+|<-. 195 | || IP || | 196 | |+--------+| | Tunneled 197 | || UDP || | UDP packet 198 | |+--------+| | 199 | | .... |<-. 200 `->+----------+ 202 Figure 2: QUIC packet sent by the client when tunneling a UDP packet 204 Figure 2 illustrates how a UDP packet is tunneled using the datagram 205 mode. The main advantage of the datagram mode is that it supports IP 206 and any protocol above the network layer. Any IP packet can be 207 transported using the datagram extension over a Multipath QUIC 208 connection. However, this advantage comes with a large per-packet 209 overhead since each packet contains both a network and a transport 210 header. All these headers must be transmitted in addition with the 211 IP/UDP/QUIC headers of the Multipath QUIC connection. For TCP 212 connections for instance, the per-packet overhead can be large. 214 5. The stream mode 216 Since QUIC support multiple streams, another possibility to carry the 217 data exchanged over TCP connections between the client and the 218 concentrator is to transport the bytestream of each TCP connection as 219 one of the bidirectional streams of the Multipath QUIC connection. 220 For this, we base our approach on the 0-RTT Converter protocol 221 [I-D.ietf-tcpm-converters] that was proposed to ease the deployment 222 of TCP extensions. In a nutshell, it is an application proxy that 223 converts TCP connections, allowing the use of new TCP extensions 224 through an intermediate relay. 226 We use a similar approach in our stream mode. When a client opens a 227 stream, it sends at the beginning of the bytestream one or more TLV 228 messages indicating the IP address and port number of the remote 229 destination of the bytestream. Their format is detailed in section 230 Section 7.1. Upon reception of such a TLV message, the concentrator 231 opens a TCP connection towards the specified destination and connects 232 the incoming bytestream of the Multipath QUIC connection to the 233 bytestream of the new TCP connection (and similarly in the opposite 234 direction). 236 Figure 3 summarizes how the new TCP connection is mapped to the QUIC 237 stream. Actions and events of a TCP connection are translated to 238 action and events of a QUIC stream, so that a state transition of one 239 is translated to the other. 241 +------------------+-------------------------+ 242 | TCP | QUIC Stream | 243 +------------------+-------------------------+ 244 | SYN received | Open Stream, send TLVs | 245 | FIN received | Send Stream FIN | 246 | RST received | Send STOP_SENDING | 247 | | Send RESET_STREAM | 248 | Data received | Send Stream data | 249 +------------------+-------------------------+ 251 +-------------------------------+------------+ 252 | QUIC Stream | TCP | 253 +-------------------------------+------------+ 254 | Stream opened, TLVs received | Send SYN | 255 | Stream FIN received | Send FIN | 256 | STOP_SENDING received | Send RST | 257 | RESET_STREAM received | Send RST | 258 | Stream data received | Send data | 259 +-------------------------------+------------+ 261 Figure 3: TCP connection to QUIC stream mapping 263 The QUIC stream-level flow control can be tuned to match the receive 264 window size of the corresponding TCP, so that no excessive data needs 265 to be buffered. 267 6. Connection establishment 269 The client MUST establish a connection using the Multipath Extensions 270 defined in [I-D.deconinck-quic-multipath]. 272 During connection establishment, the QUIC tunnel support is indicated 273 by setting the ALPN token "qt" in the TLS handshake. Draft-version 274 implementations MAY specify a particular draft version by suffixing 275 the token, e.g. "qt-00" refers to the first version of this document. 277 The concentrator can control the number of connections bytestreams 278 that can be opened initially by setting the initial_max_streams_bidi 279 QUIC transport parameter as defined in [I-D.ietf-quic-transport]. 281 After the QUIC connection is established, the client can start using 282 the datagram or the stream mode. The client may use PCP [RFC6887] to 283 request the concentrator to accept inbound connections on their 284 behalf. After the negotiation of such port mappings, the 285 concentrator can start opening bidirectional streams to forward 286 inbound connections as well as sending IP packets containing inbound 287 UDP connections in QUIC datagrams. 289 7. Messages format 291 In the following sections, we specify the format of each message 292 introduced in this document. They are encoded as TLVs, i.e. (Type, 293 Length, Value) tuples, as illustrated in Figure 4. All TLV fields 294 are encoded in network-byte order. 296 1 2 3 297 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 298 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 299 | Type (8) | Length (8) | [Value (*)] ... 300 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 302 Figure 4: QUIC tunnel TLV Format 304 The Type field is encoded as a byte and identifies the type of the 305 TLV. The Length field is encoded as a byte and indicate the length 306 of the Value field. A value of zero indicates that no Value field is 307 present. The Value field is a type-specific value whose length is 308 determined by the Length field. 310 7.1. QUIC tunnel stream TLVs 312 When using the stream mode, a one or more messages are used to 313 trigger and confirm the establishment of a connection towards the 314 final destination for a given stream. Those messages are exchanged 315 on this given QUIC stream before the TCP connection bytestream. This 316 section describes the format of these messages. 318 This document specifies the following QUIC tunnel stream TLVs: 320 +------+----------+-----------------------------+ 321 | Type | Size | Name | 322 +------+----------+-----------------------------+ 323 | 0x00 | 20 bytes | TCP Connect TLV | 324 | 0x01 | 38 bytes | TCP Extended Connect TLV | 325 | 0x02 | 2 bytes | TCP Connect OK TLV | 326 | 0x03 | Variable | Error TLV | 327 | 0xff | 2 bytes | End TLV | 328 +------+----------+-----------------------------+ 330 Figure 5: QUIC tunnel stream TLVs 332 The TCP Connect TLV is used to establish a TCP connection through the 333 tunnel towards the final destination. The TCP Extended Connect TLV 334 allows indicating more information in the establishment request. The 335 TCP Connect OK TLV confirms the establishment of this TCP connection. 336 The Error TLV is used to indicate any out-of-band error that occurred 337 during the TCP connection establishment associated to the QUIC 338 stream. Finally, the End TLV marks the end of the series of TLVs and 339 the start of the bytestream on a given QUIC stream. These TLVs are 340 detailed in the following sections. 342 Offset 0 Offset 20 Offset 22 343 | | | 344 v v v 345 +-----------------+---------+---------------- 346 Stream 0 | TCP Connect TLV | End TLV | TCP bytestream ... 347 +-----------------+---------+---------------- 349 Figure 6: Example of use of QUIC tunnel stream TLVs 351 7.1.1. TCP Connect TLV 353 The TCP Connect TLV indicates the final destination of the TCP 354 connection associated to a given QUIC stream. The fields Remote Peer 355 Port and Remote Peer IP Address contain the destination port number 356 and IP address of the final destination. 358 The Remote Peer IP Address MUST be encoded as an IPv6 address. IPv4 359 addresses MUST be encoded using the IPv4-Mapped IPv6 Address format 360 defined in [RFC4291]. Further, the Remote Peer IP address field MUST 361 NOT include multicast, broadcast, and host loopback addresses 362 [RFC6890]. 364 A QUIC tunnel peer MUST NOT send more than one TCP Connect TLV per 365 QUIC stream. A QUIC tunnel peer MUST NOT send a TCP Connect TLV if a 366 TCP Extended Connect TLV was previously sent on a given stream. A 367 QUIC tunnel peer MUST NOT send a TCP Connect TLV on non-self 368 initiated streams. 370 1 2 3 371 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 372 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 373 | Type (8) | Length (8) | Remote Peer Port (16) | 374 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 375 | | 376 | Remote Peer IP Address (128) | 377 | | 378 | | 379 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 381 Figure 7: TCP Connect TLV 383 7.1.2. TCP Extended Connect TLV 385 The TCP Extended Connect TLV is an extended version of the TCP 386 Connect TLV. It also indicates the source of the TCP connection. 387 The fields Remote Peer Port and Remote Peer IP Address contain the 388 destination port number and IP address of the final destination. The 389 fields Local Peer Port and Local Peer IP Address contain the source 390 port number and IP address of the source of the TCP connection. 392 The Remote (resp. Local) Peer IP Address MUST be encoded as an IPv6 393 address. IPv4 addresses MUST be encoded using the IPv4-Mapped IPv6 394 Address format defined in [RFC4291]. Further, the Remote (resp. 395 Local) Peer IP address field MUST NOT include multicast, broadcast, 396 and host loopback addresses [RFC6890]. 398 A QUIC tunnel peer MUST NOT send more than one TCP Extended Connect 399 TLV per QUIC stream. A QUIC tunnel peer MUST NOT send a TCP Extended 400 Connect TLV if a TCP Connect TLV was previously sent on a given 401 stream. A QUIC tunnel peer MUST NOT send a TCP Extended Connect TLV 402 on non-self initiated streams. 404 1 2 3 405 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 406 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 407 | Type (8) | Length (8) | Remote Peer Port (16) | 408 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 409 | | 410 | Remote Peer IP Address (128) | 411 | | 412 | | 413 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 414 | Local Peer Port (16) | 415 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 416 | | 417 | Local Peer IP Address (128) | 418 | | 419 | | 420 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 422 Figure 8: TCP Extended Connect TLV 424 7.1.3. TCP Connect OK TLV 426 The TCP Connect OK TLV does not contain a value. Its presence 427 confirms the successful establishment of connection to the final 428 destination. A QUIC peer MUST NOT send a TCP Connect OK TLV on self- 429 initiated streams. 431 7.1.4. Error TLV 433 The Error TLV indicates out-of-band errors that occurred during the 434 establishment of the connection to the final destination. These 435 errors can be ICMP Destination Unreachable messages for instance. In 436 this case the ICMP packet received by the concentrator is copied 437 inside the Error Payload field. 439 1 2 3 440 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 441 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 442 | Type (8) | Length (8) | Error Code (16) | 443 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 444 | [Error Payload (*)] | 445 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 447 Figure 9: Error TLV 449 The following bytestream-level error codes are defined in this 450 document: 452 +------+---------------------------+ 453 | Code | Name | 454 +------+---------------------------+ 455 | 0x0 | Protocol Violation | 456 | 0x1 | ICMP Packet Received | 457 | 0x2 | Malformed TLV | 458 | 0x3 | Network Failure | 459 +------+---------------------------+ 461 Figure 10: Bytestream-level Error Codes 463 o Protocol Violation (0x0): A general error code for all non- 464 conforming behaviors encountered. A QUIC tunnel peer SHOULD use a 465 more specific error code when possible. 467 o ICMP Packet Received (0x1): This code indicates that the 468 concentrator received an ICMP packet while trying to create the 469 associated TCP connection. The Error Payload contains the packet. 471 o Malformed TLV (0x2): This code indicates that a received TLV was 472 not successfully parsed or formed. A peer receiving a Connect TLV 473 with an invalid IP address MUST send an Error TLV with this error 474 code. 476 o Network Failure (0x3): This codes indicates that a network failure 477 prevented the establishment of the connection. 479 After sending one or more Error TLVs, the sender MUST send an End TLV 480 and terminate the stream, i.e. set the FIN bit after the End TLV. 482 7.1.5. End TLV 484 The End TLV does not contain a value. Its existence signals the end 485 of the series of TLVs. The next byte in the QUIC stream after this 486 TLV is the start of the tunneled bytestream. 488 8. Example flows 490 This section illustrates the different messages described previously 491 and how they are used in a QUIC tunnel connection. For QUIC STREAM 492 frames, we use the following syntax: STREAM[ID, Stream Data [, FIN]]. 493 The first element is the Stream ID, the second is the Stream Data 494 contained in the frame and the last one is optional and indicates 495 that the FIN bit is set. 497 Client Concentrator Final Destination 498 | STREAM[0, "TCP Connect, End"] || | 499 |------------------------------>|| SYN | 500 | ||==============================>| 501 | || SYN+ACK | 502 |STREAM[0,"TCP Connect OK, End"]||<==============================| 503 |<------------------------------|| | 504 | STREAM[0, "bytestream data"] || | 505 |------------------------------>|| bytestream data, ACK | 506 | ||==============================>| 507 | || bytestream data, ACK | 508 | STREAM[0, "bytestream data"] ||<==============================| 509 |<------------------------------|| FIN | 510 | STREAM[0, "", FIN] ||<==============================| 511 |<------------------------------|| ACK | 512 | STREAM[0, "", FIN] ||==============================>| 513 |------------------------------>|| FIN | 514 | ||==============================>| 515 | || ACK | 516 | ||<==============================| 518 Legend: 519 --- Multipath QUIC connection 520 === TCP connection 522 Figure 11: Example flow for the stream mode 524 On Figure 11, the Client is initiating a TCP connection in stream 525 mode to the Final Destination. A request and a response are 526 exchanged, then the connection is torn down gracefully. A remote- 527 initiated connection accepted by the concentrator on behalf of the 528 client would have the order and the direction of all messages 529 reversed. 531 9. Security Considerations 533 9.1. Privacy 535 The Concentrator has access to all the packets it processes. It MUST 536 be protected as a core IP router, e.g. as specified in [RFC1812]. 538 9.2. Ingress Filtering 540 Ingress filtering policies MUST be enforced at the network 541 boundaries, i.e. as specified in [RFC2827]. 543 9.3. Denial of Service 545 There is a risk of an amplification attack when the Concentrator 546 sends a TCP SYN in response of a TCP Connect TLV. When a TCP SYN is 547 larger than the client request, the Concentrator amplifies the client 548 traffic. To mitigate such attacks, the Concentrator SHOULD rate 549 limit the number of pending TCP Connect from a given client. 551 10. IANA Considerations 553 10.1. Registration of QUIC tunnel Identification String 555 This document creates a new registration for the identification of 556 the QUIC tunnel protocol in the "Application Layer Protocol 557 Negotiation (ALPN) Protocol IDs" registry established in [RFC7301]. 559 The "qt" string identifies the QUIC tunnel protocol. 561 Protocol: QUIC tunnel 563 Identification Sequence: 0x71 0x74 ("qt") 565 Specification: This document 567 10.2. QUIC tunnel stream TLVs 569 IANA is requested to create a new "QUIC tunnel stream Parameters" 570 registry. 572 The following subsections detail new registries within "QUIC tunnel 573 stream Parameters" registry. 575 10.2.1. QUIC tunnel stream TLVs Types 577 IANA is request to create the "QUIC tunnel stream TLVs Types" sub- 578 registry. New values are assigned via IETF Review (Section 4.8 of 579 [RFC8126]). 581 The initial values to be assigned at the creation of the registry are 582 as follows: 584 +------+-----------------------------+------------+ 585 | Code | Name | Reference | 586 +------+-----------------------------+------------+ 587 | 0 | TCP Connect TLV | [This-Doc] | 588 | 1 | TCP Extended Connect TLV | [This-Doc] | 589 | 2 | TCP Connect OK TLV | [This-Doc] | 590 | 3 | Error TLV | [This-Doc] | 591 | 255 | End TLV | [This-Doc] | 592 +------+-----------------------------+------------+ 594 10.2.2. QUIC tunnel streams TLVs Error Types 596 IANA is request to create the "QUIC tunnel stream TLVs Error Types" 597 sub-registry. New values are assigned via IETF Review (Section 4.8 598 of [RFC8126]). 600 The initial values to be assigned at the creation of the registry are 601 as follows: 603 +------+---------------------------+------------+ 604 | Code | Name | Reference | 605 +------+---------------------------+------------+ 606 | 0 | Protocol Violation | [This-Doc] | 607 | 1 | ICMP packet received | [This-Doc] | 608 | 2 | Malformed TLV | [This-Doc] | 609 | 3 | Network Failure | [This-Doc] | 610 +------+---------------------------+------------+ 612 11. References 614 11.1. Normative References 616 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 617 Requirement Levels", BCP 14, RFC 2119, 618 DOI 10.17487/RFC2119, March 1997, 619 . 621 [RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing 622 Architecture", RFC 4291, DOI 10.17487/RFC4291, February 623 2006, . 625 [RFC6890] Cotton, M., Vegoda, L., Bonica, R., Ed., and B. Haberman, 626 "Special-Purpose IP Address Registries", BCP 153, 627 RFC 6890, DOI 10.17487/RFC6890, April 2013, 628 . 630 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 631 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 632 May 2017, . 634 11.2. Informative References 636 [CoNEXT] De Coninck, Q. and O. Bonaventure, "Multipath QUIC: Design 637 and Evaluation", Proceedings of the 13th International 638 Conference on emerging Networking EXperiments and 639 Technologies (CoNEXT 2017) , December 2017. 641 [I-D.deconinck-quic-multipath] 642 Coninck, Q. and O. Bonaventure, "Multipath Extensions for 643 QUIC (MP-QUIC)", draft-deconinck-quic-multipath-03 (work 644 in progress), August 2019. 646 [I-D.ietf-lpwan-ipv6-static-context-hc] 647 Minaburo, A., Toutain, L., Gomez, C., Barthel, D., and J. 648 Zuniga, "Static Context Header Compression (SCHC) and 649 fragmentation for LPWAN, application to UDP/IPv6", draft- 650 ietf-lpwan-ipv6-static-context-hc-22 (work in progress), 651 October 2019. 653 [I-D.ietf-quic-transport] 654 Iyengar, J. and M. Thomson, "QUIC: A UDP-Based Multiplexed 655 and Secure Transport", draft-ietf-quic-transport-23 (work 656 in progress), September 2019. 658 [I-D.ietf-tcpm-converters] 659 Bonaventure, O., Boucadair, M., Gundavelli, S., Seo, S., 660 and B. Hesmans, "0-RTT TCP Convert Protocol", draft-ietf- 661 tcpm-converters-13 (work in progress), October 2019. 663 [I-D.pauly-quic-datagram] 664 Pauly, T., Kinnear, E., and D. Schinazi, "An Unreliable 665 Datagram Extension to QUIC", draft-pauly-quic-datagram-04 666 (work in progress), October 2019. 668 [RFC1812] Baker, F., Ed., "Requirements for IP Version 4 Routers", 669 RFC 1812, DOI 10.17487/RFC1812, June 1995, 670 . 672 [RFC2827] Ferguson, P. and D. Senie, "Network Ingress Filtering: 673 Defeating Denial of Service Attacks which employ IP Source 674 Address Spoofing", BCP 38, RFC 2827, DOI 10.17487/RFC2827, 675 May 2000, . 677 [RFC3095] Bormann, C., Burmeister, C., Degermark, M., Fukushima, H., 678 Hannu, H., Jonsson, L-E., Hakenberg, R., Koren, T., Le, 679 K., Liu, Z., Martensson, A., Miyazaki, A., Svanbro, K., 680 Wiebke, T., Yoshimura, T., and H. Zheng, "RObust Header 681 Compression (ROHC): Framework and four profiles: RTP, UDP, 682 ESP, and uncompressed", RFC 3095, DOI 10.17487/RFC3095, 683 July 2001, . 685 [RFC3843] Jonsson, L-E. and G. Pelletier, "RObust Header Compression 686 (ROHC): A Compression Profile for IP", RFC 3843, 687 DOI 10.17487/RFC3843, June 2004, 688 . 690 [RFC4019] Pelletier, G., "RObust Header Compression (ROHC): Profiles 691 for User Datagram Protocol (UDP) Lite", RFC 4019, 692 DOI 10.17487/RFC4019, April 2005, 693 . 695 [RFC4815] Jonsson, L-E., Sandlund, K., Pelletier, G., and P. Kremer, 696 "RObust Header Compression (ROHC): Corrections and 697 Clarifications to RFC 3095", RFC 4815, 698 DOI 10.17487/RFC4815, February 2007, 699 . 701 [RFC6846] Pelletier, G., Sandlund, K., Jonsson, L-E., and M. West, 702 "RObust Header Compression (ROHC): A Profile for TCP/IP 703 (ROHC-TCP)", RFC 6846, DOI 10.17487/RFC6846, January 2013, 704 . 706 [RFC6887] Wing, D., Ed., Cheshire, S., Boucadair, M., Penno, R., and 707 P. Selkirk, "Port Control Protocol (PCP)", RFC 6887, 708 DOI 10.17487/RFC6887, April 2013, 709 . 711 [RFC7301] Friedl, S., Popov, A., Langley, A., and E. Stephan, 712 "Transport Layer Security (TLS) Application-Layer Protocol 713 Negotiation Extension", RFC 7301, DOI 10.17487/RFC7301, 714 July 2014, . 716 [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for 717 Writing an IANA Considerations Section in RFCs", BCP 26, 718 RFC 8126, DOI 10.17487/RFC8126, June 2017, 719 . 721 [SIGCOMM19] 722 De Coninck, Q., Michel, F., Piraux, M., Given-Wilson, T., 723 Legay, A., Pereira, O., and O. Bonaventure, "Pluginizing 724 QUIC", Proceedings of the ACM Special Interest Group on 725 Data Communication , August 2019. 727 Acknowledgments 729 Thanks to Quentin De Coninck and Francois Michel for their comments 730 and the proofreading of the first version of this document. Thanks 731 to Gregory Vander Schueren for his comments on the first version of 732 this document. 734 Authors' Addresses 736 Maxime Piraux (editor) 737 UCLouvain 739 Email: maxime.piraux@uclouvain.be 741 Olivier Bonaventure 742 UCLouvain 744 Email: olivier.bonaventure@uclouvain.be