On Jul 20, 2015, at 4:03 PM, John Brooks john.brooks@dereferenced.net wrote:
A. Johnson aaron.m.johnson@nrl.navy.mil wrote:
This proposal doubles the default number of IPs and reduces the “cost" of being an IP since the probability of being selected is no longer bandwidth-weighted. Is this a fair tradeoff for the performance improvement?
That seems easy to fix. Make the number of Introduction Points the same as it was before and make them be selected in a bandwidth-weight way. There is no cost to this. You need IPs to be online, and so whatever number was used in the past will yield the same availability now. And bandwidth-weighting should actually improve both performance and security.
I think bandwidth weight isn't appropriate for this. If we think the cost of running a HSDir(+IP) is too low, we should increase that directly. This is a good case where we can benefit from the many honest-but-not-well-funded relays. Concentrating even more traffic and information onto the highest-bandwidth relays isn’t an improvement.
The security problem is that is it cheaper to obtain an extra IP than it is to buy the commensurate fraction (viz. 1/7000) of Tor's bandwidth. Dividing HSDir+IP duties by relay makes it cheaper to observe a given fraction of client activity than dividing it by bandwidth would. Consider, for example, the LizardNSA botnet attack on Tor, in which thousands of low-bandwidth relays were added. If they had been at all surreptitious, they could have easily flooded the HSDir ring.
The performance problem of even division is that HSDir+IPs will perform a lot of actions, and relays with low bandwidth or CPU will not be able to handle as much of that activity as larger relays.
The uniform division of the hash ring has always seemed like an incorrect design choice, and it is one that we have an opportunity to fix.
Best, Aaron