An Analysis of the Skype P2P Internet Telephonyacpang/course/voip_2005/... · 2005-05-14 · zA...

An Analysis of the Skype P2P Internet Telephony Protocol

王永豪 B91902114杜明可 B91902104吳治明 B91902110

Outline

IntroThe Skype NetworkKey ComponentsExperiment setup explainedExperiment performed and results

StartupLoginUser searchCall Establishment and teardownLogoutMedia TransferConferencing

Other Skype factsConclusion

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.

The Skype Network (as it used to be)

Central Login ServerSuper NodesOrdinary Nodes

The Skype Network (as it used to be)

NAT and Firewall traversalSTUN and TURNNo global traversal serverFunction distributed among nodes

A 3G P2P networkGlobal 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 findTCP for signalingUDP & TCP for media traffic

The way it looks now

Key Components (as they used to be)

PortsA Skype Client (SC) opens TCP and UDP listening ports as configured in the client itselfSC also listens on ports 80(HTTP) and 443(HTTPS)No default listening port

Host Cache (HC)Skype is an overlay networkThus the HC contains IP address and port# of super nodes. Used to reside in the registry

Key Components (as they used to be )

CodecsiLBC, iSAC, a third codecPossibly licensed from GlobalIPSound50-8,000Hz

Buddy ListUsed to be an encrypted registry entrySwitching computers needed reconstruction of the buddy list

Key Components (as they used to be )

EncryptionAES (Advanced Encryption Standard)256 bit

NAT and FirewallSC can traverse NAT and firewalls quite successfully using variations of STUN and TURNSC cannot prevent from becoming a super node

Key Components (what has changed)

PortsUDP and TCP ports actually used can be very random, sometimes not using the one configured in the SC.

Host CacheHost Cache is still central to the Skype ProtocolRather 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)

Buddy ListNo longer resides in the registryMoved to C:/Document and settings/username/Application Data/skypeaccount/user1024.dbbSwiching computers no longer needs reconstruction of the entire contact list.Buddy List are saved both locally and in a remote server.Last-modified based

Key Components (What has changed)

EncryptionSince 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)

In the paperSkype ver. 0.97.06Windows 2000PII 200MHz 128MB RAM, PPRO 200MHz 128MB RAM10/100 Mb/s Ethernet

Our setupSkype ver. 1.2.0.48Windows XPPentium M Centrino 1.5GHZ, 512MB RAMAthlonXP 1800+(1.4Ghz) 1GB RAMCable, ADSL

Experimenal setup (II)

Network configurations in the paperBoth machines with public IP addressesOne user behind port-restricted NATBoth users behind port restricted NAT and UDP restricted firewall

Our Network SetupBoth machines with public IP addressesOne user behind NATone users behind NAT and UDP restricted firewallOne user behind a nested port-restricted NAT (two NATs)NAT #1 – D-Link DI-714P+ Wireless RouterNAR #2 Edimax Wireless Broadband RouterFirewall – From the routers

Install & Startup

Startup as in the paperUpon first startup: HTTP GET request to skype.com with the keyword “installed”Upon subsequent startups: HTTP GET request with keyword “getlatestversion”

Startup NowUpon first startup: HTTP GET request to ui.skype.com with keyword “installed”Upon subsequent startups: HTTP GET request with keyword “getlatestversion”

Login Server(s)

Before:Skype used to have 1 login server at 80.160.91.11 located in Denmark

Now:From the numerous tests performed, we believe that Skype now has a “set” of login servers that varies with location.

Bootstrap Nodes

Nodes always present in the HC after instalation66.235.180.966.235.181.980.161.91.2580.160.91.1264.246.49.6164.246.49.6064.246.48.23

New bootstrap nodes:66.235.180.966.235.181.9195.215.8.145210.58.72.8464.246.49.6164.246.49.6064.246.48.23

First Time Login with public IPs

UDP 18BUDP 11BUDP 23BUDP 18B

UDP 18BUDP 18B

TCP:SYNTCP:ACKTCP 14BTCP 34BTCP 146BTCP 67B

ICMPICMPICMPICMP

TCP:SYNTCP:ACKTCP 14BTCP 14BTCP 176BTCP 246BFINFIN,ACK

UDP 18B NodesUDP 26B Nodes

TCP 28BTCP 197BTCP 16B

UDP 34B 17 NodesUDP 44B 5 NodesUDP 11B replies from 22 nodes

One user behind a NAT


UDP 18BUDP 18B

TCP:SYNTCP:ACKTCP 2402BTCP 14BTCP 18BTCP 34BTCP 148BTCP 61BUDP 18BUDP 18B

ICMPICMPICMPICMP

TCP 19BTCP 1206BTCP 18BTCP 34BUDP 26BTCP 19BTCP 1026BTCP 426BTCP 10B

UDP 18B NodesUDP 26B Nodes


TCP 197B NodesTCP 16B Nodes

UDP 348B NodesUDP11B Nodes

Port-restricted NAT and UDP Firewall

UDP 18B

UDP 18B

UDP 18B

TCP 197BTCP 16B

TCP 14BTCP 14BTCP 35BTCP 148BTCP 35B

ICMPICMPICMPICMP


UDP 18B 4Nodes


UDP 44B 18 Nodes

TCP 28BTCP 16BTCP 197BTCP 52BTCP 16BTCP 101BTCP 93BTCP 249BTCP 1460BTCP 588BTCP 895TCP 1460BTCP 588BTCP 895B

First Time Login (Our tests)


UDP 18BUDP 18B

TCP:SYNTCP:ACKTCP:14BTCP 14BTCP 28BTCP 232BTCP 17B

ICMPICMPICMPICMP


UDP 18B UDP 26B


UDP 348B 17 NodesUDP 44B 5 NodesUDP 11B replies from 22 nodes

TCP:SYNTCP:ACKTCP 5BTCP 5BTCP 260BTCP 16BTCP 56B TCP 24BTCP 21B TCP 18B TCP 28B TCP 25B TCP 382B TCP 16B FIN FIN, ACK

One user behind a NAT (Our Tests)


UDP 18BUDP 18B


ICMPICMPICMPICMP




UDP 18B UDP 26B



One user behind NAT and firewall

UDP 18B

TCP 197BTCP 16B

TCP 14BTCP 14BTCP 27BTCP 231BTCP 41B

ICMPICMPICMPICMP


UDP 18B 4Nodes

TCP 28BTCP 16BTCP 197BTCP 52BTCP 16BTCP 101BTCP 93BTCP 249BTCP 1460BTCP 588BTCP 895TCP 1460BTCP 588BTCP 895B



One user behind nested NAT(Our Tests)


UDP 18BUDP 18B


ICMPICMPICMPICMP




UDP 18B UDP 26B



NAT, Firewall, Alternate Node Table, Subsequent Login

The information can be detected bySTUN Receive data from other nodes after connection with SN has been established

Own AnalysisSC 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 presenceThe purpose of the ICMP packets can be similar but it is not clear at this point

Subsequent login is very similarNo ICMP packets

Login Process Time

In the paperPublic IP and single NAT 3-7 secondsFirewall 34 seconds

Our results Public IP and NAT4~5 secondsFirewall ~40 secondsLogin failure time 3 minutes

User Search

SN gives the SC the nodes to query8 nodes on averageProcess is repeated if user cannot be found

Search results will be cached at intermediate nodes

Based on user search time

TCP 16BTCP 101B

UDP 44B 4 NodesUDP 17B 2 NodesUDP 369B 1 NodeUDP 44B 5 NodesUDP 17B reply from 5 nodes

TCP 16BTCP 52B

UDP 77B 2 Nodes

TCP 16B TCP 52B TCP 406B TCP 1104B

UDP 44B 2 Nodes

TCP 183B TCP 132B TCP 205B TCP 27B TCP 205B TCP 27BTCP 205B TCP 27BTCP 138B TCP 18BPublic IP NAT

NAT & Firewall

User Search (Our Tests)

SN gives the SC the nodes to queryMore than 8 nodes were given for searchProcess is not repeated if user is not found.

Search results will be cached at intermediate nodes

Based on user search time

TCP 16BTCP 101B

UDP 41B 3 NodesUDP 1345B 2 NodesUDP 50B 2 NodeUDP 77B 3 NodesUDP 1345B 3 Nodes

TCP 16BTCP 60B

UDP 41B 3 Nodes

TCP 16B TCP 52B TCP 406B TCP 1104B

TCP 183B TCP 132B TCP 205B TCP 27B TCP 205B TCP 27BTCP 205B TCP 27BTCP 138B TCP 18B

Public IP

NATNAT & Firewall

Call Establishment for Public IP

User Not in Buddy listTCall_Est=Tsearch+Tsignalling

User in Buddy list

TCP:SYNTCP:ACKTCP 14BTCP 14BTCP 77BTCP 4BTCP 4BTCP 528BTCP 4BTCP 946BTCP 479B

One User Behind a NAT

ForwardingNo direct flow from caller to callee; signalling is forwarded through another Skype node

TCP 18BTCP 18B

TCP 19BTCP 19B

Error from paper!

NAT and Firewall

TCP SYNTCP ACK

TCP SYNTCP ACK

TCP 19BTCP 19B

TCP 19BTCP 19B

Error from paper!

Call Teardown and Logout

TCP 17BTCP 14B

Call teardown

Logout: TCP 64BTCP 21B

Media Transfer

Silence SuppressionSkype does not support silence supression. (Confirmed in test)Silence packets are transmitted to maintain UDP bindings in NATIn TCP, packets are still sent to avoid reduction of the window sizePackages not 67 bytes, actually, dynamic payload size.

Putting a Call on Hold3 messages/second to call peer, SN or media proxyAdditional TCP packets exchange

CongestionSkype needs at least 1.5kB/s uplink and downlink to maintain reasonable quality

Keep alive messagesSent to SN every 1 minute over TCP

Conferencing

Other Skype Facts

Multiple LocationsCalls and messages are forwarded to all locations where the user has signed it.

Very good voice qualityCompared to MSN Messenger and Yahoo! Messanger

SN SelectionBased on CPU power, RAM and bandwidth, and whether is on a public IP address. SC cannot be forced to become a SNThe actual algorithm is not known

The result

Problems We Have Experienced During the Experiments

Bad synchronization between SC local buddy list, and remote buddy listCall error

No ringing on the other sideNo sound on the caller side

Conclusion

First VoIP client based on P2P technologyFactors of increasing popularity

Better voice qualityWorks seamlessly behind NAT and firewallExtremely easy to install and use

NAT and firewall traversal techniquesRandom port selectionP2P overlay networkNo need for explicit NAT and firewall traversal server

An Analysis of the Skype P2P Internet Telephonyacpang/course/voip_2005/... · 2005-05-14 · zA...

Documents

Transcript of An Analysis of the Skype P2P Internet Telephonyacpang/course/voip_2005/... · 2005-05-14 · zA...