Cross-Path Inference Attacks on Multipath TCP M. Zubair Shafiq‡,FranckLe†, Mudhakar Srivatsa†, Alex X. Liu‡ ‡ Michigan State University, East Lansing, MI, USA. † IBM T. J. Watson Research Center, Yorktown Heights, NY, USA. Email: {shafiqmu,alexliu}@cse.msu.edu, {fle,msrivats}@us.ibm.com ABSTRACT 1. INTRODUCTION Multipath TCP (MPTCP) allows the concurrent use of mul- Multipath TCP (MPTCP) enables two endpoints to tiple paths between two end points, and as such holds great simultaneously use multiple paths available between them. promise for improving application performance. However, This new capability can improve application performance, in this paper, we report a newly discovered class of attacks especially considering mobile devices are increasingly on MPTCP that may jeopardize and hamper its wide-scale becoming multihomed (e.g., cellular, Wi-Fi). This fea- adoption. The attacks stem from the interdependence be- ture has consequently sparked a lot of interest and ex- tween the multiple subflows in an MPTCP connection. MPTCP citement both in industry [6, 13] and academia [14, 12, congestion control algorithms are designed to achieve re- 9, 10]. Recently, researchers have proposed numerous source pooling and fairness with single-path TCP users at theoretical frameworks and solutions to better under- shared bottlenecks. Therefore, multiple MPTCP subflows stand and take advantage of this new capability while are inherently coupled with each other, resulting in potential satisfying MPTCP’s requirements. MPTCP has three side-channels that can be exploited to infer cross-path prop- main design objectives [6]: erties. In particular, an ISP monitoring one or more paths used by an MPTCP connection can infer sensitive and pro- 1. Improve throughput: It should give a throughput prietary information (e.g., level of network congestion, end- that is at least as high as that of a single-path to-end TCP throughput, packet loss, network delay) about its TCP connection on the best available path. The competitors. Since the side-channel information enabled by goal of this objective is to incentivize MPTCP de- the coupling among the subflows in an MPTCP connection ployment. results directly from the design goals of MPTCP conges- 2. Do no harm: It should not take up more capacity tion control algorithms, it is not obvious how to circumvent on its different paths than if it were a single-path this attack easily. We believe our findings provide insights TCP connection using only one of these paths. that can be used to guide future security-related research on This is to ensure that MPTCP will not degrade MPTCP and other similar multipath extensions. the performance of applications that use single- Categories and Subject Descriptors path TCP at shared bottlenecks. C.2.5 [Computer-Communication Networks]: Lo- 3. Balance congestion: It should move traffic off from cal and Wide-Area Networks—Internet (e.g., TCP/IP) the congested paths, subject to satisfying the first two objectives. The purpose of this design objec- General Terms tive is to achieve resource pooling, i.e., MPCTP Security, Experimentation connections should send more traffic on lesser con- gested paths to alleviate overall congestion in the Keywords network. Multipath TCP, Congestion Control Recent research efforts [14, 9, 10] have focused on de- Permission to make digital or hard copies of all or part of this work for personal or classroom use is granted without fee provided that copies are not signing and improving congestion controllers to effec- made or distributed for profit or commercial advantage and that copies bear tively satisfy these design goals. However, these design this notice and the full citation on the first page. Copyrights for components goals create a tight coupling between multiple MPTCP of this work owned by others than ACM must be honored. Abstracting with credit is permitted. To copy otherwise, or republish, to post on servers or to subflows that can be exploited as side-channels to launch redistribute to lists, requires prior specific permission and/or a fee. Request a new class of attacks. permissions from [email protected]. In this paper, we present a new class of attacks on HotNets-XII, November 21–22, 2013, College Park, MD, USA. MPTCP, that we call cross-path attacks. These attacks Copyright 2013 ACM 978-1-4503-2596-7 ...$15.00. http://dx.doi.org/10.1145/2535771.2535782. enable a party monitoring one (or more) paths used by 1 Client Server ISPX Tx (TCP flowx) Client1 Initial connection setup (subflow 1) T1 (MPTCPsubflow 1) Additional subflow setup (subflow 2) ISP Y Client2 IP IP IP T2 (MPTCPsubflow 2) C1 C2 S T (TCPflowy) y MPTCP Figure 2: An example MPTCP usage scenario SPTCP Client3 throughput of other paths. For example, with the new Opportunistic Linked-Increases Algorithm (OLIA) con- gestion control algorithm [9], an attacker can conduct Figure 1: A scenario illustrating competing cross-path throughput inference up to 50% faster than single-path TCP (SPTCP) and MPTCP connec- with the initial LIA congestion control [11]. Finally, al- tions though our preliminary empirical validations focus on MPTCP subflow(s) to infer properties of other paths. inferring the throughput of a single path TCP flow in In particular, such attacks can allow ISPs to infer sen- other networks, we believe that the same principle can sitive and proprietary information (e.g., level of conges- be used to infer other key metrics including connection tion, throughput, packet loss, round trip time) about delay and packet loss. their competitors [4]. For the scenario illustrated in The rest of this paper is organized as follows. We pro- Figure 1, the coupling among MPTCP subflows 1 and vide a brief overview of MPTCP in Section 2. In Sec- 2 can enable ISP X to infer cross-path network perfor- tion 3, we introduce the cross-path inference attack on mance metrics for ISP Y (i.e., properties of single-path MPTCP. Next, we present some preliminary results in TCP flows traversing ISP Y), and vice-versa. To the Section 4 before discussing various technical challenges best of the authors’ knowledge, we are the first to de- and potential countermeasures in Section 5. Section 6 scribe this new type of attack. Cross-path attacks were provides a summary of the prior work on MPTCP se- not possible in regular TCP: although an on-path at- curity. Finally, Section 7 concludes the paper. tacker could eavesdrop and launch session hijacking or man-in-the-middle attacks, an off-path attacker could not directly infer any property about the connection in 2. BACKGROUND regular TCP. We provide a brief overview of MPTCP. More de- Using a testbed of Linux nodes supporting the MPTCP tails about MPTCP operation can be found in RFC Linked-Increases Algorithm (LIA) congestion controller [11], 6824 [6]. To facilitate its deployment and compatibility standardized by the IETF, we empirically demonstrate with middleboxes, MPTCP is defined as a set of ex- the feasibility of such attacks. Our experiments show tensions to TCP. Different MPTCP parameters are sig- that an attacker can infer the throughput that a single naled through TCP options. An MPTCP connection path TCP will obtain in other networks, with up to 90% consists of one or multiple TCP subflows. accuracy in a measurement interval of less than 8 min- Figure 2 illustrates the MPTCP connection setup steps utes, 3 minutes, and 8 minutes respectively for links for the scenario of Figure 1. The MPTCP connection with the characteristics of wired, Wi-Fi, and cellular (subflow 1) is first established between IPC1 and IPS networks. on the client and server, respectively. MPTCP capa- We highlight that this class of attacks is not specific bility is negotiated between the client and server us- to a particular congestion control algorithm (e.g., LIA ing the MP CAPABLE TCP option during the three-way [11]), but derives from the design goals of MPTCP, and handshake in the initial connection setup. During the as such applies to all congestion control algorithms de- initial MPTCP connection setup phase, the end points signed to satisfy them, including more recent propos- may also advertise the presence of multiple addresses als [9, 10]. Also, interestingly, recent congestion con- at either hosts. This allows the establishment of addi- trol proposals developed to more effectively satisfy the tional MPTCP subflows at later times. In this scenario, MPTCP design objectives work in favor of attackers, the client advertises the address IPC2 to the server us- allowing them to more quickly and accurately infer the ing the ADD ADDR TCP option on the existing subflow 2 1 and then initiates a new subflow 2 between IPC2 and 1. T>Tx: From equation (3), we have IPS using the MP JOIN TCP option. ∗ T = T (4) MPTCP runs on top of TCP subflows, and uses a 64- y ∗ bit data sequence number (DSN) for all the data sent (Ty represents an estimator for Ty. More gener- ∗ across multiple subflows. Although each TCP subflow ally, we note Ti an estimator for Ti). From the has its own 32-bit sequence number, the DSN enables MPTCP throughput T , one can infer Ty.Inother data to be retransmitted on different subflows in the words, ISP X can passively infer the throughput event of failure. MPTCP also signals connection-level of a single-path TCP in a different ISP, e.g., ISP acknowledgements (i.e., Data ACK) to implement flow Y. control. Both the MPTCP DSN and Data ACK are 2. T ≤ Tx: From (2c) and (3), T2 ≤ Ty ≤ Tx. sent as Data Sequence Signal (DSS) TCP option. The attacker can estimate T2 from the fact that T T T T T 3. MPTCP INFERENCE ATTACK = 1 + 2. By observing and 1, the through- puts of the MPTCP connection and the MPTCP ∗ We present the main idea behind the MPTCP infer- subflow 1, T2 = T −T1.