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
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 or proven.
Introduction Architecture Experiments Appendix Architecture Three types of entities • Ordinary Node • Super Peer • Skype Login Server
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
Introduction Architecture Experiments Appendix Startup First run Message to skype.com with keyword "installed". Subsequent runs Message to skype.com with keyword "getlatestversion".
Introduction Architecture Experiments Appendix Startup First run Message to skype.com with keyword "installed". Subsequent runs Message to skype.com with keyword "getlatestversion".
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)
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)
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)
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)
Introduction Architecture Experiments Appendix Network Connection
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.
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.
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.
Recommend
More recommend
