idnits 2.17.1 draft-piraux-tcpls-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 (25 October 2021) is 885 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- -- Obsolete informational reference (is this intentional?): RFC 4960 (Obsoleted by RFC 9260) -- Obsolete informational reference (is this intentional?): RFC 7540 (Obsoleted by RFC 9113) Summary: 0 errors (**), 0 flaws (~~), 1 warning (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group M. Piraux 3 Internet-Draft O. Bonaventure 4 Intended status: Informational UCLouvain 5 Expires: 28 April 2022 F. Rochet 6 University of Edinburgh 7 25 October 2021 9 TCPLS: Modern Transport Services with TCP and TLS 10 draft-piraux-tcpls-00 12 Abstract 14 This document specifies a protocol leveraging TCP and TLS to provide 15 modern transport services such as multiplexing, connection migration 16 and multipath in a secure manner. 18 Discussion Venues 20 This note is to be removed before publishing as an RFC. 22 Source for this draft and an issue tracker can be found at 23 https://github.com/mpiraux/draft-piraux-tcpls. 25 Status of This Memo 27 This Internet-Draft is submitted in full conformance with the 28 provisions of BCP 78 and BCP 79. 30 Internet-Drafts are working documents of the Internet Engineering 31 Task Force (IETF). Note that other groups may also distribute 32 working documents as Internet-Drafts. The list of current Internet- 33 Drafts is at https://datatracker.ietf.org/drafts/current/. 35 Internet-Drafts are draft documents valid for a maximum of six months 36 and may be updated, replaced, or obsoleted by other documents at any 37 time. It is inappropriate to use Internet-Drafts as reference 38 material or to cite them other than as "work in progress." 40 This Internet-Draft will expire on 28 April 2022. 42 Copyright Notice 44 Copyright (c) 2021 IETF Trust and the persons identified as the 45 document authors. All rights reserved. 47 This document is subject to BCP 78 and the IETF Trust's Legal 48 Provisions Relating to IETF Documents (https://trustee.ietf.org/ 49 license-info) in effect on the date of publication of this document. 50 Please review these documents carefully, as they describe your rights 51 and restrictions with respect to this document. Code Components 52 extracted from this document must include Simplified BSD License text 53 as described in Section 4.e of the Trust Legal Provisions and are 54 provided without warranty as described in the Simplified BSD License. 56 Table of Contents 58 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 59 2. Conventions and Definitions . . . . . . . . . . . . . . . . . 5 60 3. Modern Transport Services . . . . . . . . . . . . . . . . . . 5 61 4. TCPLS Overview . . . . . . . . . . . . . . . . . . . . . . . 6 62 4.1. Multiple Streams . . . . . . . . . . . . . . . . . . . . 7 63 4.2. Multiple TCP connections . . . . . . . . . . . . . . . . 8 64 4.2.1. Joining TCP connections . . . . . . . . . . . . . . . 8 65 4.2.2. Failover . . . . . . . . . . . . . . . . . . . . . . 9 66 4.2.3. Migration . . . . . . . . . . . . . . . . . . . . . . 9 67 4.2.4. Multipath transport . . . . . . . . . . . . . . . . . 10 68 4.3. Record protection . . . . . . . . . . . . . . . . . . . . 10 69 4.4. Closing a TCPLS session . . . . . . . . . . . . . . . . . 11 70 5. TCPLS Protocol . . . . . . . . . . . . . . . . . . . . . . . 11 71 5.1. TCPLS TLS Extensions . . . . . . . . . . . . . . . . . . 11 72 5.1.1. TCPLS . . . . . . . . . . . . . . . . . . . . . . . . 12 73 5.1.2. TCPLS Join . . . . . . . . . . . . . . . . . . . . . 12 74 5.2. TCPLS Frames . . . . . . . . . . . . . . . . . . . . . . 12 75 5.2.1. Padding frame . . . . . . . . . . . . . . . . . . . . 13 76 5.2.2. Ping frame . . . . . . . . . . . . . . . . . . . . . 13 77 5.2.3. Stream frame . . . . . . . . . . . . . . . . . . . . 14 78 5.2.4. ACK frame . . . . . . . . . . . . . . . . . . . . . . 14 79 5.2.5. New Token frame . . . . . . . . . . . . . . . . . . . 15 80 5.2.6. Connection Reset frame . . . . . . . . . . . . . . . 15 81 6. Security Considerations . . . . . . . . . . . . . . . . . . . 16 82 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16 83 7.1. TCPLS TLS Extensions . . . . . . . . . . . . . . . . . . 16 84 7.2. TCPLS Frames . . . . . . . . . . . . . . . . . . . . . . 16 85 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 16 86 8.1. Normative References . . . . . . . . . . . . . . . . . . 17 87 8.2. Informative References . . . . . . . . . . . . . . . . . 17 88 Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 18 89 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 19 91 1. Introduction 93 The TCP/IP protocol stack continuously evolves. In the early days, 94 most applications were interacting with the transport layer (mainly 95 TCP, but also UDP) using the socket API. This is illustrated in 96 Figure 1. 98 +------------------------------+ 99 | Application | 100 +------------------------------+ 101 | TCP/UDP | 102 +------------------------------+ 103 | IPv4 | 104 +------------------------------+ 106 Figure 1: The classical TCP/IP protocol stack 108 The TCP/IP stack has slowly evolved and the figure above does not 109 anymore describe current Internet applications. IPv6 is now widely 110 deployed next to IPv4 in the network layer. In the transport layer, 111 protocols such as SCTP [RFC4960] or DCCP [RFC6335] and TCP extensions 112 including Multipath TCP [RFC8684] or tcpcrypt [RFC8548] have been 113 specified. The security aspects of the TCP/IP protocol suite are 114 much more important today than in the past [RFC7258]. Many 115 applications rely on TLS [RFC8446] and their stack is similar to the 116 one shown in Figure 2. 118 +------------------------------+ 119 | Application | 120 +------------------------------+ 121 | TLS | 122 +------------------------------+ 123 | TCP | 124 +------------------------------+ 125 | IPv4/IPv6 | 126 +------------------------------+ 128 Figure 2: Today's TCP/IP protocol stack 130 Recently, the IETF went one step further in improving the transport 131 layer with the QUIC protocol [RFC9000]. QUIC is a new secure 132 transport protocol primarily designed for HTTP/3. It includes the 133 reliability and congestion control features that are part of TCP and 134 integrates the security features of TLS 1.3 [RFC8446]. This close 135 integration between the reliability and security features brings a 136 lot of benefits in QUIC. QUIC runs above UDP to be able to pass 137 through most middleboxes and to be implementable in user space. 138 While QUIC reuses TLS, it does not strictly layer TLS on top of UDP 139 as DTLS [I-D.ietf-tls-dtls13]. This organization, illustrated in 140 Figure 3 provides much more flexibility than simply layering TLS 141 above UDP. For example, the QUIC migration capabilities enable an 142 application to migrate an existing QUIC session from an IPv4 path to 143 an IPv6 one. 145 +------------------------------+ 146 | Application | 147 +------------------------------+ 148 |.......... | 149 | TLS | QUIC ..........| 150 |.......... | UDP | 151 +------------------------------+ 152 | IPv4/IPv6 | 153 +------------------------------+ 155 Figure 3: QUIC protocol stack 157 In this document, we revisit how TCP and TLS 1.3 can be used to 158 provide modern transport services to applications. We apply a 159 similar principle and combine TCP and TLS 1.3 in a protocol that we 160 call TCPLS. TCPLS leverages the security features of TLS 1.3 like 161 QUIC, but without begin simply layered above a single TCP connection. 162 In addition, TCPLS reuses the existing TCP stacks and TCP's wider 163 support in current networks. A preliminary version of the TCPLS 164 protocol is described in [CONEXT21]. 166 +------------------------------+ 167 | Application | 168 +------------------------------+ 169 |.......... | 170 | TLS | TCPLS ..........| 171 |.......... | TCP | 172 +------------------------------+ 173 | IPv4/IPv6 | 174 +------------------------------+ 176 Figure 4: TCPLS in the TCP/IP protocol stack 178 In this document, we use the term TLS/TCP to refer to the TLS 1.3 179 protocol running over one TCP connection. We reserve the word TCPLS 180 for the protocol proposed in this document. 182 This document is organized as follows. First, Section 3 summarizes 183 the different types of services that modern transports expose to 184 application. Section 4 gives an overview of TCPLS and how it 185 supports these services. Finally, Section 5 describes the TCPLS in 186 more details and the TLS Extensions introduced in this document. 188 2. Conventions and Definitions 190 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 191 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 192 "OPTIONAL" in this document are to be interpreted as described in 193 BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all 194 capitals, as shown here. 196 3. Modern Transport Services 198 Application requirements and the devices they run on evolve over 199 time. In the early days, most applications involved single-file 200 transfer and ran on single-homed computers with a fixed-line network. 201 Today, web-based applications require exchanging multiple objects, 202 with different priorities, on devices that can move from one access 203 network to another and that often have multiple access networks 204 available. Security is also a key requirement of applications that 205 evolved from only guaranteeing the confidentiality and integrity of 206 application messages to also preventing pervasive monitoring. 208 With TCP and TLS/TCP, applications use a single connection that 209 supports a single bytestream in each direction. Some TCP 210 applications such as HTTP/2 [RFC7540] use multiple streams, but these 211 are mapped to a single TCP connection which leads to Head-of-Line 212 (HoL) blocking when packet losses occur. SCTP [RFC4960] supports 213 multiple truly-concurrent streams and QUIC adopted a similar approach 214 to prevent HoL blocking. 216 Modern transport services also changed the utilization of the 217 underlying network. With TCP, when a host creates a connection, it 218 is bound to the IP addresses used by the client and the server during 219 the handshake. When the client moves and receives a different IP 220 address, it has to reestablish all TCP connections bound to the 221 previous address. When the client and the server are dual-stack, 222 they cannot easily switch from one address family to another. Happy 223 Eyeballs [RFC8305] provides a partial answer to this problem for web 224 applications with heuristics that clients can use to probe TCP 225 connections with different address families. With Multipath TCP, the 226 client and the server can learn other addresses of the remote host 227 and combine several TCP connections within a single Multipath TCP 228 connection that is exposed to the application. This supports various 229 use cases [RFC8041]. QUIC [RFC9000] enables applications to migrate 230 from one network path to another, but not to simultaneously use 231 different paths. 233 4. TCPLS Overview 235 In order for TCPLS to be widely compatible with middleboxes that 236 inspect TCP segments and TLS records, TCPLS does not modify the TCP 237 connection establishment and only adds a TLS extension to the TLS 238 handshake. Figure 5 illustrates the opening of a TCPLS session which 239 starts with the TCP 3-way handshake, followed by the TLS handshake. 240 In the Extensions of the ClientHello and in the server 241 EncryptedExtensions, the tcpls TLS Extension is introduced to 242 announce the support of TCPLS. 244 Client Server 245 | SYN | 246 |------------------------------------------>| 247 | SYN+ACK | 248 |<------------------------------------------| 249 | ACK, TLS ClientHello + tcpls | 250 |------------------------------------------>| 251 | TLS ServerHello, TLS EncryptedExtensions | 252 | + tcpls, ... | 253 |<------------------------------------------| 254 | TLS Finished | 255 |------------------------------------------>| 256 | | 258 Figure 5: Starting a TCPLS session 260 TCP/TLS offers a single encrypted bytestream service to the 261 application. To achieve this, TLS records are used to encrypt and 262 secure chunks of the application bytestream and are then sent through 263 the TCP bytestream. TCPLS leverages TLS records in a different way. 264 TCPLS defines its own framing mechanism that allows encoding both 265 application data and control information. A TCPLS frame is the basic 266 unit of information for TCPLS. One or more TCPLS frames can be 267 placed inside a TLS record. A TCPLS frame always fits in a single 268 record. This TLS record is then reliably transported by a TCP 269 connection. Figure 6 illustrates the relationship between TCPLS 270 frames and TLS records. 272 TCPLS Data TCP Control TCPLS Data TCPLS Data 273 abcdef 0010010 ghijkl mnopq... 274 <---------> <-----------> <---------> <------------> 275 / / 276 / / 277 | / 278 | / 279 | / 280 | / 281 | / 282 | / 283 +----------------+ +-----------------+ 284 | TLS record n | | TLS record n+1 | .... 285 +----------------+ +-----------------+ 287 Figure 6: The first TLS record contains three TCPLS frames 289 4.1. Multiple Streams 291 TCPLS extends the service provided by TCP with streams. Streams are 292 independent bidirectional bytestreams that can be used by 293 applications to concurrently convey several objects over a TCPLS 294 session. Streams can be opened by the client and by the server. 296 Streams are identified by a 32-bit unsigned integer. The parity of 297 this number indicates the initiator of the stream. The client opens 298 even-numbered streams while the server opens odd-numbered streams. 299 Streams are opened in sequence, e.g. a client that has opened stream 300 0 will use stream 2 as the next one. 302 Data is exchanged using Stream frames whose format is described in 303 Section 5.2.3. Each Stream frame carries a chunk of data of a given 304 stream. Applications can mark the end of a stream to close it. 306 Similarly to HTTP/2 [RFC7540], conveying several streams on a single 307 TCP connection introduces Head-of-Line (HoL) blocking between the 308 streams. To alleviate this, TCPLS provides means to the application 309 to choose the degree of HoL blocking resilience it needs for its 310 application objects by spreading streams among different underlying 311 TCP connections. 313 4.2. Multiple TCP connections 315 TCPLS is not restricted to using a single TCP connection to exchange 316 frames. A TCPLS session starts with the TCP connection that was used 317 to transport the TLS handshake. After this handshake, other TCP 318 connections can be added to a TCPLS session, either to spread the 319 load or for failover. TCPLS manages the utilization of the 320 underlying TCP connections within a TCPLS session. 322 Multipath TCP enables both the client and the server to establish 323 additional TCP connections. However, experience has shown that 324 additional subflows are only established by the clients. TCPLS 325 focuses on this deployment and only allows clients to create 326 additional TCP connections. 328 Using Multipath TCP, a client can try to establish a new TCP 329 connection at any time. If a server wishes to restrict the number of 330 TCP connections that correspond to one Multipath TCP connection, it 331 has to respond with RST to the in excess connection attempts. TCPLS 332 takes another approach. To control the number of connections that a 333 client can establish, a TCPLS server supplies unique tokens. A 334 client includes one of the server supplied tokens when it attaches a 335 new TCP connection to a TCPLS session. Each token can only be used 336 once, hence limiting the amount of additional TCP connections. 338 4.2.1. Joining TCP connections 340 The TCPLS server provides tokens to the client in order to join new 341 TCP connections to the TCPLS session. Figure 7 illustrates a client 342 and server first establishing a new TCPLS session as described in 343 Section 4. Then the server sends a token over this connection using 344 the New Token frame. Each token has a sequence number (e.g. 1) and a 345 value (e.g. "abc"). The client uses this token to open a new TCP 346 connection and initiates the TCPLS handshake. It adds the token 347 inside the TCPLS Join TLS extension in the ClientHello. 349 <-1.TCPLS Handshake-> 350 .---------------------------------. 351 | <-2.New Token(1,abc) | 352 v v 353 +--------+ +--------+ 354 | Client | | Server | 355 +--------+ +--------+ 356 ^ ^ 357 | 3.TCPLS Handshake + Join(abc)-> | Legend: 358 .---------------------------------. --- TCP connection 360 Figure 7: Joining a new TCP connection 362 When receiving a TCPLS Join Extension, the server validates the token 363 and associates the TCP connection to the TCPLS session. 365 Each TCP connection that is part of a TCPLS session is identified by 366 a 32-bit unsigned integer called its Connection ID. The first TCP 367 connection of a session corresponds to Connection ID 0. When joining 368 a new connection, the sequence number of the token, i.e. 1 in our 369 example, becomes the Connection ID of the connection. The Connection 370 ID enables the Client and the Server to identify a specific TCP 371 connection within a given TCPLS session. 373 4.2.2. Failover 375 TCPLS supports two types of failover. In make-before-break, the 376 client creates a TCP connection using the procedure described in 377 Section 4.2.1 but only uses it once the initial connection fails. 379 In break-before-make, the client creates the initial TCP connection 380 and uses it for the TCPLS handshake and the data. The server 381 advertises one or more tokens over this connection. Upon failure of 382 the initial TCP connection, the client initiates a second TCP 383 connection using the server-provided token. 385 In both cases, some records sent by the client or the server might be 386 in transit when the failure occurs. Some of these records could have 387 been partially received but not yet delivered to the TCPLS layer when 388 the underlying TCP connection fails. Other records could have 389 already been received, decrypted and data of their frames could have 390 been delivered to the application. To prevent data losses and 391 duplication, TCPLS includes its own acknowledgments. 393 A TCPLS receiver acknowledges the received records using the ACK 394 frame. Records are acknowledged after the record protection has been 395 successfully removed. This enables the sender to know which records 396 have been received. TCPLS enables the endpoint to send 397 acknowledgments for a TCP connection over any connections, e.g. not 398 only the receiving connection. 400 4.2.3. Migration 402 To migrate from a given TCP connection, an endpoint stops 403 transmitting over this TCP connection and sends the following frames 404 on other TCP connections. It leverages the acknowledgments to 405 retransmit the frames of TLS records that have not been yet 406 acknowledged. 408 When an endpoint abortfully closes a TCP connection, its peer 409 leverages the acknowlegments to retransmit the TLS records that were 410 not acknowlegded. 412 4.2.4. Multipath transport 414 TCPLS also supports the utilization of different TCP connections, 415 over different paths or interfaces, to improve throughput or spread 416 stream frames over different TCP connections. When the endpoints 417 have opened several TCP connections, they can send frames over the 418 connections. TCPLS can send all the stream frames belonging to a 419 given stream over one or more underlying TCP connections. The latter 420 enables bandwidth aggregation by using TCP connections established 421 over different network paths. 423 4.3. Record protection 425 When adding new TCP connections to a TCPLS session, an endpoint does 426 not complete the TLS handshake. TCPLS provides a nonce construction 427 for TLS record protection that is used for all connections of a 428 session. This reduces the cryptographic cost of adding connections. 429 The endpoints SHOULD send TLS messages to form an apparent complete 430 TLS handshake to middleboxes. 432 In order to use the TLS session over multiple connections, TCPLS adds 433 a record sequence number space per connection that is maintained 434 independently at both sides. Each record sent over a TCPLS session 435 is identified by the Connection ID of its connection and its record 436 sequence number. Each record nonce is constructed as defined in 437 Figure 8. 439 N N-32 64 0 440 +---------------------------------------------------------------+ 441 | client/server_write_iv | 442 +---------------------------------------------------------------+ 443 XOR XOR 444 +-------------------+ +--------------------+ 445 | Connection ID | | Conn. record sequ. | 446 +-------------------+ +--------------------+ 448 Figure 8: TCPLS TLS record nonce construction 450 This construction guarantees that every TLS record sent over the TLS 451 session is protected with a unique nonce. As in TLS 1.3, the per- 452 connection record sequence is implicit. 454 4.4. Closing a TCPLS session 456 Endpoints notify their peers that they do not intend to send more 457 data over a given TCPLS session by sending a TLS Alert 458 "close_notify". The alert can be sent over one or more TCP 459 connections of the session. The alert MUST be sent before closing 460 the last TCP connection of the TCPLS session. The endpoint MAY close 461 its side of the TCP connections after sending the alert. 463 When all TCP connections of a session are closed and the TLS Alert 464 "close_notify" was exchanged in both directions, the TCPLS session is 465 considered as closed. 467 We leave defining an abortful and idle session closure mechanisms for 468 future versions of this document. 470 5. TCPLS Protocol 472 5.1. TCPLS TLS Extensions 474 This document specifies two TLS extensions used by TCPLS. The first, 475 "tcpls", is used to announce the support of TCPLS. The second, 476 "tcpls_join", is used to join a TCP connection to a TCPLS session. 477 Their types are defined as follows. 479 enum { 480 tcpls(TBD1), 481 tcpls_join(TBD2), 482 (65535) 483 } ExtensionType; 485 The table below indicates the TLS messages where these extensions can 486 appear. "CH" indicates ClientHello while "EE" indicates 487 EncryptedExtensions. 489 +============+======================+ 490 | Extension | Allowed TLS messages | 491 +============+======================+ 492 | tcpls | CH, EE | 493 +------------+----------------------+ 494 | tcpls_join | CH | 495 +------------+----------------------+ 497 Table 1: TLS messages allowed to 498 carry TCPLS TLS Extensions 500 5.1.1. TCPLS 502 The "tcpls" extension is used by the client and the server to 503 announce their support of TCPLS. The extension contains no value. 504 When it is present in both the ClientHello and the 505 EncryptedExtensions, the endpoints MUST use TCPLS after completing 506 the TLS handshake. 508 5.1.2. TCPLS Join 510 struct { 511 opaque token<32>; 512 } Join; 514 The "tcpls_join" extension is used by the client to join the TCP 515 connection on which it is sent to a TCPLS session. The extension 516 contains a Token provided by the server. The client MUST NOT send 517 more than one "tcpls_join" extension in its ClientHello. When 518 receiving a ClientHello with this extension, the server checks that 519 the token is valid and joins the TCP connection to the corresponding 520 TCPLS session. When the token is not valid, the server MUST abort 521 the handshake with an illegal_parameter alert. 523 By controlling the amount of tokens given to the client, the server 524 can control the number of active TCP connections of a TCPLS session. 525 The server SHOULD replenish the tokens when TCP connections are 526 removed from the TCPLS session. 528 5.2. TCPLS Frames 530 TCPLS uses TLS Application Data records to exchange TCPLS frames. 531 After decryption, the record payload consists of a sequence of TCPLS 532 frames. A frame is a Type-Value unit, starting with a byte 533 indicating its frame type followed by type-specific fields. Table 2 534 lists the frames specified in this document. 536 +============+==================+=======+===============+ 537 | Type value | Frame name | Rules | Definition | 538 +============+==================+=======+===============+ 539 | 0x00 | Padding | N | Section 5.2.1 | 540 +------------+------------------+-------+---------------+ 541 | 0x01 | Ping | | Section 5.2.2 | 542 +------------+------------------+-------+---------------+ 543 | 0x02-0x03 | Stream | | Section 5.2.3 | 544 +------------+------------------+-------+---------------+ 545 | 0x04 | ACK | N | Section 5.2.4 | 546 +------------+------------------+-------+---------------+ 547 | 0x05 | New Token | S | Section 5.2.5 | 548 +------------+------------------+-------+---------------+ 549 | 0x06 | Connection Reset | | Section 5.2.6 | 550 +------------+------------------+-------+---------------+ 552 Table 2: TCPLS frames 554 The "Rules" column in Table 2 indicates special requirements 555 regarding certain frames. 557 N: Non-ack-eliciting. Receiving this frame does not elicit the 558 sending of a TCPLS acknowledgment. 560 S: Server only. This frame MUST NOT be sent by the client. 562 5.2.1. Padding frame 564 This frame has no semantic value. It can be used to mitigate traffic 565 analysis on the TLS records of a TCPLS session. The Padding frame 566 has no content. 568 Padding frame { 569 Type (8) = 0x00, 570 } 572 Figure 9: Padding frame format 574 5.2.2. Ping frame 576 This frame is used to elicit an acknowledgment from its peer. It has 577 no content. When an endpoint receives a Ping frame, it acknowledges 578 the TLS record that contains this frame. This frame can be used by 579 an endpoint to check that its peer can receive TLS records over a 580 particular TCP connection. 582 Ping frame { 583 Type (8) = 0x01, 584 } 586 Figure 10: Ping frame format 588 5.2.3. Stream frame 590 This frame is used to carry chunks of data of a given stream. 592 Stream frame { 593 Type (7) = 0x01, 594 FIN (1), 595 Stream ID (32), 596 Offset (64), 597 Length (16), 598 Stream Data (...), 599 } 601 Figure 11: Stream frame format 603 FIN: The last bit of the frame type bit indicates that this Stream 604 frame ends the stream when its value is 1. The last byte of the 605 stream is at the sum of the Offset and Length fields of this 606 frame. 608 Stream ID: A 32-bit unsigned integer indicating the ID of the stream 609 this frame relates to. 611 Offset: A 64-bit unsigned integer indicating the offset in bytes of 612 the carried data in the stream. 614 Length: A 16-bit unsigned integer indicating the length of the 615 Stream Data field. 617 5.2.4. ACK frame 619 This frame is sent by the receiver to acknowledge the receipt of TLS 620 records on a particular TCP connection of the TCPLS session. 621 Although the reliability of the data exchange on a connection is 622 handled by TCP, there are situations such as the failure of a TCP 623 connection where a sender does not know whether the TLS frames that 624 it sent have been correctly received by the peer. The ACK frame 625 allows a TCPLS receiver to indicate the highest TLS record sequence 626 number received on aspecific connection. The ACK frame can be sent 627 over any TCP connection of a TCPLS session. 629 ACK frame { 630 Type (8) = 0x04, 631 Connection ID (32), 632 Highest Record Sequence Received (64), 633 } 635 Figure 12: ACK frame format 637 Connection ID: A 32-bit unsigned integer indicating the TCP 638 connection for which the acknowledgment was sent. 640 Highest Record Sequence Received: A 64-bit unsigned integer 641 indicating the highest TLS record sequence number received on the 642 connection indicated by the Connection ID. 644 5.2.5. New Token frame 646 This frame is used by the server to provide tokens to the client. 647 Each token can be used to join a new TCP connection to the TCPLS 648 session, as described in Section 4.2.1. Clients MUST NOT send New 649 Token frames. 651 New Token frame { 652 Type (8) = 0x05, 653 Sequence (8), 654 Token (256), 655 } 657 Figure 13: New Token frame format 659 Sequence: A 8-bit unsigned integer indicating the sequence number of 660 this token 662 Token: A 32-byte opaque value that can be used as a token by the 663 client. 665 5.2.6. Connection Reset frame 667 This frame is used by the receiver to inform the sender that a TCP 668 connection has been reset. 670 Connection Reset frame { 671 Type (8) = 0x06, 672 Connection ID (32) 673 } 675 Figure 14: Connection Reset format 677 Connection ID: A 32-bit unsigned integer indicating the ID of the 678 connection that failed. 680 6. Security Considerations 682 When issuing tokens to the client as presented in Section 4.2.1, the 683 server SHOULD ensure that their values appear as random to observers 684 and cannot be correlated together for a given TCPLS session. 686 The security considerations for TLS apply to TCPLS. The next 687 versions of this document will elaborate on other security 688 considerations following the guidelines of [RFC3552]. 690 7. IANA Considerations 692 IANA is requested to create a new "TCPLS" heading for the new 693 registry described in Section 5.2. New registrations in TCPLS 694 registries follow the "Specification Required" policy of [RFC8126]. 696 7.1. TCPLS TLS Extensions 698 IANA is requested to add the following entries to the existing "TLS 699 ExtensionType Values" registry. 701 +=======+================+=========+=============+===============+ 702 | Value | Extension Name | TLS 1.3 | Recommended | Reference | 703 +=======+================+=========+=============+===============+ 704 | TBD1 | tcpls | CH, EE | N | This document | 705 +-------+----------------+---------+-------------+---------------+ 706 | TBD2 | tcpls_join | CH | N | This document | 707 +-------+----------------+---------+-------------+---------------+ 709 Table 3 711 Note that "Recommended" is set to N as these extensions are intended 712 for uses as described in this document. 714 7.2. TCPLS Frames 716 IANA is requested to create a new registry "TCPLS Frames Types" under 717 the "TCPLS" heading. 719 The registry governs an 8-bit space. Entries in this registry must 720 include a "Frame name" field containing a short mnemonic for the 721 frame type. The initial content of the registry is present in 722 Table 2, without the "Rules" column. 724 8. References 725 8.1. Normative References 727 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 728 Requirement Levels", BCP 14, RFC 2119, 729 DOI 10.17487/RFC2119, March 1997, 730 . 732 [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for 733 Writing an IANA Considerations Section in RFCs", BCP 26, 734 RFC 8126, DOI 10.17487/RFC8126, June 2017, 735 . 737 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 738 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 739 May 2017, . 741 [RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol 742 Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, 743 . 745 8.2. Informative References 747 [CONEXT21] Rochet, F., Assogba, E., Piraux, M., Edeline, K., Donnet, 748 B., and O. Bonaventure, "TCPLS - Modern Transport Services 749 with TCP and TLS", Proceedings of the The 17th 750 International Conference on emerging Networking 751 EXperiments and Technologies (CoNEXT'21) , December 2021. 753 [I-D.ietf-tls-dtls13] 754 Rescorla, E., Tschofenig, H., and N. Modadugu, "The 755 Datagram Transport Layer Security (DTLS) Protocol Version 756 1.3", Work in Progress, Internet-Draft, draft-ietf-tls- 757 dtls13-43, 30 April 2021, 758 . 761 [RFC3552] Rescorla, E. and B. Korver, "Guidelines for Writing RFC 762 Text on Security Considerations", BCP 72, RFC 3552, 763 DOI 10.17487/RFC3552, July 2003, 764 . 766 [RFC4960] Stewart, R., Ed., "Stream Control Transmission Protocol", 767 RFC 4960, DOI 10.17487/RFC4960, September 2007, 768 . 770 [RFC6335] Cotton, M., Eggert, L., Touch, J., Westerlund, M., and S. 771 Cheshire, "Internet Assigned Numbers Authority (IANA) 772 Procedures for the Management of the Service Name and 773 Transport Protocol Port Number Registry", BCP 165, 774 RFC 6335, DOI 10.17487/RFC6335, August 2011, 775 . 777 [RFC7258] Farrell, S. and H. Tschofenig, "Pervasive Monitoring Is an 778 Attack", BCP 188, RFC 7258, DOI 10.17487/RFC7258, May 779 2014, . 781 [RFC7540] Belshe, M., Peon, R., and M. Thomson, Ed., "Hypertext 782 Transfer Protocol Version 2 (HTTP/2)", RFC 7540, 783 DOI 10.17487/RFC7540, May 2015, 784 . 786 [RFC8041] Bonaventure, O., Paasch, C., and G. Detal, "Use Cases and 787 Operational Experience with Multipath TCP", RFC 8041, 788 DOI 10.17487/RFC8041, January 2017, 789 . 791 [RFC8305] Schinazi, D. and T. Pauly, "Happy Eyeballs Version 2: 792 Better Connectivity Using Concurrency", RFC 8305, 793 DOI 10.17487/RFC8305, December 2017, 794 . 796 [RFC8548] Bittau, A., Giffin, D., Handley, M., Mazieres, D., Slack, 797 Q., and E. Smith, "Cryptographic Protection of TCP Streams 798 (tcpcrypt)", RFC 8548, DOI 10.17487/RFC8548, May 2019, 799 . 801 [RFC8684] Ford, A., Raiciu, C., Handley, M., Bonaventure, O., and C. 802 Paasch, "TCP Extensions for Multipath Operation with 803 Multiple Addresses", RFC 8684, DOI 10.17487/RFC8684, March 804 2020, . 806 [RFC9000] Iyengar, J., Ed. and M. Thomson, Ed., "QUIC: A UDP-Based 807 Multiplexed and Secure Transport", RFC 9000, 808 DOI 10.17487/RFC9000, May 2021, 809 . 811 Acknowledgments 813 This work has been partially supported by the ``Programme de 814 recherche d'interet general WALINNOV - MQUIC project (convention 815 number 1810018)'' and European Union through the NGI Pointer 816 programme for the TCPLS project (Horizon 2020 Framework Programme, 817 Grant agreement number 871528). The authors thank Quentin De Coninck 818 and Louis Navarre for their comments on the first version of this 819 draft. 821 Authors' Addresses 823 Maxime Piraux 824 UCLouvain 826 Email: maxime.piraux@uclouvain.be 828 Olivier Bonaventure 829 UCLouvain 831 Email: olivier.bonaventure@uclouvain.be 833 Florentin Rochet 834 University of Edinburgh 836 Email: frochet@ed.ac.uk