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