Toad <[EMAIL PROTECTED]> writes: > On Tue, Oct 28, 2003 at 11:22:02PM +0000, Toad wrote: > > I have a better attack. You are targetting a particular area of the > > keyspace. Request a long stream of random keys very close to the target > > key. They will all DNF, and reduce the pDNF in that area of each node > > the node routes the request to, until the estimator is so low that it > > tries a different node. Keep on requesting and you can effectively > > eliminate the node's ability to route requests in that region... I have > > no idea how to fight this attack :(. Anyone have any reason why it > > wouldn't work? > Nice attack. It shows a problem with the negative trust in pDNF nicely.
> Here's a start: If pLegitDNF accurately reflects the attack, we have > little to fear, because it will affect all nodes equally. Unfortunately > getting an accurate pLegitDNF that varies per key is a bit of a bastard. > Currently we use the lowest average pDNF (not per key) of those nodes in > the RT which we alchemically choose to be mature enough to matter. This > is not exactly satisfactory, of course, and to defeat this attack we > need an accurate pLegitDNF which takes the key as a parameter. This is getting dangerously complex and is definitely another step along the way of destroying the simplicity that NGRouting could and should be. I do have to admit that the idea is sound, even if the implementation is going to be hairy. > We used > to use the same alchemical choice on the estimators for the key we were > routing, which would seem to solve the problem - but it turns out that > the estimators may well not have learned much in the area of the key we > are searching for, and result in an absurd estimated pDNF. We have > maturity data (total amount of influence on a given point) provided by > the NGRouting aging algorithm, but we would have to set an arbitrary > cutoff point, which we must presumably determine empirically... What alchemical choice did we use on estimators? I lose your train of thought about here. I hope you're not proposing we use alchemy to solve this problem, because <sarcasm> freenet is an alchemy-free zone </sarcasm>. My solution to this problem would be to just drop pDNF, and not worry about calculating the time to retry, because the node isn't going to retry anyway. The client might, but if the same nodes as made retry calculations on the first attempt get asked again, the request will still fail because it didn't take a different path. So hopefully most nodes involved in making retry calculations won't be involved in retrying, so their numbers will be irrelevant. pDNF is a nice idea, but I really think that NGRouting is getting too complicated. Just estimate routing time (time until xfer starts) and add (keysize * avg throughput). Estimate routing time however you want. Now's a great time to start trying machine learning algorithms to see how well they do. Thelema -- E-mail: [EMAIL PROTECTED] Raabu and Piisu GPG 1024D/36352AAB fpr:756D F615 B4F3 BFFC 02C7 84B7 D8D7 6ECE 3635 2AAB _______________________________________________ Devl mailing list [EMAIL PROTECTED] http://dodo.freenetproject.org/cgi-bin/mailman/listinfo/devl
