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

Tor Bug Tracker & Wiki blackhole at torproject.org
Fri Apr 15 03:03:12 UTC 2016


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

Comment (by teor):

 Restricting fallbacks to one per operator is done in
 c157a31ee8bd84587e6e61b674b33c792154d74a in my branch fallbacks-201604-v9
 in https://github.com/teor2345/tor.git
 The majority of that branch is being reviewed in #17158.

 '''One Per Operator'''

 Here's a breakdown of the selection process:
 * 100 fallbacks were selected
 * all 100 fallbacks passed the 15s consensus download check
 * 73 more are available from distinct operators
 * 104 were eliminated due to the "one per operator" restriction (family,
 contact, IP)
   * other fallbacks were commented-out in the whitelist because operators
 told me they were on the same machine, even though they had different IP
 addresses
   * if we need to in future, we can modify the restriction to one per IP,
 but 2 per family/contact

 '''Bandwidth'''

 The range of bandwidths selected is 5.4 - 70.4 MB/s, the minimum is 3MB/s,
 which is 100 times the expected extra load of 20-30KB/s. No weights were
 modified, but we do ensure that the script is harder to game by limiting
 the bandwidth or each relay to its "measured" bandwidth. (We approximate
 measured bandwidth based on a conversion that uses the median consensus
 weight to bandwidth ratio among fallbacks.)

 '''Network Diversity'''

 The script output the following analysis of the network diversity of the
 fallback list:

 {{{
 26/100 = 26% of fallbacks are on IPv6

 There are 5/100 = 5% fallbacks in the IPv4 /16 containing 178.62.199.226
 36/100 = 36% of fallbacks are in an IPv4 /16 with other fallbacks
 There are 2/100 = 2% fallbacks in the IPv4 /24 containing 91.219.237.244
 2/100 = 2% of fallbacks are in an IPv4 /24 with other fallbacks

 There are 5/26 = 19% fallbacks in the IPv6 /32 containing
 [2001:41d0:e:f67::114]
 16/26 = 62% of fallbacks are in an IPv6 /32 with other fallbacks
 There are 2/26 = 8% fallbacks in the IPv6 /48 containing
 [2001:41d0:a:74a::1]
 2/26 = 8% of fallbacks are in an IPv6 /48 with other fallbacks

 40/100 = 40% of fallbacks are on IPv4 ORPort 443
 40/100 = 40% of fallbacks are on IPv4 ORPort 9001
 20/100 = 20% of fallbacks are on other IPv4 ORPorts

 9/26 = 35% of IPv6 fallbacks are on IPv6 ORPort 443
 6/26 = 23% of IPv6 fallbacks are on IPv6 ORPort 9001
 11/26 = 42% of IPv6 fallbacks are on other IPv6 ORPorts

 35/100 = 35% of fallbacks are on DirPort 80
 44/100 = 44% of fallbacks are on DirPort 9030
 21/100 = 21% of fallbacks are on other DirPorts

 19/100 = 19% of fallbacks have the Exit flag
 }}}

 While I might like to tweak some of these figures slightly, none of them
 are critical.
 (I'd be much more concerned if some of them were over 50%.)

 '''Summary'''

 I'm happy with the diversity of the fallback list.

 As I said before, each restriction costs bandwidth, and I'm happy with the
 existing bandwidths, and the results of applying a one-per-operator rule.
 (I'm also concerned that some restrictions may reduce more important
 diversity criteria.)

 I think that the other network diversity criteria the script analyses are
 acceptable.

 I'd be interested to see how the fallbacks are spread between ASs or
 countries, if anyone else wants to do that analysis. Remember that the
 countries derived from VPS IPs are sometimes inaccurate.

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


More information about the tor-bugs mailing list