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 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 One user behind NAT and firewall 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.