Matthew Toseland wrote: > - Not compatible afaics with ULPRs / failure tables. ULPRs stop requests if > we've routed them already (for some period), with the same HTL or less.
Good point, and I guess the same would be true of request coalescing. Maybe we could get a similar effect by using the weighted coin to decide whether to coalesce or forward the new request. > - Load management issues maybe. Do we currently use the hop counter for any load management decisions? > - It's a good "invisible" DoS on a single request. Sorry, I don't see what you mean - the hop counter can be tampered with but a weighted coin can't, making it harder to influence how other nodes handle the request. > - The current counter is reset when we get closer to the target, so to some > degree it adapts to the network size. We'd lose this, so we may have to set > the probability of termination quite low, and fiddle with it... Good point, I didn't realise that resetting the counter had that function. > Why can we not analyse how much information the current counter leaks? > Because > of the uncertain topology/average number of resets? I shouldn't have said we can't analyse it, but I wouldn't know where to start because so much depends on the topology. For example, the closest-location-so-far obviously leaks information, but how do we quantify it? >> This could actually be used in place of premix routing: instead of >> constructing cells we use random "tunnel IDs". > > No use against a local attacker. What kind of attack do you have in mind? > So a local attacker *immediately* knows that the keys are connected. Right, but who cares if the attacker knows that? The attacker doesn't know whether you're the initiator of the tunnel. > This has been proposed before. One weakness is you'd need more than one > tunnel > to get good or predictable performance. And as soon as you have multiple > correlatable or identical tunnels from the same node, it gets really easy to > identify the requestor - admittedly it may require a conspiracy... The number of tunnels should be kept to a minimum to slow down predecessor attacks (that's I2P's major weakness: tunnels are rebuilt too frequently). 100 tunnels will give an attacker as much information as 100 requests under the current system. On the other hand if you use separate tunnels for separate files then it's harder for an attacker to link them, which makes it harder to use them in a predecessor attack. So the initiator should choose tunnels intelligently - eg give each client its own tunnel and each large splitfile its own tunnel. > Also, you have a very small anonymity set: if the tunnel is on average 5 hops > long, there is a 20% chance that the node that sent you the request is the > originator. This is unacceptable, especially if you can correlate the 20%'s > because of linked but non-identical tunnels. True, but the same applies to premix routing: even if there are 100 nodes in the cell, if you premix for 5 hops there's a 20% chance the previous hop is the initiator. > Finally, are there any vulnerabilities in changing paths? Yes - churn will force initiators to build new tunnels, speeding up the predecessor attack. > Indeed, random hops seem to be the way forward. But if you get the request > during the random hop phase, you can attack the originator, although it will > take much more time than without random hops. Yup, there's no way to prevent predecessor attacks as far as I can tell, but we can slow them down to one sample per tunnel instead of one sample per request. > The idea was to pick two random nodes from within the cell, and route through > them - choosing a new tunnel for every request. Why choose a new tunnel for every request? If an attacker inside the cell can somehow link messages leaving the cell with messages passing through his node, he can gather one predecessor attack sample per intercepted message. > The one big weakness is that cells would have to be relatively small > to keep global data available. The complication (IMHO solvable) is bogus > topology attacks. And bogus public key attacks (the nodes beyond my neighbour might really exist, but my neighbour might MITM their public keys in order to link traffic passing through his node with traffic exiting the cell). When you say solvable, what do you have in mind? Cheers, Michael _______________________________________________ Devl mailing list Devl@freenetproject.org http://emu.freenetproject.org/cgi-bin/mailman/listinfo/devl
