Salman A. Baset and Henning Schulzrinne An Analysis of the Skype Peer-to-Peer Internet Telephony Protocol

An Analysis of the Skype Peer-to-Peer Internet Telephony Protocol

Salman A. Baset and Henning Schulzrinne
Department of Computer Science
Columbia University, New York NY 10027
{salman,hgs}@cs.columbia.edu

ABSTRACT

Skype is a peer-to-peer VoIP client developed by KaZaa in 2003. Skype claims that it can work almost seamlessly across NATs and firewalls and has better voice quality than the MSN and Yahoo IM applications. It encrypts calls end-to-end, and stores user information in a decentralized fashion. Skype also supports instant messaging and conferencing.

This report analyzes key Skype functions such as login, NAT and firewall traversal, call establishment, media transfer, codecs, and conferencing under three different network setups. Analysis is performed by careful study of Skype network traffic. Categories and Subject Descriptors C.2.2 [Computer-Communication Networks]: Network Protocols—Applications General Terms Algorithms, Design, Measurement, Performance, Experimentation, Security, Keywords Peer-to-peer (p2p), Voice over IP (VoIP), Super Node (SN), Internet telephony, conferencing

1. INTRODUCTION

Skype is a peer-to-peer VoIP client developed by KaZaa [17] that allows its users to place voice calls and send text messages to other users of Skype clients. In essence, it is very similar to the MSN and Yahoo IM applications, as it has capabilities for voicecalls, instant messaging, audio conferencing, and buddy lists. However, the underlying protocols and techniques it employs are quite different.

Like its file sharing predecessor KaZaa, Skype is an overlay peerto- peer network. There are two types of nodes in this overlay network, ordinary hosts and super nodes (SN). An ordinary host is a Skype application that can be used to place voice calls and send text messages. A super node is an ordinary host’s end-point on the Skype network. Any node with a public IP address having sufficient CPU, memory, and network bandwidth is a candidate to become a super node. An ordinary host must connect to a super node and must register itself with the Skype login server for a successful login. Although not a Skype node itself, the Skype login server is an important entity in the Skype network. User names and passwords are stored at the login server. User authentication at login is also done at this server. This server also ensures that Skype login names are unique across the Skype name space. Figure 1 illustrates the relationship between ordinary hosts, super nodes and login server.

Apart from the login server, there is no central server in the Skype network. Online and offline user information is stored and propagated in a decentralized fashion and so are the user search queries.

NAT and firewall traversal are important Skype functions. We believe that each Skype node uses a variant of STUN [1] protocol to determine the type of NAT and firewall it is behind. We also believe that there is no global NAT and firewall traversal server because if there was one, the Skype node would have exchanged traffic with it during login and call establishment in the many experiments we performed.

The Skype network is an overlay network and thus each Skype client (SC) should build and refresh a table of reachable nodes. In Skype, this table is called host cache (HC) and it contains IP address and port number of super nodes. It is stored in the Windows registry for each Skype node. Skype claims to have implemented a ‘3G P2P’ or ‘Global Index’ [2] technology (Section 4.3), which is guaranteed to find a user if that user has logged in the Skype network in the last 72 hours. Skype uses wideband codecs which allows it to maintain reasonable call quality at an available bandwidth of 32 kb/s. It uses TCP for signaling, and both UDP and TCP for transporting media traffic. Signaling and media traffic are not sent on the same ports.

The rest of this report is organized as follows. Section 2 describes key components of the Skype software and the Skype network. Section 3 describes the experimental setup. Section 4 discusses key Skype functions like startup, login, user search, call establishment, media transfer and codecs, and presence timers. Flow diagrams based on actual network traffic are used to elaborate on the details. Section 5 discusses conferencing. Section 6 discusses other experiments.

2. KEY COMPONENTS OF THE SKYPE SOFTWARE

A Skype client listens on particular ports for incoming calls, maintains a table of other Skype nodes called host cache, uses wideband codecs, maintains a buddy list, encrypts messages endto- end, and determines if it is behind a NAT or a firewall. This section discusses these components and functionalities in detail.

2.1 Ports

A Skype client (SC) opens a TCP and a UDP listening port at the port number configured in its connection dialog box. SC randomly chooses the port number upon installation. In addition, SC also opens TCP listening ports at port number 80 (HTTP port), and port number 443 (HTTPS port). Unlike many Internet protocols, like SIP [5] and HTTP [6], there is no default TCP or UDP listening port. Figure 15 shows a snapshot of the Skype connection dialog box. This figure shows the ports on which a SC listens for incoming connections.

2.2 Host Cache

The host cache (HC) is a list of super node IP address and port pairs that SC builds and refreshes regularly. It is the most critical part to the Skype operation. At least one valid entry must be present in the HC. A valid entry is an IP address and port number of an online Skype node. A SC stores host cache in the Windows registry at HKEY_CURRENT_USER / SOFTWARE / SKYPE / PHONE / LIB / CONNECTION / HOSTCACHE. After running a SC for two days, we observed that HC contained a maximum of 200 entries. Host and peer caches are not new to Skype. Chord [19], another peer-to-peer protocol has a finger table, which it uses to quickly find a node.

2.3 Codecs

The white paper [7] observes that Skype uses iLBC [8], iSAC [9], or a third unknown codec. GlobalIPSound [10] has implemented the iLBC and iSAC codecs and their website lists Skype as their partner. We believe that Skype uses their codec implementations. We measured that the Skype codecs allow frequencies between 50-8,000 Hz to pass through. This frequency range is the characteristic of a wideband codec.

2.4 Buddy List

Skype stores its buddy information in the Windows registry. Buddy list is digitally signed and encrypted. The buddy list is local to one machine and is not stored on a central server. If a user uses SC on a different machine to log onto the Skype network, that user has to reconstruct the buddy list.

2.5 Encryption

The Skype website [13] explains: “Skype uses AES (Advanced Encryption Standard) – also known as Rijndel – which is also used by U.S. Government organizations to protect sensitive information. Skype uses 256-bit encryption, which has a total of 1.1 x 1077 possible keys, in order to actively encrypt the data in each Skype call or instant message. Skype uses 1536 to 2048 bit RSA to negotiate symmetric AES keys. User public keys are certified by Skype server at login.”

2.6 NAT and Firewall

We conjecture that SC uses a variation of the STUN [1] and TURN [18] protocols to determine the type of NAT and firewall it is behind. We also conjecture that SC refreshes this information periodically. This information is also stored in the Windows registry.

Unlike its file sharing counter part KaZaa, a SC cannot prevent itself from becoming a super node.

3. EXPERIMENTAL SETUP

All experiments were performed for Skype version 0.97.0.6. Skype was installed on two Windows 2000 machines. One machine was a Pentium II 200MHz with 128 MB RAM, and the other machine was a Pentium Pro 200 MHz with 128 MB RAM. Each machine had a 10/100 Mb/s Ethernet card and was connected to a 100 Mb/s network.

We performed experiments under three different network setups. In the first setup, both Skype users were on machines with public IP addresses; in the second setup, one Skype user was behind port-restricted NAT; in the third setup, both Skype users were behind a port-restricted NAT and UDP-restricted firewall. NAT and firewall machines ran Red Hat Linux 8.0 and were connected to 100 Mb/s Ethernet network.

Ethereal [3] and NetPeeker [4] were used to monitor and control network traffic, respectively. NetPeeker was used to tune the bandwidth so as to analyze the Skype operation under network congestion.

For each experiment, the Windows registry was cleared of any Skype entries and Skype was reinstalled on the machine. All experiments were performed between February and April, 2004.