P2P System :----- Skype
Skype is a peer-to-peer VoIP(voice over IP) client developed in 2003 by the organization that created Kazaa. Skype claims that it can work almost seamlessly across NATs and firewalls and has better voice quality than other VoIP clients. It encrypts calls end-to-end, and stores user information in a decentralized fashion. Skype also supports instant messaging and conferencing.
The typical bandwidth load on a supernode is relatively low, even if the supernode is relaying VoIP traffic. Email was the original killer application for the Internet. Today, voice over IP (VoIP) and instant messaging (IM) are fast supplementing email in both enterprise and home networks. Skype is an application that provides these VoIP and IM services in an easy-to-use package that works behind Network Address Translators (NAT) and firewalls. It has attracted a user-base of 50 million users,
I. INTRODUCTION
Skype 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 uses 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 authenticate itself with the Skype login server. Although not a Skype node itself, the Skype login server is an important entity in the Skype network as user names and passwords are stored at the login server. This server ensures that Skype login names are unique
across the Skype name space. Starting with Skype version 1.2, the buddy list is also stored on the login server.
Apart from the login server, there are SkypeOut and SkypeIn servers which provide PC-to-PSTN and PSTN-to-PC bridging. SkypeOut and SkypeIn servers do not play a role in PC-to-PC call establishment and hence we do not consider them to be a part of the Skype peer-to-peer network. Thus, we consider the login server to be the only central component in the Skype p2p network. Online and offline user information is stored and propagated in a decentralized fashion.
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 the login and call establishment phases in the many experiments we performed.
The Skype network is an overlay network and thus each Skype client (SC) needs to 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. Starting with Skype v1.0, the HC is stored in an XML file.
II. KEY COMPONENTS OF THE SKYPE SOFTWARE
A Skype client listens on particular ports for incoming calls, maintains a table of other Skype nodes called a 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.
A. 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 and 443 which, otherwise, are used to listen for incoming HTTP and HTTP-over-TLS requests. Unlike many Internet protocols like SIP and HTTP , there is no default TCP or UDP listening port. Figure 1 shows a snapshot of the Skype (v1.4) connection dialog box
Fig:-1
B. 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 a critical part to the Skype operation. In SC v0.97, 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. At login time, a SC v0.97 tried to establish a TCP connection and exchange information with any HC entry. If it was unable to do so, it reported a login failure. In Skype v1.2 and onwards, if a SC is unable to establish a TCP connection with any HC entry, it tries to establish a TCP connection and exchange information with one of the seven bootstrap IP address and port pairs hard-coded in the Skype executable
C. Codecs
During our experiments, we observed that Skype uses the iLBC iSAC and iPCM codecs
D. Buddy List1
In Windows XP, Skype stores its buddy information in an XML file . Starting with Skype v1.2 for Windows XP, the buddy list is also stored on a central Skype server The buddy list is stored unencrypted on a computer
E. Encryption
The Skype website explains: “Skype uses AES (Advanced Encryption Standard), also known as Rijndael, which is 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 1024 bit RSA to negotiate symmetric AES keys.
F. NAT and Firewall
We conjecture that SC uses a variation of the STUN and TURN 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 shared.xml file. Unlike its file sharing counter part Kazaa, a Skype client cannot prevent itself from becoming a super node.
III. 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.
A. Startup
When SC v1.4 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 requestcontained the keyword ‘installed’.
B. 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, discovers online Skype nodes with public IP addresses, and checks the availability of latest Skype version.
1) Login Process
Using the library function call overloading technique described in section III.B, we overrode the connect(), and sendto() calls such that these calls always returned with a failure. However, we permitted a TCP connection to localhost since Skype refuses to run if cannot establish this connection. The system time was printed whenever the connect() and sendto() functions were called to accurately profile the time at which Skype sends its login messages.
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 p2p 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 the login server for a successful login. During our experiments we observed that SC always exchanged data over TCP with a node
3) Bootstrap Super Nodes
We list the IP address and port numbers of the seven default SNs observed during a failed login attempt. The corresponding hostnames and the first entry of the authority section returned by reverse lookup query (dig) are given in Table II. From the reverse lookup, it appears that one SN is maintained by Skype itself.
4) NAT and Firewall Determination
We conjecture that a SC is able to determine at login if it is behind a NAT and a 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 protocol. The other possibility is that during login, a SC sends and possibly receives data from some nodes after it has established a TCP connection with the SN. We conjecture that at this point, SC uses its variation of STUN [5] protocol to determine the type of NAT or firewall it is behind. Once determined, the SC stores this information in the shared.xml file. 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.
5) Login Process Time
We measured the time to login on the Skype network for the three different network setups described in section III. For this experiment, the HC already contained the maximum of two hundred entries. The SC with a public IP address and the SC behind a port-restricted NAT took about 3-7 seconds to complete the login procedures.
C. User Search
Skype uses its Global Index (GI) technology to search for a user. Skype claims that search is distributed and is guaranteed to find a user if it exists and has logged in during the last 72 hours. Extensive testing suggests that Skype was always able to locate users who logged in using a public or private IP address in the last 72 hours. Skype is a not an open protocol and its messages are encrypted. Whereas for login, we were able to form a reasonably precise opinion about the different entities involved, it is not possible to do so in search, since we cannot trace the Skype messages beyond a SN. Also, we were unable to force a SC to connect to a particular SN. Nevertheless, we have observed and present search message flows for the three different network setups. A SC has a search dialog box. After entering the Skype user id and pressing the find button, SC starts its search for a particular user. For SC on a public IP address, SC sent a TCP packet to its SN. It appears that the SN gave SC the IP address and port number of eight nodes to query, since after that exchange with SN, SC sent UDP packets to eight nodes. If it could not find the user, it informed the SN over TCP. It appears that the SN now asked it to contact sixteen different nodes, since the SC then sent UDP packets to sixteen different nodes. This process continued until the SC found the user or it determined that the user did not exist. On average, SC contacted more than 24 nodes. The search took three to four seconds.
A SC behind a port-restricted NAT exchanged data between SN and some of the nodes which responded to its UDP request during login process. The search took about five to six seconds.
A SC behind a port-restricted NAT and UDP-restricted firewall sent the search request over TCP to its SN. We believe that SN then performed the search query and informed SC of the search results. Unlike a user search by SC on a public IP address, SC did not contact any other nodes. This suggests that SC knew that it was behind a UDP-restricted firewall. The aggregated message flow is shown Figure 7. The search took about 10-15 seconds. In some successful searches, we saw the SC exchanging information with the login server. It appears that Skype is using the login server as a fall back option in case the search is unsuccessful. For a non-existent Skype name, a SC always contacted the login server.
D.Skype Super Node Map
We performed experiments to get insights into the Skype super node selection mechanism. We know that at login, a SC must always connect to a SN. We take advantage of the fact that if a SC is behind a NAT, it will never become a SN and it will most likely connect to only one super node. Also, in a subsequent immediate login, a SC does not always reconnect to the same super node it connected last time. By having Skype repeatedly login onto the Skype network for an extended period of time, we can get a partial snapshot of the Skype super nodes.
No comments:
Post a Comment