Security for multipath TCP - CiteSeerX

5 downloads 33421 Views 588KB Size Report
Engineering in 2010 and BSc in Computer Science in 2005 from the University Carlos III de. Madrid .... Figure 3 Full hijacking attack scenario (see online version.
146

Int. J. Internet Protocol Technology, Vol. 6, No. 3, 2011

Security for multipath TCP: a constructive approach Javier Díez *, Marcelo Bagnulo, Francisco Valera and Iván Vidal Telematics Engineering Department, University Carlos III of Madrid Avda. Universidad, 30, 28911 Leganés, Madrid, Spain E-mail: [email protected] E-mail: [email protected] E-mail: [email protected] E-mail: [email protected] *Corresponding author Abstract: Multipath TCP (MPTCP) is a new protocol being developed in the IETF’s MPTCP working group in order to provide higher communication availability and to improve the throughput between two multi-addressed endpoints by using multiple paths. Due to the multipath nature and specifically its path management, some new security threats arise apart from those that are already present in standard single-path TCP. These new attacks include flooding and hijacking attacks performed by an off-path attacker. In this paper, we explore different solutions in order to cover the identified security flaws. The main proposal is based on hash chains, which significantly reduces the initial set of threats resulting in a residual group of vulnerabilities, which are also identified. Keywords: multipath TCP; MPTCP; security; hash chains. Reference to this paper should be made as follows: Díez, J., Bagnulo, M., Valera, F. and Vidal, I. (2011) ‘Security for multipath TCP: a constructive approach’, Int. J. Internet Protocol Technology, Vol. 6, No. 3, pp.146–155. Biographical notes: Javier Díez is a part-time Lecturer in the Telematics Engineering Department at the University Carlos III of Madrid. He received both his MSc in Telematics Engineering in 2010 and BSc in Computer Science in 2005 from the University Carlos III de Madrid, as well as a Technical Engineering degree in 2002 from the University of Oviedo. His main research focuses on multipath TCP. Marcelo Bagnulo is an Associate Professor in the Telematics Engineering Department at the University Carlos III of Madrid. His main research interest is the internet architecture and protocols. He is very active in the internet standards community (IETF), being author of several IETF RFCs, including the Shim6 protocol for IPv6 multihoming and the DNS64/NAT64 tool suite for the IPv6 transition. During 2009−2011, he was a member of the Internet Architecture Board (IAB), the body that oversees the internet standardisation. In addition, he is the Director of the Telefonica Chair on Future Internet at the University Carlos III of Madrid and he was the Technical Leader for the Huawei Labs at University Carlos III of Madrid. He has a PhD from the University Carlos III of Madrid and a Bachelor on Electrical Engineering from the University of Uruguay. Francisco Valera received his Telecommunication Engineering degree in 1998 from the Technical University of Madrid (UPM), and his PhD in Telecommunications in 2002 from the University Carlos III de Madrid (UC3M), where he is currently a Tenured Associate Professor. He has published over 50 papers in the field of advanced communications in magazines and conferences. He has also participated in the scientific committee, organisation and technical review in different national and international conferences. Iván Vidal received his Telecommunication Engineering degree in 2001 from the University of Vigo and his PhD in Telematics Engineering in 2008 from the University Carlos III of Madrid. His research interests include network security, multiparty services based on network multicast in the IP multimedia subsystem (IMS) and peer-to-peer overlays for multimedia streaming in the internet and IMS-based next generation networks.

Copyright © 2011 Inderscience Enterprises Ltd.

Security for multipath TCP: a constructive approach

1

Introduction

The idea of providing multi-path support to TCP is not new. Over the past years, several proposals have been made in order to enhance the resilience, the load balancing and to improve the throughput of a TCP connection: pTCP (Hsieh and Sivakumar, 2002), M/TCP (Rojviboonchai and Aida, 2002), mTCP (Zhang et al., 2004), cTCP (Dong et al., 2006) and CMT (Sarkar, 2006). However, none of them made it into the mainstream. Currently, there is a standardisation effort by the IETF with the creation of a new working group called MPTCP, and a new proposal for multi-path support in TCP (Ford et al., 2011) is being developed. In addition, a threat analysis for multi-addressed/multi-path TCP (Bagnulo, 2011) has been performed, resulting in a set of observed vulnerabilities, like flooding or hijacking attacks, basically due to the fact of adding new addresses to the connection. The rest of the paper is organised as follows; we first describe the fundamentals of a generic MPTCP proposal, next we summarise the existing security risks and propose an incremental series of measures in order to reduce the group of identified vulnerabilities. These measures are mainly based on the usage of hash chains to secure the path management signalling between the endpoints. We then identify the set of residual threats and compare them to the current single-path TCP. Next, as related work, we briefly survey two other approaches aimed to provide security to MPTCP, comparing them to the one proposed. Finally, we conduct a performance analysis and present our conclusions as well as suggest some considerations as future work.

2

Basic multipath TCP

MPTCP enables the transfer of data through multiple paths by allowing the usage of multiple addresses per node within the same connection. This approach provides certain degree of multihoming and mobility support. The proposed mechanism allows the endpoints to change their addresses while maintaining the connection. Figure 1 depicts two nodes with two addresses per node establishing an MPTCP connection over two paths (subflows), achieving enhanced resilience and load balancing capabilities. In the example, two additional paths could be established (IPA-IPD and IPB-IPC), using the two remaining addresses combinations. Figure 1

Multi-addresses/multi-path scenario (see online version for colours)

147 An MPTCP connection is initiated as a regular single-path TCP connection, using the TCP three-way handshake but the MPTCP-capable endpoints will identify themselves as such by including a multi-path capability tag in a newly defined TCP option. Once the MPTCP-enabled connection is established between a single pair of addresses, additional addresses from the ends can be associated to the ongoing connection. This is done by setting up new subflows, i.e., performing the three-way handshake using alternative addresses and identifying the new subflow as belonging to the existing MPTCP connection. So, the address pair initially used to set up the connection has a special meaning, since these initial addresses are used by the upper layers to identify the peers of the connection, despite the fact that the peer may have more addresses later on, and even though in the future this peer may no longer be located at that address. Therefore, in MPTCP there exists an identifier/locator split, since identifiers used by applications are decoupled from locators used by routing. This new scheme introduces additional vulnerabilities to the trust model of traditional TCP based on that coupling. The specification proposed for MPTCP contains a great deal of details concerning the congestion control mechanisms for MPTCP, flow control and error control. Whilst these are critical for the performance of MPTCP, none of these have an impact in the security analysis. For the sake of our security analysis, it is only relevant to assume that, according to (Wischik et al., 2008), in order to maximise the utilisation of the multiple paths and benefit from robustness and flexibility, MPTCP uses all the address pairs that the connection has available to send packets. In addition, the load will be distributed based on congestion among the different paths.

3

Security threat analysis

An MPTCP connection comprises one or more TCP connections. Thus, MPTCP is going to be vulnerable to at least the same set of risks that TCP is already exposed to, and in particular to those performed by an on-path attacker. Such attacker acts as a man-in-the-middle who may impersonate either the sender or the recipient of a communication while eavesdropping, tampering or dropping packets and even hijacking the session. From a security standpoint, the proposed target is that MPTCP must not behave worse than current single-TCP. In order to achieve this, we first identify the vulnerabilities that are introduced due to the multi-addresses/multi-path nature of the new protocol. These additional vulnerabilities introduced by MPTCP result from the capability of adding new addresses to an ongoing connection, which can result in redirection attacks (Aura et al., 2004). There are two types of new attacks that can be performed by off-path attackers, namely, flooding and hijacking attacks.

148

J. Díez et al.

3.1 Flooding attack As illustrated in Figure 2, an attacker attempts to deceive a server, making it send a large amount of traffic to a victim so as to exhaust its resources. Figure 2

Flooding attack scenario (see online version for colours)

The attack is performed as follows: first, the attacker establishes an MPTCP connection with the server through a three-way handshake by using IPA as a source address and IPS as a destination address. Then, the attacker adds the address of the victim (IPV) as an additional address for this connection. The malicious node requests a traffic download from the server, but it does not acknowledge data packets delivered to the original address IPA. The server sends the bulk of the data flow to the IPV address, flooding the victim. The attacker can maintain the data flow from the server (IPS) to the victim (IPV) by acknowledging only those data packets sent to the victim (IPV) and dropping those addressed to the attacker (IPA). By doing so, the victim will be overwhelmed by data, especially if the attacker increases the receive window size of the victim by making use of the TCP window scale option, and managing to send acknowledgments in a timely fashion so that the slow start algorithm can be triggered off. However, in order to successfully perform such attack, the attacker would need to guess the sequence number of the packets that have been received by the victim, as well as the pace at which the server sends data to the victim so that forged acknowledgments arrive just in time.

still receive data from the original peer (node A) and send data to it. In order to accomplish a full hijacking attack, the attacker removes the original address (IPA) from the set of available addresses for the MPTCP connection. At this point, the connection is completely hijacked and traffic is exchanged between the victim and the attacker. Figure 3

Full hijacking attack scenario (see online version for colours)

A specific case of hijacking attack is depicted in Figure 4, where the attacker places itself as a man-in-the-middle, deceiving both ends, and making them think they are communicating with the legitimate peer. To do so, an analogous procedure will be performed with the other node of the communication. The main difference with the abovementioned hijacking attack is that, in this case, the attacker cannot only forge but also eavesdrop the traffic that is forwarded through it. Figure 4

Man-in-the-middle flavour of hijacking attack scenario (see online version for colours)

3.2 Hijacking attack In this case, the attacker hijacks an MPTCP connection impersonating one of the legitimate peers (node A in Figure 3). This results in redirecting the traffic to the attacker without being noticed by the victim (node B), who believes that is exchanging packets with the legitimate node while actually talking with the attacker. The attack is performed by an off-path attacker who adds its own address (IPT) as an additional address for the established MPTCP connection between the legitimate nodes. To do so, the attacker must know the 4-tuple that identifies the connection {IPA, port A, IPB, port B}, being the source port the more challenging part assuming that the destination port would be a well-known server port. At this point, the attack is partially done, because the victim can

4

Basic solutions

In this section, we will provide some simple but effective counter measurements in order to mitigate the identified redirection attacks. Afterwards, we will identify the remaining vulnerabilities.

4.1 Preventing flooding attack In order to prevent flooding attacks, before sending a packet to a new address, the endpoint performs a reachability check. By doing so, the sender asks whether the receiver is willing to accept data from the connection identified by the 4-tuple {IPA, port A, IPB, port B}.

Security for multipath TCP: a constructive approach

149

In the example seen in Figure 2, the server would first check whether the victim located at IPV is willing to receive a data flow that belongs to an MPTCP connection identified by the 4-tuple {IPA, port A, IPS, port S}. Since this would result into a negative answer, the server will not send data belonging to the ongoing MPTCP connection to IPV. One particular approach to implement the reachability check described above is to perform a three-way handshake for every new address pair that will be part of the MPTCP connection, thus establishing a new subflow. The way such a new subflow joins the MPTCP connection is initiated by sending a SYN segment, using the new address as the source address and an already used address of the peer as the destination address. This three-way handshake approach does also have the advantage of being NAT traversal friendly. From now on, we assume that the three-way handshake is performed when adding a new address/subflow to an ongoing MPTCP connection.

the path at some point, snooping and/or tampering packets, but the attack itself continues when it has left the on-path location. In particular, we consider the case of an MPTCP connection secured through the usage of a cookie and an attacker located along the path during the establishment phase, i.e., when the cookie is exchanged. Once the attacker has learnt the cookie, it can move away from the path and it will still be able to launch a hijacking attack by adding its own address to the connection (as described in Section 3.2). Actually, although the cookie is initially exchanged in the establishment of the MPTCP connection, the attacker does not have to be on-path in order to capture it in that moment, since any of the subsequent subflow establishments will be repeating the cookie again in plaintext. Figure 5 shows the man-in-the-middle version of this time-shifted attack. The following section describes our proposed solution to this problem.

4.2 Preventing hijacking attack

Figure 5

Man-in-the-middle flavour of time-shifted attack scenario (see online version for colours)

4.2.1 Off-path flavour of hijacking attack As it was stated in Section 3.2, in order to accomplish a full hijacking attack, the malicious node must first add its own address to the MPTCP connection and then remove the address of the legitimate peer, thus hijacking both the incoming and the outgoing traffic to/from the victim. Additionally, in the previous section we have just assumed the use of the three-way handshake as the method to allow a subflow to join the MPTCP connection. We will also assume, likewise, the standard four-way TCP FIN handshake as the one to close it. Therefore, should ingress filtering be implemented in the network of the attacker then it would prevent it from launching the attack. In the original specification of MPTCP (Ford et al., 2010), the proposed mean to prevent an off-path attacker from launching a hijacking attack was to use a cookie to secure the address agility management of the packets utilised to add new addresses to an MPTCP connection. This security token is exchanged in plaintext during the establishment of the connection and is presented later in every attempt to establishing a new subflow between the peers, proving that the token-holder was the one involved in the establishment phase. With the introduction of the security cookie, off-path attackers will no longer be allowed to launch hijacking attacks (including the man-in-the-middle variation). While this level of security seems similar to single-path TCP, where only on-path attackers can launch this kind of attack, there is still another variation of hijacking attack not yet avoided with the introduction of the security token. These are the so-called time-shifted attacks.

5

Crypto-based solution

5.1 Hash chain background A hash chain (Lamport, 1981) is a list made up of hash values generated by recursively applying a hash function. It is first applied over an initial random value called seed, and then over the result of the previous iteration until the desired length of the hash chain is reached. The subscript of the hash chain values depicts the order in which the element will be revealed to the other end, but the reverse order in which the value is calculated: starting with n and finishing with 0 or the so-called anchor value. H n = Hash ( seed ) H n −1 = Hash ( H n ) … H1 = Hash ( H 2 )

4.2.2 Time-shifted variation of hijacking attack

H 0 = Hash ( H1 ) == Anchor

The term ‘time-shifting’ attack is defined in (Nordmark, 2005) as the ability of an attacker to continue an attack once it has left the path. Thus, the attacker would have been on

seed = random number Hash Chain = H 0 , H1 , H 2 ,… , H n −1 , H n

150

J. Díez et al.

During the establishment of the connection, both peers exchange, by means of TCP Options, their anchor values H0. Subsequently, the creation of a new subflow is protected using the hash chains. Each peer will send the next value of its hash chain, i.e., H1, so that the other peer is able to verify whether the result of applying the hash to the received element matches the stored anchor of the peer. The procedure is the same for the rest of the chain, but replacing the stored value with the last received hash. In this process, only the node that generated the original hash chain knows the next value, and thus the peer may check whether the received value is the next in the chain of the peer, as a mechanism to perform source authentication. Hash chains must have a concrete length which may get depleted. When a hash chain is close to its end, it is possible to generate a new one (with another random number as seed). In order to link both chains, a particular message is sent, including: the penultimate value of the old hash chain new H nold of the new hash chain −1 , the anchor value H 0 (authenticated by H nold −1 ) and a keyed-hash message authentication code (HMAC) to prevent a forged hash chain from being inserted. This HMAC includes the new anchor, and the key is the last value of the old hash chain H nold . The latter is released in the next authenticated packet that the node has to send to the peer, so that the peer is able to check the integrity of the new anchor before having to use the new hash chain. The next packet that is received is already authenticated with the first value of the new hash chain H1new .

(

old new node → peer : H 0new , H nold −1 , HMAC H n , H 0

)

node → peer : H nold node → peer

: H1new

Since the linking message may deplete the TCP option space in SYN or data segments, it will be conveyed through TCP Options but in an ACK segment.

5.2 Hash chain interactive exchange The hash chain-based mechanism defined in this proposal is based on weak identifier multihoming protocol framework (WIMP-F) (Ylitalo et al., 2004) which in turn is based on timed efficient stream loss-tolerant authentication (TESLA) (Perrig et al., 2005). The TESLA protocol was conceived for a broadcasting environment which uses a time-based approach to sign messages that requires loose time synchronisation between the sender and the receivers. The sender, after having sent the anchor of its hash chain to a group of receivers, will send them packets protected by an HMAC using, during a certain time interval, the next unrevealed element of the hash chain as a key, which will be disclosed after this time span. Each key in the chain is associated with a time interval known by the receivers, so that they are able to

authenticate and check the integrity of their buffered messages as soon as the corresponding element is disclosed. Time synchronisation ensures that the receivers only accept packets until the sender reveals the corresponding hash chain element. This ensures that only the sender, who is in possession of the hash chain, can sign messages. On the other hand, WIMP-F is conceived for unicast communication in which both nodes use a hash chain and exchange, in an interactive fashion, elements of their hash chain as the way to perform source authentication. Additionally, messages are also HMAC signed using the next unrevealed hash element as a key. Our proposal, like WIMP-F, is focused on a hash-chain-synchronised two-ended connection, but since MPTCP is supposed to work in the internet today where middleboxes are widespread, no integrity checking approach can be implemented to the address agility management of the packets. Due to NAT traversal considerations, the address embedded in the SYN segment which is added to the connection cannot be HMAC protected because that would imply that it would not be able to be changed by a potential middlebox, thus resulting it impossible to differentiate from a spoofing attack made by a man-in-the-middle. We propose here the usage of a weak authentication technique (Arkko and Nikander, 2002), assuming that peers have not known each other before establishing the MPTCP connection (and no third-party trust is present). Particularly, the security level we aim to achieve is for parties be able to verify that the other communicating party is the same as the one that was previously in the establishment phase, provided there was not any man-in-the-middle attacker in that moment.

5.2.1 Connection establishment Since there is no previous contact between the peers, a leap-of-faith is done during the establishment of the connection (see Figure 6). The peers will exchange their anchors as plaintext. We have considered here that it is not worthwhile introducing more complexity in order to protect this exchange, since an on-path attacker is able to replace the exchanged anchors of the legitimate peers with the anchor of its own hash chain, which would allow it to launch not only a man-in-the-middle attack, but also a time-shifted attack. Figure 6

Connection establishment (leap of faith) (see online version for colours)

The anchor is conveyed in a new TCP option included in both SYN segment of Node A and SYN+ACK segment of Node B. The anchor of the peer is stored since it is the initial value of the security mechanism used by a

Security for multipath TCP: a constructive approach node in order to later check whether the address management events received from the peer are really originated from the legitimate owner of the hash chain related to that anchor.

5.2.2 Adding a new subflow to the connection When a node wants to add a new subflow to the connection, it sends a SYN segment including the appropriate hash chain value from the address and port that it is attempting to add to the connection to an already known address and port of the peer. As we mentioned in Section 4.1, the TCP three-way handshake between the peers is required in order to prevent flooding attacks. Similarly to Figure 6, the respective next value of the hash chain is conveyed in each SYN segment, i.e., H1(A) and H1(B) for joining the first subflow to the connection, and appropriate subscripts for the following events. Once the peers have exchanged authenticated packets, they verify that the received hash chain value is the one that follows the stored hash chain value by simply applying the hash function over the received hash chain value and checking whether the result matches the stored value for the peer. At this point, the stored value is replaced with the last hash chain received. When the hash chain of a node is about to finish, the extension mechanism explained in Section 5.1 is applied.

151 the algorithm used as a hash function is negotiated between parties during the establishment of the connection. Since this algorithm is not changed afterwards and considering that if a man-in-the-middle is present the easiest attack is to replace the hash chain, downgrading attacks are not a concern. The main potential well-known risk against hash chains is the pre-computed dictionary attack. An attacker that captures a packet with a hash value inside may try to infer its pre-image by looking up into the off-line built dictionary in order to guess the next element in the chain. In order to avoid this type of attack, in the connection establishment phase, when both peers generate their hash chains, a salt will be appended to the previous hash value as the input for the hash function in each iteration. We propose that this salt value is derived from the 32-bit sequence number concatenated with itself resulting in a 64-bit number, so that both peers can deduce other’s salt through in-band signalling from the synchronisation of their sequence numbers. Thereby, each node is able to verify whether the peer’s stored value matches the next hash value received, by simply appending the salt of the peer to the received hash value and applying the hash function. H n = Hash( seed ) H n −1 = Hash( H n || salt )

5.3 Security analysis for hash function



Two cryptographic hash functions are used in the solution: one to generate the hash chain and another one to compute HMAC. We propose the use of SHA-1 for both, since this cryptographic algorithm is in widespread use in internet protocols, as evidenced by the fact that it is being adopted in current IETF security proposals, e.g., TCP-AO (Lebovitz and Rescorla, 2010). Aside from that, in order to achieve a reasonable trade-off between security properties and the size of TCP header options, the 160-bit output of these hash functions are truncated to 96 bits, resulting in SHA-1-96 and HMAC-SHA-1-96 for the hash chain and HMAC, respectively. The length of 96 bits has been selected because it meets the security requirements for HMAC described in (Krawczyk et al., 1997), which recommend that the length be not less than half the length of the hash output (to match the birthday attack bound) and not less than 80 bits (a suitable lower bound on the number of bits that need to be predicted by an attacker). Moreover, since HMAC is computed using the hash value as a key, in order to not downgrade its robustness, both outputs are truncated to the same length and 96 bits is the longest one that fit three times in the 40-byte field assigned to TCP options (considering the space occupied by the type-length-value format in itself) in the ACK segment that conveys the above-mentioned linking message. Below, we study the security analysis of the cryptographic hash function. To support algorithm agility,

H1 = Hash( H 2 || salt ) H 0 = Hash( H1 || salt ) == Anchor seed = 160 − bit random number salt = sequence number || sequence number Hash Chain = H 0 , H1 , H 2 ,… , H n −1 , H n

The construction of an off-line dictionary requires a considerable amount of storage. Taking into account that the length of the truncated hash value is 96 bits and the salt is double the bit length of the sequence number, the dictionary would require of 296 * 232 entries, i.e., 4.06 * 1031 GB. In case of 2 GB SDRAM memory modules (13.33 cm × 3.0 cm × 0.2 cm) an attacker needs 1.62 * 1026 m3, or 1.55 * 1018 Empire State buildings (volume of 37 million cubic feet). On the other hand, performing a brute-force attack, i.e., constructing such a dictionary, would require O(296) calculations of the hash value. In each iteration, an attacker hashes 20 bytes (the 96-bit previous hash chain value and the 64-bit salt). According to openssl speed1, a computer with a Pentium Core 2 Duo P8700 (2.53 GHz) and 4 GB of RAM hashes 76,818.75 KB per second, when doing SHA-1 on 64B size blocks. This means that an attacker would spend more than 6.5*1014 years hashing all the possible inputs.

152

J. Díez et al.

5.4 Residual threats We now identify the residual threats for an MPTCP protocol that relies on hash-chains for the protection of the address management signalling. Due to the unique use of a hash chain value and its unpredictable nature, replay attacks are not possible. Therefore, the vulnerability window for this type of attack is limited to the forgery of the crypto anchor during the initial connection establishment phase, provided that a man-in-the-middle attacker is present in that moment. Moreover, should this type of attack occur, then when peers try to establish another subflow over again they would detect a problem, since their hash chain values would not match the expected values. As a consequence, only attackers that remain on-path for the whole time will be undetectable, as it happens with normal TCP. Another residual threat that cannot be avoided is the integrity time-shifted attack, where an initially on-path attacker (equipped with another off-path IP address) forges an attempt to establish a subflow by the legitimate peer by replacing the address of the peer with its own off-path address. In order to perform such an attack, it is necessary that the legitimate peer creates a new subflow using the next hash value in the chain. Figure 7 illustrates how node A tries to join IPA2 to the previously established MTPCP connection between IPA1 and IPB by using IPA2 as the source address and IPB as the destination address in the three-way handshake. The on-path attacker impersonates node A and will deceive node B that thinks is establishing a new subflow with node A when it is actually doing with the attacker at the off-path IPT address. From now on, either the attacker sends an RST segment to node A or leaves the place and node A tries to send data through the supposedly new established subflow, which will cause in turn the receipt of an RST segment from node B, the subflow is hijacked and actually established between node B and the attacker at its off-path IPT address. Figure 7

Hijacked subflow by an on-path attacker scenario (see online version for colours)

In order for the attacker to be placed as a man-in-the-middle, another attempt to establish a new subflow has to be performed but in the other direction, i.e., from a new IP address of node B to a well-known IP address of node A (now node B can choose to establish the

subflow with IPA1 or IPT, since these are the two addresses known by node B as belonging to node A). The next section provides a feasible solution which could be implemented for this last possible thread.

5.5 Solution based on subflow identifiers In order to mitigate subflow hijacking attacks, we propose to force peers to communicate between them the list of shared subflows they keep alive. When a subflow is hijacked, only one of the nodes maintains it active without awareness of the other node. So, as soon as they communicate their lists, they will be able to realise whether a subflow hijack has been performed. In order to do that, each subflow establishment (including the connection establishment) could be equipped with a subflow identifier chosen by the initiator. Periodically, the peers would exchange a packet with the list of subflow identifiers that they have established and which are active at one particular moment. This packet would be sent in both directions using the initial subflow and another one randomly selected. No action would be taken if any of the subflows is temporarily down and the packet does not get to its destination. However, if the list of subflow identifiers received through any of the subflows does not match the corresponding list that maintains the other peer, then the attack would be detected. Thereby, for an attacker to avoid the detection, it must remain on-path in all the hijacked subflows for the lifetime of the connection, which essentially means that it needs to become an on-path attacker.

6

Related work

6.1 Security solution based on HMAC Currently, the MPTCP specification (Ford et al., 2011) proposes HMAC, based on the usage of the hash function SHA-1, as the mechanism to protect the addition of new subflows. Figure 8 depicts the entire process. Initially, the peers exchange a randomly generated 64-bit key which will be used as the key for the HMAC in each direction, remaining the responder stateless until the third segment of the three-way handshake arrives. Later, when a node wants to setup a new subflow, it starts another three-way handshake, presenting a 32-bit truncated hash over the receiver’s key as a token to identify the corresponding connection. Along with the token, a 32-bit random number generated by the sender is carried as a nonce, used to prevent replay attacks, providing freshness to the request. The responder will reply generating another nonce and HMAC protecting a message composed of the concatenation of both nonces and using as a key the concatenation of the shared keys exchanged during the establishment phase. However, due to space limitations, the output is truncated to the leftmost 64 bits. Finally, an analogous procedure is performed by the initiator in the third segment but without truncation of the 160-bit output.

Security for multipath TCP: a constructive approach Figure 8

Security solution based on HMAC (see online version for colours)

6.2 Security solution based on public-key Another security approach that has been discussed in the MPTCP working group (Bagnulo, 2011) is the one based on public-key cryptography. A basic implementation of 1024-bit RSA public-key has been tested in this work whose scheme can be observed in Figure 9. Similarly to the HMAC approach, 64-bit keys are exchanged through the first two segments of the establishment phase with the aim of being later used as an identifier of the connection. On the contrary, the connection is established using a four-way handshake so that the peers can exchange their public keys through the two last segments of the establishment phase. Thereafter, when a node wants to add a new subflow to the connection, it will identify the connection by computing a hash over the receiver’s initial key and generate a nonce as a fresh random number. Then, the responder will reply by sending its own random number and signing with its private key a message digest computed over the concatenation of both random numbers. Upon the receipt of this segment, the initiator will verify the signature received from the responder by using its corresponding public key and it will in turn reply by signing a hash over both nonces that will be verified by the responder, closing the three-way handshake. Figure 9

Security solution based on public-key (see online version for colours)

6.3 Comparison of security solutions The three security approaches (the hash chain-based, the HMAC-based and the public-key-based) guarantee source authentication for new subflows, since only a node that was involved in the establishment of the connection will know the required key for setting up new subflows. So, in all cases the vulnerability window for forging the crypto-material is limited to the initial exchange, but the vulnerability window for integrity attacks includes all the

153 subflow establishments. However, the main difference between them is that the HMAC scheme is vulnerable to passive attackers at first who may listen to the initial exchange of the key, whilst the hash chain and public-key schemes require a more active role played by the attacker, who may replace the exchanged crypto-material with its own generated crypto-material. Moreover, should a man-in-the-middle attacker capture the exchanged key in the HMAC scheme, it could use it to establish new subflows without noticing from the legitimate peers. This is not the case with either the hash chain or public-key schemes, because since the crypto-material has to be replaced for an attack to be successful, if the legitimate peers try again to establish a new subflow, they will realise that an attack has been performed.

7

Performance analysis

The three studied approaches (the one proposed based on hash chains, the HMAC-based and the public-key-based) have been implemented by using the openssl2 libraries in a Pentium Core 2 Duo P8700 (2.53 GHz) with 4 GB of RAM. Table 1 summarises the overhead introduced by these solutions in terms of extra bytes and computational processing time, from the standpoint of an initiator who sets up a connection and afterward adds subsequent subflows. Table 1 details the different stages of each approach. Firstly, the establishment of the connection by exchanging the required crypto-material, which in the case of the hash chain solution is conveyed through one segment, whilst in the HMAC and public-key approaches is transported through a couple of segments (hence the additions in the first row). And finally, the process of joining a subflow to the connection (whose overhead is measured on a persubflow basis), which involves the following stages: •

Identification of the connection: through the corresponding hash in the case of the hash chain or by hashing the receiver’s token in the other two schemes.



Verification of the received crypto-material by means of the appropriate mechanism: hashing the received hash value and checking against the previous stored hash, through a signature verification process by using the public key of the peer or by checking the HMAC using the shared keys.



Signing crypto-material: in order for the initiator to authenticate itself to the responder. In the public-key solution, the initiator will generate a signature with its private key, whilst in the HMAC approach a message authentication code is computed. On the other hand, this stage does not apply to the hash chain scheme.

In the hash chain solution, a length of ten elements has been considered sufficient for most scenarios, covering the establishment of the connection and the addition of nine additional subflows.

154

J. Díez et al.

Table 1

Comparison of MPTCP security approaches Hash chain (ten elements)

Public-key (1024-bit RSA)

HMAC (SHA-1)

Overhead (bytes)

Time (ms)

Overhead (bytes)

Time (ms)

Overhead (bytes)

Time (ms)

20

578

8 + 288

21 + 113

8 + 16

21 + 1

Connection establishment Crypto-material generation Addition of a new subflow Identify the connection

12

-

8

107

8

107

Verify crypto-material received

-

76

-

52

-

125

Signing crypto-material

-

-

128

46

20

62

The first row of Table 1 shows that the hash chain solution spends 578 ms generating the chain, whereas in the publickey solution the generation of the random key and the RSA key pair takes 21 ms and 113 ms, respectively. Analogously, the HMAC approach requires 21 ms to generate the random key, but just one second in the concatenation of the shared keys. Regarding to the size overhead, the hash chain and HMAC approaches introduce a similar amount of extra bytes during the establishment phase (20 bytes vs. 24 bytes), while the public-key scheme adds the considerable figure of 296 bytes, mostly due to the public key exchange. Relating to the addition of new subflows, Table 1 illustrates that the hash chain approach takes less time and overhead than the other two solutions. This is because the mechanism used to identify the connection as well as to perform source authentication is the sending of the corresponding hash value from a chain that was already generated during the establishment phase. So, it is ready to be used without introducing more operations, apart from the required verification of the received crypto-material, which takes 76 ms, i.e., somewhere in between the other two approaches. In summary, in the hash chain approach there is a tradeoff between the significant consumption of time at generating the hash chain and the rapid subsequent usage of its elements, which equates to the other two approaches when two additional subflows are established in the case of the public-key scheme and five in the case of the HMAC solution. On the contrary, the size overhead introduced by the public-key and HMAC is much higher than in the hash chain proposal, especially in the public-key solution which requires the exchanging of 272-byte public-key and the later sending of a 128-byte signature, with the consequent impact on the transmission delay.

8

Conclusions and future work

This work presents a security solution based on hash chains to enhance the security provided for MPTCP. The proposal provides protection against redirection attacks, which are susceptible to happen due to MPTCP address agility mechanism when the nodes try to add additional subflows to the established connection. In particular, flooding and

hijacking attacks are prevented; including the time-shifted flavour. Unlike in the HMAC solution (the chosen approach for the MPTCP specification), in our proposal the timeshifted attack is mitigated as it will end up being detected if peers try to establish a new subflow again. One potential threat is that of a man-in-the-middle attacker who is present in the connection establishment and later remains on-path on all the hijacked subflows for the lifetime of the connection. Nevertheless, since this vulnerability is already present in regular TCP, it is considered out of scope as far as this study is concerned. The only residual threat that has been pinpointed but not completely developed, just outlined, is that of the integrity time-shifted attack whose solution based on subflow identifiers has not been implemented. The rationale for this is that the complexity introduced does not trade off the mitigation of the minor vulnerability it constitutes. In addition to the above, this threat is not avoided either in the MPTCP specification with the usage of HMAC as its security mechanism. Therefore, it remains as future work to be considered. The solution based on hash chains is very efficient because it only involves hash operations, and the crypto-material is included in the TCP header as TCP options, without the need to encrypt or modify the payload. In contrast to the public-key solution, which provides a similar kind of protection, our proposal introduces less overhead (the public-key approach requires the exchanging of a 272-byte public-key) and speeds up the addition of new subflows, at the expense of a somewhat higher processing time during the establishment of the connection due to the generation of the hash chain. Finally, since MPTCP is being developed to work not only with IPv6 but also with IPv4, some characteristics of IPv6 such as the usage of cryptographically generated addresses (CGA) (Aura, 2005) cannot be used in this context, but it may be taken into account as future work when considering the application of this protocol to IPv6.

Acknowledgements This article has been partially granted by the Community of Madrid through the MEDIANET project (S2009-TIC1468).

Security for multipath TCP: a constructive approach

References Arkko, J. and Nikander, P. (2002) ‘Weak authentication: how to authenticate unknown principals without trusted parties’, Proceedings of Security Protocols Workshop, Cambridge, UK, 16–19 April, February. Aura, T. (2005) ‘Cryptographically generated addresses (CGA)’, RFC 3972, available at http://www.rfc-editor.org/rfc/rfc3972.txt, March (accessed on 1 July 2011). Aura, T., Nikander, P. and Camarillo, G. (2004) ‘Effects of mobility and multihoming on transport-protocol security’, IEEE Symposium on Security and Privacy, May, pp.12−16. Bagnulo, M. (2011) ‘Threat analysis for multi-addressed/ multi-path TCP’, RFC 6181, available at http://www.rfc-editor.org/rfc/rfc6181.txt, March (accessed on 1 April 2011). Dong, Y., Wang, D. and Wang, J. (2006) ‘A concurrent transmission control protocol’, IEEE Conference on Communications Network, June, Vol. 3, Nos. 25–28, pp.796−800. Ford, A., Raiciu, C., Handley, M. and Barre, S. (2011) ‘TCP extensions for multipath operation with multiple addresses’, work in progress, available at http://tools.ietf.org/html/draft-ietf-mptcp-multiaddressed-03, March, (accessed on 10 May 2011). Hsieh, H. and Sivakumar, R. (2002) ‘pTCP: an end-to-end transport layer protocol for striped connections’, IEEE International Conference on Network Protocols (ICNP), Paris, France, November. Krawczyk, H., Bellare, M. and Canetti, R. (1997) ‘HMAC: keyedhashing for message authentication’, RFC 2104, available at http://www.rfc-editor.org/rfc/rfc2104.txt, February (accessed on 5 October 2011). Lamport, L. (1981) ‘Password authentication with insecure communication’, Communications of the ACM, November, Vol. 24, No. 11, pp.770–772. Lebovitz, G. and Rescorla, E. (2010) ‘Cryptographic algorithms, use, & implementation requirements for tcp authentication option’, RFC 5925, available at http://www.rfc-editor.org/rfc/rfc5925.txt, June (accessed on 5 October 2011).

155 Nordmark, E. (2005) ‘Threats relating to IPv6 multihoming solutions’, RFC 4218, available at http://www.rfc-editor.org/rfc/rfc4218.txt, October (accessed on 5 October 2011). Perrig, A., Song, D., Canetti, R., Tygar, J.D. and Briscoe, B. (2005) ‘Timed efficient stream loss-tolerant authentication (TESLA): multicast source authentication transform introduction’, RFC 4082, available at http://www.rfc-editor.org/rfc/rfc4082.txt, June (accessed on 5 October 2011). Rojviboonchai, K. and Aida, H. (2002) ‘An evaluation of multi-path transmission control protocol (M/TCP) with robust acknowledgement schemes’, IEICE Transactions on Communications, Vol. E87-B, No. 9, pp.2699–2707, October. Sarkar, D. (2006) ‘A concurrent multipath TCP and its Markov model’, Proceedings of International Conference on Communications, Istanbul, Turkey, June, pp.645–656. Wischik, D., Handley, M. and Bagnulo, M. (2008) ‘The resource pooling principle’, ACM SIGCOMM Computer Communication Review, October, Vol. 38, No. 5, pp.47–52. Ylitalo, J., Torvinen, V. and Nordmark, E. (2004) ‘Weak identifier multihoming protocol framework (WIMP-F)’, work in progress, available at https://datatracker.ietf.org/doc/draft-ylitalo-multi6-wimp, June, (accessed on 5 October 2011). Zhang, M., Lai, J., Krishnamurthy A., Peterson, L. and Wang, R. (2004) ‘A transport layer approach for improving end-to-end performance and robustness using redundant paths’, Proceedings of the USENIX Annual Technical Conference, Boston, MA, June, pp.99−112.

Notes 1 2

openssl speed is a command part of the OpenSSL Project, http://www.openssl.org. openssl is an open-source general purpose cryptography library licensed under an Apache-style license.