This problem is due to having fewer estimators than
keys in the keyspace (due to resource constraints :)
and interpolating between estimators. The attack is
exploiting this interpolation. I propose using
dynamic estimators to thwart this attack. If an
estimator is "moving" a lot it is either due to dnf's
or the data being found nearby. In either case, it
may be a good idea to spawn one or more NEW estimators
near the old one. This way NGR can ddynamicallyscale
it's precision in certain parts of the keyspace if
there happens to be a lot of keys in that area or the
new estimators can act as a "wall" to thwart the
attack. Another idea is to have the estimators "move"
faster, but I think this would introduce more noise
into NGR. Maybe we could analyze the amount of NGR
noise and add more estimators if there is too much
noise. Just some thoughts.
----- Original Message -----
From: "Toad" <[EMAIL PROTECTED]>
To: "Discussion of development issues"
<[EMAIL PROTECTED]>
Sent: Tuesday, October 28, 2003 5:22 PM
Subject: Re: [freenet-dev] Re: Frost and Routing -
solution ?
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?
On Tue, Oct 28, 2003 at 11:20:47AM +0200, Jusa Saari
wrote:
> On Mon, 27 Oct 2003 23:10:15 -0600, Tom Kaitchuck
wrote:
>
> > If we had TUKs why would we ever have a request
fail for data other
> > than: A. It really isn't in the network. or B. It
used to be in the
> > network and fell out.
>
> C. People keep on using the old version of Frost
("the good old Frost").
>
> D. Someone purposefully sabotages the network by
making an interesting-
> looking program that requests guessable keys.
>
> E. Someone makes such a program out of ignorance.
>
> F. Someone starts uploading something with FUQID,
uses the "insert
> metadata first" -option, and posts the key.
People start downloading,
> but of course most of the file parts aren't
inserted yet.
>
> G. All of the above happen.
>
> The point is that this is a vulnerability in the
network, and should be
> fixed.
>
> BTW. Would it be an effective attack, if someone
would simply flood the
> network with queries for nonexisting keys ? It would
at least disturb the
> malignant nodes neighbours...
>
> Would it be worth it to keep stats on the proportion
of requests resulting
> in DNF of all requests from node A (that is, how
many requests that have
> led to DNF we have gotten from A versus how many
requests total we have
> gotten from A) and use that to decide how likely
those DNF's a legitimate
> ? It should make such an attack more difficult, but
would it have an
> adverse effect for routing ?
>
> Of course, if we have several bad apples, traversing
the network
> (switching the attack targets, or simply changing
their node key) it would
> defeat this defense... Hmm.
>
> > Frost can have each board on a SSK or 20 each with
their own TUK. If the
> > TUK can be updated by any node that has the key,
then all frost would
> > have to do is request the TUK. Then if that
version was newer than what
> > you have you can request the new messages. There
is no reason to try to
> > guess keys and request them. (The only thing I
wonder about is if two
> > node insert the same new key at exactly the same
time, and they cross
> > paths, what would happen?)
>
>
> Wouldn't this cause messages to be dropped (I insert
a message at 10:00
> and someone else inserts his own at 10:01, therefore
superceding my
> message) ? In any case, this would require work from
both Frost developers
> and users part (but, if I understood it correctly,
would solve the
> DBR/Edition freesite problems).
>
> _______________________________________________
> 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.
_______________________________________________
Devl mailing list
[EMAIL PROTECTED]
http://dodo.freenetproject.org/cgi-bin/mailman
__________________________________
Do you Yahoo!?
Exclusive Video Premiere - Britney Spears
http://launch.yahoo.com/promos/britneyspears/
_______________________________________________
Devl mailing list
[EMAIL PROTECTED]
http://dodo.freenetproject.org/cgi-bin/mailman/listinfo/devl
