[tor-bugs] #4771 [BridgeDB]: bridgedb should make clearer in its logs which addresses it knows are from bulk-exitlist

[Tor Bug Tracker & Wiki]

#4771: bridgedb should make clearer in its logs which addresses it knows are from
bulk-exitlist
-------------------------+-------------------------------------------------
     Reporter:  arma     |      Owner:  isis
         Type:  defect   |     Status:  needs_review
     Priority:  minor    |  Milestone:
    Component:           |    Version:
  BridgeDB               |   Keywords:  bridgedb-dist, bridgedb-0.3.2,
   Resolution:           |  isis2015Q1Q2, isisExB, isisExC
Actual Points:           |  Parent ID:
       Points:           |
-------------------------+-------------------------------------------------

Comment (by isis):

 Replying to [comment:25 arma]:
 > Replying to [comment:23 isis]:
 > > I'm changing the IPv4 `/24` to `/16` to mimic Tor's logic for
 `EnforceDistinctSubnets`.
 >
 > I haven't looked at the other changes, but this one sounds plausible to
 me. I imagine we're going to have a much more non-uniform load on bridges
 given out with this distributor, since some /16's have lots of users in
 them and some /16's have zero users in them. Or actually, maybe this isn't
 true, since we're breaking the bridges into a reasonable small number of
 buckets and mapping each /16 onto a bucket, so there will still be many
 many /16's that map to each bucket, thus making the distribution more
 uniform? Or am I misunderstanding where the design has gone?

 If the IP space of all `/16`s is 2¹⁶, then there are 65535 possible
 subnets that users can be in. I'm not sure what the normal distribution is
 for percentage of that 65535 being used by clients at any given point in
 time, but perhaps if we say that, in the worst-case, only ¼ of those 65535
 are being used, so 16384 distinct subnets likely to be in use at any given
 point in time. This means that the HTTPS, non-Tor subhashring size would
 need to contain ⪞16384*3 ≅ 49000 bridges (ignoring overlap of Alice and
 Bob who end up in adjacent positions in the hashring, such that Alice gets
 bridges A, B, and C, and Bob gets B, C, and D). If we say that a "normal"
 number of bridges in the HTTPS hashrings is 3000 (that sounds about
 right), then (3000/3)/2¹⁶ gives the maximum percentage of those 65535
 subnets which may be in use and still (probably, again, roughly ignoring
 overlap) allow for each set of bridges which would be handed out to only
 be mapped to 1 in-use `/16` subnet at a time. (3000/3)/2¹⁶=0.0152587890625
 or ~1.5% of the 65535 possible `/16`s.

 If we think that our users are coming from significantly less than ~1.5%
 of the possible `/16`s, then we need to change this number. I'm fairly
 certain that, while there are rather large swaths of IP space not in use
 by general public end-users, I'm inclined to believe that the percentages
 aren't ''that'' low… but I that's just an intuition with little evidence
 to back it.

 However, if my intuition and assumptions are correct, we should end up
 with ''many'' multiple `/16`s mapped to the same set of bridges within a
 time period, meaning a more uniform distribution. I suspect that
 previously, there may have been positions within the hashrings which might
 have only been obtainable via requesting bridges without using Tor from
 any of the
 [https://cryptoanarchy.freed0m4all.net/wiki/Authority_Netblock_Blacklist
 many /8s and /16s assigned to the "DoD"], for example. Not that I think
 that the NSA whistleblowers on those networks ''shouldn't'' have bridges,
 but rather that I would assume their bridges should have sufficient
 unrelated cover traffic to decrease any potential success rate of
 correlation attacks. Or does this mean that I should be wanting to map
 `/16`s and sets of bridges 1:1 to avoid their colleagues conducting
 [https://blog.torproject.org/blog/research-problems-ten-ways-discover-tor-
 bridges the zig-zag attack you described in point #10 of your blog post]?
 Would it be safer to have a `/16` only have one set of bridges (or some
 sets uniquely assigned to it) for all the potential users in it?

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