Multipath TCP discussed at Blackhat 2014

The interest in Multipath TCP continues to grow. During IETF90, an engineer from Oracle confirmed that they were working on an implementation of Multipath TCP on Solaris. This indicates that companies see a possible benefit with Multipath TCP. Earlier this week, Catherine Pearce and Patrick Thomas from Neohapsis gave a presentation on how the deployment of Multipath TCP could affect enterprise that heavily rely on firewalls and IDS in their corporate network. This first ‘heads up’ for the security community will likely be followed by many other attempts to analyse the security of Multipath TCP and its implications on the security of an enterprise network.

In parallel with their presentation, Catherine and Patrick have released two software packages that could be useful for Multipath TCP users. Both are based on a first implementation of Multipath TCP inside scapy written by Nicolas Maitre during his Master thesis at UCL.

  • mptcp_scanner is a tool that probes remote hosts to verify whether they support Multipath TCP. It would be interesting to see whether an iPhone is detected as such (probably not because there are no servers running on the iPhone). In the long term, we can expect that nmap
  • mptcp_fragmenter is a tool that mimics how a Multipath TCP connection could send start over different subflows. Currently, the tool is very simple, five subflows are used and their source port numbers are fixed. Despite of this limitation, it is a good starting point to test the support of Multipath TCP on firewalls. We can expect that new features will be added as firewalls add support for Multipath TCP.

NorNet moving to Multipath TCP

The NortNet testbed is a recent and very interesting initiative from the Simula laboratory in Norway. This testbed is composed of two parts :

  • the NorNet Core is a set of servers on different locations in Norway and possibly abroad. Each location has a few servers that are connected to several ISPs. There are correctly more than a dozen of NortNet Core sites in Norway
  • the NorNet Edge comprises hundreds of nodes that are connected to several cellular network providers

As os this writing, NortNet is the largest experimental platform that gathers nodes that are really multihomed. Recently, NortNet has upgraded its kernels to include Multipath TCP. This will enable large scale experiments with Multipath TCP in different network environments. We can expect more experimental papers that use Multipath TCP at a large scale.

Additional information about NortNet maybe be found on the web and in scientific articles such as :

Gran, Ernst Gunnar; Dreibholz, Thomas and Kvalbein, Amund: NorNet Core - A Multi-Homed Research Testbed Computer Networks, Special Issue on Future Internet Testbeds, vol. 61, pp. 75-87, DOI 10.1016/j.bjp.2013.12.035, ISSN 1389-1286, March 14, 2014.

Tracebox for Android

tracebox is a middlebox detection tool that was desgined by Gregory Detal to detect middleboxes that modify IP or TCP headers [IMC] . The command line version of tracebox runs of various Linux variants and allows to craft special packets with various options to test for middleboxes that :

  • add TCP options (e.g. many ADSL routers would insert an MSS option in the SYN segment)
  • modify TCP options (e.g. a transparent proxy will change the timestamp option)
  • remove TCP options (e.g. some firewalls remove unknown TCP options)

The latter is problematic for extensions like Multipath TCP <http://www.multipath-tcp.org> and various testers and informed us that some 3G/4G networks block Multipath TCP by default. Some operators have even informed us that they’ve used tracebox to detect the offending firewall and change its configuration. However, running tracebox from a laptop is not always convenient.

Valentin Thirion, a student from the University of Liege, has been recently working on a port of some of the features of tracebox on the Android platform. His App, Android Tracebox runs on rooted smartphones and contains a basic implementation of tracebox that can be used to detect where some specific options, including the MP_CAPABLE option are removed or modified in the network.

../../../_images/tracebox.png

In the Mobistar network that I use, it does not reveal any strange behavior

traceboxing to 173.252.110.27
1 * * *
2 10.40.211.145 IP::DSCP/ECN IP::TTL IP::Checksum TCP::Checksum TCP::Option_MSS
3 172.31.5.238 IP::DSCP/ECN IP::TTL IP::Checksum
4 10.30.23.89 IP::DSCP/ECN IP::TTL IP::Checksum TCP::Checksum TCP::Option_MSS
5 212.65.36.129 IP::DSCP/ECN IP::TTL IP::Checksum
6 81.52.186.121 IP::TTL IP::Checksum
7 193.251.240.218 IP::TTL IP::Checksum TCP::Checksum TCP::Option_MSS
8 193.251.132.15 IP::TTL IP::Checksum TCP::Checksum TCP::Option_MSS
9 193.251.252.166 IP::TTL IP::Checksum
10 204.15.22.198 IP::TTL IP::Checksum TCP::Checksum TCP::Option_MSS
11 31.13.29.255 IP::TTL IP::Checksum TCP::Checksum TCP::Option_MSS
12 31.13.24.95 IP::TTL IP::Checksum TCP::Checksum TCP::Option_MSS
13 173.252.65.99 IP::DSCP/ECN IP::TTL IP::Checksum

This output indicates that this 3G provider is using DSCP to mark packets, and that it updates or inserts the MSS option. This is a common behavior to prevent some problems with Path MTU discovery.

On the WiFi access provided by Voo, the path seems to be even cleaner

traceboxing to 173.252.110.27
1 192.168.0.1 IP::Checksum
2 10.163.0.1 IP::TTL IP::Checksum
3 78.129.125.89 IP::TTL IP::Checksum
4 212.3.237.49 IP::TTL IP::Checksum
5 4.69.148.182 IP::TTL IP::Checksum TCP::Checksum
6 4.69.143.94 IP::TTL IP::Checksum TCP::Checksum
7 4.69.137.70 IP::TTL IP::Checksum TCP::Checksum
8 4.69.141.18 IP::TTL IP::Checksum TCP::Checksum
9 4.69.202.57 IP::TTL IP::Checksum TCP::Checksum
10 4.69.134.150 IP::TTL IP::Checksum TCP::Checksum
11 4.69.149.210 IP::TTL IP::Checksum
12 4.53.116.78 IP::TTL IP::Checksum
13 31.13.24.8 IP::TTL IP::Checksum TCP::Checksum
14 31.13.29.232 IP::TTL IP::Checksum TCP::Checksum
15 173.252.64.191 IP::TTL IP::Checksum

References

[IMC]Gregory Detal, Benjamin Hesmans, Olivier Bonaventure, Yves Vanaubel, and Benoit Donnet. 2013. Revealing middlebox interference with tracebox. In Proceedings of the 2013 conference on Internet measurement conference (IMC ‘13). ACM, New York, NY, USA, 1-8. DOI=10.1145/2504730.2504757 http://doi.acm.org/10.1145/2504730.2504757

Dissecting Siri

Siri is the voice recognition application used by Appel’s iPhones and iPads. The application captures the user’s voice and send it to Apple servers on the cloud that run voice recognition algorithms and return the voice samples converted in text format. Since this is a closed source application, there are very few details about its operation. Still, it is the largest user of Multipath TCP and for this reason, it’s worth being discussed here.

A recent paper [Cavivlione] written by Luca Caviglione briefly analyses the Siii application from a networking viewpoint. The papers looks at the sizes of the packets that were exchanged, tries to infer the type of data exchanged and the duration of the TCP connections. It discusses several scenarios during the user dictates various sentences. Unfortunately, the paper was written before the release of iOS7 that started to use Multipath TCP for Siri.

It could be interesting to perform similar tests with a recent version of Siri that uses Multipath TCP. Unfortunately, since the data is encrypted and potentially partially transmitted over cellular networks, this is more challenging than when a single TCP connection was used. Up to iOS6, the open-source SiriProxy could be used to intercept Siri messages and even use them to trigger some specific operations for e.g. home automation. Unfortunately, SiriProxy does not seem to be useable anymore with iOS7 as discussed in details on https://github.com/plamoni/SiriProxy/issues/542

References

[Cavivlione]Luca Caviglione, A first look at traffic patterns of Siri, Transactions on Emerging Telecommunications Technologies, 2013, http://dx.doi.org/10.1002/ett.2697