idnits 2.17.1 draft-piraux-intarea-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 212 has weird spacing: '... Client v ...' -- The document date (2 November 2020) is 1263 days in the past. Is this intentional? Checking references for intended status: Experimental ---------------------------------------------------------------------------- == Missing Reference: 'This-Doc' is mentioned on line 413, but not defined == Outdated reference: A later version (-34) exists of draft-ietf-quic-transport-32 Summary: 0 errors (**), 0 flaws (~~), 4 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Area Working Group M. Piraux 3 Internet-Draft O. Bonaventure 4 Intended status: Experimental UCLouvain 5 Expires: 6 May 2021 2 November 2020 7 Tunneling TCP inside QUIC 8 draft-piraux-intarea-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 6 May 2021. 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 (https://trustee.ietf.org/ 39 license-info) in effect on the date of publication of this document. 40 Please review these documents carefully, as they describe your rights 41 and restrictions with respect to this document. Code Components 42 extracted from this document must include Simplified BSD License text 43 as described in Section 4.e of the Trust Legal Provisions and are 44 provided without warranty as described in the Simplified BSD License. 46 Table of Contents 48 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 49 2. Conventions and Definitions . . . . . . . . . . . . . . . . . 3 50 3. The stream mode . . . . . . . . . . . . . . . . . . . . . . . 3 51 4. Connection establishment . . . . . . . . . . . . . . . . . . 4 52 5. Messages format . . . . . . . . . . . . . . . . . . . . . . . 4 53 5.1. QUIC tunnel stream TLVs . . . . . . . . . . . . . . . . . 5 54 5.1.1. TCP Connect TLV . . . . . . . . . . . . . . . . . . . 6 55 5.1.2. TCP Connect OK TLV . . . . . . . . . . . . . . . . . 6 56 5.1.3. Error TLV . . . . . . . . . . . . . . . . . . . . . . 6 57 5.1.4. End TLV . . . . . . . . . . . . . . . . . . . . . . . 7 58 6. Example flows . . . . . . . . . . . . . . . . . . . . . . . . 8 59 7. Security Considerations . . . . . . . . . . . . . . . . . . . 8 60 7.1. Denial of Service . . . . . . . . . . . . . . . . . . . . 9 61 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 62 8.1. QUIC tunnel stream TLVs . . . . . . . . . . . . . . . . . 9 63 8.1.1. QUIC tunnel stream TLVs Types . . . . . . . . . . . . 9 64 8.1.2. QUIC tunnel streams TLVs Error Types . . . . . . . . 9 65 8.2. QUIC Transport Parameter Registry . . . . . . . . . . . . 10 66 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 10 67 9.1. Normative References . . . . . . . . . . . . . . . . . . 10 68 9.2. Informative References . . . . . . . . . . . . . . . . . 11 69 Appendix A. Change Log . . . . . . . . . . . . . . . . . . . . . 11 70 A.1. Since draft-piraux-quic-tunnel-tcp-01 . . . . . . . . . . 11 71 A.2. Since draft-piraux-quic-tunnel-tcp-00 . . . . . . . . . . 11 72 Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 12 73 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 12 75 1. Introduction 77 The recently proposed QUIC tunnel protocol 78 [I-D.piraux-intarea-quic-tunnel] supports the exchange of IP packets 79 and Ethernet frames over a QUIC connection. Its two existing 80 operating modes transports plain packets inside QUIC frames. Their 81 main advantage is that they support any network-layer protocol. 82 However, this advantage comes with a large per-packet overhead since 83 each packet contains both a network and a transport header. All 84 these headers must be transmitted in addition to the IP/UDP/QUIC 85 headers of the QUIC connection. For TCP connections for instance, 86 the per-packet overhead can be large. 88 In this document, we propose a new operating mode for the QUIC tunnel 89 protocol, called the stream mode. It takes advantage of the QUIC 90 streams to efficiently transport TCP bytestreams over a QUIC 91 connection. Section 3 describes this new mode. Section 5 specifies 92 the format of the messages introduced by this document. Section 6 93 contains example flows. 95 2. Conventions and Definitions 97 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 98 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 99 "OPTIONAL" in this document are to be interpreted as described in BCP 100 14 [RFC2119] [RFC8174] when, and only when, they appear in all 101 capitals, as shown here. 103 3. The stream mode 105 Since QUIC supports multiple streams, another possibility to carry 106 the data exchanged over TCP connections between the client and the 107 concentrator is to transport the bytestream of each TCP connection as 108 one of the bidirectional streams of the QUIC connection. For this, 109 we base our approach on the 0-RTT Convert protocol 110 [I-D.ietf-tcpm-converters] that was proposed to ease the deployment 111 of TCP extensions. In a nutshell, it is an application proxy that 112 converts TCP connections, allowing the use of new TCP extensions 113 through an intermediate relay. 115 A similar approach is used in the stream mode. When a client opens a 116 stream, it sends at the beginning of the bytestream one or more TLV 117 messages indicating the IP address and port number of the remote 118 destination of the bytestream. Their format is detailed in section 119 Section 5.1. Upon reception of such a TLV message, the concentrator 120 opens a TCP connection towards the specified destination and connects 121 the incoming bytestream of the QUIC connection to the bytestream of 122 the new TCP connection (and similarly in the opposite direction). 124 Figure 1 summarizes how the new TCP connection is mapped to the QUIC 125 stream. Actions and events of a TCP connection are translated to 126 actions and events of the associated QUIC stream, so that a state 127 transition on one is translated to the other. 129 +------------------+-------------------------+ 130 | TCP | QUIC Stream | 131 +------------------+-------------------------+ 132 | SYN received | Open Stream, send TLVs | 133 | FIN received | Send Stream FIN | 134 | RST received | Send STOP_SENDING | 135 | | Send RESET_STREAM | 136 | Data received | Send Stream data | 137 +------------------+-------------------------+ 139 +-------------------------------+------------+ 140 | QUIC Stream | TCP | 141 +-------------------------------+------------+ 142 | Stream opened, TLVs received | Send SYN | 143 | Stream FIN received | Send FIN | 144 | STOP_SENDING received | Send RST | 145 | RESET_STREAM received | Send RST | 146 | Stream data received | Send data | 147 +-------------------------------+------------+ 149 Figure 1: TCP connection to QUIC stream mapping 151 When sending STOP_SENDING or RESET_STREAM frames in response to the 152 receipt of a TCP RST, QUIC tunnel peers MUST use the application 153 protocol error code 0x00 (TCP_CONNECTION_RESET). 155 The QUIC stream-level flow control can be tuned to match the receive 156 window size of the corresponding TCP connection, so that no excessive 157 data needs to be buffered. 159 4. Connection establishment 161 The support of the stream mode is negotiated during the connection 162 establishment by including the quic_tunnel_stream_mode transport 163 parameter (value TBD). The parameter value has no meaning and SHOULD 164 be null. 166 During the connection establishment, the concentrator can control the 167 number of TCP bytestreams that can be opened initially by setting the 168 initial_max_streams_bidi QUIC transport parameter as defined in 169 [I-D.ietf-quic-transport]. 171 5. Messages format 173 In the following sections, we specify the format of each message 174 introduced in this document. They are encoded using the TLV format 175 described in [I-D.piraux-intarea-quic-tunnel]. 177 5.1. QUIC tunnel stream TLVs 179 When using the stream mode, one or more messages are used to trigger 180 and confirm the establishment of a connection towards the final 181 destination for a given stream. Those messages are exchanged on this 182 QUIC stream before the TCP connection bytestream. This section 183 describes the format of these messages. 185 This document specifies the following QUIC tunnel stream TLVs: 187 +------+----------+-----------------------------+ 188 | Type | Size | Name | 189 +------+----------+-----------------------------+ 190 | 0x00 | 20 bytes | TCP Connect TLV | 191 | 0x01 | 2 bytes | TCP Connect OK TLV | 192 | 0x02 | Variable | Error TLV | 193 | 0xff | 2 bytes | End TLV | 194 +------+----------+-----------------------------+ 196 Figure 2: QUIC tunnel stream TLVs 198 The TCP Connect TLV is used to request the establishment a TCP 199 connection by the concentrator towards the final destination. The 200 TCP Connect OK TLV confirms the establishment of this TCP connection. 201 The Error TLV is used to indicate any error that occurred during the 202 establishment of a TCP connection. Finally, the End TLV marks the 203 end of the series of TLVs and the start of the bytestream on a given 204 QUIC stream. These TLVs are detailed in the following sections. 206 Future versions of this document may define new TLVs. The End TLV 207 allows a QUIC tunnel peer to send several TLVs before the start of 208 the bytestream. 210 Offset 0 Offset 20 Offset 22 211 | | | 212 Client v v v 213 +-----------------+---------+---------------- 214 Stream 0 | TCP Connect TLV | End TLV | TCP bytestream ... 215 +-----------------+---------+---------------- 217 Figure 3: Example of use of QUIC tunnel stream TLVs 219 Figure 3 illustrates an example of use of QUIC tunnel streams TLVs. 220 In this example, the client opens Stream 0 and sends two TLVs. The 221 first one requests the concentrator to establish a new TCP 222 connection. The second TLV marks the end of the series of TLV and 223 the start of the TCP bytestream. 225 5.1.1. TCP Connect TLV 227 The TCP Connect TLV indicates the final destination of the TCP 228 connection associated to a given QUIC stream. The fields Remote Peer 229 Port and Remote Peer IP Address contain the destination port number 230 and IP address of the final destination. 232 The Remote Peer IP Address MUST be encoded as an IPv6 address. IPv4 233 addresses MUST be encoded using the IPv4-Mapped IPv6 Address format 234 defined in [RFC4291]. Further, the Remote Peer IP address field MUST 235 NOT include multicast, broadcast, and host loopback addresses 236 [RFC6890]. 238 A QUIC tunnel peer MUST NOT send more than one TCP Connect TLV per 239 QUIC stream. A QUIC tunnel peer MUST NOT send a TCP Connect TLV on 240 non-self initiated streams. 242 1 2 3 243 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 244 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 245 | Type (8) | Length (8) | Remote Peer Port (16) | 246 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 247 | | 248 | Remote Peer IP Address (128) | 249 | | 250 | | 251 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 253 Figure 4: TCP Connect TLV 255 5.1.2. TCP Connect OK TLV 257 The TCP Connect OK TLV does not contain a value. Its presence 258 confirms the successful establishment of the requested TCP connection 259 to the final destination. A QUIC peer MUST NOT send a TCP Connect OK 260 TLV on self-initiated streams. 262 5.1.3. Error TLV 264 The Error TLV indicates out-of-band errors that occurred during the 265 establishment of the TCP connection to the final destination. These 266 errors can be ICMP Destination Unreachable messages for instance. In 267 this case the ICMP packet received by the concentrator is copied 268 inside the Error Payload field. 270 1 2 3 271 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 272 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 273 | Type (8) | Length (8) | Error Code (16) | 274 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 275 | [Error Payload (*)] | 276 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 278 Figure 5: Error TLV 280 The following bytestream-level error codes are defined in this 281 document: 283 +------+---------------------------+ 284 | Code | Name | 285 +------+---------------------------+ 286 | 0x0 | Protocol Violation | 287 | 0x1 | ICMP Packet Received | 288 | 0x2 | Malformed TLV | 289 | 0x3 | Network Failure | 290 +------+---------------------------+ 292 Figure 6: Bytestream-level Error Codes 294 * Protocol Violation (0x0): A general error code for all non- 295 conforming behaviors encountered. A QUIC tunnel peer SHOULD use a 296 more specific error code when possible. 298 * ICMP Packet Received (0x1): This code indicates that the 299 concentrator received an ICMP packet while trying to create the 300 associated TCP connection. The Error Payload contains the packet. 302 * Malformed TLV (0x2): This code indicates that a received TLV was 303 not successfully parsed or formed. A peer receiving a TCP Connect 304 TLV with an invalid IP address MUST send an Error TLV with this 305 error code. 307 * Network Failure (0x3): This codes indicates that a network failure 308 prevented the establishment of the connection. 310 After sending one or more Error TLVs, the sender MUST send an End TLV 311 and terminate the stream, i.e. set the FIN bit after the End TLV. 313 5.1.4. End TLV 315 The End TLV does not contain a value. Its existence signals the end 316 of the series of TLVs. The next byte in the QUIC stream after this 317 TLV is part of of the tunneled bytestream. 319 6. Example flows 321 This section illustrates the different messages described previously 322 and how they are used in a QUIC tunnel connection. For QUIC STREAM 323 frames, we use the following syntax: STREAM[ID, Stream Data [, FIN]]. 324 The first element is the Stream ID, the second is the Stream Data 325 contained in the frame and the last one is optional and indicates 326 that the FIN bit is set. 328 Client Concentrator Final Destination 329 | STREAM[0, "TCP Connect, End"] || | 330 |------------------------------>|| SYN | 331 | ||==============================>| 332 | || SYN+ACK | 333 |STREAM[0,"TCP Connect OK, End"]||<==============================| 334 |<------------------------------|| | 335 | STREAM[0, "bytestream data"] || | 336 |------------------------------>|| bytestream data, ACK | 337 | ||==============================>| 338 | || bytestream data, ACK | 339 | STREAM[0, "bytestream data"] ||<==============================| 340 |<------------------------------|| FIN | 341 | STREAM[0, "", FIN] ||<==============================| 342 |<------------------------------|| ACK | 343 | STREAM[0, "", FIN] ||==============================>| 344 |------------------------------>|| FIN | 345 | ||==============================>| 346 | || ACK | 347 | ||<==============================| 349 Legend: 350 --- QUIC connection 351 === TCP connection 353 Figure 7: Example flow for the stream mode 355 On Figure 7, the client is initiating a TCP connection in stream mode 356 to the Final Destination. A request and a response are exchanged, 357 then the connection is torn down gracefully. A remote-initiated 358 connection accepted by the concentrator on behalf of the client would 359 have the order and the direction of all messages reversed. 361 7. Security Considerations 362 7.1. Denial of Service 364 There is a risk of an amplification attack when the Concentrator 365 sends a TCP SYN in response of a TCP Connect TLV. When a TCP SYN is 366 larger than the client request, the Concentrator amplifies the client 367 traffic. To mitigate such attacks, the Concentrator SHOULD rate 368 limit the number of pending TCP Connect from a given client. 370 8. IANA Considerations 372 8.1. QUIC tunnel stream TLVs 374 IANA is requested to create a new "QUIC tunnel stream Parameters" 375 registry. 377 The following subsections detail new registries within "QUIC tunnel 378 stream Parameters" registry. 380 8.1.1. QUIC tunnel stream TLVs Types 382 IANA is request to create the "QUIC tunnel stream TLVs Types" sub- 383 registry. New values are assigned via IETF Review (Section 4.8 of 384 [RFC8126]). 386 The initial values to be assigned at the creation of the registry are 387 as follows: 389 +------+-----------------------------+------------+ 390 | Code | Name | Reference | 391 +------+-----------------------------+------------+ 392 | 0 | TCP Connect TLV | [This-Doc] | 393 | 1 | TCP Connect OK TLV | [This-Doc] | 394 | 2 | Error TLV | [This-Doc] | 395 | 255 | End TLV | [This-Doc] | 396 +------+-----------------------------+------------+ 398 8.1.2. QUIC tunnel streams TLVs Error Types 400 IANA is request to create the "QUIC tunnel stream TLVs Error Types" 401 sub-registry. New values are assigned via IETF Review (Section 4.8 402 of [RFC8126]). 404 The initial values to be assigned at the creation of the registry are 405 as follows: 407 +------+---------------------------+------------+ 408 | Code | Name | Reference | 409 +------+---------------------------+------------+ 410 | 0 | Protocol Violation | [This-Doc] | 411 | 1 | ICMP packet received | [This-Doc] | 412 | 2 | Malformed TLV | [This-Doc] | 413 | 3 | Network Failure | [This-Doc] | 414 +------+---------------------------+------------+ 416 8.2. QUIC Transport Parameter Registry 418 This document defines a new transport parameter for the negotiation 419 of the stream mode. The following entry in Table 1 should be added 420 to the "QUIC Transport Parameters" registry under the "QUIC Protocol" 421 heading. 423 +=======+=========================+===============+ 424 | Value | Parameter Name | Specification | 425 +=======+=========================+===============+ 426 | TBD | quic_tunnel_stream_mode | Section 4 | 427 +-------+-------------------------+---------------+ 429 Table 1: Addition to QUIC Transport Parameters 430 Entries 432 9. References 434 9.1. Normative References 436 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 437 Requirement Levels", BCP 14, RFC 2119, 438 DOI 10.17487/RFC2119, March 1997, 439 . 441 [RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing 442 Architecture", RFC 4291, DOI 10.17487/RFC4291, February 443 2006, . 445 [RFC6890] Cotton, M., Vegoda, L., Bonica, R., Ed., and B. Haberman, 446 "Special-Purpose IP Address Registries", BCP 153, 447 RFC 6890, DOI 10.17487/RFC6890, April 2013, 448 . 450 [I-D.piraux-intarea-quic-tunnel] 451 Piraux, M., Bonaventure, O., and A. Masputra, "Tunneling 452 Internet protocols inside QUIC", Work in Progress, 453 Internet-Draft, draft-piraux-intarea-quic-tunnel-00, 2 454 November 2020, . 457 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 458 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 459 May 2017, . 461 9.2. Informative References 463 [I-D.ietf-tcpm-converters] 464 Bonaventure, O., Boucadair, M., Gundavelli, S., Seo, S., 465 and B. Hesmans, "0-RTT TCP Convert Protocol", Work in 466 Progress, Internet-Draft, draft-ietf-tcpm-converters-19, 467 22 March 2020, . 470 [I-D.ietf-quic-transport] 471 Iyengar, J. and M. Thomson, "QUIC: A UDP-Based Multiplexed 472 and Secure Transport", Work in Progress, Internet-Draft, 473 draft-ietf-quic-transport-32, 20 October 2020, 474 . 477 [I-D.piraux-quic-tunnel] 478 Piraux, M., Bonaventure, O., and A. Masputra, "Tunneling 479 Internet protocols inside QUIC", Work in Progress, 480 Internet-Draft, draft-piraux-quic-tunnel-03, 12 August 481 2020, . 484 [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for 485 Writing an IANA Considerations Section in RFCs", BCP 26, 486 RFC 8126, DOI 10.17487/RFC8126, June 2017, 487 . 489 Appendix A. Change Log 491 A.1. Since draft-piraux-quic-tunnel-tcp-01 493 * Nits 495 A.2. Since draft-piraux-quic-tunnel-tcp-00 496 * Add the quic_tunnel_stream_mode transport parameter for 497 negotiation 499 Acknowledgments 501 This documents draws heavily on the initial version of 502 [I-D.piraux-quic-tunnel]. Their contributors are thanked again here. 503 This work was partially supported by the MQUIC project. 505 Authors' Addresses 507 Maxime Piraux 508 UCLouvain 510 Email: maxime.piraux@uclouvain.be 512 Olivier Bonaventure 513 UCLouvain 515 Email: olivier.bonaventure@uclouvain.be