"Scott Young" <scottyoung at adelphia.net> writes: > HTL has 2 main problems: > First hop - Incoming HTL values can be used to determine if a node is likely > to be the originator of a request > HTL-1 - Malicious node may find out if a node contains specific data. > good description of the problem.
> One suggested solution to both of theese is to abandon HTL for a > probabalistic forwarding approach, but that suffers from a huge variance in > request times. The more probability-based the forwarding, the higher the > standard deviation of request times. The more statically decremented the > HTL value, the more vunerable it is to analysis. > Agreed; moving to completely statistical methods is as bad/worse than strict HTL. > A solution to this could work in 3 steps: > > 1. HTL|P mode - HTL stays the same until the probability turns up negative > 2. Normal HTL mode > 3. HTL 1 mode - requests keep on going on with P(forwarding) probability. > I'm with you so far. > Nodes can specify HTL|P, HTL, and P(forwarding). no. This is where I have to disagree with you. P(forwarding) should definitely not be specified by the requesting node. Similarly, there's no real good reason for the probability of starting HTL decrementing to be specified by the requestor; we should pick a value of both and use that everywhere. > P(forwarding) has a > minimum value so that malicious nodes have a harder time determining if a > node has specific data. It needs to also have a maximum value so that requests won't go on forever because they never stop forwarding. While we're at it, there's no good reason to have this vary at all. > The HTL of all 3 must be below MAX HTL, where the > HTL of the first and third steps is counted by the average number of hops at > that probability. If the total HTL exceeds MAX HTL, then P(forwarding) is > decreased first (down as far as its minimum value). Then, the normal HTL is > decremented, then the HTL|P, as necessary. > There's no reason to ever decrement the HTL|P if you decrease the HTL to suit. But this is still too fancy a solution, being just a bit too complex. > If a node doesn't care about the request time, it could start at HTL 1 mode <SNIP fancy plans> > > Just my $0.02. > > Scott Young > There's no reason for every initial request to look as much alike each other as possible. To that end, I propose the addition of a modification to nodes' behavior that requires no protocol changes and is in line with the current functioning of the node. The idea is basically the same as the "don't decrement HTL=1 with a certain probability", but adds the same non-decrementing HTL to incoming messages with max HTL. To re-iterate, we'd simply not decrement the HTLs equal to MaxHTL with a certain probability. I'm not sure if the same probability as HTL=1 non-decrementing will work, or if something higher is needed, but this will solve the problem with a minimum of fuss. Thelema -- E-mail: thelema314 at swbell.net Raabu and Piisu GPG 1024D/36352AAB fpr:756D F615 B4F3 BFFC 02C7 84B7 D8D7 6ECE 3635 2AAB _______________________________________________ devl mailing list devl at freenetproject.org http://hawk.freenetproject.org/cgi-bin/mailman/listinfo/devl
