6.7.10

Special Look: Face Time (part 1: Introduction)

Facetime Introduction

With the iPhone 4g, video chat through Facetime is a reality in a mobile device. As a frequent traveler, I use Skype on my laptop or netbook to stay in touch with family and friends, but it usually requires some planning and coordination. With Facetime, we can initiate a voice call over the cellular network, then switch to video on demand, when WiFi service is also available (which hopefully not be a requirement in the future).

As a packet junkie, I find the concept of Facetime very interesting. The intended usage for Facetime, as described by SteveEsteban, is for a user to place a call over the cellular network with the freedom to switch to video, then back and forth as desired. Focusing on the network protocol components, there are several interesting challenges:

Device capabilities negotiation and call setup over WiFi;

Video content streaming between devices;

Authorization to accept the video stream by recipient;

NAT traversal for users behind a WiFi NAT interface;

Binding between GSM and WiFi traffic to mitigate spoofing attacks.

Knowing this, a lot of interesting questions come to mind. How is the management and streaming traffic protected? How is the call authorized by the end-user? What can we deduce by sniffing the WiFi-side of a Facetime transaction?

In this multi-part series, we'll look at how the Facetime protocol works, answering these and other questions while looking at tools and techniques for network protocol analysis. It's my hope that you'll learn about the Facetime protocol by reading this series, and furthermore, be able to apply these techniques to other protocols as well.

High-Level Assessment

To assess the protocol, I've taken several packet captures from my unencrypted wireless network, c alling 888-Facetime (Apple's service for customers to try out Facetime) and a colleague at the SANS Institute. Most of the analysis will be on the call to 888-Facetime, though I'll introduce other packet captures as needed.

The Facetime call with 888-Facetime was initiated by Apple's representative, which I'll herein refer to as an "inbound" session, due to the differences in Facetime calls in the role of initiator or responder. The details of my iPhone 4g are as follows:

iOS Version:

4.0 (8A293)

IP Address:

172.16.0.114

MAC Address:

5c:59:48:02:8a:65

My AP was running in 802.11b mode (for simplifying the packet capture process), also acting as a NAT at 172.16.0.1.

Loading up the packet capture in Wireshark, I applied a display filter to include traffic only from or to my address:

ip.addr eq 172.16.0.114

Using Wireshark's Protoco l Hierarchy summary (Statistics | Protocol Hierarchy), we can get a quick look at all the protocols in this 28,034 packet capture file, as shown.

Besides the low-layer protocols, we can see different activity here:

UDP DNS traffic (to be expected);

Session Traversal Utilities for NAT (STUN);

Session Initiation Protocol (SIP);

Lots of unrecognized UDP data packets;

HTTP traffic transmitting XML data;

HTTPS traffic;

Unrecognized TCP traffic;

ICMP.

Wireshark doesn't give us the option to sort this traffic view by time, but we can switch to the Conversations view (Statistics | Conversations) to view time-relative data by protocol, as shown (TCP first, then UDP):

We can see a few nodes are involved here:

Address

Name

Note

17.149.36.103

No DNS Name

Apple, Inc system in the 17/8 netblock

72.215.224.43

init.ess.apple.com.edgesuite.net

An Akamai server, a239.da1.akamai.net

199.7.52.190

crl.verisign.net

Verisign's CRL server

17.155.4.14

No DNS Name

Apple, Inc system in the 17/8 netblock

17.155.5.251

No DNS Name

Apple, Inc system in the 17/8 netblock

17.155.5.252

No DNS Name

Apple, Inc system in the 17/8 netblock

68.105.28.11

cdns1.cox.net

My ISP's DNS server

17.109.28.227

No DNS Name

Apple, Inc system in the 17/8 netblock

Using the timing and address information, we can construct a timeline of what happens in this session:

Step

Nodes

Description

1

172.16.0.114 -> 17.149.36.103

The iPhone 4g initiates a TCP session to the remote host over TCP/5223. Wireshark does not have a dissector for this protocol, though it believes the port number is associated with the HP Virtual Group protocol.

2

172.16.0.114 -> 17.155.5.251

Several UDP connections from the iPhone 4g to Apple's server over UDP/59007.