skype_p2p_model

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 September 15, 2004 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, Experimenta- tion, 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 voice- calls, 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 peer- to-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. Figure 1. Skype Network. There are three main entities: supernodes, ordinary nodes, and the login server. 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 end- to-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. 4. SKYPE FUNCTIONS Skype functions can be classified into startup, login, user search, call establishment and tear down, media transfer, and presence messages. This section discusses each of them in detail. 4.1 Startup When SC was run for the first time after installation, it sent a HTTP 1.1 GET request to the Skype server (skype.com). The first line of this request contains the keyword ‘installed’. During subsequent startups, a SC only sent a HTTP 1.1 GET request to the Skype server (skype.com) to determine if a new version is available. The first line of this request contains the keyword ‘getlatestversion’. See the Appendix for complete messages. 4.2 Login Login is perhaps the most critical function to the Skype operation. It is during this process a SC authenticates its user name and password with the login server, advertises its presence to other peers and its buddies, determines the type of NAT and firewall it is behind, and discovers online Skype nodes with public IP addresses. We observed that these newly discovered nodes were used to maintain connection with the Skype network should the SN to which SC was connected became unavailable. 4.2.1 Login Process As discussed in Section 2, the HC must contain a valid entry for a SC to be able to connect to the Skype network. If the HC was filled with only one invalid entry, SC could not connect to the Skype network and reported a login failure. However, we gained useful insights in the Skype login process by observing the message flow between SC and this invalid HC entry. The experimental setup and observations for the login process are described below. First, we flushed the SC host cache and filled it with only one entry which was the IP address and port number of a machine on which no Skype client was running. The SC was then started and a login attempt was made. Since HC had an invalid entry, SC could not connect to the Skype network. We observed that the SC first sent a UDP packet to this entry. If there was no response after roughly five seconds, SC tried to establish a TCP connection with this entry. It then tried to establish a TCP connection to the HC IP address and port 80 (HTTP port). If still unsuccessful, it tried to connect to HC IP address and port 443 (HTTPS port). SC then waited for roughly 6 seconds. It repeated the whole process four more times after which it reported a login failure. We observed that a SC must establish a TCP connection with a SN in order to connect to the Skype network. If it cannot connect to a super node, it will report a login failure. Most firewalls are configured to allow outgoing TCP traffic to port 80 (HTTP port) and port 443 (HTTPS port). A SC behind a firewall, which blocks UDP traffic and permits selective TCP traffic, takes advantage of this fact. At login, it establishes a TCP connection with another Skype node with a public IP address and port 80 or port 443. Figure 2. Skype login algorithm. Only one entry is present in the HC. If there is more than one entry, SC sends UDP packets to them before attempting a TCP connection. Authentication with the login server is not shown. 4.2.2 Login Server After a SC is connected to a SN, the SC must authenticate the user name and password with the Skype login server. The login server is the only central component in the Skype network. It stores Skype user names and passwords and ensures that Skype user names are unique across the Skype name space. SC must authenticate itself with login server for a successful login. During our experiments we observed that SC always exchanged data over TCP with a node whose IP address was 80.160.91.11. We believe that this node is the login server. A reverse lookup of this IP address retrieved NS records whose values are ns14.inet.tele.dk and ns15.inet.tele.dk. It thus appears from the reverse lookup that the login server is hosted by an ISP based in Denmark. 4.2.3 Bootstrap Super Nodes After logging in for the first time after installation, HC was initialized with seven IP address and port pairs. We observed that upon first login, HC was always initialized with these seven IP address and port pairs except for a rare random occurrence. In the case where HC was initialized with more than seven IP addresses and port pairs, it always contained those seven IP address and port pairs. It was with one of these IP address and port entries a SC established a TCP connection when a user used that SC to log onto the Skype network for the first time after installation. We call these IP address and port pairs bootstrap super nodes. Figure 16 shows a snapshot of the host cache of the SC that contains IP address and port numbers of these bootstrap super nodes. These IP address and port pairs and their corresponding host names obtained using a reverse lookup are: IP address:port Reverse lookup result 66.235.180.9:33033 sls-cb10p6.dca2.superb.net 66.235.181.9:33033 ip9.181.susc.suscom.net 80.161.91.25:33033 0x50a15b19.boanxx15.adsl-dhcp.tele.dk 80.160.91.12:33033 0x50a15b0c.albnxx9.adsl-dhcp.tele.dk 64.246.49.60:33033 rs-64-246-49-60.ev1.net 64.246.49.61:33033 rs-64-246-49-61.ev1.net 64.246.48.23:33033 ns2.ev1.net From the reverse lookup, it appears that bootstrap SNs are connected to the Internet through four ISPs. Superb [14], Suscom [15], ev1.net [16] are US-based ISPs. After installation and first time startup, we observed that the HC was empty. However upon first login, the SC sent UDP packets to at least four nodes in the bootstrap node list. Thus, either bootstrap IP address and port information is hard coded in the SC, or it is encrypted and not directly visible in the Skype Windows registry, or this is a one-time process to contact bootstrap nodes. We also observed that if the HC was flushed after the first login, SC was unable to connect to the Skype network. These observations suggest that we perform separate experiments to analyze the first-time and subsequent login processes. 4.2.4 First-time Login Process The SC host cache was empty upon installation. Thus, a SC must connect to well known Skype nodes in order to log on to the Skype network. It does so by sending UDP packets to some bootstrap super nodes and then waits for their response over UDP for some time. It is not clear how SC selects among bootstrap SNs to send UDP packets to. SC then established a TCP connection with the bootstrap super node that responded. Since more than one node could respond, a SC could establish a TCP connection with more than one bootstrap node. A SC, however, maintains a TCP connection with at least one bootstrap node and may close TCP connections with other nodes. After exchanging some packets with SN over TCP, it then perhaps acquired the address of the login server (80.160.91.11). SC then establishes a TCP connection with the login server, exchanges authentication information with it, and finally closes the TCP connection. The initial TCP data exchange with the bootstrap SN and the login server shows the existence of a challenge-response mechanism. The TCP connection with the SN persisted as long as SN was alive. When the SN became unavailable, SC establishes a TCP connection with another SN. Figure 3. Message flow for the first login after installation for SC on a public IP address. ‘B’ stands for bytes and ‘N’ stands for node. SYN and ACK packets are shown to indicate who initiated TCP connection. Message flows are not strictly according to time. Messages have been grouped together to provide a better picture. Message size corresponds to size of TCP or UDP payload. Not all messages are shown. For the login process, we observed message flow for the same Skype user id for the three different network setups described in Section 3. The message flow for the first-time login process for a SC running on a machine with public IP address is shown in Figure 3. The total data exchanged between SC, SN, login server, and other nodes during login is about 9 kilobytes. Figure 4. Message flow for first login after installation for SC behind a simple NAT. ‘B’ stands for bytes and ‘N’ stands for node. SYN and ACK packets are shown to indicate who initiated TCP connection. Message flows are not strictly according to time. Messages have been grouped together to provide a better picture. Message size corresponds to size of TCP or UDP payload. Not all messages are shown in the message flow. For a SC behind a port-restricted NAT, the message flow for login was roughly the same as for a SC on a public IP address. However, more data was exchanged. On average, SC exchanged 10 kilobytes of data with SN, login server, and other Skype nodes. The message flow is shown in Figure 4. A SC behind a port-restricted NAT and a UDP-restricted firewall was unable to receive any UDP packets from machines outside the firewall. It therefore could send and receive only TCP traffic. It had a TCP connection with a SN and the login server, and it exchanged information with them over TCP. On average, it exchanged 8.5 kilobytes of data with SN, login server, and other Skype nodes. The message flow is shown in Figure 5. Figure 5. Message flow for first login after installation for a SC behind a firewall, which blocks UDP packets. ‘B’ stands for bytes and ‘N’ stands for node. SYN and ACK packets are shown to indicate who initiated TCP connection. Message flows are not strictly according to time. Messages have been grouped together to provide a better picture. Message size corresponds to size of TCP or UDP payload. Not all messages are shown in the message flow. The following inferences can be drawn by careful observation of call flows in Fig 3, 4, and 5. 4.2.4.1 NAT and Firewall Determination We conjecture that a SC is able to determine at login if it is behind a NAT and firewall. We guess that there are at least two ways in which a SC can determine this information. One possibility is that it can determine this information by exchanging messages with its SN using a variant of the STUN [1] protocol. The other possibility is that during login, a SC sends and possibly receives data from some nodes after it has made a TCP connection with the SN. We conjecture that at this point, SC uses its variation of STUN [1] protocol to determine the type of NAT or firewall it is behind. Once determined, the SC stores this information in the Windows registry. We also conjecture that SC refreshes this information periodically. We are not clear on how often a SC refreshes this information since Skype messages are encrypted. 4.2.4.2 Alternate Node Table Skype is a p2p client and p2p networks are very dynamic. SC, therefore, must keep track of online nodes in the Skype network so that it can connect to one of them if its SN becomes unavailable. From Figure 3 and 4, it can be seen that SC sends UDP packets to 2