idnits 2.17.1 draft-piraux-quic-tunnel-tcp-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 == Line 205 has weird spacing: '... Client v ...' -- The document date (March 09, 2020) is 1503 days in the past. Is this intentional? Checking references for intended status: Experimental ---------------------------------------------------------------------------- == Missing Reference: 'This-Doc' is mentioned on line 420, but not defined == Outdated reference: A later version (-34) exists of draft-ietf-quic-transport-27 == Outdated reference: A later version (-19) exists of draft-ietf-tcpm-converters-18 Summary: 0 errors (**), 0 flaws (~~), 5 warnings (==), 1 comment (--). 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: September 10, 2020 March 09, 2020 7 Tunneling TCP inside QUIC 8 draft-piraux-quic-tunnel-tcp-00 10 Abstract 12 This document specifies a new operating mode for a QUIC tunnel to 13 efficiently convey TCP bytestreams. 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 September 10, 2020. 32 Copyright Notice 34 Copyright (c) 2020 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. The stream mode . . . . . . . . . . . . . . . . . . . . . . . 3 52 4. Connection establishment . . . . . . . . . . . . . . . . . . 4 53 5. Messages format . . . . . . . . . . . . . . . . . . . . . . . 4 54 5.1. QUIC tunnel stream TLVs . . . . . . . . . . . . . . . . . 4 55 5.1.1. TCP Connect TLV . . . . . . . . . . . . . . . . . . . 5 56 5.1.2. TCP Connect OK TLV . . . . . . . . . . . . . . . . . 6 57 5.1.3. Error TLV . . . . . . . . . . . . . . . . . . . . . . 6 58 5.1.4. End TLV . . . . . . . . . . . . . . . . . . . . . . . 7 59 6. Example flows . . . . . . . . . . . . . . . . . . . . . . . . 8 60 7. Security Considerations . . . . . . . . . . . . . . . . . . . 8 61 7.1. Denial of Service . . . . . . . . . . . . . . . . . . . . 9 62 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 63 8.1. Registration of QUIC tunnel Identification String . . . . 9 64 8.2. QUIC tunnel stream TLVs . . . . . . . . . . . . . . . . . 9 65 8.2.1. QUIC tunnel stream TLVs Types . . . . . . . . . . . . 9 66 8.2.2. QUIC tunnel streams TLVs Error Types . . . . . . . . 10 67 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 10 68 9.1. Normative References . . . . . . . . . . . . . . . . . . 10 69 9.2. Informative References . . . . . . . . . . . . . . . . . 11 70 Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 11 71 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 11 73 1. Introduction 75 The recently proposed QUIC tunnel protocol [I-D.piraux-quic-tunnel] 76 supports the exchange of IP packets or Ethernet frames over a QUIC 77 connection. Its first operating mode, the datagram mode, transports 78 plain packets inside QUIC frames. Its main advantage is that it 79 supports any network-layer protocol. However, this advantage comes 80 with a large per-packet overhead since each packet contains both a 81 network and a transport header. All these headers must be 82 transmitted in addition to the IP/UDP/QUIC headers of the QUIC 83 connection. For TCP connections for instance, the per-packet 84 overhead can be large. 86 In this document, we propose a new operating mode for the QUIC tunnel 87 protocol, called the stream mode. It takes advantage of the QUIC 88 streams to efficiently transport TCP bytestreams over a QUIC 89 connection. Section 3 describes this new mode. Section 5 specifies 90 the format of the messages introduced by this document. Section 6 91 contains example flows. 93 2. Conventions and Definitions 95 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 96 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 97 "OPTIONAL" in this document are to be interpreted as described in BCP 98 14 [RFC2119] [RFC8174] when, and only when, they appear in all 99 capitals, as shown here. 101 3. The stream mode 103 Since QUIC supports multiple streams, another possibility to carry 104 the data exchanged over TCP connections between the client and the 105 concentrator is to transport the bytestream of each TCP connection as 106 one of the bidirectional streams of the QUIC connection. For this, 107 we base our approach on the 0-RTT Convert protocol 108 [I-D.ietf-tcpm-converters] that was proposed to ease the deployment 109 of TCP extensions. In a nutshell, it is an application proxy that 110 converts TCP connections, allowing the use of new TCP extensions 111 through an intermediate relay. 113 We use a similar approach in our stream mode. When a client opens a 114 stream, it sends at the beginning of the bytestream one or more TLV 115 messages indicating the IP address and port number of the remote 116 destination of the bytestream. Their format is detailed in section 117 Section 5.1. Upon reception of such a TLV message, the concentrator 118 opens a TCP connection towards the specified destination and connects 119 the incoming bytestream of the QUIC connection to the bytestream of 120 the new TCP connection (and similarly in the opposite direction). 122 Figure 1 summarizes how the new TCP connection is mapped to the QUIC 123 stream. Actions and events of a TCP connection are translated to 124 actions and events of the associated QUIC stream, so that a state 125 transition on one is translated to the other. 127 +------------------+-------------------------+ 128 | TCP | QUIC Stream | 129 +------------------+-------------------------+ 130 | SYN received | Open Stream, send TLVs | 131 | FIN received | Send Stream FIN | 132 | RST received | Send STOP_SENDING | 133 | | Send RESET_STREAM | 134 | Data received | Send Stream data | 135 +------------------+-------------------------+ 137 +-------------------------------+------------+ 138 | QUIC Stream | TCP | 139 +-------------------------------+------------+ 140 | Stream opened, TLVs received | Send SYN | 141 | Stream FIN received | Send FIN | 142 | STOP_SENDING received | Send RST | 143 | RESET_STREAM received | Send RST | 144 | Stream data received | Send data | 145 +-------------------------------+------------+ 147 Figure 1: TCP connection to QUIC stream mapping 149 When sending STOP_SENDING or RESET_STREAM frames in response to the 150 receipt of a TCP RST, QUIC tunnel peers MUST use the application 151 protocol error code 0x00 (TCP_CONNECTION_RESET). 153 The QUIC stream-level flow control can be tuned to match the receive 154 window size of the corresponding TCP connection, so that no excessive 155 data needs to be buffered. 157 4. Connection establishment 159 During the connection establishment, the concentrator can control the 160 number of TCP bytestreams that can be opened initially by setting the 161 initial_max_streams_bidi QUIC transport parameter as defined in 162 [I-D.ietf-quic-transport]. 164 5. Messages format 166 In the following sections, we specify the format of each message 167 introduced in this document. They are encoded using the TLV format 168 described in [I-D.piraux-quic-tunnel]. 170 5.1. QUIC tunnel stream TLVs 172 When using the stream mode, one or more messages are used to trigger 173 and confirm the establishment of a connection towards the final 174 destination for a given stream. Those messages are exchanged on this 175 QUIC stream before the TCP connection bytestream. This section 176 describes the format of these messages. 178 This document specifies the following QUIC tunnel stream TLVs: 180 +------+----------+-----------------------------+ 181 | Type | Size | Name | 182 +------+----------+-----------------------------+ 183 | 0x00 | 20 bytes | TCP Connect TLV | 184 | 0x01 | 2 bytes | TCP Connect OK TLV | 185 | 0x02 | Variable | Error TLV | 186 | 0xff | 2 bytes | End TLV | 187 +------+----------+-----------------------------+ 189 Figure 2: QUIC tunnel stream TLVs 191 The TCP Connect TLV is used to request the establishment a TCP 192 connection by the concentrator towards the final destination. The 193 TCP Connect OK TLV confirms the establishment of this TCP connection. 194 The Error TLV is used to indicate any error that occurred during the 195 establishment of a TCP connection. Finally, the End TLV marks the 196 end of the series of TLVs and the start of the bytestream on a given 197 QUIC stream. These TLVs are detailed in the following sections. 199 Future versions of this document may define new TLVs. The End TLV 200 allows a QUIC tunnel peer to send several TLVs before the start of 201 the bytestream. 203 Offset 0 Offset 20 Offset 22 204 | | | 205 Client v v v 206 +-----------------+---------+---------------- 207 Stream 0 | TCP Connect TLV | End TLV | TCP bytestream ... 208 +-----------------+---------+---------------- 210 Figure 3: Example of use of QUIC tunnel stream TLVs 212 Figure 3 illustrates an example of use of QUIC tunnel streams TLVs. 213 In this example, the client opens Stream 0 and sends two TLVs. The 214 first one requests the concentrator to establish a new TCP 215 connection. The second TLV marks the end of the series of TLV and 216 the start of the TCP bytestream. 218 5.1.1. TCP Connect TLV 220 The TCP Connect TLV indicates the final destination of the TCP 221 connection associated to a given QUIC stream. The fields Remote Peer 222 Port and Remote Peer IP Address contain the destination port number 223 and IP address of the final destination. 225 The Remote Peer IP Address MUST be encoded as an IPv6 address. IPv4 226 addresses MUST be encoded using the IPv4-Mapped IPv6 Address format 227 defined in [RFC4291]. Further, the Remote Peer IP address field MUST 228 NOT include multicast, broadcast, and host loopback addresses 229 [RFC6890]. 231 A QUIC tunnel peer MUST NOT send more than one TCP Connect TLV per 232 QUIC stream. A QUIC tunnel peer MUST NOT send a TCP Connect TLV on 233 non-self initiated streams. 235 1 2 3 236 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 237 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 238 | Type (8) | Length (8) | Remote Peer Port (16) | 239 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 240 | | 241 | Remote Peer IP Address (128) | 242 | | 243 | | 244 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 246 Figure 4: TCP Connect TLV 248 5.1.2. TCP Connect OK TLV 250 The TCP Connect OK TLV does not contain a value. Its presence 251 confirms the successful establishment of the requested TCP connection 252 to the final destination. A QUIC peer MUST NOT send a TCP Connect OK 253 TLV on self-initiated streams. 255 5.1.3. Error TLV 257 The Error TLV indicates out-of-band errors that occurred during the 258 establishment of the TCP connection to the final destination. These 259 errors can be ICMP Destination Unreachable messages for instance. In 260 this case the ICMP packet received by the concentrator is copied 261 inside the Error Payload field. 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 | Type (8) | Length (8) | Error Code (16) | 267 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 268 | [Error Payload (*)] | 269 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 271 Figure 5: Error TLV 273 The following bytestream-level error codes are defined in this 274 document: 276 +------+---------------------------+ 277 | Code | Name | 278 +------+---------------------------+ 279 | 0x0 | Protocol Violation | 280 | 0x1 | ICMP Packet Received | 281 | 0x2 | Malformed TLV | 282 | 0x3 | Network Failure | 283 +------+---------------------------+ 285 Figure 6: Bytestream-level Error Codes 287 o Protocol Violation (0x0): A general error code for all non- 288 conforming behaviors encountered. A QUIC tunnel peer SHOULD use a 289 more specific error code when possible. 291 o ICMP Packet Received (0x1): This code indicates that the 292 concentrator received an ICMP packet while trying to create the 293 associated TCP connection. The Error Payload contains the packet. 295 o Malformed TLV (0x2): This code indicates that a received TLV was 296 not successfully parsed or formed. A peer receiving a TCP Connect 297 TLV with an invalid IP address MUST send an Error TLV with this 298 error code. 300 o Network Failure (0x3): This codes indicates that a network failure 301 prevented the establishment of the connection. 303 After sending one or more Error TLVs, the sender MUST send an End TLV 304 and terminate the stream, i.e. set the FIN bit after the End TLV. 306 5.1.4. End TLV 308 The End TLV does not contain a value. Its existence signals the end 309 of the series of TLVs. The next byte in the QUIC stream after this 310 TLV is part of of the tunneled bytestream. 312 6. Example flows 314 This section illustrates the different messages described previously 315 and how they are used in a QUIC tunnel connection. For QUIC STREAM 316 frames, we use the following syntax: STREAM[ID, Stream Data [, FIN]]. 317 The first element is the Stream ID, the second is the Stream Data 318 contained in the frame and the last one is optional and indicates 319 that the FIN bit is set. 321 Client Concentrator Final Destination 322 | STREAM[0, "TCP Connect, End"] || | 323 |------------------------------>|| SYN | 324 | ||==============================>| 325 | || SYN+ACK | 326 |STREAM[0,"TCP Connect OK, End"]||<==============================| 327 |<------------------------------|| | 328 | STREAM[0, "bytestream data"] || | 329 |------------------------------>|| bytestream data, ACK | 330 | ||==============================>| 331 | || bytestream data, ACK | 332 | STREAM[0, "bytestream data"] ||<==============================| 333 |<------------------------------|| FIN | 334 | STREAM[0, "", FIN] ||<==============================| 335 |<------------------------------|| ACK | 336 | STREAM[0, "", FIN] ||==============================>| 337 |------------------------------>|| FIN | 338 | ||==============================>| 339 | || ACK | 340 | ||<==============================| 342 Legend: 343 --- QUIC connection 344 === TCP connection 346 Figure 7: Example flow for the stream mode 348 On Figure 7, the client is initiating a TCP connection in stream mode 349 to the Final Destination. A request and a response are exchanged, 350 then the connection is torn down gracefully. A remote-initiated 351 connection accepted by the concentrator on behalf of the client would 352 have the order and the direction of all messages reversed. 354 7. Security Considerations 355 7.1. Denial of Service 357 There is a risk of an amplification attack when the Concentrator 358 sends a TCP SYN in response of a TCP Connect TLV. When a TCP SYN is 359 larger than the client request, the Concentrator amplifies the client 360 traffic. To mitigate such attacks, the Concentrator SHOULD rate 361 limit the number of pending TCP Connect from a given client. 363 8. IANA Considerations 365 8.1. Registration of QUIC tunnel Identification String 367 This document creates a new registration for the identification of 368 the QUIC tunnel protocol in the "Application Layer Protocol 369 Negotiation (ALPN) Protocol IDs" registry established in [RFC7301]. 371 The "qt" string identifies the QUIC tunnel protocol. 373 Protocol: QUIC tunnel 375 Identification Sequence: 0x71 0x74 ("qt") 377 Specification: This document 379 8.2. QUIC tunnel stream TLVs 381 IANA is requested to create a new "QUIC tunnel stream Parameters" 382 registry. 384 The following subsections detail new registries within "QUIC tunnel 385 stream Parameters" registry. 387 8.2.1. QUIC tunnel stream TLVs Types 389 IANA is request to create the "QUIC tunnel stream TLVs Types" sub- 390 registry. New values are assigned via IETF Review (Section 4.8 of 391 [RFC8126]). 393 The initial values to be assigned at the creation of the registry are 394 as follows: 396 +------+-----------------------------+------------+ 397 | Code | Name | Reference | 398 +------+-----------------------------+------------+ 399 | 0 | TCP Connect TLV | [This-Doc] | 400 | 1 | TCP Connect OK TLV | [This-Doc] | 401 | 2 | Error TLV | [This-Doc] | 402 | 255 | End TLV | [This-Doc] | 403 +------+-----------------------------+------------+ 405 8.2.2. QUIC tunnel streams TLVs Error Types 407 IANA is request to create the "QUIC tunnel stream TLVs Error Types" 408 sub-registry. New values are assigned via IETF Review (Section 4.8 409 of [RFC8126]). 411 The initial values to be assigned at the creation of the registry are 412 as follows: 414 +------+---------------------------+------------+ 415 | Code | Name | Reference | 416 +------+---------------------------+------------+ 417 | 0 | Protocol Violation | [This-Doc] | 418 | 1 | ICMP packet received | [This-Doc] | 419 | 2 | Malformed TLV | [This-Doc] | 420 | 3 | Network Failure | [This-Doc] | 421 +------+---------------------------+------------+ 423 9. References 425 9.1. Normative References 427 [I-D.piraux-quic-tunnel] 428 Piraux, M. and O. Bonaventure, "Tunneling Internet 429 protocols inside QUIC", draft-piraux-quic-tunnel-01 (work 430 in progress), March 2020. 432 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 433 Requirement Levels", BCP 14, RFC 2119, 434 DOI 10.17487/RFC2119, March 1997, 435 . 437 [RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing 438 Architecture", RFC 4291, DOI 10.17487/RFC4291, February 439 2006, . 441 [RFC6890] Cotton, M., Vegoda, L., Bonica, R., Ed., and B. Haberman, 442 "Special-Purpose IP Address Registries", BCP 153, 443 RFC 6890, DOI 10.17487/RFC6890, April 2013, 444 . 446 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 447 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 448 May 2017, . 450 9.2. Informative References 452 [I-D.ietf-quic-transport] 453 Iyengar, J. and M. Thomson, "QUIC: A UDP-Based Multiplexed 454 and Secure Transport", draft-ietf-quic-transport-27 (work 455 in progress), February 2020. 457 [I-D.ietf-tcpm-converters] 458 Bonaventure, O., Boucadair, M., Gundavelli, S., Seo, S., 459 and B. Hesmans, "0-RTT TCP Convert Protocol", draft-ietf- 460 tcpm-converters-18 (work in progress), March 2020. 462 [RFC7301] Friedl, S., Popov, A., Langley, A., and E. Stephan, 463 "Transport Layer Security (TLS) Application-Layer Protocol 464 Negotiation Extension", RFC 7301, DOI 10.17487/RFC7301, 465 July 2014, . 467 [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for 468 Writing an IANA Considerations Section in RFCs", BCP 26, 469 RFC 8126, DOI 10.17487/RFC8126, June 2017, 470 . 472 Acknowledgments 474 This documents draws heavily on the initial version of 475 [I-D.piraux-quic-tunnel]. Their contributors are thanked again here. 476 This work was partially supported by the MQUIC project. 478 Authors' Addresses 480 Maxime Piraux 481 UCLouvain 483 Email: maxime.piraux@uclouvain.be 484 Olivier Bonaventure 485 UCLouvain 487 Email: olivier.bonaventure@uclouvain.be