-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi,
I'm not sure whether your message just came through to the list or whether I just noticed it. Either way, I hope it's not too late to reply. The following papers describe attacks that can be carried out by malicious nodes in structured P2P networks: E. Sit and R. Morris. Security considerations for peer-to-peer distributed hash tables. 1st International Workshop on Peer-to-Peer Systems (IPTPS ?02), Cambridge, MA, USA, March 2002. http://citeseer.ist.psu.edu/viewdoc/summary?doi=10.1.1.11.7175 M. Castro, P. Druschel, A. Ganesh, A. Rowstron, and D.S. Wallach. Secure routing for structured peer-to-peer overlay networks. 5th Symposium on Operating Systems Design and Implementation, Boston, MA, USA, December 2002. http://citeseer.ist.psu.edu/viewdoc/summary?doi=10.1.1.118.1870 I'd recommend checking out the papers that cite those papers, some of which propose solutions to some of the attacks. Cheers, Michael On 13/03/13 05:44, offbynull wrote: > Hi, > > Does anyone know of any strategies to prevent, identify, or > work-around malicious nodes in a structured overlay? I'm > specifically interested in Chord's ring overlay. It seems like > there are a lot of things a malicious node could to to interfere > with normal operations (e.g. routing / lookup / etc..), or to > bypass certain regions of the ring. > > Examples of things that a malicious node could do ... > > 1. Imagine someone wanted to prevent others from accessing a > key-value pair. That person would create a malicious node with an > id of hash(key), ensuring that queries for that key would end up at > the malicious node. When the malicious node receives queries for > that key, it simply ignores them or responds that the key was never > set. > > 2. This is similar to the one above. Imagine someone wanted to > prevent others from accessing a key-value pair, but a legitimate > node already existed with an id of hash(key). That person would > create a malicious node with an id of hash(key) - 1. When other > nodes ask the malicious node to be routed to that key, the > malicious node would respond with a node other than it's successor, > ensuring that the request never gets routed to its true > destination. > > 3. Imagine someone wanted to cut out a portion of the nodes in the > overlay. That person would create a malicious node that has its > finger table set to skip over a bunch of existing nodes in front of > it. > > > Are there strategies to deal with this, or is this just something > that's expected with Chord's design (as in peers can't be untrusted > nodes)? > > _______________________________________________ p2p-hackers mailing > list [email protected] > http://lists.zooko.com/mailman/listinfo/p2p-hackers > -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) iQEcBAEBAgAGBQJR9o5bAAoJEBEET9GfxSfMj0AIALZ+lSnA7GDh+Y3iifdVotwK YXdjGjv+qJcvOIO/rHtTEyPMzp7yqz0X0VxeiC8XIjXP6rwvFGOXuClqd0NAjFW9 lHYtO9tHBkCV/LOU5hHrD3510Ry6gYkuDnyDeWBlwQ2i/zUU160PqGr+Esd1IpNP zu5JKSHHq61wr5GisXOB+pWOxrKEEKtQAtv3ibFNBDXhGyJwg+U/LCe9Q14V9Q4t BiOKgce8xHhbytY8B/5t3HW6cCavQAq/TR0CfjpWRtz823hs0lTdepJJXPnKVYIo HD0u+cwnCGr7LNF5szMvkvdEkyXsbXGLYX+2cK7aHBPO4kGoXw5DrNAhS2Gkh+g= =xMmD -----END PGP SIGNATURE----- _______________________________________________ p2p-hackers mailing list [email protected] http://lists.zooko.com/mailman/listinfo/p2p-hackers
