a hybrid topology architecture for p2p systems
Download
Skip this Video
Download Presentation
A Hybrid Topology Architecture for P2P Systems

Loading in 2 Seconds...

play fullscreen
1 / 25

A Hybrid Topology Architecture for P2P Systems - PowerPoint PPT Presentation


  • 336 Views
  • Uploaded on

A Hybrid Topology Architecture for P2P Systems. Ling Liu [email protected] Aameek Singh [email protected] College of Computing Georgia Institute of Technology. Road Ahead …. Introduction Structured and Unstructured Overlays Routing and Lookups, Anonymity, Data Placement

loader
I am the owner, or an agent authorized to act on behalf of the owner, of the copyrighted work described.
capcha
Download Presentation

PowerPoint Slideshow about 'A Hybrid Topology Architecture for P2P Systems' - wyatt


An Image/Link below is provided (as is) to download presentation

Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.


- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -
Presentation Transcript
a hybrid topology architecture for p2p systems

A Hybrid Topology Architecture for P2P Systems

Ling Liu

[email protected]

Aameek Singh

[email protected]

College of Computing

Georgia Institute of Technology

ICCCN 2004

road ahead
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

introduction
Introduction
  • Advent of Peer-to-Peer (P2P) Systems
  • 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

our system
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

what gives us anonymity
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

clouds over dht
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

clouds
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

routing
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

mapping services to clouds
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

r rings motivation
R-Rings - Motivation
  • Membership based mapping?
  • Peers are too dynamic!
  • Mapping based on clouds?
  • Cloudname is static

ICCCN 2004

r rings
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

routing protocol
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

routing protocol14
Routing Protocol

Query with TTL 4

Get First-Hop Address

DHT Phase (Query R-Ring)

Initiate Reply

Broadcast Query in ReplyCloud

ICCCN 2004

limiting size of clouds
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

recap
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

performance scalability
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

effect of system parameters
Effect of System Parameters

R-Diameter

Degree

ICCCN 2004

security analysis
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

attacks
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

cloud creation attack
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

block attack
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

defenses
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

conclusions
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

thanks

Thanks!

ICCCN 2004

ad