April 2017 – Multipath news

  • Information
  • 0 comments

Welcome to this new monthly note that summarises the main news about multipath protocols such as Multipath TCP in April.

IETF 98

The IETF MPTCP Working Group met during two successive sessions during the IETF 98 meeting in Chicago. These two sessions covered different topics.

The meeting began with a summary of the recent progress for the charter items of the working group. The chairs noted the publication of RFC804 that describes the use cases and operational experience with Multipath TCP.

Then the chairs asked for implementation update. Christoph Paasch gave an update of the Linux implementation of Multipath TCP. This implementation is now aligned with Linux kernel 4.4 and a new official release is expected in the coming weeks. Christoph Paasch has started to work on supporting the changes introduced by RFC6824bis. Christoph confirmed that the new handshake does not appear too difficult to implement. He has identified a few points in RFC6824bis, that could be slightly clarified and will share them in a few weeks. He is also updating the implementation of the ADD_ADDR2 option. A first patch was proposed months ago, but the specification has changed since this patch and Christoph is updating it. He is also working on supporting the Multipath TCP RST as specified in RFC6824bis.

Then, Alan Ford discussed the evolution of RFC6824bis. Several points are still being discussed. The two main ones are the modifications to the address advertisement that were presented by Fabien Duchene last year in draft-duchene-mptcp-add-addr-00. The slide below summarises the current situation. The first two points have been accepted, the third has received some support from Christoph. Some discussion is stil expected in the mailing list.

The second point is the Application layer authentication, i.e. the ability to extract the keys that are used by Multipath TCP from the application using the bytestream. With TLS or SSH it becomes possible to derive a Multipath TCP key from the secure key that has been negotiated during the secure handshake at the application layer. This idea had been initially proposed in draft-paasch-mptcp-ssl-00, it has been updated in draft-paasch-mptcp-tls-authentication-00 and draft-paasch-mptcp-application-authentication-00. This approach has two benefits. First it allows Multipath TCP to leverage the security key handshake that is performed by the application. Second, the server can directly select the token used by each connection, which could ease the deployment of some load balancers.

The discussion continued with several presentations about recent research results.
Olivier Bonaventure discussed two directions to improve Multipath TCP. First, Olivier explained that on smartphones most applications do not transmit a large amount of data. On smartphones, bandwidth aggregation is not the main benefit of Multipath TCP. The main benefit is the possibility of fast handovers when the smartphone leaves a wireless network and needs to switch to another. This fast handover is the main reason why Apple has chosen Multipath TCP to support Siri. On the other hand, smartphone users want to limit the utilisation of the cellular network which is often more expensive than the Wi–Fi and minimise energy consumption. Olivier explained that if a smartphone wants to use break-before-make to reduce its energy consumption, then the four-way handshake that is required to create an additional subflow causes an additional delay of two round-trip-times which can affect interactive applications such as voice recognition. He suggested that Multipath TCP should support the transmission of data inside the SYN+MP_JOIN. This idea raised several questions and several members of the WG would support such an extension. Then Olivier described Multipath TCP Secure. Multipath TCP Secure is an extension to Multipath TCP that provides the ability to encrypt and authenticate data and TCP options. Compared with running TLS over Multipath TCP, a major benefit of Multipath TCP Secure is that if an attacker modifies data or TCP options on one path, Multipath TCP Secure detects the attack, stops using that path and moves data over clean paths.  TLS over Multipath TCP would terminate the TLS session. Additional details and an implementation in the Linux kernel are available in a forthcoming INFOCOM’17 paper.
Costin Raiciu continued with a new secure handshake that leverages the availability of two (or more) paths to enhance the security of the key handshake. The solution proposed performs part of the secure key handshake on the initial subflow and part on the second subflow. If the second subflow is disjoint from the first one, the solution can cope with passive and active attackers, provided that there is at least one path on which the attacker is not active (i.e. they cannot modify the packets passing on this path). Given that this security key handshake needs to send data over the second subflow at the beginning of the connection, it would also benefit from a solution that allows to transmiting data inside the SYN+MP_JOIN. A paper describing the solution has been submitted and a prototype implementation is being written.
Then, Joseph Isaac described the results of experiments when he used Multipath TCP to bond several low bandwidth satellite links during a flight. This environment is pretty challenging since the links have varying qualities and performance. Initially, they worked with Multilink PPP but did not obtain good results. They deployed Multipath TCP proxies to support the HTTP and IRC applications that are required during the flight and obtained good results.
Then, Kien Nguyen proposed to duplicate SYNs to create all subflows simultaneously instead of using MP_CAPABLE on the initial subflow and MP_JOIN on the additional ones.  This idea reduces the delay to create the additional subflows, but unfortunately this solution does not appear to be secure.
The second part of the meeting was devoted to discussion on Multipath TCP proxies. Multipath TCP proxies allow the conversion of regular TCP connections into Multipath TCP connections and conversely. They have already been deployed for two different use cases: smartphones and hybrid access networks. The discussion focused mainly on hybrid access networks and the slide below shown by the chairs summarises the three main approaches that have been explored in the working group.
In a hybrid access network, the client host is connected to a CPE that is connected to two different networks, typically an xDSL and an LTE network operated by the same network operator. The network operator controls a network proxy that is reachable from the two access networks. When a client host opens a TCP connection towards a remote server, this connection is intercepted by the CPE and converted into a Multipath TCP connection towards the network proxy. The network proxy terminates the connection and creates a new one to the final destination server.
Those hybrid access networks are being developed within the Broadband Forum that has already defined an architecture for them in TR-348 , but not yet a protocol to allow the CPE to interact with the network proxy.
Three main types of solutions have been discussed within the Multipath TCP working group. They differ in how they answer two key design questions :
Q1. How do the packets sent by the CPE reach the network proxy ?
Q2. How does the network proxy learns the address of the final server ?
The simplest solution is solution 2 in the slide above. It relies on the SOCKS protocol defined in RFC1928. When a CPE wants to create a connection towards a remote server, it first opens a SOCKS session towards the network proxy. SOCKS supports commands that allow the authentication of the CPE and also to send the address and port of the remote server. Unfortunately, SOCKS is an application layer protocol that requires the exchange of several messages to create each connection. This significantly increases the end-to-end delay and can affect short connections that are frequent nowadays.
The first solution tries to reduce the end-to-end delay by placing the address and ports of the remote server inside the SYN that is sent by the CPE to the network proxy. This idea was initially proposed in a research article. It has been refined in draft-boucadair-mptcp-plain-mode-10
Finally, the third solution is the transparent mode proposed in draft-peirens-mptcp-transparent-00. This solution leverages the ability of the underlying network to steer the packets from the CPE towards the network proxy and thus does not require a special protocol to indicate the address and ports of the final server.

MPTCP-dev Mailing list

 The mptcp-dev mailing is used to coordinate the development of the Multipath TCP implementation in the Linux kernel. Its archives are available from https://sympa-2.sipr.ucl.ac.be/sympa/arc/mptcp-dev
The most interesting messages during the last month are:

Scientific publications

Here are pointers to some scientific publications on Multipath TCP that have appeared during the last month.
M. Jadin et al. Securing MultiPath TCP: Design & Implementation, to appear, IEEE INFOCOM’17
S. Pokhrel, et al., Analytical Modeling of Multipath TCP Over Last-Mile Wireless, to appear, IEEE/ACM Transactions on Networking, to appear,
G. Papastergiou, et al., De-Ossifying the Internet Transport Layer: A Survey and Future perspectives,
  • Share

Related content