iOS 7 Adds Multipath TCP

Published: 2013-10-01
Last Updated: 2013-10-01 12:55:28 UTC
by Johannes Ullrich (Version: 1)

iOS 7 added a new feature, that hasn't been widely advertised. This feature, Multi Path TCP (MPTCP) is currently used by Siri, but could be used by other applications down the road. MPTCP is an extension to TCP allowing a TCP connection between hosts using multiple IP addresses. It's design is in particularly interesting in that it is backwards compatible with firewalls. As far as your firewall or other network devices are concerned, each multipath TCP connection is a valid TCP connection using it's own sequence numbers and its own handshake to set it up and tear it down. All the "magic" of signaling happens via new TCP options.

MPTCP is not proprietary. It is a standard (RFC 6824 [1]), and has been implemented for Linux for example, but so far has not seen much use, which may cause you to notice it the first time when looking at traffic from iOS 7 devices.

Just as a quick refresher: A TCP connection is established by the client sending a SYN packet to the server. The server responds with a SYN-ACK and the client completes the handshake using an ACK packet. During this handshake, the hosts will exchange random initial sequence numbers. The sequence number will increment by one for each byte transmitted. The sequence number is very important to reassemble the data stream. Without sequence number, the data stream could loose it's order.

Simplistically, one could setup two TCP connections, and just distribute the data between them. But if the sequence number stream is not continuous, many firewalls will disrupt the connection. This is why each MPTCP stream has its own sequence number. But this puts up another problem: How do we know how the streams, or "subflows" as the RFC calls them, fit together?

Lets first talk about how the MPTCP connection is setup:

The TCP connection starts out like any TCP connections with a SYN/SYN-ACK/ACK handshake. However, if MPTCP is available, the three handshake packets will include the "Multipath Capable (MP_CAPABLE)" option. Both ends need to support multipath, or it will not be used. The MP_CAPABLE option includes a key, that will later be used to authenticate additional subflows.

A host may now add a new subflow, and this subflow will be authenticated using a hash derived from the keys exchanged earlier, and nonces that are unique to each new subflow. The MP_JOIN option is used to carry this data. Throughout the connection, hosts may inform each other of newly acquired addresses and they may use the for new subflows. Since each subflow has its own set of sequence numbers, "Data Sequence Signals" are used to communicate how the sequence numbers in the subflow map to the combined data flow. The protocol has a lot of little details that make it well suited for hosts connected to multiple wireless networks. For example, different subflows may have different priorities. One usage scenario is a cell phone connected to a Wifi as well as a cellular network, and roaming between the two. For example, you start a TCP connection at home, and continue using it as you leave the house and your phone switches to the cellular network. As long as both networks are available for a while, MPTCP may drop the Wifi connection and exclusively use the cell phone data connection until you reach another WiFi network. But enough about how the protocol works, here are some packets. A quick BPF to capture these packets (for example with tcpdump):

tcp[12]&0xf0=>0xe0

It is not perfect, but because the options involved are rather large, you will find MPTCP packets by looking for larger TCP header sizes. This filter looks for a header size of 56 and above, with 60 being the maximum (you don't really need the bitmask for the filter). Wireshark and tshark deal rather well with MPTCP. For example, tshark displays for the TCP options:

        Multipath TCP: Multipath Capable
            Kind: Multipath TCP (30)
            Length: 12
            0000 .... = Multipath TCP subtype: Multipath Capable (0)
            .... 0000 = Multipath TCP version: 0
            Multipath TCP flags: 0x01
                0... .... = Checksum required: 0
                .... ...1 = Use HMAC-SHA1: 1
            Multipath TCP Sender's Key: 8848941202347829228

tcpdump on the other hand has a much harder time:

16:44:15.681318 IP 70.91.145.11.57799 > 17.174.8.5.443: Flags [S], seq 847601216, win 65535, options [mss 1460,nop,wscale 3,Unknown Option 3000017acdc123cc42a7ec,nop,nop,TS val 102569696 ecr 0,sackOK,eol], length 0

it just displays the raw option as an "Unknown Option" Option "0x30" happens to be the "Multipath Capable" option.

Other options:

0x31: MP_JOIN

0x32: DSS - Data Sequence Signal

0x33: ADD_ADDR - Add new address

0x34: REMOVE_ADDR - Remove address

0x35: MP_PRIO - Change subflow priority

0x36: MP_FAIL - Fallback (used to communicate checksum failures back to sender)

0x37: MP_FASTCLOSE - Fast Close (like TCP Reset, but only for subflow)

[1] http://tools.ietf.org/html/rfc6824

------
Johannes B. Ullrich, Ph.D.
SANS Technology Institute
Twitter

Keywords: iOS MPTCP siri TCP