An Analysis of the Skype P2P Internet Telephony Protocol 王永豪 B 杜明可 B 吳治明 B

Size: px

Start display at page:

Download "An Analysis of the Skype P2P Internet Telephony Protocol 王永豪 B 杜明可 B 吳治明 B"

Melvyn Jones
5 years ago
Views:

1 An Analysis of the Skype P2P Internet Telephony Protocol 王永豪 B 杜明可 B 吳治明 B

2 Outline Intro The Skype Network Key Components Experiment setup explained Experiment performed and results Startup Login User search Call Establishment and teardown Logout Media Transfer Conferencing Other Skype facts Conclusion

3 Introduction Previous solutions are cost saving however falls short on quality. Call-completion rate are low due to NATs and Firewalls. Bloated interface makes usage a hassle. Requires technical expertise.

4 The Skype Network (as it used to be) Central Login Server Super Nodes Ordinary Nodes

5 The Skype Network (as it used to be) NAT and Firewall traversal STUN and TURN No global traversal server Function distributed among nodes A 3G P2P network Global Index Technology 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 72 hour guaranteed user find TCP for signaling UDP & TCP for media traffic

6 The way it looks now

7 Key Components (as they used to Ports be) A Skype Client (SC) opens TCP and UDP listening ports as configured in the client itself SC also listens on ports 80(HTTP) and 443(HTTPS) No default listening port Host Cache (HC) Skype is an overlay network Thus the HC contains IP address and port# of super nodes. Used to reside in the registry

8 Key Components (as they used to be Codecs ilbc, isac, a third codec Possibly licensed from GlobalIPSound 50-8,000Hz Buddy List Used to be an encrypted registry entry Switching computers needed reconstruction of the buddy list )

9 Key Components (as they used to be Encryption AES (Advanced Encryption Standard) 256 bit NAT and Firewall ) SC can traverse NAT and firewalls quite successfully using variations of STUN and TURN SC cannot prevent from becoming a super node

10 Ports Key Components (what has changed) UDP and TCP ports actually used can be very random, sometimes not using the one configured in the SC. Host Cache Host Cache is still central to the Skype Protocol Rather than residing in the Windows registry, it has been moved to C:/Documents and Settings/All Users/Application Data/Skype/shared.xml

11 Key Components (What has changed) Buddy List No longer resides in the registry Moved to C:/Document and settings/username/application Data/skypeaccount/user1024.dbb Swiching computers no longer needs reconstruction of the entire contact list. Buddy List are saved both locally and in a remote server. Last-modified based

12 Key Components (What has changed) Encryption 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.

13 Experimental setup (I) In the paper Skype ver Windows 2000 PII 200MHz 128MB RAM, PPRO 200MHz 128MB RAM 10/100 Mb/s Ethernet Our setup Skype ver Windows XP Pentium M Centrino 1.5GHZ, 512MB RAM AthlonXP 1800+(1.4Ghz) 1GB RAM Cable, ADSL

14 Experimenal setup (II) Network configurations in the paper Both machines with public IP addresses One user behind port-restricted NAT Both users behind port restricted NAT and UDP restricted firewall Our Network Setup Both machines with public IP addresses One user behind NAT one users behind NAT and UDP restricted firewall One user behind a nested port-restricted NAT (two NATs) NAT #1 D-Link DI-714P+ Wireless Router NAR #2 Edimax Wireless Broadband Router Firewall From the routers

15 Install & Startup Startup as in the paper Upon first startup: HTTP GET request to skype.com with the keyword installed Upon subsequent startups: HTTP GET request with keyword getlatestversion Startup Now Upon first startup: HTTP GET request to ui.skype.com with keyword installed Upon subsequent startups: HTTP GET request with keyword getlatestversion

16 Login

17 Login Server(s) Before: Skype used to have 1 login server at located in Denmark Now: From the numerous tests performed, we believe that Skype now has a set of login servers that varies with location.

18 Bootstrap Nodes Nodes always present in the HC after instalation New bootstrap nodes:

19 First Time Login with public IPs UDP 11B UDP 23B TCP:SYN TCP:ACK TCP 14B TCP 14B TCP 176B TCP 246B FIN FIN,ACK Nodes UDP 26B Nodes TCP:SYN TCP:ACK TCP 14B TCP 34B TCP 146B TCP 67B TCP 28B TCP 197B UDP 34B 17 Nodes UDP 44B 5 Nodes UDP 11B replies from 22 nodes

20 One user behind a NAT UDP 11B UDP 23B UDP 11B TCP:SYN TCP:ACK TCP 2402B TCP 14B TCP 18B TCP 34B TCP 148B TCP 61B TCP 19B TCP 1206B TCP 18B TCP 34B UDP 26B TCP 19B TCP 1026B TCP 426B TCP 10B Nodes UDP 26B Nodes TCP:SYN TCP:ACK TCP 14B TCP 14B TCP 176B TCP 246B FIN FIN,ACK TCP 197B Nodes Nodes UDP 348B Nodes UDP11B Nodes

21 Port-restricted NAT and UDP Firewall UDP 44B 18 Nodes TCP 197B TCP 14B TCP 14B TCP 35B TCP 148B TCP 35B TCP 19B TCP 1205B TCP 407B 4Nodes TCP:SYN TCP:ACK TCP 14B TCP 14B TCP 176B TCP 246B FIN FIN,ACK TCP 28B TCP 197B TCP 52B TCP 101B TCP 93B TCP 249B TCP 1460B TCP 588B TCP 895 TCP 1460B TCP 588B TCP 895B

22 First Time Login (Our tests) UDP 11B UDP 23B UDP 58B TCP:SYN TCP:ACK TCP:14B TCP 14B TCP 28B TCP 232B TCP 17B TCP:SYN TCP:ACK TCP 5B TCP 5B TCP 399B TCP 218B FIN FIN,ACK UDP 26B TCP 25B TCP 437B UDP 348B 17 Nodes UDP 44B 5 Nodes UDP 11B replies from 22 nodes TCP:SYN TCP:ACK TCP 5B TCP 5B TCP 260B TCP 56B TCP 24B TCP 21B TCP 18B TCP 28B TCP 25B TCP 382B FIN FIN, ACK

23 One user behind a NAT (Our Tests) UDP 11B UDP 23B UDP 11B TCP:SYN TCP:ACK TCP 2402B TCP 14B TCP 18B TCP 34B TCP 148B TCP 61B TCP 19B TCP 1206B TCP 18B TCP 34B UDP 26B TCP 19B TCP 1026B TCP 426B TCP 10B UDP 26B TCP:SYN TCP:ACK TCP 5B TCP 5B TCP 399B TCP 218B FIN FIN,ACK TCP 197B Nodes Nodes UDP 348B Nodes UDP11B Nodes TCP:SYN TCP:ACK TCP 5B TCP 5B TCP 260B TCP 56B TCP 24B TCP 21B TCP 18B TCP 28B TCP 25B TCP 382B FIN FIN, ACK

24 One user behind NAT and firewall TCP 197B TCP 14B TCP 14B TCP 27B TCP 231B TCP 41B TCP 19B TCP 1205B TCP 407B 4Nodes TCP:SYN TCP:ACK TCP 5B TCP 5B TCP 399B TCP 218B FIN FIN,ACK TCP 28B TCP 197B TCP 52B TCP 101B TCP 93B TCP 249B TCP 1460B TCP 588B TCP 895 TCP 1460B TCP 588B TCP 895B TCP:SYN TCP:ACK TCP 5B TCP 5B TCP 260B TCP 56B TCP 24B TCP 21B TCP 18B TCP 28B TCP 25B TCP 382B FIN FIN, ACK

25 One user behind nested NAT (Our Tests) UDP 11B UDP 23B UDP 11B TCP:SYN TCP:ACK TCP 2402B TCP 14B TCP 18B TCP 34B TCP 148B TCP 61B TCP 19B TCP 1206B TCP 18B TCP 34B UDP 26B TCP 19B TCP 1026B TCP 426B TCP 10B UDP 26B TCP:SYN TCP:ACK TCP 5B TCP 5B TCP 399B TCP 218B FIN FIN,ACK TCP 197B Nodes Nodes UDP 348B Nodes UDP11B Nodes TCP:SYN TCP:ACK TCP 5B TCP 5B TCP 260B TCP 56B TCP 24B TCP 21B TCP 18B TCP 28B TCP 25B TCP 382B FIN FIN, ACK

26 NAT, Firewall, Alternate Node Table, Subsequent Login The information can be detected by STUN Receive data from other nodes after connection with SN has been established Own Analysis SC initiates all connections, TCP or UDP. Combination with STUN solves the NAT problem P2P networks are very dynamic, thus: During login SC sends packets to 22 distinct nodes over UDP to advertise its presence The purpose of the packets can be similar but it is not clear at this point Subsequent login is very similar No packets

27 Login Process Time In the paper Public IP and single NAT 3-7 seconds Firewall 34 seconds Our results Public IP and NAT4~5 seconds Firewall ~40 seconds Login failure time 3 minutes

28 User Search SN gives the SC the nodes to query 8 nodes on average Process is repeated if user cannot be found Search results will be cached at intermediate nodes Based on user search time TCP 52B TCP 101B TCP 52B TCP 406B TCP 1104B Public IP UDP 77B 2 Nodes UDP 44B 2 Nodes NAT UDP 44B 4 Nodes UDP 17B 2 Nodes UDP 369B 1 Node UDP 44B 5 Nodes UDP 17B reply from 5 nodes TCP 183B TCP 132B TCP 205B TCP 27B TCP 205B TCP 27B TCP 205B TCP 27B TCP 138B TCP 18B NAT & Firewall

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

30 Call Establishment for Public IP User Not in Buddy list T Call_Est =T search +T signalling 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

31 One User Behind a NAT Forwarding 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!

32 NAT and Firewall TCP SYN TCP ACK TCP SYN TCP ACK TCP 19B TCP 19B TCP 19B TCP 19B Error from paper!

33 Call Teardown and Logout Call teardown TCP 17B TCP 14B Logout: TCP 64B TCP 21B

34 Media Transfer Silence Suppression Skype does not support silence supression. (Confirmed in test) Silence packets are transmitted to maintain UDP bindings in NAT In TCP, packets are still sent to avoid reduction of the window size Packages not 67 bytes, actually, dynamic payload size. Putting a Call on Hold 3 messages/second to call peer, SN or media proxy Additional TCP packets exchange Congestion Skype needs at least 1.5kB/s uplink and downlink to maintain reasonable quality Keep alive messages Sent to SN every 1 minute over TCP

35 Conferencing

36 Other Skype Facts Multiple Locations Calls and messages are forwarded to all locations where the user has signed it. Very good voice quality Compared to MSN Messenger and Yahoo! Messanger SN Selection Based on CPU power, RAM and bandwidth, and whether is on a public IP address. SC cannot be forced to become a SN The actual algorithm is not known

37 The result

38 Problems We Have Experienced During the Experiments Bad synchronization between SC local buddy list, and remote buddy list Call error No ringing on the other side No sound on the caller side

39 Conclusion First VoIP client based on P2P technology Factors of increasing popularity Better voice quality Works seamlessly behind NAT and firewall Extremely easy to install and use NAT and firewall traversal techniques Random port selection P2P overlay network No need for explicit NAT and firewall traversal server

Analysis and Signature of Skype VoIP Session Traffic

Ensimag-4MMSR 2011-2012 Student seminars Analysis and Signature of Skype VoIP Session Traffic Sven Ehlert Sandrine Petgang Fraunhofer FOKUS, Berlin, Germany July 25th, 2006 Students :Amine.Boukioud@ensimag.fr