[tor-bugs] #18749 [Tor]: Consider only including one fallback per operator

[Tor Bug Tracker & Wiki]

#18749: Consider only including one fallback per operator
-------------------------+------------------------------
 Reporter:  teor         |          Owner:
     Type:  enhancement  |         Status:  new
 Priority:  Medium       |      Milestone:  Tor: 0.2.???
Component:  Tor          |        Version:
 Severity:  Normal       |     Resolution:
 Keywords:               |  Actual Points:
Parent ID:               |         Points:  small
 Reviewer:               |        Sponsor:
-------------------------+------------------------------

Comment (by teor):

 Replying to [comment:3 tscpd]:
 > Proper configured fallbacks should not get excluded from whitelist.
 Those who are not lie and not leave empty are most likely those we can
 consider to be trustworthy.

 Regardless of whether an operator is trustworthy or not, relays operated
 by a single operator are more likely to change address or go down at the
 same time. And I don't want to paint a target on any one operator by
 putting a large number of their relays in the list.

 > I think AS, adressrange and country are more important values here. This
 could be a great point to add a pile of anonymity and security with a few
 amount of effort: Fallbacks in rare countrys could get extra weight. Same
 with with unique adressrange or fameless ASes. Here could something like a
 diversity weight take place. Some algorithm to rate rarity could possibly
 take place in other cases.

 I have access to IPv4 and IPv6 addresses, but I don't have access to
 country or AS in the python script I'm using. I don't have time to develop
 that feature before 0.2.8-rc, please feel free to open a ticket for it in
 "0.2.???". (I'm not sure if it will make it into 0.2.9, because we've
 already triaged many tickets out.)

 Also, a system like this is easy to game: "Want to get a relay on the
 fallback list? Put it in a rare country/AS."

 I prefer not to have a diversity weighting system, because they are
 complex, and mash together many criteria into a single number. It's hard
 to reason correctly about complex systems like this.

 I propose instead that we limit the number of relays in the list that
 share certain attributes, like operator and IP address. This ensures good
 uptime, which I believe to be a significant threat to reliability. It also
 ensures that no one operator sees too much client traffic, which is also a
 significant threat to privacy. (Fortunately, mitigating one of these
 threats tends to mitigate the other.)

 > But even those who are doing proper description should not get assigned
 more than a cap of x% fallback weight.

 I agree, see above.

 > In cases of fallbacks with same family / contactinfo get in sum over x%
 i would tend to blacklist higher-weight fallbacks of those. This would
 reduce the cases of blacklisting multiple fallbacks of such a group to get
 under x% cap which would increase diversity again.

 We are weighting each fallback equally for client selection, because it's
 simpler and easier to reason about (#17905). It also allows me to remove
 some complex code that down-weighted high weight fallbacks so they didn't
 see too much client traffic (and so we don't depend on them being up too
 much).

--
Ticket URL: <https://trac.torproject.org/projects/tor/ticket/18749#comment:5>
Tor Bug Tracker & Wiki <https://trac.torproject.org/>
The Tor Project: anonymity online