“From a security point of view, MPTCP is suitable for any corporate environment where TCP is already accepted.” 

How does the security of MPTCP compare vs TCP?

The purpose of this blog post is to compare the security of MPTCP vs TCP. Multipath TCP was designed in the early 2010s as an extension to TCP. It inherits the main security limitations of TCP. MPTCP has been successful in achieving its goal of being at least as secure as TCP.

From a security viewpoint, TCP has evolved in two directions during the last decade: 

• The first approach was to add cryptographical techniques to TCP. This approach was suggested by the TCPCrypt paper and resulted in the creation of the tcpinc IETF working group. This working group published several documents that specify extensions to make TCP more secure against some types of attacks, but no major TCP stack has adopted it.
• The second approach was to secure the application that uses TCP. In the early 2010s, many applications, including HTTP, still used TCP without any encryption. During the last decade, the adoption of Transport Layer Security (TLS) has skyrocketed. The latest version of TLS, TLS 1.3, brings stronger security performance and reduces the overhead of TLS. Today, we can safely assume that by default a networked application will use TLS and that non-TLS applications will be the exception. 

In this document, we discuss the security of Multipath TCP by assuming the use of an underlying secure protocol such as TLS. Our baseline application will be HTTPS, but the same reasoning applies to protocols such as SSH.

Attack surface

To understand the security of TLS over Multipath TCP, it is important to consider the different types of possible attackers that might interfere with it. For simplicity, we focus on an application that runs on a smartphone equipped with two network interfaces: Wi-Fi and cellular. This is, by far, the most popular deployment of Multipath TCP in 2022. This smartphone application interacts with a server as illustrated in the figure below.

Attackers can mount different types of attacks against an application that uses TLS over Multipath TCP. For each type of attacker, we compare TLS over TCP with TLS over Multipath TCP.

Passive Attackers

TLS over TCP

The first class of attackers that we consider are the passive attackers. These attackers can capture the packets passing on a particular path, but cannot modify them or inject new packets on a path. With TLS/TCP, such an attacker can collect metadata and identify the servers that are contacted by our smartphone application. This can provide some information about the interactions between our smartphone and other users, but nowadays many applications and websites rely on Content Distribution Networks (CDN) and are served by the same edge server. The attacker does not learn a lot of information from the fact that the smartphone interacts with an edge server from CDN vendor A. If the attacker can capture the beginning of the TCP connection, it can leverage the Server Name Indication (SNI) TLS extension to learn the name of the service that the smartphone uses. It is interesting to note that there are ongoing efforts to replace this SNI extension with an encrypted one. However, some networks block this ESNI extension and it is not yet widely deployed. The SNI is the only useful information that is exchanged in plaintext over this TLS/TCP connection. The attacker can collect packet traces in the hope of being able to decrypt them later. Since TLS 1.3 requires Perfect Forward Secrecy, this is highly improbable.

TLS over MPTCP

Considering TLS/MPTCP, the security properties are similar. The attacker can learn that the smartphone interacts with the server, but cannot collect the data. It can collect the SNI exchanged at the beginning of the connection. As there are two paths between the smartphone and the server, we need to discuss the location of the attacker. If the attacker captures the packets on the initial path, it will also learn the MPTCP keys and tokens exchanged over this path. This information can be valuable if the attacker can send packets. We discuss such an attacker later in this article. To defeat an attacker that collects the SNI TLS extension on only one path, the TLS/MPTCP application could operate as follows: Initiate the MPTCP connection over the first path. Exchange the beginning of the TLS ClientHello over the initial path and immediately create an MPTCP subflow over the second path. Once the second subflow has been established, send the end of the TLS ClientHello message over the second path. An attacker that captures packets over only one path will only be able to observe a fraction of the SNI extension. This could slightly improve the security of the application provided that the DNS name contained in this extension is not easily guessable by the attacker. However, if an application always uses the two paths, it becomes easier for the attacker to collect the list of the servers that are contacted by the smartphone. For example, consider an attacker that captures the packets sent over the cellular network but not those sent over a Wi-Fi hotspot. If the application always uses both cellular and Wi-Fi, then an attacker who only wants to collect metadata will always collect all servers by only observing the cellular network. Furthermore, changing the TLS library to send a fraction of the ClientHello over one path increases its complexity and increases the connection establishment time since the application needs to wait for the establishment of the two subflows before actually exchanging data. This delay could be acceptable for a VPN application using TLS/MPTCP that uses long connections, but not for HTTPS. 

Off Path Active Attackers

TLS over TCP

Our second attacker can inject packets using a spoofed address, but cannot capture any packet exchanged over the first or second path. This is a completely off-path attacker. TCP alone already includes techniques to prevent such an attacker from injecting data in an established TCP connection. These include the negotiation of the initial TCP sequence numbers and the TCP timestamps. With TLS, packet injection attacks are impossible since the attacker would need to find the keys negotiated during the TLS handshake.

TLS over MPTCP

Multipath TCP inherits from the features of TCP and TLS, but it also supports the ability to add a subflow to an existing connection. Multipath TCP authenticates the establishment of an additional subflow in two different ways:

• The server verifies the token contained in the SYN with the MP_JOIN option
• The establishment of the subflow is authenticated by using the keys negotiated during the handshake over the initial path with an HMAC computed over random numbers proposed by the client and the server

To create an additional subflow without having observed the initial one, an attacker would need to:

1. guess the token selected by the server for this specific connection. Tokens are 32 bits long and chosen randomly by the server.
2. guess the two security keys that were exchanged during the initial handshake. Each key is 64 bits long and they are generated randomly by the client and the server. Given the size of these two keys, an attack by such an offline attacker is not possible.

Half On Path

Our third attacker can inject packets using its own IP address, but cannot capture any packet exchanged by the smartphone application. Such an attacker cannot do more than the previous one. 

TLS over TCP

An attacker can modify data that it can see.

TLS over MPTCP

An additional consideration for MPTCP, an attacker can receive the SYN+ACK returned by the server, but cannot determine the security keys that are required to authenticate the establishment of the additional subflow. This prevents the attacker from becoming On Path.

On Path Attackers

Our fourth attacker is the most powerful one. It can capture packets over one path and inject packets using its own IP address.

TLS over TCP

With TLS/TCP it could inspect all the information exchanged over the connection that uses the initial path. TLS prevents it from being able to inject data over the connection or modify the exchanged data. Since this attacker is on the path used by the TCP connection, it can launch a denial of service attack by blocking all the packets sent to a specific server or from a specific client.

TLS over MPTCP

With Multipath TCP, the end hosts can detect problems such as failed TCP connections or TLS errors over a compromised path to switch all active connections to an alternate path where there is no attacker.

What about middleboxes ?

In the previous sections, we have discussed “attackers”. In the Multipath TCP context, it is important to also discuss middleboxes such as Carrier Grade NAT, firewalls, WAN Optimisers, … These middleboxes can interfere with protocols as shown by several research papers. Since these middleboxes usually reside on one path, they have similar capabilities as active on-path attackers that were discussed above. We now briefly discuss how different types of actions performed by middleboxes could interfere with TLS/MPTCP.

When there is a middlebox that changes the client IP address or port number, Multipath TCP continues to use the available paths without any difficulty. This type of middlebox was considered by the designers of Multipath TCP. These middleboxes are one of the reasons why Multipath TCP assigns an identifier to each IP address. This identifier is included in the ADD_ADDR option that advertises a new address, but also in the MP_JOIN option that creates a new subflow. The REMOVE_ADDR option also contains the identifier of the address that is removed. This enables a host to remove all the subflows that are associated with a given address identifier.

Some middleboxes such as firewalls are configured to only accept some specific TCP options. The firewalls that do not support Multipath TCP could forbid the utilisation of Multipath TCP by either removing the MP_CAPABLE option in the SYN packets or replacing it with a NOP option. In this case, the server does not receive the MP_CAPABLE option in the SYN and cannot use Multipath TCP for the new TCP connection. If a middlebox accepts the MP_CAPABLE option during the handshake, but blocks the other Multipath TCP options during the data transfer, Multipath TCP will detect that its options are not exchanged and will fall back to regular TCP to preserve connectivity.

A middlebox such as a transparent proxy that terminates the TCP connection with the client and creates a new TCP connection between itself and the server will affect the utilisation of Multipath TCP. If this middlebox supports Multipath TCP, e.g. by using the 0-RTT Convert protocol, it will enable the utilisation of Multipath TCP on the first part of the end-to-end path between the client and the middlebox. This can be beneficial if the server does not support Multipath TCP and there are multiple paths between the client and the middlebox, e.g. when the client is a smartphone connected to both Wi-Fi and cellular. If the middlebox does not support Multipath TCP, then the client will not be able to use Multipath TCP even if the server supports this extension.

Our last middlebox is a middlebox that changes the content of some packets and adjusts the TCP sequence numbers and acknowledgement numbers accordingly. Two types of middleboxes perform such modifications to the payload of the packets exchanged over TCP connections:

• Network Address Translators need to change the payload for applications such as FTP that exchange IP addresses in cleartext. Since the NAT changes the IP addresses in the IP header, it also needs to change it in the payload to support those protocols.
• Content injection proxies that were used in some cellular networks to inject HTTP headers and in some cases advertisements in web traffic

These two types of middleboxes were possible when applications did not use TLS. Today’s applications rely on TLS or security protocols with similar features which makes the inspection and the modification of encrypted data irrelevant.

Conclusion

An MPTCP connection is made up of two or more TCP connections with each TCP connection no more or less secure than any other TCP connection. Splitting the traffic across two TCP connections increases the number of attack vectors from one to two but significantly decreases the chances of an attacker obtaining the whole exchange. MPTCP is designed to make it impossible for an attacker to join an existing MPTCP connection. TCP should always be forced to use TLS and this is also recommended for MPTCP.

From a security point of view, MPTCP is suitable for any corporate environment where TCP is already accepted.

This work is supported by NGI POINTER (NGI Program for Open Internet Renovation) which has received funding from the European Commission, as part of the Horizon 2020 Research and Innovation Programme, under Grant Agreement Nº871528.