A Hybrid Topology Architecture for P2P Systems

1. A Hybrid Topology Architecture for P2P Systems Ling Liu lingliu@cc.gatech.edu Aameek Singh aameek@cc.gatech.edu College of Computing Georgia Institute of Technology ICCCN 2004

2. Road Ahead … • Introduction • Structured and Unstructured Overlays • Routing and Lookups, Anonymity, Data Placement • Hybrid Topology Design • Performance Analysis • Conclusions and Future Work • Questions? ICCCN 2004

3. Introduction • Advent of Peer-to-Peer (P2P) Systems • Seti@Home → Napster → Gnutella → Chord/Pastry • Overlay Networks • Data sharing • Data dissemination e.g. Application-level Multicast • Security • Voice over IP (VoIP) • Distinguishing Features • Overlay Topologies • Routing and Lookup • Level of Anonymity ICCCN 2004

4. Overlay Topologies ICCCN 2004

5. Our System • Decentralized Mutually Anonymous System • Maintains all “nice” DHT properties • Scalable & guaranteed lookup • Add-on unstructured topologies (Clouds) • Protect service requester and service provider • Use the underlying DHT routing in-between • To follow: • Identification of Topology Design Features • Design and Performance Analysis ICCCN 2004

6. What gives us anonymity? • Iterative Chord • Peers only give next-hop address • Querying peer revealed! • Also, Replying peer revealed to querying peer! • Recursive Chord • Follows Message Forwarding • Looks like Gnutella • Anonymous? NO ICCCN 2004

7. Clouds over DHT DHT- Query Items mapped to Peers- Combine information from routing tables to identify the service provider Our System- Query Items map to Clouds- Local Knowledge in clouds provides anonymity ICCCN 2004

8. Clouds • Each cloud has a unique string name • Rendezvous Node • Entry Points • Node responsible for cloudname • There always exists one RN • Dynamics Handling • Issues • Reliability • Initial anonymity ICCCN 2004

9. Routing • Multi-phase mix • Gnutella like Routing in Clouds • Message Forwarding and Broadcasts • Provides Privacy • DHT routing between various clouds • For Guaranteed & Scalable Lookup • Appropriate linking of clouds to services • Limit size of clouds to prevent exponential costs ICCCN 2004

10. Mapping Services to Clouds • Semantic • Clouds where services offered are semantically linked • E.g. music sharing system – clouds containing files of one artist • Discovery of Service • Availability of a discovery of service mechanism • E.g. centralized directory • Dynamic • Infeasible to have a discovery mechanism • High performance applications with peers contributing resources • E.g. decentralized web crawling ICCCN 2004

11. R-Rings - Motivation • Membership based mapping? • Peers are too dynamic! • Mapping based on clouds? • Cloudname is static ICCCN 2004

12. R-Rings • Take a RN from each cloud and create new DHT ring • Always one representative per cloud at the same position • How to make its position static? • Each RN occupies position hquery(cloudname) ICCCN 2004

13. Routing Protocol • Three phases • Query forwarding in QueryCloud • Ring Phase: DHT lookup (Main/R-Ring) • Reply cloud broadcast • Crossover peers • Cross over from the first phase to the ring-phase • Should be unique • Equal distribution of load • Random walks Querying Peer Anonymity Scalable Routing Replying Peer Anonymity ICCCN 2004

14. Routing Protocol Query with TTL 4 Get First-Hop Address DHT Phase (Query R-Ring) Initiate Reply Broadcast Query in ReplyCloud ICCCN 2004

15. Limiting Size of Clouds • Prevent exponential costs • System Parameters • R-diameter: Maximum distance from a RN (length dim) • Degree (m): Maximum number of neighbors (breadth) • Enforcing system parameters • In every ping cycle, peers exchange their distance vectors • Recursively evaluation of distance • Converges to the actual values • Temporary aberrations tolerated ICCCN 2004

16. Recap • Add-on unstructured topologies – Clouds • Map services to clouds • Routing • Random walk in query cloud • Crossover onto the ring • Broadcast in response cloud • Limit size of clouds ICCCN 2004

17. Performance: Scalability - System is as scalable as popular DHT based systems in terms of both number of hops and aggregate messages transmitted - The messaging costs are higher because of broadcast in the response cloud ICCCN 2004

18. Effect of System Parameters R-Diameter Degree ICCCN 2004

19. Security Analysis • Passive-logging Model • No online malicious behavior like protocol manipulation • Only offline sharing of logs • Goal: Identify origin/destination of messages • Prevention • Only one good edge required • Attack • Malicious Nodes need to surround the good node • Need more – the knowledge of it ! ICCCN 2004

20. Attacks • How to get the knowledge? • Saturate all m slots • Distance vectors information • Ping/Pong information • Best Attack Scenario • 1 bad node per good node • Requires extensive online manipulation – Not permissible ICCCN 2004

21. Cloud-creation Attack • Malicious nodes start a cloud and join en-masse • Effects vary with m • Greater m causes more compromises • Efficiency of attack decreases as more good nodes enter the cloud • Remember - 1 Good Edge ICCCN 2004

22. Block Attack • Malicious nodes join in groups, interspersing between good node arrivals • Find out intervals from historical analysis • Good nodes welcomed by one group of bad nodes and surrounded by another group ICCCN 2004

23. Defenses • Group strategy • Tough to achieve because bad nodes are indistinguishable • Get A Buddy Along • Join with a trusted friend and keep one edge with him/her • Trust • Only not to share logs • No privacy information revealed • Connect to RNs • Connect to peers from distinct domains only ICCCN 2004

24. Conclusions • Hybrid Topology – best from the unstructured & structured topologies • Scalable Routing, Mutual Anonymity, Guaranteed Lookups • Data Placement Benefits • Security Analysis – Anonymity compromising attacks • Securing the whole system – DHT vulnerabilities … ICCCN 2004

25. Thanks! ICCCN 2004