Securing MultiPath TCP

Mathieu Jadin and Gautier Tihon Universite´ catholique de Louvain, Louvain-la-Neuve, Belgium Emails: [email protected], [email protected]

Abstract—MultiPath TCP (MPTCP) is a recent TCP extension protocols can also encrypt and authentic- that enables hosts to send the data belonging to one connection ate data. Security (TLS) [3] was designed for over multiple paths. It is already deployed for various use this purpose. Various documents have analysed the security of cases, notably on smartphones. In parallel with this, there is a growing deployment of encryption and authentication techniques the TLS protocol from different viewpoints [10, 11, 12]. Over to counter various forms of attacks. Tcpcrypt and the Transport the years, various extensions to TLS have been developed and Layer Security (TLS) are some of these security solutions. deployed. Besides attacks on the cryptographic algorithms or In this paper, we propose MPTCPsec, a MultiPath TCP their implementations [10], TLS is also vulnerable to some extension that closely integrates authentication and encryption forms of attacks that affect the underlying TCP protocol [13]. inside the protocol and shows how it counters several types of attacks. In this paper, we propose a security scheme specially designed for Multipath TCP: MPTCPsec (MPTCP secure). I.INTRODUCTION MPTCPsec brings two main improvements compared to using The Transmission Control Protocol (TCP) is the most application layer security protocols such as TLS or SSH above widely used protocol to exchange data over the Internet. MPTCP: It was designed at a time when security was not a major • MPTCPsec can detect and recover from packet injection concern. Multipath TCP [1] is a major extension to TCP attacks by closing a compromised subflow, in constrast that allows data from a single connection to be exchanged with application layer protocols like TLS that just close over different paths. It has already seen significant adoption the TCP connection when they detect an attack. since it is used on all Apple devices to support the Siri voice • MPTCPsec protects the application data (with authentic- recognition application. In Korea, high-end smartphones use ation and encryption) and authenticates the TCP options Multipath TCP to combine WiFi and LTE and achieve higher that are used to control the Multipath TCP connection. bandwidth [2]. This prevents various types of attacks where an attacker During the last decade, security has been a growing concern would try to impact subflows that he does not control. for Internet protocols and various solutions using encryption This paper is organised as follows. We first describe the key and authentication have been deployed. Most of the success- parts of Multipath TCP in Section II. We then detail the main ful deployments are in the application layer with protocols threats that we have considered in our design of MPTCPsec like SSH or TLS [3]. In the network and transport layer, and explain how they can be countrered in Section III. We encryption and authentication have been less successful. When compare MPTCPsec with related work in Section IV. Our IPsec [4] was designed, it was intended as a mandatory part work goes beyond the design of MPTCPsec since we have also of IPv6. IPv6 is now widely deployed but IPsec remains implemented it inside the Linux kernel. Our implementation restricted to some VPNs. In the transport layer, progress has leverages both the reference implementation of Multipath TCP been slower. Three types of solutions have been proposed in the Linux kernel [14] and the Linux crypto API and to improve the security of TCP. A first approach is to tune performs all cryptographic operations inside the kernel. Due the TCP stack to prevent some segment injection attacks. to space limitations, it unfortunately cannot be described in [5, 6]. Another approach is to add authentication to the TCP this short paper. protocol [7]. However, these solutions assume that a secret is shared between the communicating hosts. They are currently II.MULTIPATH TCP only used to authenticate BGP sessions. Another approach is MultiPath TCP [1] uses several paths to exchange data by tcpcrypt [8]. This TCP extension adds authentication and establishing one TCP connection, called subflow in [1], over encryption to TCP. It was designed to provide opportunistic each path. The number of subflows that compose a Multipath encryption. In contrast with application layer solutions such TCP connection is not constant. Subflows can appear and as TLS, it does not use certificates to authenticate the server, disappear during the lifetime of a connection. For example, but allows the client and the server to perform a secure key a smartphone can create a new subflow each time it attaches handshake and negotiate keys. This prevents attacks such as itself to a new WiFi access point. Thanks to the utilisation of pervasive monitoring [9] but does not address man-in-the- multiple subflows, Multipath TCP can support mobility [15] middle attacks. The IETF has formed the tcpinc working and achieve resource pooling [16]. A detailed overview of group to standardise a TCP extension heavily inspired by Multipath TCP may be found in [17]. We focus here on the tcpcrypt [8]. TCP options that are used by Multipath TCP and are relevant 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 Host A Host B Address A1 Address A2 Address B1 Kind Length Subtype (reserved) F m M a A SYN + MP_CAPABLE(Key-A) Data ACK (4 or 8 bytes, depending on flags) Data sequence number (4 or 8 bytes, depending on flags) SYN/ACK + MP_CAPABLE(Key-B) ACK + MP_CAPABLE(Key-A, Key-B) Subflow Sequence Number

Data-Level Length Checksum SYN + MP_JOIN(Token-B, R-A)

Figure 2. Format of the DSS option. SYN/ACK + MP_JOIN(HMAC-B, R-B) ACK + MP_JOIN(HMAC-A)

ACK number space of the subflow. It also contains a cumulative acknowledgement field (Data ACK in Figure 2). Thanks to the Figure 1. MPTCP three-way handshake (between addresses A1 and B1) and DSS option, it is possible to retransmit over a subflow data that subflow establishment (between addresses A2 and B1). R-A (resp. R-B) is the was transmitted initially over another subflow without success. random number of Host A (resp. Host B). HMAC-A (resp. HMAC-B) is equal to HMAC(R-A+R-B, Key-A+Key-B) (resp. HMAC(R-B+R-A, Key-B+Key-A)). The DSS option contains an optional Checksum that allows to detect middlebox interference [1]. When packet losses occur, Multipath TCP first retransmits for understanding the security issues that affect Multipath TCP the lost packets over the same subflow. In this case, the retrans- [18, 19]. mitted packet contains the same DSS option as the original one. If a subflow fails, unacknowledged data previously sent A. Connection and subflow establishment on this subflow must be retransmitted on another subflow. This A Multipath TCP connection starts with a three-way hand- is called a re-injection [1]. In this case, a new DSS shake. The Multipath Capable (MP_CAPABLE) option option is computed to map the retransmitted data onto the is used, as shown in the top of Figure1, to negotiate the use of new subflow. MPTCP and exchange 64-bit keys. These keys are sent in clear The DSS option contains a series of flags. The F flag marks during the handshake of the first subflow1. MPTCP uses these the end of the bytestream. DSS options with the F flag set are keys for three different purposes. Firstly, MPTCP hosts derive called DATA-FIN. They are used to terminate Multipath TCP a token that uniquely identifies the Multipath TCP connection connections as the FIN flag is used in TCP to terminate regular from a hash of the key [1]. Secondly, the Initial Data connections. Sequence Number (IDSN) of a connection is also derived C. Address advertisement from these keys. Thirdly, the keys are used to authenticate the establishment of subflows with the MP_JOIN option. To establish subflows between their different interfaces, The Join (MP_JOIN) option enables hosts to attach new hosts that use Multipath TCP must learn the IP addresses of subflows to an existing Multipath TCP connection. This option the remote host. Multipath TCP uses two TCP options for is used during the three-way handshake that establishes the this purpose. The Add Address (ADD_ADDR) and Remove additional subflow. An example is shown in Figure 1. The Address (REMOVE_ADDR) options allow hosts to advertise establishment of the additional subflow is authenticated with a and remove addresses on which subflows can be established. HMAC computed over random numbers exchanged during the These options are typically included in pure acknowledge- handshake (R-A and R-B in Figure 1) with the keys exchanged ments and the host that receives an option can decide to create during the initial TCP handshake. The token is used by Host a subflow or not towards the advertised address. The ability to B to identify the concerned MPTCP connection. advertise addresses creates a security threat that is discussed in [19, 18]. The latest Multipath TCP draft has added a HMAC B. Data transfer in the ADD_ADDR option to authenticate it. Data Sequence Signal DSS The ( ) option, shown in D. Connection release Figure 2, enables the transmission of data over different paths. In a nutshell, Multipath TCP uses two levels of sequence A Multipath TCP connection can be closed gracefully by numbers: (i) the regular TCP sequence numbers at the subflow using a DSS option with the F flag set (called a DATA-FIN) or level and (ii) the Data Sequence Numbers (DSN) at the con- abruptly with the Fast Close (MP_FASTCLOSE) option. nection level. Each byte sent over a Multipath TCP connection This option is to MPTCP what a RST segment is to TCP. To is identified by one DSN that indicates its position in the prevent attacks with spoofed RST segments, the host that sends bytestream. The DSN option maps these DSNs onto the TCP a MP_FASTCLOSE option in a RST segment must include the sequence numbers that are included in the regular TCP headers key that it sent during the establishment of the initial subflow. and used on the different subflows. Each DSS option maps III.MPTCPSECURE a block of Len bytes from the DSN space to the sequence As described in the previous section, Multipath TCP has 1They also appear in RST segments that carry the MP_FASTCLOSE option been designed to be as secure as regular TCP. The security see Section II-D. threats that were considered during the design of Multipath TCP are described in [19, 18]. Basically, these threats assume prevented thanks to the certificates authenticating the hosts that there is no active attacker on the path between the that can be exchanged during the TLS handshake. Of course, communicating hosts. MPTCPsec goes much beyond those re- this key derivation is not sufficient alone to tackle all the other quirements by considering more powerful attackers, including threats but this is a required step. some who can modify packets. It has been designed to counter six main threats: B. Protecting the data T1) Eavesdropping: an attacker can read the data sent Once MPTCPsec has securely obtained its keys, it can use between hosts on the paths that he controls. them to counter threats T1, T4 and partially T3 by encrypting T2) Identity spoofing: an attacker can impersonate a host and authenticating data. To this end, MPTCPsec uses of because there is no host authentication. Authenticated Encryption with Associated Data (AEAD) al- T3) Data truncation: an attacker can prevent some data from gorithms. These algorithms, according to [21], provide encryp- reaching their final destination without the application tion and authentication of a plaintext and only authentication to noticing the failure. He can do it either by closing the some associated data. These algorithms need as input a shared connection prematurely with a MP_FASTCLOSE or a key and a unique nonce. They produce as output the ciphertext DATA-FIN or by removing some data from the data and an authentication tag. MPTCPsec uses the shared key stream and by modifying the DSNs of all subsequent derived during the TLS handshake and a nonce based on the segments. DSN. T4) Data modification: an attacker can modify, inject and MPTCPsec does not use records like TLS and tcpcrypt remove the data as he wants, i.e., he can change the bits do, but uses DSS options since MPTCPsec is integrated and modify the DSNs of all subsequent segments. to MPTCP. A block of encrypted data is covered by one T5) Segment replay: an attacker can replay a segment already and only one DSS. The ciphertext length is given by the sent (or a part of it). The replay of the payload is Data-Level Length field. This choice requires MPTCPsec to not harmful because the receiver can discard the data authenticate DSS (i.e., because of the DATA-FIN flag) and with an old DSN2. The replay of ADD_ADDR and MP_FASTCLOSE options in order to fully tackle threat T3. REMOVE_ADDR options can be harmful because they are A last important point is the reaction to authentication not idempotent. The consequences of this attack depends failure. MPTCPsec does not close the whole connection since on the option replayed. it is aware of the subflow that has received this corrupted data. T6) Option insertion/removal/modification: an attacker can This prevents potential Denial of Service attacks. Indeed, an insert, modify or remove a MPTCP option from a seg- attacker would only need to control one of the paths used by ment. Even the MP_JOIN and MP_FASTCLOSE options the connection to shut it down. can be forged if the attacker knows the key exchanged C. Protecting TCP options in clear during the first handshake. Again, the impact of this attack depends on the option used. For instance, the Multipath TCP uses TCP options to exchange control in- MP_FASTCLOSE option can close the whole connection formation. Any modification to these options can affect the if the attacker controls a single path. security of a Multipath TCP connection. We now show how MPTCPsec tackles threats T3, T5 and T6. We now describe the algorithms that are included inside The MP_CAPABLE and MP_JOIN options are already au- MPTCPsec to counter these important security threats. thenticated (see Section III-A). A. Securing the Handshake The MP_FASTCLOSE option is authenticated with a HMAC instead of the key since it is also used to encrypt data and it In order to counter almost all the threats but segment would allow eavesdropping (threat T1). The authentication of replay (threat T5), MPTCPsec needs a shared secret: the keys. this option covers partially data truncation (threat T3). Nevertheless, in the regular MPTCP handshake, the session This leaves the authentication of ADD_ADDR, keys are exchanged in clear. MPTCPsec thus leverages the REMOVE_ADDR and DSS options. MPTCPsec could include TLS handshake to derivate the keys. The use of the TLS them as associated data in the same AEAD computation handshake in another protocol has already been designed in used for the data, but it would entail to recompute the whole [20]. Since it allows to take additional data as seed for the ciphertext each time the segment is re-injected on another keys derivation, MPTCPsec uses the MP_CAPABLE options subflow, since the SSN of the DSS option would change. (covering threat T6 for these options) exchanged in order to MPTCPsec therefore authenticates the options separately, so authenticate its content. Indeed, if both hosts do not see the that only the option authentication tag must be recomputed same options, the keys are going to be different. Moreover, this in case of re-injection. secure shared key derivation also prevents threat T6 for the In order to still link these options to the data and thus MP_JOIN option since it is already protected by a HMAC prevent option removal (threat T6), MPTCPsec includes the computed with these keys. Finally, threat T2 is completely data authentication tag in the computation of the option tag. 2This DSN is on 64 bits and therefore there is a barely possible risk of This option tag is computed by a second run of the AEAD wrapping for a connection since no connection sends 264 bytes. algorithm. It is then appended to the ciphertext in the payload Table I THIS TABLE SHOWS HOW THE MPTCP OPTIONSAREPROTECTEDANDTHEIRHANDLINGINCASEOFRE-INJECTION.

Options Protection Re-injection MP CAPABLE Included in TLS export key material Cannot be re-injected MP JOIN HMAC (as in regular MPTCP) Cannot be re-injected ADD ADDR Option tag Nothing can be changed REMOVE ADDR Option tag Nothing can be changed The SSN must be modified. The Data ACK DSS Option tag and the DSN can be truncated or not. MP FASTCLOSE HMAC in the option Nothing can be changed

Table II DEFENCEMECHANISMSUSEDTOPREVENTTHETHREATSTO MPTCP

T2 Identity T3 Data T5 Segment T6 Option T1 Eavesdropping T4 Data modif. spoofing truncation replay modif. TLS handshake v v v v v AEAD on data v v v v AEAD on options v v v HMAC in MP_FASTCLOSE / MP_JOIN v v v

header with DSS encrypted data data tag (option+data tag) tag T3) Data truncation: MPTCPsec is secure against trun- cation attacks. Since all data (and the DSN) sent are Figure 3. Segment format, with tag the authentication tag produced by the authenticated (Section III-B), the sole way to make a AEAD. truncation attack in MPTCPsec would be to close the connection on behalf of one of the hosts and without (i.e., after the encrypted data and its authentication tag). Figure raising an error. But each method to close a connection 3 represents this segment format. is protected: The tag increases the DSN since it is in the payload. • RST and FIN: if an attacker succeeds to close all This makes replay attacks (threat T5) impossible. Indeed the TCP subflows (with RST or FIN), the MPTCP MPTCPsec only needs to check that the segment covering connection itself will not be closed. Therefore, each this DSN has not been already received (e.g., on another host knows that there can be still pending data (and subflow) before applying the options. The DSN should make a new subflows will be created). whole cycle to make a replay attack possible... and it is barely • DATA-FIN: the DATA-FIN is a flag in the DSS possible with 64-bits DSN. These options are thus applied option and MPTCPsec authenticates the DSS (Sec- once and only once. tion III-C). Table I gives a summary of how the options are protected • MP_FASTCLOSE: in MPTCP, if the attacker knows and about what can be or must be changed in the options in the keys sent in clear during the initial handshake, case of re-injection (in order to keep the same semantics). he can forge this option. MPTCPsec removes this As for data authentication failure, MPTCPsec does not close weakness by protecting the key derivation pro- the whole connection since it is aware of the subflow that cess (Section III-A). Moreover, MPTCPsec sends a received this corrupted segment. This prevents potential Denial HMAC instead of the key in order to keep protection of Service attacks. against eavesdroppers (Section III-C). D. MPTCPsec more secure than MPTCP MPTCPsec is therefore secure against truncation attacks. This section shows how MPTCPsec counters the threats T4) Data modification: in MPTCPsec, data cannot be modi- shown at the beginning of Section III. A summary of this fied without raising an error since they are authenticated explanation is shown in Table II. (Section III-B). An attacker cannot even replace some T1) Eavesdropping: MPTCPsec is secure against eaves- data by another authenticated cipher of a previous seg- dropping. The cipher cannot be decrypted without the ment. Indeed, the data are authenticated with their DSN keys thanks to the AEAD algorithm applied on data as associated data. (Section III-B). These keys cannot be learned because T5) Segment replay: ADD_ADDR, REMOVE_ADDR are the they are derived by the TLS handshake (Section III-A) only options that are not idempotent. These options are and because they are not leaked in the MP_FASTCLOSE always linked to a DSS and thus to a DSN because option (Section III-C). the option tag is counted as data (Section III-C). This T2) Identity spoofing: MPTCPsec ensures the identity of prevents any replay attack because either the option tag the hosts by means of certificates exchanged during by would be out of sequence (if the attacker has kept the the TLS handshake (Section III-A). same DSN) or the option tag would be incorrect (if the attacker has modified the DSN). a secure handshake to authenticate the establishment of the T6) Option insertion / removal / modification: The Multipath TCP subflows [27, 28]. These solutions do not MP_CAPABLE option is protected by the TLS handshake provide encryption or authentication for the data and the other (Section III-A) and therefore cannot be modified nor Multipath TCP options. An earlier work [29] proposed to use inserted. The MP_JOIN and MP_FASTCLOSE options hash chains to secure the control part of Multipath TCP instead are protected by their respective HMAC because the of the HMAC solution chosen by the IETF. To our knowledge, keys are derived securely in MTPCPsec (Section III-A). this solution has not been implemented. The ADD_ADDR, REMOVE_ADDR and DSS options are Compared with application layer solutions such as SSH protected by the option tag (Section III-C) and removing or TLS running over the existing Multipath TCP, MPTCPsec one of them would lead to an authentication error. Even provides several advantages from a security viewpoint. First, if a segment without data is dropped by an attacker, as application layer protocols close the Multipath TCP connec- the tag is covered by the DSN, the receiver will notice tion as soon as some data has been injected in the under- that a segment has been lost thanks to the gap of DSNs. lying connection. This is a strong risk of denial of service. In conclusion, MPTCPsec is secure against any attacker who MPTCPsec reacts to such attacks by either ignoring the can freely observe, drop, modify or forge any segment on injected segments that are not authenticated or by closing the network. Furthermore, since MPTCPsec is integrated to the subflow, but not the entire connection. Furthermore, by MPTCP, it can identify the paths where attackers are present protecting the options, MPTCPsec prevents attacks where an and decide to stop using them while still exchanging data over attacker could block the establishment of subflows over paths the other paths. that it does not control. Our work goes beyond this design of MPTCPsec since Another design point is the one chosen by the designers of we have also implemented it inside the Linux kernel3. The QUIC [30]. QUIC integrates features usually found in TCP, performance of this implementation is in the same order of TLS and HTTP/2 in a single protocol running above UDP. magnitude as OpenSSL [22] implementation. Due to space To prevent any middlebox interference, QUIC encrypts and limitations, it unfortunately cannot be described in this short authenticates all the headers and data, except the connection paper but more details can be found in [23]. identifier that appears in clear in each packet. QUIC aims at supporting multiple paths, but the current specification does IV. RELATED WORK not yet describe how this will be done. MPTCPsec extends Encryption and authentication have traditionally been im- Multipath TCP and provides authentication and encryption plemented either in the application layer [24, 3] or in the without hiding TCP headers and options. This is a less radical [4]. Application layer solutions have been quite design than QUIC that still enables firewalls to counter various successful, but only a small fraction of the Internet traffic types of attacks by verifying that packets are received in is encrypted and authenticated. In 2012, Andrea Bittau and sequence over established connections. his colleagues proposed to extend TCP in order to support opportunistic encryption [8]. With their tcpcrypt proposal, V. CONCLUSION hosts negotiate keys securely at the beginning of the connec- tion and encrypt and authenticate all the data exchanged. After The traditional TCP/IP protocol stack is not sufficient for the Snowden revelations, the IETF has declared that pervasive today’s Internet users. On one hand, they expect better security monitoring was an attack [9] and the tcpinc working has and require the utilisation of cryptographic techniques to been formed to standardise a solution that is heavily inspired secure their data transfers. On the other hand, they use mobile from tcpcrypt. As of this writing, despite a large literature devices equiped with multiple interfaces. In this paper, we on Multipath TCP, nobody has proposed a solution that is have proposed MTCPsec, an extension to Multipath TCP that similar to MPTCPsec, neither in scientific publications nor at includes authentication and encryption to counter various se- the IETF. curity attacks. We have explained how our design can counter Within the IETF, two drafts are related to MPTCPsec: six different threats that were not considered during the design MPTLS [25] and Secure MPTCP [26]. MPTLS proposes to of Multipath TCP. MPTCPsec authenticates and encrypts the couple Multipath TCP and TLS together. It proposes to use data transported over a connection while still supporting their Encrypt-then-MAC and places the HMAC computed by TLS reinjection over other subflows, a key feature of Multipath for each record inside the DSS option. MPTCPsec leverages TCP. Furthermore, MPTCPsec authenticates the MPTCP op- AEAD to secure both data and options. Secure MPTCP [26] tions to prevent several types of attacks. To demonstrate the discusses how tcpcrypt could be included inside Multipath feasibility of our approach, we implement MPTCPsec entirely TCP, but only at a high level. To our knowledge, neither in the Linux kernel. MPTLS nor Secure MPTCP have been implemented. Finally, several documents have proposed to use a key derived by ACKNOWLEDGMENTS 3The starting point for our implementation is the mptcp_trunk branch, kernel version 4.1 and MPTCP version 0.90. The code is available at : We would like to thank our supervisors, Olivier Bonaventure //bitbucket.org/mptcpsecteam/mptcpsec. and Olivier Pereira, for their continuous support. REFERENCES [24] T. Ylonen, “SSH–secure login connections over the internet,” in Proceedings of the 6th USENIX Security [1] A. Ford et al., “TCP extensions for Multipath operation Symposium, vol. 37, 1996. with multiple addresses,” RFC 6824, January 2013. [25] O. Bonaventure, “MPTLS : Making TLS and Multipath [2] O. Bonaventure and S. Seo, “Multipath TCP deploy- TCP stronger together,” Oct. 2014, internet draft, draft- ments,” IETF Journal, vol. 12, no. 2, pp. 24–27, 2016. bonaventure-mptcp-tls-00, work in progress. [3] E. Rescorla, SSL and TLS: Designing and Building [26] M. Bagnulo, “Secure MPTCP,” Feb 2014, internet draft, Secure Systems. Addison-Wesley, 2000. draft-bagnulo-mptcp-secure-00, work in progress. [4] S. Kent and K. Seo, “Security architecture for the internet [27] C. Paasch and O. Bonaventure, “Securing the Multipath protocol,” RFC 4301, December 2005. TCP handshake with external keys,” Oct. 2012, internet [5] F. Gont, “Icmp attacks against TCP,” RFC 5927, July draft, draft-paasch-mptcp-ssl-00, work in progress. 2010. [28] C. Paasch and A. Ford, “TLS Authentication for [6] A. Ramaiah et al., “Improving TCP’s robustness to blind MPTCP,” May 2016, internet draft, draft-paasch-mptcp- in-window attacks,” RFC 5961, August 2010. tls-authentication-00, work in progress. [7] J. Touch, A. Mankin, and R. Bonica, “The TCP authen- [29] J. Diez, M. Bagnulo, F. Valera, and I. Vidal, “Security for tication option,” RFC 5925, June 2010. Multipath TCP: a constructive approach,” International [8] A. Bittau et al., “The case for ubiquitous transport-level Journal of Technology, vol. 6, no. 3, encryption,” in USENIX Security’10. Berkeley, CA, pp. 146–155, 2011. USA: USENIX Association, 2010, pp. 26–26. [30] J. Iyengar and M. Thomson, “QUIC: A UDP-Based Mul- [9] S. Farrell and H. Tschofenig, “Pervasive monitoring is tiplexed and Secure Transport,” November 2016, internet an attack,” BCP 188, May 2014. draft, draft-ietf--transport-00, work in progress. [10] Y. Sheffer, R. Holz, and P. Saint-Andre, “Summarizing known attacks on (tls) and data- gram tls (dtls),” RFC 7457, February 2015. [11] H. Krawczyk and H. Wee, “The OPTLS protocol and TLS 1.3,” in IEEE EuroS&P. IEEE, 2016, pp. 81–96. [12] B. Beurdouche et al., “A messy state of the union: Taming the composite state machines of TLS,” in IEEE SP 2015. IEEE Computer Society, 2015, pp. 535–552. [13] F. Gont, “Security assessment of the transmission control protocol (TCP),” Internet-Draft draft-gont-tcp-security- 00, February 2009. [14] C. Paasch, S. Barre et al., “Multipath TCP in the Linux Kernel,” Available from http://www.multipath-tcp.org. [15] C. Paasch et al., “Exploring mobile/wifi handover with Multipath TCP,” in Cellnet’12. ACM, 2012, pp. 31–36. [16] D. Wischik, M. Handley, and M. B. Braun, “The resource pooling principle,” ACM SIGCOMM Computer Commu- nication Review, vol. 38, no. 5, pp. 47–52, 2008. [17] C. Raiciu et al., “How hard can it be? Designing and implementing a deployable Multipath TCP,” in NSDI’12. USENIX, 2012, pp. 29–29. [18] M. Bagnulo et al., “Analysis of Residual Threats and Possible Fixes for Multipath TCP (MPTCP),” RFC 7430, Jul. 2015. [19] M. Bagnulo, “Threat analysis for TCP extensions for Multipath operation with multiple addresses,” RFC 6181, March 2011. [20] E. Rescorla, “Keying material exporters for transport layer security (tls),” RFC 5705, March 2010. [21] D. McGrew, “An interface and algorithms for authentic- ated encryption,” RFC 5116, January 2008. [22] I. Ristic, “Openssl cookbook,” Feisty Duck, 2013. [23] M. Jadin and G. Tihon, “Secure MultiPath TCP : Design and Implementation,” Master’s thesis, Universite´ cath- olique de Louvain, 2016.