Abstract
Multipath Transmission Control Protocol (MPTCP) is an approach towards high-throughput and efficient load balancing over multiple paths. Each of paths forms a TCP connection with an IP address, and those can be implemented as multiple network interfaces or multiple ports within a network interface. In this paper, we focus on the multiple network interfaces environment. Each network interface with an IP address is called as a subflow. A subflow is a TCP connection which can have a different internet path identified by IP addresses of source and destination network interfaces. To control these multiple subflows, MPTCP supports many options. Specifically, to establish a new subflow, MPTCP uses an <monospace xmlns:mml="http://www.w3.org/1998/Math/MathML" xmlns:xlink="http://www.w3.org/1999/xlink">ADD_ADDR</monospace> option. A host sends <monospace xmlns:mml="http://www.w3.org/1998/Math/MathML" xmlns:xlink="http://www.w3.org/1999/xlink">ADD_ADDR</monospace> option to inform another host of its IP address, and then, the host receiving <monospace xmlns:mml="http://www.w3.org/1998/Math/MathML" xmlns:xlink="http://www.w3.org/1999/xlink">ADD_ADDR</monospace> option tries to establish a subflow at the address of <monospace xmlns:mml="http://www.w3.org/1998/Math/MathML" xmlns:xlink="http://www.w3.org/1999/xlink">ADD_ADDR</monospace> option. However, by forging the <monospace xmlns:mml="http://www.w3.org/1998/Math/MathML" xmlns:xlink="http://www.w3.org/1999/xlink">ADD_ADDR</monospace> option, an attacker can create a fake subflow that passes through itself and eventually hijack the connection between both end hosts. In a previous study, Hash-based Message Authentication (HMAC) was added to the <monospace xmlns:mml="http://www.w3.org/1998/Math/MathML" xmlns:xlink="http://www.w3.org/1999/xlink">ADD_ADDR</monospace> option, preventing it from being forged. Nevertheless, since the keys for generating HMAC can be leaked during three-way handshake, a variant of the <monospace xmlns:mml="http://www.w3.org/1998/Math/MathML" xmlns:xlink="http://www.w3.org/1999/xlink">ADD_ADDR</monospace> attack called the persistent <monospace xmlns:mml="http://www.w3.org/1998/Math/MathML" xmlns:xlink="http://www.w3.org/1999/xlink">ADD_ADDR</monospace> attack can be possible. To this end, we propose a protocol that can prevent the <monospace xmlns:mml="http://www.w3.org/1998/Math/MathML" xmlns:xlink="http://www.w3.org/1999/xlink">ADD_ADDR</monospace> attacks by backward confirmation of the <monospace xmlns:mml="http://www.w3.org/1998/Math/MathML" xmlns:xlink="http://www.w3.org/1999/xlink">ADD_ADDR</monospace> option without encryption. The main idea of our proposal is to apply a digital signature scheme for the backward confirmation. We show security analysis for the proposed protocol and compare with the previous studies in terms of time/space overheads.
Highlights
Multipath Transmission Control Protocol (MPTCP), specified in RFC 6824 [1], is a TCP extension for a transport connection to utilize multiple network interfaces on multi-homed hosts concurrently
In MPTCP, a MPTCP connection consists of subflows, each of which is a TCP connection which can have a different Internet path identified by IP addresses of source and destination network interfaces
If an application changes its transport layer protocol to MPTCP, concurrent transmission of data through multiple subflows can be possible with better throughput, more reliable connectivity, and little deployment cost
Summary
Multipath Transmission Control Protocol (MPTCP), specified in RFC 6824 [1], is a TCP extension for a transport connection to utilize multiple network interfaces on multi-homed hosts concurrently. In mobile environments, this ADD_ADDR option is important, because whenever IP address of a network interface in a mobile device changes over time, the device needs to inform the peer host of its changed IP address with the ADD_ADDR option without encryption To this end, an attacker on the path can eavesdrop the control message, send a forged control message to the target (i.e., peer) host, and establish a fake subflow with the target host. Another research effort [16] suggests to exchange keys for each subflow handshaking, but frequent handoffs may consume too much power and computation resources in highly mobile environments such as high-speed rails [5] To this end, we propose a novel protocol to prevent the ADD_ADDR attack with minimal overhead. The sections of this paper are as follows: the background information for MPTCP is provided in II, definitions of threat models in III, an explanation of the proposed protocol in IV, an overall evaluation in V, information on related works in VI, and the conclusion of the paper in VII
Sign-in/Register to view highlights & summary Sign-in/Register to access full text options 
Talk to us
Join us for a 30 min session where you can share your feedback and ask us any queries you have
Schedule a call
