Survey
* Your assessment is very important for improving the workof artificial intelligence, which forms the content of this project
* Your assessment is very important for improving the workof artificial intelligence, which forms the content of this project
Cracking of wireless networks wikipedia , lookup
Recursive InterNetwork Architecture (RINA) wikipedia , lookup
Internet protocol suite wikipedia , lookup
SIP extensions for the IP Multimedia Subsystem wikipedia , lookup
Zero-configuration networking wikipedia , lookup
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] Motivation of Reputation Systems XRep protocol [2] Security considerations on XRep Distribution of Servent & Resource Conclusions References 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. Gnutella Gnutella is a protocol for distributed search. Nodes are called servents.(server + client) Servents communicate by exchanging descriptors. 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 Descriptor routing A servent P requiring a resource broadcasts a Query out. A servent S will respond with a QueryHit if 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. 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. Gnutella A servent S will descriptors forward incoming QueryHit may Query A servent S receiving a descriptor descriptors all of its directly connected be sent along the same Awhich servent Stowill respond with anot S only has received before will servents, except one that the A servent Pthe requiring aincoming resource path that carried thedelivered forward the descriptor QueryHit if a match is found incoming Query. a Query out. broadcasts Query descriptor against its local database. Match O O P P: servent looking for a resource O: offerer Query QueryHit Download Match Structure of Gnutella descriptor Every descriptor has two parts: 1. Descriptor Header Descriptor ID Payload Descriptor TTL Hops Payload Length 2. Payload Query: Minimum Speed Search criteria QueryHit: Number of Hits Port IP Trailer Servent Speed Result Set File File Index Size File Name ID Motivation of Reputation systems Most P2P systems protect peers’ anonymity. Anonymity opens the door to possible misuses and abuses -- Bad service, low quality resources -- 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 resources. XRep: Basic Assumptions Each node keeps track and share with others information about the reputation of their peers and resources Reputation sharing is based on a distributed polling protocol Each servent has a servent_id which is a digest of a public key obtained using a secure hash function Each resource has an resource_id which is a digest computed by applying a secure hash function to the resource content XRep: Reputations Storage Each servent maintains two repositories that store its opinions about resources and servents it had experiences resource_repository: set of pairs (resource_id, value) servent_repository: set of triples (servent_id, num_plus, num_minus) A peer votes on resources and servents with which it had experiences translation of reputations into votes: votes are expressed on the basis of information available in the resource_repository & servent_repository XRep: Polling Protocol Phase 1: Resource searching. p sends a Query message for searching resources, 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,trailer,servent_i d) Trailer: resource_id XRep: Polling Protocol Phase 2: Vote polling. p polls its peers about the reputation of a resource and the set of servents that offer it. Peers wishing to respond send back a PollReply Peers vote on the resource_id and each servent_id Initiator p Servent s Poll (resource_id, {servent_id1… servent_idn}, PKpoll) PollRepley ({(IP,port,Votes)}PKpoll) XRep: Polling Protocol Phase 3: Vote evaluation. (two steps) 1. p clusters Voter’s IP and weight the votes within a cluster --Reducing the effect of a clique 2. p selects a set of voters in each cluster, contacts them directly, and expects back a confirmation message. Not enough responses, then p repeats step 2. Initiator p Servent s TrueVote ( Vote ) TrueVoteRepley ( responses ) XRep: Polling Protocol Phase 4: Best servent check. p contacts the best servent S to check the fact that it exports resource r Initiator p Servent s AreYou (servent_ids, r) AreYouRepley({response}SKs, PKs) XRep: Polling Protocol Phase 5: Resource download. p selects a servent s, downloads resource r and checks it against its digest Update its resource_repository & servent_repository Initiator p Servent s download ( r ) resource ( r ) XRep: Security Considerations XRep allows to protect P2P against most knows attacks Self replication Man in the middle ID Stealth Pseudospoofing Shilling Self replication: A malicious peer 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 resource -- Worms slightly modifying themselves Cannot collect positive recommendations Check reputation of the servent 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. Unlikely to be chosen. Even is so, the fake content provided by E will not match the digest of the legitimate resource, then be discarded. (Phase 5) A E B ID Stealth: A malicious peer answers with two QueryHits, carrying the digest of a doctored resource and one of them carrying the ID of a reputable servent Xrep checks whether the best servent is offering that resource (Phase 4). 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 Servents have different but faked IP address TrueVote/TrueVoteRepley (phase 3) These two cases are called Psedospoofing Psedospoofing & Shilling: 2 Servents have different real IP address. And those IP addresses have same net_id. IP cluster may reduce the effect 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. Distribution of Servent & Resource An important aspect for the applicabilty of this approach frequent resources are more frequently searched => the number of votes will be high few servents offering many resources => these servents will probably well know 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 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/