[tor-bugs] #15517 [BridgeDB]: BridgeDB considers IPv6 clients in the same /64 to be "in the same subnet"

[Tor Bug Tracker & Wiki]

#15517: BridgeDB considers IPv6 clients in the same /64 to be "in the same subnet"
-----------------------------------------------+----------------------
 Reporter:  isis                               |          Owner:  isis
     Type:  defect                             |         Status:  new
 Priority:  critical                           |      Milestone:
Component:  BridgeDB                           |        Version:
 Keywords:  bridgedb-dist, bridge-enumeration  |  Actual Points:
Parent ID:                                     |         Points:
-----------------------------------------------+----------------------
 And an IPv6 `/48` is rather trivial to obtain.  When discussing this in
 the IRC channel, several people immediately spoke up to say that they have
 an IPv6 `/48` subnet, which is equivalent to 65535 `/64`s. The current
 code (from #4297 and
 [https://gitweb.torproject.org/user/isis/bridgedb.git/commit/?h=develop&id=3bee35c8d3977d0645bd57b8fc7bf4ef003538af
 this commit]) at `bridgedb.Dist.uniformMap()` would allow anyone with an
 `/48` to pretend to be a maximum of 65535 clients to BridgeDB (which would
 still allow them to request IPv4 bridges, as well as Pluggable Transport
 bridges, I might add) and obtain a maximum of 65535 unique positions
 within a distributor's hashring per period, allowing the bridges within
 most hashrings to be entirely enumerated within a matter of a few hours.

 As for fixing this bug, I planned to use (both for IPv4 and IPv6) whatever
 logic tor uses for the `EnforceDistinctSubnets` option. However, as it
 turns out, there may be a bug in that logic (#XXXXX) with respect to IPv6.

 I propose (from talking to people, and glancing at
 https://en.wikipedia.org/wiki/IPv6_subnetting_reference and
 https://www.arin.net/resources/request/ipv6_initial_assign.html) that
 BridgeDB switch to treating IPv6 `/32`s (the minimum ARIN allocation for
 an LIR) as distinct subnets, and treat clients within the same `/32` as
 coming from the same IP address.

 [This was discovered while working on #4771 and #1839.]

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