Session 2: Protocols and Architectures HotNets '20, November 4–6, 2020, Virtual Event, USA TCPLS: Closely Integrating TCP and TLS Florentin Rochet Emery Assogba Olivier Bonaventure UCLouvain, Louvain-la-Neuve, UCLouvain, Louvain-la-Neuve, UCLouvain, Louvain-la-Neuve, Belgium Belgium Belgium [email protected] [email protected] [email protected] ABSTRACT During the late nineties, early 2000s, transport protocol researchers TCP and TLS are among the most essential protocols in today’s explored other alternatives to TCP . Two of these approaches were Internet. TCP ensures reliable delivery of data while TLS secures adopted and standardized within the IETF: DCCP [43] and SCTP the data transfer. Following the layered model, TLS was designed [65]. We rarely use DCCP today. Despite its benefits (support for to be as independent as possible from the underlying transport multihoming, better design, and extensibility), only a few niche protocol. applications use SCTP [12]. This limited deployment is probably This paper revisits this assumption and demonstrates the various due to two different factors. First, SCTP required changes tothe benefits that a closer integration between TCP and TLS brings. We applications to replace TCP . Second, operators have deployed mid- implement a first TCPLS prototype that demonstrates the feasibility dleboxes (NAT, firewalls) that often block packets that do not carry of this integration. We show its usefulness on different use cases TCP or UDP [35]. such as the benefit of bandwidth aggregation during a connection SCTP initially supported multihoming by switching from one migration, and discuss several open research directions. path to another. It was later extended to be able to use different paths continuously [40]. Multipath TCP [26, 57] brought similar CCS CONCEPTS multihoming capabilitiy to TCP , and included a coupled congestion control scheme [75], later brought to SCTP as well. This particular • Networks ! Session protocols. succession of events shows how different designs can collobarate to advance each others. Multipath TCP is now deployed, notably KEYWORDS on smartphones [8]. Other recent TCP extensions include TCP Fast Transport Layer; TCPLS; Cross-Layer; Extensibility Open [15] or TCPCrypt [7]. In the mid-nineties, the Secure Socket Layer protocol was pro- ACM Reference Format: Florentin Rochet, Emery Assogba, and Olivier Bonaventure. 2020. TCPLS: posed to secure emerging e-commerce websites [22]. This protocol Closely Integrating TCP and TLS. In Proceedings of the 19th ACM Workshop evolved in different versions of the Transport Layer Security (TLS ) on Hot Topics in Networks (HotNets ’20), November 4–6, 2020, Virtual Event, protocol, the most recent one being version 1.3 [58]. Many details USA. ACM, New York, NY, USA, 8 pages. https://doi.org/10.1145/3422604. of the TLS protocol have changed since the first version of SSL [44]. 3425947 Nowadays, TLS is almost ubiquitous on web servers [34] thanks to the availability of various TLS implementations and automated 1 INTRODUCTION certificate authorities [1]. Furthermore, many non-web applications also rely on TLS [2]. The Transmission Control Protocol (TCP )[55] is one of the most Transport protocols continued to evolve in parallel. QUIC started critical protocols in today’s Internet. A wide range of applications as a proprietary protocol used by Google to speed up web trans- that require reliable delivery use it. During the last four decades, fers [45, 60]. During the last years, it evolved into a complete trans- TCP evolved under the pressure of competing protocols. During port protocol whose standardization is being finalized within the the 1980s, software-based TCP implementations were considered IETF [39]. QUIC combines the functions that are usually found in too slow. Researchers proposed new transport protocols such as TCP , TLS , and HTTP/2. A key characteristic of QUIC is that it XTP [61] which could be implemented in hardware. TCP imple- encrypts almost all the packets, including most of their headers. mentations got a considerable speed boost [16], and XTP did not Although QUIC is essentially a new transport protocol, it does not succeed. However, the TCP speed boost and usage triggered the run directly above IP in contrast with SCTP, TCP , or DCCP. QUIC development of various important TCP extensions, including, times- runs above UDP. This choice is mainly motivated by the desire to tamps and large windows [10] to scale to the gigabit link speed or avoid as much as possible middlebox interference. QUIC’s clean Selective Acknowledgments [25]. architecture has attracted researchers who have already proposed various extensions to the protocol [17, 18, 37, 50, 54, 66, 72]. Permission to make digital or hard copies of all or part of this work for personal or Does the finalization of version 1 of the QUIC specification mark classroom use is granted without fee provided that copies are not made or distributed TCP for profit or commercial advantage and that copies bear this notice and the full citation the end of the era and move all transport research on this new on the first page. Copyrights for components of this work owned by others than the protocol? We do not think so. History tells us that TCP has evolved author(s) must be honored. Abstracting with credit is permitted. To copy otherwise, or with competing transport protocols. QUIC is today’s competitor, republish, to post on servers or to redistribute to lists, requires prior specific permission and/or a fee. Request permissions from [email protected]. but there is still plenty of room to improve TCP . HotNets ’20, November 4–6, 2020, Virtual Event, USA In this paper, we take a step back. As QUIC benefits from a closer © 2020 Copyright held by the owner/author(s). Publication rights licensed to ACM. integration between the reliability and the security mechanisms, ACM ISBN 978-1-4503-8145-1/20/11...$15.00 TCP TLS TLS https://doi.org/10.1145/3422604.3425947 we reconsider the separation between and . brings 45 Session 2: Protocols and Architectures HotNets '20, November 4–6, 2020, Virtual Event, USA security features, but TLS 1.3 can do much more. Thanks to the TLS handshake messages and new TLS records. Since this informa- TLS 1.3 messages and records’ extensibility, TLS can provide a tion is encrypted and authenticated, the communicating hosts can secondary channel that enables hosts to exchange more control exchange new control information without encountering middle- information and structured data. Furthermore, since TLS records box interference. We describe several examples of these new types are encrypted, middleboxes cannot easily interfere with the data of control information in Section 2.2 and Section 3.2. exchanged over this new channel. In our current prototype, a TCPLS session starts with a classic We combine TCP and TLS in a protocol that we call TCPLS . We TCP handshake. Immediately after, the client sends the ClientHello describe in Section 2 a first design for TCPLS with the goals of (i) TLS message. The server replies with a ServerHello message which solving extensibility issues in TCP . (ii) Exporting complex trans- can contain encrypted data but also encrypted control information. port features to the application and (iii) drawing a path to make For example, a dual-stack server may advertise its IPv6 address in TCP /TLS a good challenger to QUIC with modern appications. Then, the encrypted ServerHello message when contacted over its IPv4 we discuss how TLS ’ flexible record layer can be used to provide a address. We highlight one of our roadmap features in Section 4 to new channel to exchange information between TCPLS implementa- enable a 0-RTT TCPLS which would enable TCP to catchup the QUIC tions. The design presentation concludes with an overview of the design regarding fast connection establishment. We also describe API to interact with the application. Our second contribution is the in Section 3 how our current prototype uses this information to ongoing implementation of a TCPLS prototype on Linux by extend- support connection migration, failover, and other features. ing picotls, a TLS 1.3 implementation. We use it in Section 3 Once the TCPLS session has been established, TCPLS sends TLS to illustrate the benefits of TCPLS with a multihoming connection records. Most of these records contain application data transmit- migration use case. Finally, we analyze in Section 4 some of the ted by the client or the server. The control channel between the research questions that TCPLS opens. client and the server enables TCPLS to support new features, such as streams. Indeed, applications such as HTTP/2 support multiple streams mapped to a single TCP connection. However, there are 2 TCPLS DESIGN situations, e.g., to prevent head-of-line blocking, where different TCPLS offers a cross-layer interface to TLS and TCP with the moti- streams should be mapped over other underlying TCP connections. vation to do more than securing the transport layer. Merging the With TCPLS , the client and the server can establish different datas- stacks benefits both protocols and the application using this new treams over a single TCPLS session. The data from all these streams approach. First, TCP suffers from a lack of extensibility due tosize is encrypted using TLS . Furthermore, thanks to the TCPLS API, the restrictions in its header and due to potential middlebox interfer- client and the server can map each data stream to an underlying ences [35]. TCPLS aims to solve TCP ’s extensibility issue in the long TCP connection. Thus, a TCPLS session can be composed of one run by offering a secure control channel to exchange TCP options or more TCP connections similarly as a Multipath TCP connection without suffering from middlebox interferences and size restric- gathers subflows. Note that, if the multipath mode is enabled, then tions in TCP headers.