[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:           |  Milestone:
  critical               |    Version:
    Component:           |   Keywords:  bridgedb-dist, bridge-enumeration,
  BridgeDB               |  ipv6
   Resolution:           |  Parent ID:
Actual Points:           |
       Points:           |
-------------------------+-------------------------------------------------
Changes (by isis):

 * keywords:  bridgedb-dist, bridge-enumeration => bridgedb-dist, bridge-
     enumeration, ipv6


Old description:

> 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.]

New description:

 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 (#15518) 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#comment:1>
Tor Bug Tracker & Wiki <https://trac.torproject.org/>
The Tor Project: anonymity online