On Mon, Jul 21, 2003 at 11:45:59AM -0700, Ian Clarke wrote:
> On Mon, Jul 21, 2003 at 07:02:46PM +0100, Toad wrote:
> > On Thu, Jul 03, 2003 at 11:40:18AM -0700, Ian Clarke wrote:
> > > If my memory serves me correctly, we currently select the first step in 
> > > routing at random as a security measure.
> > > 
> > > Translating this over to NGrouting, I suggest that for the first hop in 
> > > a request, instead of using the RTE to estimate the per-key request time 
> > > estimate, we use a random number between the minimum and maximum points 
> > > in the RTE for that node.
> > > 
> > > This introduces randomness into the first step - but without ignoring 
> > > other issues such as connection failures, QRs, and DNF liklihoods.
> > 
> > Could you elaborate slightly here? Can't we simply route to a random
> > key, like we do now? That should take into account QRs, connection
> > failures and so on.
> 
> Yeah, I am not really sure whether I like the whole idea of 
> random-first-step routing anyway.  If NG routing is really good at 
> routing requests, then the recepient of a randomly routed request might 
> be able to distinguish it from a request routed from a node that is 
> trying hard - this could be a threat to anonymity.
> 
> I say get rid of the randomly routed request thing, if someone makes a 
> good argument to put it back in then we will.

The main argument put forward at the time was to prevent the network
from dividing into islands, or to stitch it back together when they did
form. However, random routing every request on the origin node is not the
only way to deal with it - one reasonable possibility would be to have a
(very low - way under 1/htl) probability to fork the request at any
node, sending the second request to a random route. This would not give 
away the privelidged information of whether the request started on that 
node, so seems safer. It might introduce a slight performance bias,
which is why similar proposals weren't implemented in the past - but
NGRouting introduces a massive performance bias, completely swamping the
effects of occasionally forking requests.
> 
> Ian.
> 
> -- 
> Ian Clarke                                                [EMAIL PROTECTED]
> Coordinator, The Freenet Project            http://freenetproject.org/
> Founder, Locutus                                      http://locut.us/
> Personal Homepage                                 http://locut.us/ian/

-- 
Matthew J Toseland - [EMAIL PROTECTED]
Freenet Project Official Codemonkey - http://freenetproject.org/
ICTHUS - Nothing is impossible. Our Boss says so.

Attachment: pgp00000.pgp
Description: PGP signature

Reply via email to