310 likes | 886 Views
Peer-to-Peer Networks - Skype. Hongli Luo CEIT, IPFW. Skype. Reference: An Analysis of the Skype Peer-to-peer Internet Telephony Protocol, S. Baset, H. Schulzrinne, 2004
E N D
Peer-to-Peer Networks - Skype Hongli Luo CEIT, IPFW
Skype • Reference: An Analysis of the Skype Peer-to-peer Internet Telephony Protocol, S. Baset, H. Schulzrinne, 2004 • Use traffic analysis, shared library and system call interception techniques to analyze the various aspects of the Skype protocol
Voice over IP (VoIP) VoIP – transport of voice over IP-based networks Complexity ranges from Hobbyists using Internet to get free phone calls on peer-to-peer basis to Full scale PSTN replacement networks VoIP must address Types of end user terminals - IP phones, PC clients Quality of Service – ensure agreed quality Security risks must be clearly identified Last mile bandwidth – which affects codec, packetization period and where to use compression to best meet service goals Signaling protocol must support service set required
VoIP Quality of Service (Delay, Jitter, Packet loss) Use RSVP, DiffServ, MPLS, even ATM RTP is used for media traffic Signaling protocol: SIP Video on Skype Provide video calling on Skype Need a web camera Available on computer, mobile, TV
Skype clients (SC) Skype login server P2P Case study: Skype • A peer-to-peer (P2P) overlay network for VoIP and other applications, developed by founder of KaZaA • P2P (pc-to-pc, pc-to-phone, phone-to-pc) Voice-Over-IP (VoIP) application • also IM • SkypeOut and SkypeIn servers – PC-to-PSTN and PSTN-to-PC • proprietary application-layer protocol (inferred via reverse engineering) • Packet transmission (voice and control packets) are encrypted Supernode (SN)
The Skype Network hierarchical overlay
The Skype Network (contd…) • Ordinary host (SC) • A Skype client • Super nodes (SN) • A Skype client • Has public IP address, ‘sufficient’ bandwidth, CPU and memory • Login server • Stores Skype id’s, passwords, and buddy lists • Used at login for authentication • Version 1.4.0.84: 212.72.49.141 and 195.215.8.141 • Peer uses a variant of STUN protocol to determine the type of NAT and firewall it is behind
The Skype Network (contd…) • NAT and firewall traversal • Public IP address • Port-restricted NAT • A port-restricted NAT allows an external host, with source IP address X and source port P, to send a packet to the internal host only if the internal host had previously sent a packet to IP address X and port P. • UDP-restricted firewall • Uses wideband codec to maintain reasonable call quality at an available bandwidth of 32 kbps • Uses TCP for signaling • Uses both UDP and TCP for transporting media traffic
Skype: making a call • User starts Skype • SC registers with SN • list of bootstrap SNs Skype login server • SC logs in (authenticate) • Call: SC contacts SN with callee ID • SN contacts other SNs (unknown protocol, maybe flooding) to find addr of callee; returns addr to SC • SC directly contacts callee, over TCP
Skype Components • Client listens on particular ports for incoming calls • Maintains a table of other Skype nodes called host cache • Wide codec • Buddy list • Encrypts messages end-to-end • Determines whether it is behind a NAT or a firewall
Skype Components • Ports • No default listening port • Randomly chooses a port (P1) on installation • Also opens TCP listener sockets at port 80 (HTTP) for incoming http requests and port 443 (HTTPS)
Skype Components (contd…) • Host cache (HC) • IP address and port number of online Skype nodes (SNs) • Maximum size: 200 entries • Liang, Kumar and Ross. Understanding KaZaA • 200 entries for ordinary nodes (ON) • Login server IP address and port number • If unable to establish a connection with any HC entry • Connect with one of the seven bootstrap IP address and port pairs hardcoded in the Skype executable • HC Windows location C:\Documents and Settings\All Users\Application Data\Skype\shared.xml
Skype Components (Contd…) • Codecs (GlobalIPSound) • Wide band codecs (50-8,000 Hz) • iLBC (packet size: 20 and 30 ms bitrate: 15.2 kbps and 13.3 kbps) • iSAC (packet size: 30-60 ms bitrate: 10-32 kbps) • G.729 for SkypeOut? • Buddy list • Stored in ‘config.xml’ file • C:\Documents and Settings\<XP user>\Application Data\Skype\<skype user id> <CentralStorage> <LastBackoff>0</LastBackoff> <LastFailure>0</LastFailure> <LastSync>1120325519</LastSync> <NeedSync>0</NeedSync> <SyncSet> <u> <skypebuddy1>f384d3a0:1</skypebuddy1> <skypebuddy2>7d1dafc4:1</skypebuddy2>
Skype Functions • Startup • Login • User search • Call establishment • Media transfer • Keep-alive • NAT and firewall traversal • Conferencing
Skype Functions: STARTUP • First time startup • Sent a HTTP 1.1 GET request to the Skype server (Skype.com) • GET /ui/0/97/en/installed HTTP/1.1 • Normal startup • To determine a newer version of Skype is available, during login • GET /ui/0/97/en/getlatestversion?ver=0.97.0.6 HTTP/1.1
Skype Functions: LOGIN • Establishes a TCP connection with SN • Authenticates with the login server and gets a certified public key • Bootstrap super nodes - Hard-coded in Skype • A SC must establish a TCP connection with a SN in order to connect to Skype network • A SC is able to determine at login if it is behind a NAT and a firewall • Bootstrap sn IP address and hostnames obtained by a reverse lookup
Skype Functions: USER SEARCH • Claimed by Skype • Guaranteed to find a user if it exists and logged in the last 72 hours • Search results are cached at intermediate nodes • Unable to trace messages beyond SN • Cannot force a node to become a SN • Host cache is used for connection establishment and not for SN selection • User does not exist. How does search terminate? • Skype contacts login server for failed searches • SN searches for a user behind UDP-restricted firewall • Same wildcard (sal*) search query from two different machines initiated at the same time gives different results
Skype Functions: CALL ESTABLISHMENT • Call signaling always carried over TCP and goes e2e • Calls to non buddies=search+call • Initial exchange checks for blocked users • Public-public call • Caller SC establishes a TCP connection with callee SC • Public-NAT • Caller SC is behind port-restricted NAT • Caller---->Skype node (SN) ----> Callee • TCP connection established between caller, callee, and more than one Skype nodes • Unknown: How a node is selected to route calls from caller to callee? • Perhaps determined at login • Firewall-firewall call • Same as public-NAT but no in-UDP packets
Skype Functions: CALL ESTABLISHMENT • Caller is behind port-restricted NAT and callee has a public IP address • Caller sent signaling to an online Skype node which forwarded it to callee (both over TCP) • Media flowed directly between caller and callee over UDP
Skype Functions: CALL ESTABLISHMENT • Caller and callee are behind port-restricted NAT and UDP-blocking firewall • Both caller and callee exchange signaling information over TCP with another online Skype node.
Skype Functions: MEDIA TRANSFER • 10/100 Mbps Ethernet • iSAC codec was used (adaptive bit-rate)
Skype Functions: MEDIA TRANSFER • No silence suppression • Silence packets are used to • play background noise at the peer • maintain UDP NAT binding • avoid drop in the TCP congestion window • Putting a call on hold • Send 1 packet/3 seconds to call-peer or Skype node • same reasons as above • Codec frequency range • 50-8,000 Hz (total bw of 3 kilobytes/s) • Reasonable call quality at (4 kilobytes/s)
Skype Functions: KEEP ALIVE • Send refresh message over TCP to SN every 120 seconds • Refresh message size: 2 bytes
Skype Functions: CONFERENCING • A, B, and C have public IP addresses • B and C were sending traffic over UDP to A • A acts as a mixer A:1.6GHz Pentium4, 512MB RAM B A+C B: 3 GHz Pentium4, 1GB C A+B C: 3 GHz Pentium4, 1GB