Skype P2P Protocol Bolesaw Kulbabi nski According to "An - - PowerPoint PPT Presentation

▶
skype p2p protocol
SMART_READER_LITE
LIVE PREVIEW

Skype P2P Protocol Bolesaw Kulbabi nski According to "An - - PowerPoint PPT Presentation

Nov 12, 2022 404 likes •1.15k views

Introduction Architecture Experiments Appendix Skype P2P Protocol Bolesaw Kulbabi nski According to "An Analysis of the Skype Peer-to-Peer Internet Telephony Protocol", S.A.Baset, H.Schulzrinne, 2004 Introduction

slide-1
SLIDE 1

Introduction Architecture Experiments Appendix

Skype P2P Protocol

Bolesław Kulbabi´ nski According to "An Analysis of the Skype Peer-to-Peer Internet Telephony Protocol", S.A.Baset, H.Schulzrinne, 2004

slide-2
SLIDE 2

Introduction Architecture Experiments Appendix

Introduction

The paper presents a reverse-engineering process that leads to some conclusions about Skype architecture and protocol. Many claims are highly probable guesses but cannot be guaranteed

  • r proven.
slide-3
SLIDE 3

Introduction Architecture Experiments Appendix

Architecture

Three types of entities

  • Ordinary Node
  • Super Peer
  • Skype Login Server
slide-4
SLIDE 4

Introduction Architecture Experiments Appendix

Node types

  • Ordinary node - must connect to a super peer. These are

stored in Host Cache.

  • Super peer - anyone with public IP

, enough bandwidth, CPU and RAM can become a super peer.

  • Skype login server - ensures name uniqueness.
slide-5
SLIDE 5

Introduction Architecture Experiments Appendix

Node types

  • Ordinary node - must connect to a super peer. These are

stored in Host Cache.

  • Super peer - anyone with public IP

, enough bandwidth, CPU and RAM can become a super peer.

  • Skype login server - ensures name uniqueness.
slide-6
SLIDE 6

Introduction Architecture Experiments Appendix

Node types

  • Ordinary node - must connect to a super peer. These are

stored in Host Cache.

  • Super peer - anyone with public IP

, enough bandwidth, CPU and RAM can become a super peer.

  • Skype login server - ensures name uniqueness.
slide-7
SLIDE 7

Introduction Architecture Experiments Appendix

Node types

  • Ordinary node - must connect to a super peer. These are

stored in Host Cache.

  • Super peer - anyone with public IP

, enough bandwidth, CPU and RAM can become a super peer.

  • Skype login server - ensures name uniqueness.
slide-8
SLIDE 8

Introduction Architecture Experiments Appendix

Components

  • Ports - listening on 80 (HTTP), 443 (HTTPS) and random

ports for TCP and UDP .

  • Host Cache - list of IP:port addresses of Super Peers. Min.

1, max. 200 entries, regularly refreshed.

  • Codecs - iLBS, iSAC from GlobalIPSound + one unknown.
  • Buddy list - encrypted and stored only locally.
slide-9
SLIDE 9

Introduction Architecture Experiments Appendix

Components

  • Ports - listening on 80 (HTTP), 443 (HTTPS) and random

ports for TCP and UDP .

  • Host Cache - list of IP:port addresses of Super Peers. Min.

1, max. 200 entries, regularly refreshed.

  • Codecs - iLBS, iSAC from GlobalIPSound + one unknown.
  • Buddy list - encrypted and stored only locally.
slide-10
SLIDE 10

Introduction Architecture Experiments Appendix

Components

  • Ports - listening on 80 (HTTP), 443 (HTTPS) and random

ports for TCP and UDP .

  • Host Cache - list of IP:port addresses of Super Peers. Min.

1, max. 200 entries, regularly refreshed.

  • Codecs - iLBS, iSAC from GlobalIPSound + one unknown.
  • Buddy list - encrypted and stored only locally.
slide-11
SLIDE 11

Introduction Architecture Experiments Appendix

Components

  • Ports - listening on 80 (HTTP), 443 (HTTPS) and random

ports for TCP and UDP .

  • Host Cache - list of IP:port addresses of Super Peers. Min.

1, max. 200 entries, regularly refreshed.

  • Codecs - iLBS, iSAC from GlobalIPSound + one unknown.
  • Buddy list - encrypted and stored only locally.
slide-12
SLIDE 12

Introduction Architecture Experiments Appendix

Components

  • Ports - listening on 80 (HTTP), 443 (HTTPS) and random

ports for TCP and UDP .

  • Host Cache - list of IP:port addresses of Super Peers. Min.

1, max. 200 entries, regularly refreshed.

  • Codecs - iLBS, iSAC from GlobalIPSound + one unknown.
  • Buddy list - encrypted and stored only locally.
slide-13
SLIDE 13

Introduction Architecture Experiments Appendix

Components

  • Encryption - 256-bit AES negotiated using 2048-bit RSA.

User public keys are certified at login.

  • NAT and Firewall traversal - probably some variation of

STUN or TURN is used. Info refreshed periodically.

  • User Search - Skype guarantees finding users that logged

in during last 72 hours.

slide-14
SLIDE 14

Introduction Architecture Experiments Appendix

Components

  • Encryption - 256-bit AES negotiated using 2048-bit RSA.

User public keys are certified at login.

  • NAT and Firewall traversal - probably some variation of

STUN or TURN is used. Info refreshed periodically.

  • User Search - Skype guarantees finding users that logged

in during last 72 hours.

slide-15
SLIDE 15

Introduction Architecture Experiments Appendix

Components

  • Encryption - 256-bit AES negotiated using 2048-bit RSA.

User public keys are certified at login.

  • NAT and Firewall traversal - probably some variation of

STUN or TURN is used. Info refreshed periodically.

  • User Search - Skype guarantees finding users that logged

in during last 72 hours.

slide-16
SLIDE 16

Introduction Architecture Experiments Appendix

Components

  • Encryption - 256-bit AES negotiated using 2048-bit RSA.

User public keys are certified at login.

  • NAT and Firewall traversal - probably some variation of

STUN or TURN is used. Info refreshed periodically.

  • User Search - Skype guarantees finding users that logged

in during last 72 hours.

slide-17
SLIDE 17

Introduction Architecture Experiments Appendix

Setup

Three configurations

  • 1. Two machines with public IPs.
  • 2. One public, one behind port-restricted NAT.
  • 3. Both behind port-restricted NAT and UDP-restricted

firewall.

slide-18
SLIDE 18

Introduction Architecture Experiments Appendix

Setup

Three configurations

  • 1. Two machines with public IPs.
  • 2. One public, one behind port-restricted NAT.
  • 3. Both behind port-restricted NAT and UDP-restricted

firewall.

slide-19
SLIDE 19

Introduction Architecture Experiments Appendix

Setup

Three configurations

  • 1. Two machines with public IPs.
  • 2. One public, one behind port-restricted NAT.
  • 3. Both behind port-restricted NAT and UDP-restricted

firewall.

slide-20
SLIDE 20

Introduction Architecture Experiments Appendix

Setup

Three configurations

  • 1. Two machines with public IPs.
  • 2. One public, one behind port-restricted NAT.
  • 3. Both behind port-restricted NAT and UDP-restricted

firewall.

slide-21
SLIDE 21

Introduction Architecture Experiments Appendix

Startup

First run

Message to skype.com with keyword "installed".

Subsequent runs

Message to skype.com with keyword "getlatestversion".

slide-22
SLIDE 22

Introduction Architecture Experiments Appendix

Startup

First run

Message to skype.com with keyword "installed".

Subsequent runs

Message to skype.com with keyword "getlatestversion".

slide-23
SLIDE 23

Introduction Architecture Experiments Appendix

Login process

Login process

  • 1. Network connection (needs at least one valid Host Cache

entry that can be reached via TCP)

  • 2. Authentication with Skype server (80.160.91.11,

ns14.inet.tele.dk)

slide-24
SLIDE 24

Introduction Architecture Experiments Appendix

Login process

Login process

  • 1. Network connection (needs at least one valid Host Cache

entry that can be reached via TCP)

  • 2. Authentication with Skype server (80.160.91.11,

ns14.inet.tele.dk)

slide-25
SLIDE 25

Introduction Architecture Experiments Appendix

Login process

Login process

  • 1. Network connection (needs at least one valid Host Cache

entry that can be reached via TCP)

  • 2. Authentication with Skype server (80.160.91.11,

ns14.inet.tele.dk)

slide-26
SLIDE 26

Introduction Architecture Experiments Appendix

Bootstrap nodes

During first login attempt Host Cache is always filled with at least these peers:

  • 1. 66.235.180.9:33033 (sls-cb10p6.dca2.superb.net)
  • 2. 66.235.181.9:33033 (ip9.181.susc.suscom.net)
  • 3. 80.161.91.25:33033

(0x50a15b19.boanxx15.adsl-dhcp.tele.dk)

  • 4. 80.160.91.12:33033

(0x50a15b0c.albnxx9.adsl-dhcp.tele.dk)

  • 5. 64.246.49.60:33033 (rs-64-246-49-60.ev1.net)
  • 6. 64.246.49.61:33033 (rs-64-246-49-61.ev1.net)
  • 7. 64.246.48.23:33033 (ns2.ev1.net)
slide-27
SLIDE 27

Introduction Architecture Experiments Appendix

Network Connection

slide-28
SLIDE 28

Introduction Architecture Experiments Appendix

Observations

It was observed that:

  • Skype Client tries to reach many nodes via UDP but

maintains TCP connections with only a few of them (at least one).

  • After connecting to another node, Skype Client exchanged

messages with login server.

  • After some time, the Client tried to reach some nodes not

from the bootstrap list (probably got their addresses from bootstrap peers).

  • The Client not always updated the host cache with nodes it

exchanged messages with.

slide-29
SLIDE 29

Introduction Architecture Experiments Appendix

Observations

It was observed that:

  • Skype Client tries to reach many nodes via UDP but

maintains TCP connections with only a few of them (at least one).

  • After connecting to another node, Skype Client exchanged

messages with login server.

  • After some time, the Client tried to reach some nodes not

from the bootstrap list (probably got their addresses from bootstrap peers).

  • The Client not always updated the host cache with nodes it

exchanged messages with.

slide-30
SLIDE 30

Introduction Architecture Experiments Appendix

Observations

It was observed that:

  • Skype Client tries to reach many nodes via UDP but

maintains TCP connections with only a few of them (at least one).

  • After connecting to another node, Skype Client exchanged

messages with login server.

  • After some time, the Client tried to reach some nodes not

from the bootstrap list (probably got their addresses from bootstrap peers).

  • The Client not always updated the host cache with nodes it

exchanged messages with.

slide-31
SLIDE 31

Introduction Architecture Experiments Appendix

Observations

It was observed that:

  • Skype Client tries to reach many nodes via UDP but

maintains TCP connections with only a few of them (at least one).

  • After connecting to another node, Skype Client exchanged

messages with login server.

  • After some time, the Client tried to reach some nodes not

from the bootstrap list (probably got their addresses from bootstrap peers).

  • The Client not always updated the host cache with nodes it

exchanged messages with.

slide-32
SLIDE 32

Introduction Architecture Experiments Appendix

Observations

It was observed that:

  • Skype Client tries to reach many nodes via UDP but

maintains TCP connections with only a few of them (at least one).

  • After connecting to another node, Skype Client exchanged

messages with login server.

  • After some time, the Client tried to reach some nodes not

from the bootstrap list (probably got their addresses from bootstrap peers).

  • The Client not always updated the host cache with nodes it

exchanged messages with.

slide-33
SLIDE 33

Introduction Architecture Experiments Appendix

Observations

It was observed that:

  • Machine in configuration 3 (firewall) was not able to receive

UDP datagrams but it was still able to connect via TCP .

  • Login process takes about 3-7 second in configurations 1

and 2.

  • Login process takes about 34 second in configuration 3.
slide-34
SLIDE 34

Introduction Architecture Experiments Appendix

Observations

It was observed that:

  • Machine in configuration 3 (firewall) was not able to receive

UDP datagrams but it was still able to connect via TCP .

  • Login process takes about 3-7 second in configurations 1

and 2.

  • Login process takes about 34 second in configuration 3.
slide-35
SLIDE 35

Introduction Architecture Experiments Appendix

Observations

It was observed that:

  • Machine in configuration 3 (firewall) was not able to receive

UDP datagrams but it was still able to connect via TCP .

  • Login process takes about 3-7 second in configurations 1

and 2.

  • Login process takes about 34 second in configuration 3.
slide-36
SLIDE 36

Introduction Architecture Experiments Appendix

Observations

It was observed that:

  • Machine in configuration 3 (firewall) was not able to receive

UDP datagrams but it was still able to connect via TCP .

  • Login process takes about 3-7 second in configurations 1

and 2.

  • Login process takes about 34 second in configuration 3.
slide-37
SLIDE 37

Introduction Architecture Experiments Appendix

User Search

Global Index

  • Skype claims it is able to find any user that logged in

during last 72 hours.

slide-38
SLIDE 38

Introduction Architecture Experiments Appendix

Network Data Flow

Configurations 1 and 2

  • 1. Contact Super Node via TCP

.

  • 2. Contact 4 unknown nodes via UDP

.

  • 3. Contact 8 more unknown nodes via UDP (iterate).
  • 4. After 3-4 second find the user or say that it is unknown.

Configuration 3 (UDP firewall)

  • 1. Contact Super Node via TCP

.

  • 2. After 7-8 second find the user or say that it is unknown.
slide-39
SLIDE 39

Introduction Architecture Experiments Appendix

Network Data Flow

Configurations 1 and 2

  • 1. Contact Super Node via TCP

.

  • 2. Contact 4 unknown nodes via UDP

.

  • 3. Contact 8 more unknown nodes via UDP (iterate).
  • 4. After 3-4 second find the user or say that it is unknown.

Configuration 3 (UDP firewall)

  • 1. Contact Super Node via TCP

.

  • 2. After 7-8 second find the user or say that it is unknown.
slide-40
SLIDE 40

Introduction Architecture Experiments Appendix

Network Data Flow

Configurations 1 and 2

  • 1. Contact Super Node via TCP

.

  • 2. Contact 4 unknown nodes via UDP

.

  • 3. Contact 8 more unknown nodes via UDP (iterate).
  • 4. After 3-4 second find the user or say that it is unknown.

Configuration 3 (UDP firewall)

  • 1. Contact Super Node via TCP

.

  • 2. After 7-8 second find the user or say that it is unknown.
slide-41
SLIDE 41

Introduction Architecture Experiments Appendix

Network Data Flow

Configurations 1 and 2

  • 1. Contact Super Node via TCP

.

  • 2. Contact 4 unknown nodes via UDP

.

  • 3. Contact 8 more unknown nodes via UDP (iterate).
  • 4. After 3-4 second find the user or say that it is unknown.

Configuration 3 (UDP firewall)

  • 1. Contact Super Node via TCP

.

  • 2. After 7-8 second find the user or say that it is unknown.
slide-42
SLIDE 42

Introduction Architecture Experiments Appendix

Network Data Flow

Configurations 1 and 2

  • 1. Contact Super Node via TCP

.

  • 2. Contact 4 unknown nodes via UDP

.

  • 3. Contact 8 more unknown nodes via UDP (iterate).
  • 4. After 3-4 second find the user or say that it is unknown.

Configuration 3 (UDP firewall)

  • 1. Contact Super Node via TCP

.

  • 2. After 7-8 second find the user or say that it is unknown.
slide-43
SLIDE 43

Introduction Architecture Experiments Appendix

Network Data Flow

Configurations 1 and 2

  • 1. Contact Super Node via TCP

.

  • 2. Contact 4 unknown nodes via UDP

.

  • 3. Contact 8 more unknown nodes via UDP (iterate).
  • 4. After 3-4 second find the user or say that it is unknown.

Configuration 3 (UDP firewall)

  • 1. Contact Super Node via TCP

.

  • 2. After 7-8 second find the user or say that it is unknown.
slide-44
SLIDE 44

Introduction Architecture Experiments Appendix

Network Data Flow

Configurations 1 and 2

  • 1. Contact Super Node via TCP

.

  • 2. Contact 4 unknown nodes via UDP

.

  • 3. Contact 8 more unknown nodes via UDP (iterate).
  • 4. After 3-4 second find the user or say that it is unknown.

Configuration 3 (UDP firewall)

  • 1. Contact Super Node via TCP

.

  • 2. After 7-8 second find the user or say that it is unknown.
slide-45
SLIDE 45

Introduction Architecture Experiments Appendix

Network Data Flow

Configurations 1 and 2

  • 1. Contact Super Node via TCP

.

  • 2. Contact 4 unknown nodes via UDP

.

  • 3. Contact 8 more unknown nodes via UDP (iterate).
  • 4. After 3-4 second find the user or say that it is unknown.

Configuration 3 (UDP firewall)

  • 1. Contact Super Node via TCP

.

  • 2. After 7-8 second find the user or say that it is unknown.
slide-46
SLIDE 46

Introduction Architecture Experiments Appendix

Observations

It was observed that:

  • Machine in configuration 3 probably knew about the firewall

it is behind as it did not send any UDP datagrams.

  • Search results are probably cached in nodes as repeated

search attempts (from clean Skype Clients) gave better results.

slide-47
SLIDE 47

Introduction Architecture Experiments Appendix

Observations

It was observed that:

  • Machine in configuration 3 probably knew about the firewall

it is behind as it did not send any UDP datagrams.

  • Search results are probably cached in nodes as repeated

search attempts (from clean Skype Clients) gave better results.

slide-48
SLIDE 48

Introduction Architecture Experiments Appendix

Observations

It was observed that:

  • Machine in configuration 3 probably knew about the firewall

it is behind as it did not send any UDP datagrams.

  • Search results are probably cached in nodes as repeated

search attempts (from clean Skype Clients) gave better results.

slide-49
SLIDE 49

Introduction Architecture Experiments Appendix

Calling

General observations

  • Calling users that are not on the Buddy List is equal to

search and call.

  • Calling is always initiated and ended via TCP

.

slide-50
SLIDE 50

Introduction Architecture Experiments Appendix

Calling

General observations

  • Calling users that are not on the Buddy List is equal to

search and call.

  • Calling is always initiated and ended via TCP

.

slide-51
SLIDE 51

Introduction Architecture Experiments Appendix

Calling

General observations

  • Calling users that are not on the Buddy List is equal to

search and call.

  • Calling is always initiated and ended via TCP

.

slide-52
SLIDE 52

Introduction Architecture Experiments Appendix

Calling

Configuration 1

  • Direct communication via UDP

.

Configuration 2

  • Super Node routing both TCP and then UDP voice packets

directly to callee.

Configuration 3

  • Both sides contacted only their super nodes.
slide-53
SLIDE 53

Introduction Architecture Experiments Appendix

Calling

Configuration 1

  • Direct communication via UDP

.

Configuration 2

  • Super Node routing both TCP and then UDP voice packets

directly to callee.

Configuration 3

  • Both sides contacted only their super nodes.
slide-54
SLIDE 54

Introduction Architecture Experiments Appendix

Calling

Configuration 1

  • Direct communication via UDP

.

Configuration 2

  • Super Node routing both TCP and then UDP voice packets

directly to callee.

Configuration 3

  • Both sides contacted only their super nodes.
slide-55
SLIDE 55

Introduction Architecture Experiments Appendix

Calling

Configuration 1

  • Direct communication via UDP

.

Configuration 2

  • Super Node routing both TCP and then UDP voice packets

directly to callee.

Configuration 3

  • Both sides contacted only their super nodes.
slide-56
SLIDE 56

Introduction Architecture Experiments Appendix

Calling

Configuration 1

  • Direct communication via UDP

.

Configuration 2

  • Super Node routing both TCP and then UDP voice packets

directly to callee.

Configuration 3

  • Both sides contacted only their super nodes.
slide-57
SLIDE 57

Introduction Architecture Experiments Appendix

Calling

Configuration 1

  • Direct communication via UDP

.

Configuration 2

  • Super Node routing both TCP and then UDP voice packets

directly to callee.

Configuration 3

  • Both sides contacted only their super nodes.
slide-58
SLIDE 58

Introduction Architecture Experiments Appendix

Calling

Observations

  • Call used approximately 5 kB/s (Skype claims 3-16 kB/s).
  • At least 2 kB/s was required for reasonable voice quality.
  • No silence suppression was observed.
  • While on hold, 3 packets per second were sent.
slide-59
SLIDE 59

Introduction Architecture Experiments Appendix

Calling

Observations

  • Call used approximately 5 kB/s (Skype claims 3-16 kB/s).
  • At least 2 kB/s was required for reasonable voice quality.
  • No silence suppression was observed.
  • While on hold, 3 packets per second were sent.
slide-60
SLIDE 60

Introduction Architecture Experiments Appendix

Calling

Observations

  • Call used approximately 5 kB/s (Skype claims 3-16 kB/s).
  • At least 2 kB/s was required for reasonable voice quality.
  • No silence suppression was observed.
  • While on hold, 3 packets per second were sent.
slide-61
SLIDE 61

Introduction Architecture Experiments Appendix

Calling

Observations

  • Call used approximately 5 kB/s (Skype claims 3-16 kB/s).
  • At least 2 kB/s was required for reasonable voice quality.
  • No silence suppression was observed.
  • While on hold, 3 packets per second were sent.
slide-62
SLIDE 62

Introduction Architecture Experiments Appendix

Calling

Observations

  • Call used approximately 5 kB/s (Skype claims 3-16 kB/s).
  • At least 2 kB/s was required for reasonable voice quality.
  • No silence suppression was observed.
  • While on hold, 3 packets per second were sent.
slide-63
SLIDE 63

Introduction Architecture Experiments Appendix

Conference

Most powerful machine acts as a mixer.

slide-64
SLIDE 64

Introduction Architecture Experiments Appendix

Other

Multiple login

  • User sees incoming call on every machine.
  • After picking up, the call is immediately cancelled on other

machines.

Super Node selection

  • It is impossible to manually select super node by putting it

into host cache.

slide-65
SLIDE 65

Introduction Architecture Experiments Appendix

Other

Multiple login

  • User sees incoming call on every machine.
  • After picking up, the call is immediately cancelled on other

machines.

Super Node selection

  • It is impossible to manually select super node by putting it

into host cache.

slide-66
SLIDE 66

Introduction Architecture Experiments Appendix

Other

Multiple login

  • User sees incoming call on every machine.
  • After picking up, the call is immediately cancelled on other

machines.

Super Node selection

  • It is impossible to manually select super node by putting it

into host cache.

slide-67
SLIDE 67

Introduction Architecture Experiments Appendix

Other

Multiple login

  • User sees incoming call on every machine.
  • After picking up, the call is immediately cancelled on other

machines.

Super Node selection

  • It is impossible to manually select super node by putting it

into host cache.

slide-68
SLIDE 68

Introduction Architecture Experiments Appendix

Other

Multiple login

  • User sees incoming call on every machine.
  • After picking up, the call is immediately cancelled on other

machines.

Super Node selection

  • It is impossible to manually select super node by putting it

into host cache.

slide-69
SLIDE 69

Introduction Architecture Experiments Appendix

Questions?

slide-70
SLIDE 70

Introduction Architecture Experiments Appendix

NAT Types

slide-71
SLIDE 71

Introduction Architecture Experiments Appendix

STUN

slide-72
SLIDE 72

Introduction Architecture Experiments Appendix

STUN

slide-73
SLIDE 73

Introduction Architecture Experiments Appendix

TURN