An Analysis of the Skype P2P Internet Telephony Protocol

王永豪 B91902114 杜明可 B91902104 吳治明 B91902110 Outline z Intro z The Skype Network z Key Components z Experiment setup explained z Experiment performed and results z Startup z Login z User search z Call Establishment and teardown z Logout z Media Transfer z Conferencing z Other Skype facts z Conclusion Introduction z Previous solutions are cost saving however falls short on quality. z Call-completion rate are low due to NATs and Firewalls. z Bloated interface makes usage a hassle. Requires technical expertise. The Skype Network (as it used to be) z Central Login Server z Super Nodes z Ordinary Nodes The Skype Network (as it used to be) z NAT and Firewall traversal z STUN and TURN z No global traversal server z Function distributed among nodes z A 3G P2P network z Global Index Technology z Multi-tiered network where supernodes communicate in such a way that every node in the network has full knowledge of all available users and resources with minimal latency z 72 hour guaranteed user find z TCP for signaling z UDP & TCP for media traffic The way it looks now Key Components (as they used to be) z Ports z A Skype Client (SC) opens TCP and UDP listening ports as configured in the client itself z SC also listens on ports 80(HTTP) and 443(HTTPS) z No default listening port z Host Cache (HC) z Skype is an overlay network z Thus the HC contains IP address and port# of super nodes. z Used to reside in the registry Key Components (as they used to be ) z Codecs z iLBC, iSAC, a third codec z Possibly licensed from GlobalIPSound z 50-8,000Hz z Buddy List z Used to be an encrypted registry entry z Switching computers needed reconstruction of the buddy list Key Components (as they used to be ) z Encryption z AES (Advanced Encryption Standard) z 256 bit z NAT and Firewall z SC can traverse NAT and firewalls quite successfully using variations of STUN and TURN z SC cannot prevent from becoming a super node Key Components (what has changed) z Ports z UDP and TCP ports actually used can be very random, sometimes not using the one configured in the SC. z Host Cache z Host Cache is still central to the Skype Protocol z Rather than residing in the Windows’ registry, it has been moved to C:/Documents and Settings/All Users/Application Data/Skype/shared.xml Key Components (What has changed) z Buddy List z No longer resides in the registry z Moved to C:/Document and settings/username/Application Data/skypeaccount/user1024.dbb z Swiching computers no longer needs reconstruction of the entire contact list. z Buddy List are saved both locally and in a remote server. z Last-modified based Key Components (What has changed) z Encryption z Since the size of the encrypted packets have changed since the publication of the paper, we believe that some level of modification has been made to the encryption method. Experimental setup (I) z In the paper z Skype ver. 0.97.06 z Windows 2000 z PII 200MHz 128MB RAM, PPRO 200MHz 128MB RAM z 10/100 Mb/s Ethernet z Our setup z Skype ver. 1.2.0.48 z Windows XP z Pentium M Centrino 1.5GHZ, 512MB RAM z AthlonXP 1800+(1.4Ghz) 1GB RAM z Cable, ADSL Experimenal setup (II) z Network configurations in the paper z Both machines with public IP addresses z One user behind port-restricted NAT z Both users behind port restricted NAT and UDP restricted firewall z Our Network Setup z Both machines with public IP addresses z One user behind NAT z one users behind NAT and UDP restricted firewall z One user behind a nested port-restricted NAT (two NATs) z NAT #1 – D-Link DI-714P+ Wireless Router z NAR #2 Edimax Wireless Broadband Router z Firewall – From the routers Install & Startup z Startup as in the paper z Upon first startup: HTTP GET request to skype.com with the keyword “installed” z Upon subsequent startups: HTTP GET request with keyword “getlatestversion” z Startup Now z Upon first startup: HTTP GET request to ui.skype.com with keyword “installed” z Upon subsequent startups: HTTP GET request with keyword “getlatestversion” Login Login Server(s) z Before: z Skype used to have 1 login server at 80.160.91.11 located in Denmark z Now: z From the numerous tests performed, we believe that Skype now has a “set” of login servers that varies with location. Bootstrap Nodes

z Nodes always present in the HC after instalation z 66.235.180.9 z 66.235.181.9 z 80.161.91.25 z 80.160.91.12 z 64.246.49.61 z 64.246.49.60 z 64.246.48.23 z New bootstrap nodes: z 66.235.180.9 z 66.235.181.9 z 195.215.8.145 z 210.58.72.84 z 64.246.49.61 z 64.246.49.60 z 64.246.48.23 First Time Login with public IPs

TCP:SYN UDP 18B TCP:ACK UDP 11B TCP 14B UDP 23B TCP 14B UDP 18B TCP 176B TCP 246B FIN FIN,ACK UDP 18B UDP 18B

UDP 18B Nodes UDP 26B Nodes

TCP:SYN TCP:ACK TCP 14B TCP 28B TCP 34B TCP 197B TCP 146B TCP 16B TCP 67B

ICMP UDP 34B 17 Nodes ICMP UDP 44B 5 Nodes ICMP UDP 11B replies from 22 nodes ICMP One user behind a NAT

ICMP TCP:SYN ICMP UDP 18B TCP:ACK ICMP UDP 11B TCP 14B ICMP UDP 23B TCP 14B UDP 11B TCP 176B TCP 246B FIN TCP 19B FIN,ACK TCP 1206B UDP 18B TCP 18B UDP 18B TCP 34B UDP 26B TCP 197B Nodes TCP 19B TCP 16B Nodes TCP 1026B TCP:SYN TCP 426B TCP:ACK TCP 10B TCP 2402B TCP 14B TCP 18B TCP 34B UDP 348B Nodes TCP 148B UDP 18B Nodes UDP11B Nodes TCP 61B UDP 26B Nodes UDP 18B UDP 18B Port-restricted NAT and UDP Firewall

ICMP ICMP UDP 18B ICMP UDP 44B 18 Nodes ICMP

UDP 18B TCP 19B TCP 28B TCP 1205B TCP 16B TCP 407B TCP 197B UDP 18B TCP 52B TCP 16B TCP 101B TCP 93B UDP 18B 4Nodes TCP 249B TCP 197B TCP 1460B TCP 16B TCP 588B TCP 895 TCP:SYN TCP 1460B TCP:ACK TCP 588B TCP 14B TCP 14B TCP 895B TCP 14B TCP 14B TCP 35B TCP 176B TCP 148B TCP 246B TCP 35B FIN FIN,ACK First Time Login (Our tests)

TCP:SYN TCP:SYN UDP 18B TCP:ACK TCP:ACK UDP 11B TCP 5B TCP 5B UDP 23B TCP 5B TCP 5B UDP 58B TCP 399B TCP 260B TCP 218B TCP 16B ICMP FIN TCP 56B ICMP FIN,ACK TCP 24B ICMP TCP 21B ICMP TCP 18B TCP 28B TCP 25B UDP 18B TCP 382B UDP 26B TCP 16B UDP 18B FIN UDP 18B FIN, ACK

TCP 25B TCP:SYN TCP 437B TCP:ACK TCP 16B TCP:14B TCP 14B TCP 28B TCP 232B UDP 348B 17 Nodes TCP 17B UDP 44B 5 Nodes UDP 11B replies from 22 nodes One user behind a NAT (Our Tests)

TCP:SYN UDP 18B UDP 18B 4Nodes TCP:ACK TCP 5B TCP 5B TCP:SYN TCP 260B TCP 197B TCP:ACK TCP 16B TCP 16B TCP 5B TCP 56B TCP 5B TCP 24B TCP 399B TCP 21B TCP 218B TCP 18B TCP 28B TCP 14B FIN TCP 25B TCP 14B FIN,ACK TCP 382B TCP 27B TCP 16B TCP 231B FIN TCP 41B FIN, ACK TCP 28B ICMP TCP 16B ICMP TCP 197B ICMP TCP 52B ICMP TCP 16B TCP 101B TCP 93B TCP 249B TCP 1460B TCP 588B TCP 19B TCP 1205B TCP 895 TCP 407B TCP 1460B TCP 588B TCP 895B One user behind nested NAT (Our Tests)

TCP:SYN ICMP TCP:SYN TCP:ACK UDP 18B ICMP TCP:ACK TCP 5B UDP 11B ICMP TCP 5B TCP 5B UDP 23B ICMP TCP 5B UDP 11B TCP 399B TCP 260B TCP 218B TCP 16B FIN TCP 56B FIN,ACK TCP 24B TCP 19B TCP 21B UDP 18B TCP 1206B TCP 18B UDP 18B TCP 18B TCP 28B TCP 34B TCP 25B UDP 26B TCP 197B Nodes TCP 382B TCP 19B TCP 16B Nodes TCP 16B TCP:SYN TCP 1026B FIN TCP:ACK TCP 426B FIN, ACK TCP 2402B TCP 10B TCP 14B TCP 18B TCP 34B UDP 348B Nodes TCP 148B UDP11B Nodes TCP 61B UDP 18B UDP 18B UDP 26B UDP 18B NAT, Firewall, Alternate Node Table, Subsequent Login z The information can be detected by z STUN z Receive data from other nodes after connection with SN has been established z Own Analysis z SC initiates all connections, TCP or UDP. Combination with STUN solves the NAT problem z P2P networks are very dynamic, thus: z During login SC sends packets to 22 distinct nodes over UDP to advertise its presence z The purpose of the ICMP packets can be similar but it is not clear at this point z Subsequent login is very similar z No ICMP packets Login Process Time z In the paper z Public IP and single NAT 3-7 seconds z Firewall 34 seconds z Our results z Public IP and NAT4~5 seconds z Firewall ~40 seconds z Login failure time 3 minutes User Search z SN gives the SC the nodes to query z 8 nodes on average z Process is repeated if user cannot be found Search results will be cached at intermediate nodes z Based on user search time TCP 16B TCP 52B TCP 406B TCP 16B TCP 16B TCP 1104B TCP 52B TCP 101B

TCP 183B TCP 132B UDP 77B 2 Nodes TCP 205B UDP 44B 4 Nodes TCP 27B UDP 17B 2 Nodes TCP 205B UDP 369B 1 Node TCP 27B UDP 44B 2 Nodes UDP 44B 5 Nodes TCP 205B UDP 17B reply from 5 nodes TCP 27B TCP 138B Public IP NAT TCP 18B NAT & Firewall User Search (Our Tests) z SN gives the SC the nodes to query z More than 8 nodes were given for search z Process is not repeated if user is not found. Search results will be cached at intermediate nodes z Based on user search time TCP 16B TCP 52B TCP 406B TCP 16B TCP 16B TCP 1104B TCP 60B TCP 101B

TCP 183B TCP 132B UDP 41B 3 Nodes TCP 205B UDP 41B 3 Nodes TCP 27B UDP 1345B 2 Nodes TCP 205B Public IP UDP 50B 2 Node TCP 27B UDP 77B 3 Nodes TCP 205B UDP 1345B 3 Nodes TCP 27B TCP 138B NAT TCP 18B NAT & Firewall Call Establishment for Public IP z User Not in Buddy list

z TCall_Est=Tsearch+Tsignalling z User in Buddy list

TCP:SYN TCP:ACK TCP 14B TCP 14B TCP 77B TCP 4B TCP 4B TCP 528B TCP 4B TCP 946B TCP 479B One User Behind a NAT

z Forwarding z No direct flow from caller to callee; signalling is forwarded through another Skype node

TCP 18B TCP 18B TCP 19B TCP 19B

Error from paper! NAT and Firewall

TCP SYN TCP ACK TCP SYN TCP ACK

TCP 19B TCP 19B TCP 19B TCP 19B

Error from paper! Call Teardown and Logout

Call teardown TCP 17B TCP 14B

Logout: TCP 64B TCP 21B Media Transfer

z Silence Suppression z Skype does not support silence supression. (Confirmed in test) z Silence packets are transmitted to maintain UDP bindings in NAT z In TCP, packets are still sent to avoid reduction of the window size z Packages not 67 bytes, actually, dynamic payload size. z Putting a Call on Hold z 3 messages/second to call peer, SN or media proxy z Additional TCP packets exchange z Congestion z Skype needs at least 1.5kB/s uplink and downlink to maintain reasonable quality z Keep alive messages z Sent to SN every 1 minute over TCP Conferencing Other Skype Facts z Multiple Locations z Calls and messages are forwarded to all locations where the user has signed it. z Very good voice quality z Compared to MSN Messenger and Yahoo! Messanger z SN Selection z Based on CPU power, RAM and bandwidth, and whether is on a public IP address. z SC cannot be forced to become a SN z The actual algorithm is not known The result Problems We Have Experienced During the Experiments z Bad synchronization between SC local buddy list, and remote buddy list z Call error z No ringing on the other side z No sound on the caller side Conclusion z First VoIP client based on P2P technology z Factors of increasing popularity z Better voice quality z Works seamlessly behind NAT and firewall z Extremely easy to install and use z NAT and firewall traversal techniques z Random port selection z P2P overlay network z No need for explicit NAT and firewall traversal server