----- Original Message -----
From: "Stefan Reich" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Friday, May 11, 2001 2:08 PM
Subject: Re: [freenet-tech] Ideas for a FreeNet Process
> The point is... if you execute code on a Freenet node you got from
someplace
> you-don't-know-where, it can do all kinds of weird things to your system.
> All I can say is that I wouldn't want to do that to my system.
Ahhh now I see your delema.
The code is not run on the executor's computer. Its run on a set of unknown
nodes. ie each node has freenet processing capabilities as well as freenet
storage capability.
Of course the results will come to the executor's machine but it doesn't
have to. The output could simply be a memory update that would exist
somewhere in the freenet, unknown to the executor.
The point is the executor will not know where the code is being executed at.
So much more difficult to attack the process.
>
> > > Without untrusted code, you need a constant flood of requests to force
a
> > > node into DOS.
> >
> > This is bad???
> > Is this phrased poorly or am I not getting this.
> > Please explain.
>
> It's phrased brilliantly of course!!!! ;-)
hehe sry.
>
> With "you" I meant the attacker that tries to bring down a node. If we
> implement Freenet processes as your proposed, it will be very easy for
that
> person to bring down the node - sHe just sends the node some code that
> contains an endless loop.
Consider that the process is distributed in pieces in the freenet. It is
also duplicated, so the different attackers actually use different nodes
runing the same process.
How would the attacker know which node to target?
The executor of a DOS attack could send lots of useless commands that the
freenet process target usually executes and yes therefore if enough useless
commands are sent, then others may have difficulty accessing the process.
HOWEVER,
freenet provides a natural defense to this type of attack. Simply that
multiple attackers could not agree on the exact locations of process targets
in the freenet, hence not enough useless commands could be sent to the exact
nodes involved in the process. Freenet would essentially by its current
nature diffuse the attack. Executors would have their requests done on
different nodes most likely as due to the reduncy of data in the freenet.
The freenet could be the largest distributed processing system ever built,
hence therefore I might claim that DOS is impossible as the power of the
freenet is distributed and hence untargetable. Also the overall distributed
power of the freenet could handle an enormous amount of useless requests as
attackers might be able to muster 1000 machines in an attack, but the
freenet would be spread out amonst millions. Randomly selecting small
portions of the freenet would fail.
HKF
>
> -Stefan
>
> ----- Original Message -----
> From: "JF" <[EMAIL PROTECTED]>
> To: <[EMAIL PROTECTED]>
> Sent: Friday, May 11, 2001 7:59 PM
> Subject: Re: [freenet-tech] Ideas for a FreeNet Process
>
>
> >
> >
> > > Thanks for the move ;-)
> >
> > No prob. I'm a newbie here so please forgive me.
> > >
> > > My point was that with untrusted code, only one request is enough to
> bring
> > a
> > > node to its knees. The code can run in an endless loop.
> >
> > Ok for which other nodes are waiting. The other nodes could detrmine a
> > problem and distrbute the process elsewhere.
> > If I am correct in reading the freenet protocol, copies and duplicate
> files
> > are made all over as more requests for that file occur. So if one dup
> falls
> > out or is taken up by a cancer node. then the file can be goten
elsewhere.
> > So could the process do the same. Again we have to detct cancer nodes.
> Of
> > course a cancer node could be very clever and get around cancer
detectors.
> > But that node might not be selected agaian and again for processing due
to
> > the random nature of freenet.
> >
> > >
> > > Without untrusted code, you need a constant flood of requests to force
a
> > > node into DOS.
> >
> > This is bad???
> > Is this phrased poorly or am I not getting this.
> > Please explain.
> >
> > HackerKungFu
> >
> >
> >
> > _______________________________________________
> > freenet-tech mailing list
> > [EMAIL PROTECTED]
> > http://lists.freenetproject.org/mailman/listinfo/tech
>
>
> _______________________________________________
> freenet-tech mailing list
> [EMAIL PROTECTED]
> http://lists.freenetproject.org/mailman/listinfo/tech
>
_______________________________________________
freenet-tech mailing list
[EMAIL PROTECTED]
http://lists.freenetproject.org/mailman/listinfo/tech
