My next class:

iOS 7 Adds Multipath TCP

Published: 2013-10-01. Last Updated: 2013-10-01 12:55:28 UTC
by Johannes Ullrich (Version: 1)
4 comment(s)
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
4 comment(s)
My next class:

Comments

Hey Johannes - really enjoying the podcasts. Thanks!

Should this line read 'each new subflow'?
"and nonces that are unique to each no subflow."

Does this mean that we are likely to see mobile malware that makes use of Multipath TCP to find byod devices that talk back to a server on two different IP addresses, one of which is likely bypassing the corporate firewall via a cellular network and essentially advertising itself as an attack vector to the malware originator?

Anonymous

Oct 1st 2013
1 decade ago

Fixed the typo. thanks.

I haven't had a chance yet to test this with different IDS/Firewalls, but I expect that they will have problems with it. They need to be able to combine the subflows and figure out the combined content. If possible, it may be best to block TCP Option 0x30, but again, I haven't test this, and it may "break stuff".

The use case for MPTCP assumes that you are connected to different networks that are not necessarily under one administrative control. This is a difficult scenario no matter what IDS or firewall you have.

Anonymous

Oct 1st 2013
1 decade ago

This article is particularly interesting to me since our company has a whole effort to support Apple products, and iOS 7 is obviously getting a lot of attention right now. I'm curious about the statement that MPTCP is backwards compatible with firewalls. I imagine it would be better supported with an application-layer firewall vs a stateful firewall? I'm assuming the bigger name firewall vendors would support looking in the packet for the "Multipath Capable" option but sometimes these things don't work. Would love to hear any experiences with having MPTCP work with firewalls.

Anonymous

Oct 2nd 2013
1 decade ago

Minor typo. "the data stream could loose it's order." Should be "lose", not "loose". Loose is not tight. Lose is the opposite of found.

Anonymous

Oct 4th 2013
1 decade ago

Login here to join the discussion.


Top of page
Diary Archives