Observing Siri : the three-way handshake
Apple’s Siri is the largest use of Multipath TCP as of this writing. This post looks at one Multipath TCP connection established by a single-homed iPad running iOS7 over a single WiFi interface. The trace below shows a simple Multipath TCP session between this iPad and the standard Siri server. As all Multipath TCP connections, it starts with a three-way exchange :
12:43:31.311061 IP (tos 0x0, ttl 64, id 54778, offset 0, flags [DF], proto TCP (6), length 76)
192.168.2.2.62787 > siri.4.https: Flags [S], cksum 0x5e3a (correct), seq 2739181685, win 65535, options [mss 1460,nop,wscale 3,mp capable flags:H sndkey:96e576198c475350,nop,nop,TS val 1363555813 ecr 0,sackOK,eol], length 0
The first segment is a SYN segment. It contains several TCP options :
These TCP options are standard TCP options that are used on modern TCP stacks. It is a bit surprising to see a window scale option for an application like Siri where typically only a small amount of data will be exchanged.
The last option is the MP_CAPABLE option defined in RFC 6824 that proposes the utilisation of Multipath TCP. In the SYN segment, this option contains the random 64 bits key chosen by the sender.
12:43:31.342236 IP (tos 0x0, ttl 244, id 52382, offset 0, flags [DF], proto TCP (6), length 64)
siri.4.https > 192.168.2.2.62787: Flags [S.], cksum 0x034b (correct), seq 1880401460, ack 2739181686, win 8190, options [mss 1460,nop,wscale 4,nop,nop,sackOK,mp capable flags:H sndkey:d7b705e4d86c1a66], length 0
The second segment is the SYN+ACK segment returned by the server. It is interesting to note that this segment does not contain the RFC 1323 timestamp option and uses a different windows scale than the one proposed by the client in the SYN segment. The absence of the timestamp option is probably to avoid using too many option bytes in the data segments.
12:43:31.345448 IP (tos 0x0, ttl 64, id 47496, offset 0, flags [DF], proto TCP (6), length 60)
192.168.2.2.62787 > siri.4.https: Flags [.], cksum 0x3719 (correct), seq 1, ack 1, win 8280, options [mp capable flags:H sndkey:96e576198c475350 rcvkey:d7b705e4d86c1a66], length 0
The third segment, contains the MP_CAPABLE option that includes the keys chosen by the sender and the receiver. Since the client repeats the sender and receiver keys in the ACK segment, the server can remain stateless.
12:43:31.357386 IP (tos 0x0, ttl 64, id 53779, offset 0, flags [DF], proto TCP (6), length 204)
192.168.2.2.62787 > siri.4.https: Flags [P.], cksum 0xeb34 (correct), seq 1:145, ack 1, win 8280, options [mp dss flags:MA dack: 2248627404 dsn: 3845908739 sfsn: 1 dlen: 144,eol], length 144
12:43:31.357430 IP (tos 0x0, ttl 64, id 23748, offset 0, flags [DF], proto TCP (6), length 100)
192.168.2.2.62787 > siri.4.https: Flags [P.], cksum 0x0c31 (correct), seq 145:185, ack 1, win 8280, options [mp dss flags:MA dack: 2248627404 dsn: 3845908883 sfsn: 145 dlen: 40,eol], length 40
12:43:31.385032 IP (tos 0x0, ttl 244, id 30705, offset 0, flags [DF], proto TCP (6), length 48)
siri.4.https > 192.168.2.2.62787: Flags [.], cksum 0x4c82 (correct), seq 1, ack 145, win 2221, options [mp dss flags:A dack: 3845908883], length 0
12:43:31.389460 IP (tos 0x0, ttl 244, id 31058, offset 0, flags [DF], proto TCP (6), length 48)
siri.4.https > 192.168.2.2.62787: Flags [.], cksum 0x4c34 (correct), seq 1, ack 185, win 2219, options [mp dss flags:A dack: 3845908923], length 0
The data transfer can now start. Siri uses HTTPS and thus the Multipath TCP connection begins with a TLS handshake. The details of this handshake are not important for Multipath TCP. There are some interesting details to mention concerning this utilisation of Multipath TCP. First, iOS7 does not seem to use the DSS checksum. This checksum was designed to detect payload modifications by middleboxes. With TLS, it is unlikely that a middlebox will modify the contents of the segment. Second, the DSNs and Data acks are 32 bits wide while RFC 6824 defines both 32 bits and 64 bits Data sequence numbers. iOS7 seems to place one DSS option inside each segment.
When analyzing packet traces, it is often interesting to show graphically the evolution of the connection. For regular TCP, tcptrace provides various ways to visualise the evolution of a TCP connection. Benjamin Hesmans is developing a tool that will provide the same features but for Multipath TCP. This tool is still being developed, but it already provides some nice visualisations. Since Siri only sends a small amount of data, we can only plot the evolution of the Multipath TCP Data Sequence Number.
The figure below shows the flow of data from the client (i.e. the iPad) to the server. Each vertical bar corresponds to one or more segments and the red dots represent acknowledgments. The WiFi network used for the test worked well and there were no losses.
With Siri, most of the data is sent by the client as shown by the server sequence number trace below. After the TLS handshake, only very few data is sent by the server.
