Changes between Initial Version and Version 1 of Ticket #15517


Ignore:
Timestamp:
Mar 31, 2015, 12:53:01 AM (4 years ago)
Author:
isis
Comment:

Legend:

Unmodified
Added
Removed
Modified
  • Ticket #15517

    • Property Keywords ipv6 added
  • Ticket #15517 – Description

    initial v1  
    11And 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.
    22
    3 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.
     3As 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.
    44
    55I 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.