> On Jul 20, 2015, at 4:03 PM, John Brooks <[email protected]> wrote: > > A. Johnson <[email protected]> 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
signature.asc
Description: Message signed with OpenPGP using GPGMail
_______________________________________________ tor-dev mailing list [email protected] https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
