1 / 27

A Reputation-Based Approach for Choosing Reliable Resources in Peer-to-Peer Networks

A Reputation-Based Approach for Choosing Reliable Resources in Peer-to-Peer Networks. E. Damiani S. De Capitani di Vimercati S. Paraboschi P. Samarati F. Violante http://seclab.dti.unimi.it/p2prep/. Outline. P2P Networks & Gnutella protocol [1] XRep protocol [2]

lester-shaw
Download Presentation

A Reputation-Based Approach for Choosing Reliable Resources in Peer-to-Peer Networks

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. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. A Reputation-Based Approach for Choosing Reliable Resources in Peer-to-Peer Networks E. Damiani S. De Capitani di Vimercati S. Paraboschi P. Samarati F. Violante http://seclab.dti.unimi.it/p2prep/

  2. Outline • P2P Networks & Gnutella protocol [1] • XRepprotocol [2] • Security considerations on XRep • Conclusions • References

  3. P2P Networks • All the nodes offer the same services and follow the same behavior. • Nodes act both as servers and as clients. • There are no nodes with a special responsibility to monitor or supervise the network behavior. • P2P networks for file sharing involves two phases: 1 Search of the peers where the requested file resides. 2 Download from the exporting peers the requested information.

  4. Gnutella • Gnutella is a protocol for distributed search. • Nodes are called servents.(server + client) • Each servent has a servent_id • Servents communicate by exchangingdescriptors. • Ping, Pong – are used to discover servents • Query, QueryHit – Searching files in the P2P network • Push – allows a firewalled servent to contribute files to the P2P network The Gnutella Protocol Specification v0.4 www9.limewire.com/developer/gnutella_protocol_0.4.pdf

  5. Descriptor routing 1 • A servent P requiring a resource broadcasts a Query out. • A servent S will respond with a QueryHitif a match is found against its local database. And S will forward incoming Query descriptors to all of its directly connected servents, except the one that delivered the incoming Query. • QueryHit descriptors may only be sent along the same path that carried the incoming Query descriptor.

  6. Descriptor routing 2 • A servent will decrement a descriptor header’s TTL field, and increment its Hops field, before it forwards the descriptor to any directly connected servent. • If, after decrementing the header’s TTL field, the TTL field is found to be zero, the descriptor is not forwarded along any connection. • A servent receiving a descriptor with the same Payload Descriptor and Descriptor ID as one it has received before, should attempt to avoid forwarding the descriptor to any connected servent.

  7. Gnutella 8 3 Match Match 2 7 4 9 1 6 5 Query QueryHit Not a descriptor 1: initiator 2&7: responders

  8. Structure of Gnutella descriptor • Every descriptor has two parts: 1. Header + 2. Payload Query: sent by initiator QueryHit: sent by responder

  9. Motivation of Reputation systems • Most P2P systems protect peers’ anonymity. Anonymity opens the door to possible misuses and abuses. No way to verify the source or content of files -- Bad service, low quality files -- The content of a file is different than the title -- Trojan horses and viruses • e.g. Mandragore – a Gnutella worm -- Act as a servent and answer all Queries. -- Provides a renamed copy of itself for downloading. Peer review process: the peers’ opinions is used to establish a reputation for peers and files.

  10. XRep: Basic Assumptions • Each servent maintains information on its own experience on files and other servents and share such experience with others upon request • Each servent has a servent_idwhich is a digest of a public key obtained using a secure hash function • Servent reputations are associated with the servent_id • Each file has a resource_idwhich is a digest computed by applying a secure hash function to the file content • File reputations are coupled to resource_id

  11. Reputations Storage & votes calculation 1 • Each servent maintains a resource_repository &a servent_repository that store its opinions about files and servents it had experiences • A servent votes on files and servents with which it hadexperiences.Votes are its opinion on files and servents • Votes are expressed on the basis of information available in the resource_repository & servent_repository.

  12. Reputations Storage & votes calculation 2 • resource_repository: set of pairs (resource_id, value) value=0 or 1 • servent_repository: set of triples (servent_id, num_plus, num_minus) num_plus, num_minus are positive integers • Vote = 0 or 1 • Vote of servent =1, if num_plus>>num_minus • Vote of file = value

  13. XRep: Polling Protocol Phase 1: Resource searching. • psends a Query message for searching files, and servents matching the request respond with a QueryHit Initiator p Servent s Query (Min_Speed, Search_criteria) QueryHit(num_hit,IP,port,speed,Result_set,trailer,servent_id) Trailer: resource_ids of files in result set

  14. Phase 2: Vote polling • P selects a file r that best seems to satisfy its request. Such selection may be guided by the user’s preference • ppolls its peers about the reputation of a file and the set of servents that offer it. • Servents wishing to respond vote on the resource_id and servent_ids and send back a PollReply Initiator p Servent s Poll (resource_id, {servent_id1… servent_idn}, PKpoll) PollReply ({(IP,port,Votes)}PKpoll)

  15. Phase 3: Vote evaluation & reliability check 1. p decrypts PollReply, discards tampered ones. 2. p clustersVoter’s IP and weight the votes within a cluster --Reducing the effect of a clique 3. p selects a set of voters in each cluster, contacts them directly, and expects back confirmation messages. If not enough responses, then p repeats step 3. Initiator p Servent s TrueVote ( Vote ) TrueVoteReply ( responses )

  16. Phase 4: Best servent check • p cannot always download file from best servent • p contacts the best servent S to check the fact that it exports file which p wants to download • Preventing ID stealth attack. Initiator p Servent s AreYou (servent_ids, resource_id) AreYouRepley({response}SKs,PKs)

  17. Phase 5: Resource download • p selects a servent s, downloads the file r and checks it against its digest • Update its resource_repository & servent_repository Initiator p Servent s download ( r) resource ( r )

  18. Initiator p Servent s Query (Min_Speed, Search_criteria) { QueryHit(num_hit,IP,port,speed,Result,trailer,servent_id) { Poll (resource_id, {servent_id1… servent_idn}, PKpoll) PollRepley ({(IP,port,Votes)}PKpoll) { TrueVote ( Vote ) TrueVoteRepley ( responses ) AreYou (servent_ids, resource_id) { AreYouRepley({response}SKs, PKs) { download ( r ) resource ( r )

  19. XRep: Security Considerations • XRep allows to protect P2P against following attacks • Self replication • Man in the middle • ID Stealth • Pseudospoofing • Shilling

  20. Self replication: • A malicious servent could answer all Queries and provide doctored content. • Even honest peers, unaware of the malicious content, could share it and contributing to its diffusion. e.g. Mandragore – a Gnutella worm • Bad reputations of file -- Worms slightly modifying themselves • Cannot collect positive recommendations • Check reputation of the servent

  21. Man in the middle: • A broadcasts a Query. B responds a QueryHit. • E replaces IP and Port of the QueryHit with E’s IP and Port, sends it back to A. • A may download from E. • The fake content provided by E will not match the digest of the legitimate file, then be discarded. (Phase 5) A Modified QueryHit QueryHit Query E B Query Download

  22. ID Stealth: • A malicious peer answers withtwo QueryHits, carrying the digest of a doctored file and one of them carrying the ID of a reputable servent • Xrep checks whether the best servent is offering that file (Phase 4).

  23. Psedospoofing & Shilling: 1 • Attackers create and control multiple servents. They give positive votes to the attacker. • Four cases: • Multiple servents have same IP address • IP cluster (phase 3) • Servents have different but faked IP address • TrueVote/TrueVoteRepley (phase 3) These two cases are called Psedospoofing

  24. Psedospoofing & Shilling: 2 • Servents have different real IP address. And those IP addresses have same net_id. • IP cluster may reduce the effect (phase 3) • Servents have different real IP address. And those IP addresses have different net_id. • To ensure a high number of voters. These two cases are call Shilling.

  25. Distribution of Servent & Resource An important aspect for the applicabilty of this approach • frequent files are more frequently searched => the number of votes will be high • few servents offering many files => these servents will probably well know • Cold-start problem

  26. Conclusions • XRep is a reputation management protocol for anonymous P2P environments • It prevents malicious behaviors in P2P network • Future work: -- reputation mechanism with supernodes -- performance optimization

  27. References [1] The Gnutella Protocol Specification v0.4 www9.limewire.com/developer/gnutella_protocol_0.4.pdf [2] “ A Reputation-based Approach for Choosing Reliable Resources in Peer-to-Peer Networks," E. Damiani, etc. [3] http://www.limewire.com/

More Related