On Wed, Oct 29, 2003 at 01:51:03AM -0600, Edgar Friendly wrote: > 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.
Yeah. :( > > > 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. Hopefully the node with the lowest pDNF would be the node we routed to, therefore this might work.. IF we get the alchemy right for calculating pLegitDNF, which I am not sure about. Another possibility would be to bolt something onto the failure table: if we get several failed requests for the same key (in some period?), count it on pLegitDNF... but that would completely ignore random close key attacks, and so would not be good... Any ideas? > > 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. I don't see any other way to solve the problem, and if we have pDNF we need to have pLegitDNF. > > > 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>. We have 2 levels: pLegitDNF and pWildLegitDNF. The latter is used if there are not enough eligible nodes for the former to be accurate - the threshold is arbitrarily set at 25% of the routing table. pLegitDNF counts an estimate if it has open connections, and 5 successful transfers. pWildLegitDNF counts an estimate if it has 1 successful transfer. This is all in NGRoutingTable.route(...), and it's a horrible mess. > > 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. We have to have some non-alchemical way to take into account the possibility of the node DNFing. Otherwise we will get cancer nodes that answer a few keys from the store, really fast, and take either a long time or a short time to DNF on everything else. If we can't use pDNF, I suggest we should go back to classic routing and be done with it. > > 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 -- 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
