gzz-dev
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Gzz] Hemppah's PEG round 2 comments


From: Hermanni Hyytiälä
Subject: Re: [Gzz] Hemppah's PEG round 2 comments
Date: 05 Jun 2003 13:49:36 +0300

On Thu, 2003-06-05 at 13:15, Tuomas Lukka wrote:

> > 
> > Directly related to DHTs, there are two publications about this topic:
> > 
> > "Security Considerations for Peer-to-Peer Distributed Hash Tables"
> > by Emil Sit and Robert Morris
> > 
> > "Security for structured peer-to-peer overlay networks"
> > by M. Castro, P. Druschel, A. Ganesh, A. Rowstron and and D. Wallach
> > 
> > Both papers discusses scenarions you mentioned above, e.g., Sit's
> > paper describes:
> ...
> 
> Ok, since none of the defences are implemented in GISP, 
> the simulation should be postponed to see if we can make exploit programs
> and get GISP proofed against them. If not, we need another platform.
> 
> So that changes the goals; we don't want to do the abstract simulations --
> we want to do concrete simulation of gisp clients with a fraction of
> hostile exploiters and see how easy it is to stop things. 
> 
> Therefore, I suggest postponing this PEG and starting a new one:
> "Attacking GISP", which contains your plans on how you will make an exploit..


Ok, will do that.


> > 
> > Since original GISP publication talks about Chord-like routing table, we
> > can assume that GISP doesn't use Kademlia's routing table (abstraction).
> > Thus, GISP requires O(log^2 n) messages when a peer joins/leaves the
> > system.
> 
> Which is not acceptable for us - network connections will get severed &c.
> 
> So GISP doesn't even know how to deal with machines vanishing from the 
> network?

No, it *does* know how to deal with leaving peers -- by using same
mechanisms se Chord. But as said, Chord's routing table/virtual overlay
topology is rigid for a highly dynamic environment.

> 
> > > If they are, then we should move away from it immediately!
> > 
> > Hm, do have any options ? I still recommend Kademlia ;).
> 
> Yes, you mentioned the python client -- might be worth looking at.

Indeed. First, however, I will ask from the authors of Kashmir how
similar their implementation is compared to Kademlia paper. Hm, perhaps
I should also ask from the authors of Kademlia paper what's the current
situation of their C++ implementation of Kademlia (brief history: first,
there was a Java implementation and now they are working with the C++
implementation).



> Remember also that if we use indices for transclusions, we have a fresh
> problem as it becomes possible to spam...

Btw, there is a paper about DHT design, which is designed to be
resilient against spam attacks:
http://iptps03.cs.berkeley.edu/final-papers/simple_fault_tolerant.pdf



-Hermanni






reply via email to

[Prev in Thread] Current Thread [Next in Thread]