On Fri, Oct 10, 2003 at 11:24:34AM +0200, Some Guy wrote: > --- Toad <[EMAIL PROTECTED]> wrote: > > On Thu, Oct 09, 2003 at 05:06:52PM +0200, Frank v Waveren wrote: > > > On Thu, Oct 09, 2003 at 01:23:25PM +0200, Some Guy wrote: > > > > > Succeed? I'm assuming that means we have the key in our DS? Wouldn't that > > > > > make it possible to probe a node's DS if we force it to overload? > > > > No the idea but it will let another node learn its specialization, which isn't > > > > the same > > thing. > > > > You'll learn of broad areas of hash space not single keys. > > > If a single request gets answered even though an overload is happening > > > (detectable remotely), that answers something about the presence of that > > > specific key, not about broad areas. > > > > This is a point. Hrrm. Maybe we need to rethink it. It certainly helps > > w.r.t. overload... but maybe it's excessive. Anyway if it makes probing > > easier, it may be a problem... > Wait let's read the orginally posted idea: > "Should the code be changed so highly overloaded nodes send DNFs when the > keys are in the Failure Table." > I think we all missread it. Sorry hope it wasn't my fault. Is this "Failure Table" > a list of > keys that recently failed to be resolved by the node? If so, the security issues > are different. > All you could find out by probing an overloaded node is which keys it had failed to > look up > recently. Knowing what I failed to find won't tell you what I have in my store, but > it might be > dangerous too I guess. > > I'm not sure if this could have adverse effects on routing, though you'd have to > time the elements > of this table out at any rate. > > > > > To probe someone's datastore for a particular key, the attack will be to just > > > > send him a > > request > > > > with HTL 1. I think you can defend against this some, if you > > > > probabalistically extend the > > HTL. > > > We currently propagate FNP HTL 1 requests with a small probability. It's not > > > as good as a purely probabilistic HTL implementation*, but more efficient > > > and it will do for the time being. > > > > Probability is something like 30% for HTL 1. > Cool. > > > > * I still hope one day the network will become healthy enough to allow > > > requests to be terminated only by loops occuring, which would be a > > > wonderful thing. > > Interesting idea, I've wondered if such cycles could be used for something. > > > No. We do NOT want requests to visit every node. If they do the network > > will collapse in a mass of O(n^2) requests. > > Toad, if the routing is working well, there must be a small pool of interconnected > nodes > specialized around that area of hash space. The messages will be probably cycle in > this pool. > This is why you have to worry about rejecting queries you're already handliing; it > is probable > event. > > My worry would be that a cycle would be created to quickly: > 1st best asks 2nd best. > 2nd best asks 3rd best. > 3rd best asks 1st best. --- Cycle > It takes just 3 to make the cycle, assuming they all know each other.
All these are competent nodes. They will know how to get to other areas of the keyspace as well as their specialization. And a cycle does not terminate the request. > > If you assume there are N indistiguishably good nodes, I believe it'll randomly > bounce around for > SQRT(N) hops before making a cycle. So even if freenet used Really Stupid Routing > (RSR) you'd > have a cycle in SQRT(N) not SQR(N), though that would still suck. > > > > > Genenerally though what's in your datastore isn't supposed to be 100% > > > > encriminating, though > > with > > > > some statistics it might be. > > > It's never 100% incriminating, but especially with keys associated to > > > eachother (in the most extreme case, splitfile parts), it gets damn close. > Yes, infact you can probably do better: > If the splitfile parts in the datastore are in correlation to the specialization, > the node was > just handling the request. > If the splitfile chunks are spread evenly over all of hashspace then you can be > pretty sure he was > requesting the file for himself. > > The ideas going around about trimming the datastore to match the specialization may > defend against > this. See the never ending Probablistic Caching Thread I started. > > > > As far as I'm aware one of the intentions has always been to not allow remote > > > datastore probing anyway. > > Nice intention, can it really be done 100%? > > __________________________________________________________________ > > Gesendet von Yahoo! Mail - http://mail.yahoo.de > Logos und Klingelt?ne f?rs Handy bei http://sms.yahoo.de > _______________________________________________ > Devl mailing list > [EMAIL PROTECTED] > http://dodo.freenetproject.org/cgi-bin/mailman/listinfo/devl -- Matthew J Toseland - [EMAIL PROTECTED] Freenet Project Official Codemonkey - http://freenetproject.org/ ICTHUS - Nothing is impossible. Our Boss says so.
signature.asc
Description: Digital signature
_______________________________________________ Devl mailing list [EMAIL PROTECTED] http://dodo.freenetproject.org/cgi-bin/mailman/listinfo/devl
