13.07.2015 Views

WWW/Internet - Portal do Software Público Brasileiro

WWW/Internet - Portal do Software Público Brasileiro

WWW/Internet - Portal do Software Público Brasileiro

SHOW MORE
SHOW LESS

Create successful ePaper yourself

Turn your PDF publications into a flip-book with our unique Google optimized e-Paper software.

IADIS International Conference <strong>WWW</strong>/<strong>Internet</strong> 2010newcomer (i.e., max( 1,2θA)). This approach captures the idea of a node effort to reciprocate favors of the bestcollaborators.The original NoF <strong>do</strong> not address malicious attacks by rogue peers that desire to slow <strong>do</strong>wn the system bysending bogus pieces of data to their neighbors. Furthermore, we highlight the impact of transmitting a boguspiece to peers of a P2P content distribution system might be orders of magnitude worse, if the P2P systemrelies on a MANET, due to the hop by hop nature of a MANET. As the bogus piece traverses a MANET,many nodes may be requested to forward the t from the sender node to the receiver node. In case of acollusion attack, a few rogue nodes can saturate the entire network sending bogus pieces to diametricallyopposed nodes.To circumvent this problem, we modify the original NoF, adding a blacklist feature. The aim of theblacklist is punishing immediately any P2MAN sending node that sends a bogus piece to the requesting node.Hence, as soon as a bogus piece is <strong>do</strong>wnloaded by P2MAN requesting nodes, they lay the sending node inblacklist, avoiding answer its requests (e.g., reply to content requests, send pieces) for a penalty period. Thepenalty period can be tuned appropriately by system user. In order to calculate rA (B), we assume that aP2MAN node has reliable information about v ( B, A)and v ( A,B), the value of favors received from andprovided to another P2MAN node. Specifically, we assume that a generic P2MAN node can both: (i)measure the value of a favor <strong>do</strong>ne by another P2MAN node, and (ii) verify that the favor delivered was vali<strong>do</strong>r not, (i.e. that the sent data was not bogus). These assumptions are no stronger than the assumptions madefor another decentralized reputation schemes.3.2 Avoiding Rogue Peer ActivitiesAs a multicast-based P2P content distribution protocol designed for MANETs, one strategy of P2MAN isavoiding multiple one-to-one peer traffic of content distribution, reducing network transmission saturation.Instead, P2MAN enforces the selection of a single sending node for each content transmission by a processnamed owner node selection. Recall that, as part of P2MAN design, a requesting node which desires aspecific content must asking for it by sending a message to the Public Channel (i.e., a special multicastgroup). By receiving a requesting message, owner nodes can reply to the Public Channel, if they want to <strong>do</strong>so, informing that possesses the content and giving metadata having detailed information about the content(e.g., how it is divided in pieces, multicast group to be used in the transmission). All owner nodes can reply arequest in the Public Channel, if they own the requested content. After analyze the possible multiple replies,the requesting node choose a unique sending node to be authorized in the Public Channel, by sending anauthorization message. In particular, the owner node selection and authorization procedures are relevant toavoid the rogue peer activities in P2MAN, as following explained.Suppose that a rogue peer wants to send bogus pieces for dishonestly profiting favors, or to slowing <strong>do</strong>wnthe system. Hence, the rogue node may respond to any content request, as an owner node. To complete theattack, a rogue node must wait for an authorization, because if a requesting node receives a piece from anunauthorized owner node, it rejects (i.e., discards) the piece. When a rogue node is authorized, it maycomplete the attack, sending bogus pieces in a specific multicast address. As the first bogus piece is<strong>do</strong>wnloaded by the receiving nodes in the target multicast group, the sending node is inserted in the blacklistof each receiving node, that will leave that multicast group immediately. For the penalty period, the attackedreceiving nodes will ignore further replies, pieces and requests from the blacklisted nodes. We argue that thisapproach is sufficient to minimize rogue peer activities, by avoiding that rogue peers receive pieces theyrequest, and receive authorization messages. Free riding is also minimized, due to the low reputation of noncollaborators, as follows.Suppose now that a rogue peer desires to be a free rider, not replying to any content requests. Hence, itsreputation will not increase in the course of time. Even in the event of an ID-changing attack, the rogue peerstays in the zero favors landing, just as any newcomer.3.3 LimitationsWe assume that P2MAN is intended to distribute digital contents in a MANET, which by definition, isassembled for a known beneficial purpose. Hence, this work <strong>do</strong>es not address the possibility of byzantine223

Hooray! Your file is uploaded and ready to be published.

Saved successfully!

Ooh no, something went wrong!