IEG3090

A case study: Skype

Dah Ming Chiu

Chinese University of Hong Kong
Skype overview
 VoIP, Instant Messaging and Videoconferencing
 Original name of project – “Sky Peer-to-Peer”
 Developers of P2P system Kazaa
 Kazaa was used for content sharing; but the system
got into legal problems
 The company changed direction to adapt Kazaa for
VoIP
 Skype was free, easy to use, with good
performance
 It had rapid growth since it came out in August 2003
 It was sold to eBay in 2006 for US$2.6B
User interface of latest version
User population

 By Q4 of 2008, Skype has 405M accounts, with

more than 33M daily active users
 It had 20.5B Skype-to-Skype minutes, and 2.6
Skype-out minutes.
 Skype-out is charged; Skype needs to pay local phone
companies for access to their customers – a form of
“peering”
 It had US$145M net revenue
New announcements

New initiatives to generate revenue

 Skype for SIP

 Skype for iPhone

Why is Skype successful?

 Many possible reasons

 Using P2P technology is one possible reason
 Better Codecs?
 Better handling of peers behind NAT and firewalls?
 Better integration with Instant Messaging and
Presence?
 Better integration with PSTN?
 …
 The Skype protocol is encrypted, so it is not
possible to truly “reverse engineer” it, but guess
what it does
Learning about a protocol from traffic
analysis
Baset and Schulzrinne, “An analysis of the Skype peer-to-
peer Internet telephony protocol”, Infocom 2006

 Capture packets using tools such as Wireshark

 Try to deduce the design of the system from traffic
analysis
 We can compare Skype with a SIP-based VoIP system
SIP – session initiation protocol

 Look up user’s
addr/port, based on
name 1) register
 First look up proxy server Proxy
of user domain in DNS, server
similar to mail server
lookup 4) Set up rest
3) What is my of parameters
 Then look up user from friend’s IP
proxy server addr?

 Then negotiate the rest DNS

of parameters between 2) Where is my friend’s
the two peers proxy server?

 SIP is a text-based
protocol allowing you to
Skype nodes

Skype client (SC)

 Use a host cache to
remember Super nodes

Super node (SN)

 providing p2p service
 a bit like proxy server
 but providing more services

Login Server:
 only centralized server
 provide login service
Not all nodes are born equal

What a node is capable of doing depends on:

 Does the node have a public IP address?

 Is the node behind a NAT box?

 Is the node behind a firewall that blocks UDP

packets?

Only peers with public IP addresses (and with

sufficient CPU and memory) can become a SN
A peer cannot control whether it becomes a SN
Services provided by SN

 A few special “bootstrap” SNs help SC find login

server
 A SN helps a SC determine whether it is behind
NAT or UDP-blocking firewall
 A SN helps a SC search a user
 Any user logged in during the last 72 hours can be
found
 This is validated by the paper
 A SN helps two SC behind firewalls to relay voice
packets
Transport protocols used

 Signaling is done using TCP

 Why?
 Voice packets are usually transferred using UDP
 Why?
 If there are UDP-blocking firewall in between,
then TCP is used.
Bootstrapping

 To avoid hard-wiring the login-server info in the

software, perhaps a small number of SNs are
hardwired (with fixed IP addresses and using port
80 and 443).
 These bootstrap SNs seems to provide addr/port
of login-server
 They may also help SC to determine whether it is
behind NAT or firewall
STUN

 STUN = Simple Traversal of UDP datagram

protocol through NATs
 Skype may use something similar to STUN
 A server implementing STUN will respond to a
client, after repeated messages, the client knows
whether it is behind a NAT or/and a firewall

STUN NAT or STUN

client firewall, or server
nothing?
Login

 The login server ensures each user has unique

name
 Establish session keys for SCs
 Based on close examination of the few protocol
messages, it appears Skype is using SSL
 The login servers appear to be in Denmark and
Netherlands

Try UDP first,

then TCP
 Searching for users

When not restricted by firewall, SC

goes through this loop
1) Talk to SN (TCP), get a list of peers
2) Talk to the list of peers (UDP)
3) If not found, get a longer list from
SN to repeat search

Something in-between flood and

random walk?

If restricted by firewall, SN does the

search instead
More about search

 Login server may help search

 Search result is cached in intermediate nodes
 Search for wildcards allowed
 The retrieved results are not identical
Tools used to help analysis

 Ethereal is used to capture packets generated by

Skype
 NetPeeker is used to tune the bandwidth to study
Skype operation under congestion
 DNS – reverse DNS lookup
 MaxMind – used to look up country/city of IP
address
 NAT box
 UDP-blocking firewall
 Autolt – a scripting tool used to start/stop Skype
sessions
 Netstat – to see to check addr/port of a
Experiments to reverse engineer

 Try the three scenarios one by one:

 Public IP
 Behind NAT
 Behind firewall
 Try emptying Host Cache
 Write a script to try many sessions, capture
session specific data
Number of SN seen

After 8163 successful logins

Distribution of SNs

Note, majority (83.7%) found in US

About the authors

 Professor Henning Schulzrinne is chair of

Columbia’s CS Dept.
 He is one of the most important contributors to
multimedia networking, particularly VoIP
 He was the main contributor for RTP, SIP etc
 P2P SIP also started with his project at Columbia

There is more references about “Skype analysis” at:

http://www1.cs.columbia.edu/~salman/skype/