Re: [tor-dev] Lets give every circuit its own exit IP?

[grarpamp]

You may also be interested in
- newnym exit bucketing (in trac somewhere),
this guarantees cycling through all exits before reusing one
- openvpn exit termination (in tor-relays somewhere),
this gives non-tor IP to clients that initiate a termination
___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev

[tor-dev] Lets give every circuit its own exit IP?

[nusenu]

The unbearable situation with Google's reCAPTCHA
motivated this email (but it is not limited to this
specific case).
This idea came up when seeing a similar functionality
in unbound (which has it for a different reason).

Assumption: There are systems that block some tor exit 
IP addresses (most likely the bigger once), but they 
are not blocked due to the fact that they are tor exits. 
It just occurred that the IP got flagged 
because of "automated / malicious" requests and IP reputation
systems.

What if every circuit had its "own" IP
address at the exit relay to avoid causing collateral damage
to all users of the exit if one was bad? (until the exit runs out of IPs and
starts to recycle previously used IPs again)
The goal is to avoid accumulating a bad "reputation" for the
single used exit IP address that affects all tor users
of that exit. 

Instead of doing it on the circuit level you could do it
based on time. Change the exit IP every 5 minutes (but
do _not_ change the exit IPs for _existing_ circuits even if they
live longer than 5 minutes). 

Yes, no one has that many IPv4 addresses but with the 
increasing availability of IPv6 at exits and destinations,
this could be feasible to a certain extend, depending on
how many IPv6 addresses the exit operator has.
There are exit operators that have entire /48 IPv6 blocks. 


problems:
- will not solve anything since reputation will shift to netblocks as well
(How big of a netblock are you willing to block?)
- you can tell two tor users easily apart from each other
even if they use the same exit (or more generally: you can 
tell circuits apart). There might be all kinds of bad implications
that I'm not thinking off right now.
- check.tpo would no longer be feasible
- how can do we still provide the list of exit IPs for easy blocking?
Exits could signal their used netblock via their descriptor. What if they don't?
(that in turn opens new kinds of attacks where an exit claims to be /0 
and the target effectively blocks everything)
- more state to track and store at the exit
-...


some random thoughts,
nusenu



-- 
https://mastodon.social/@nusenu
twitter: @nusenu_



signature.asc
Description: OpenPGP digital signature
___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev

Re: [tor-dev] Is there strictly a one-to-one BW scanner to BW auth relationship?

[Rob Jansen]

> On Mar 25, 2018, at 12:13 PM, Sebastian Hahn  wrote:
> 
> 
>> On 24. Mar 2018, at 13:50, Rob Jansen  wrote:
>>> I think moria1 runs its own, and Faravahar runs its own. I've lost track
>>> of the others, but I'd guess that bastet also runs its own, and that
>>> maatuska pulls numbers from a bwauth that tjr runs.
>>> 
>>> https://consensus-health.torproject.org/#bwauthstatus
>> 
>> Hmm. I wish we were more transparent about who is running scanners and which 
>> bwauths consume results from which scanners. Something to keep in mind for 
>> those of us working on next-gen replacement scanners.
> 
> It is at the discretion of the bwauth operator to ensure that
> they're using a trusted source for their data. To me, that
> means anything other than running the code myself is utterly
> unacceptable, other operators might make other choices. I
> think it makes sense to say that the operator of a given bw
> auth is *responsible* for whatever they're voting on, whether
> they run the bwauth themselves or not.

I totally agree! Though, I do think that the decisions of which data sources 
are used could be made public - not as a means to call into question or 
criticize the choice of the data source, but more as a means to understand how 
the system works. Eventually (in an ideal world where the scanners report their 
status) the community could help monitor the health of the scanners. If this 
makes the job of a bwauth more difficult (we should design it so it doesn't), 
that should certainly be considered as well.

Best,
Rob


signature.asc
Description: Message signed with OpenPGP
___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev

Re: [tor-dev] Is there strictly a one-to-one BW scanner to BW auth relationship?

[Sebastian Hahn]

> On 24. Mar 2018, at 13:50, Rob Jansen  wrote:
>> I think moria1 runs its own, and Faravahar runs its own. I've lost track
>> of the others, but I'd guess that bastet also runs its own, and that
>> maatuska pulls numbers from a bwauth that tjr runs.
>> 
>> https://consensus-health.torproject.org/#bwauthstatus
> 
> Hmm. I wish we were more transparent about who is running scanners and which 
> bwauths consume results from which scanners. Something to keep in mind for 
> those of us working on next-gen replacement scanners.

It is at the discretion of the bwauth operator to ensure that
they're using a trusted source for their data. To me, that
means anything other than running the code myself is utterly
unacceptable, other operators might make other choices. I
think it makes sense to say that the operator of a given bw
auth is *responsible* for whatever they're voting on, whether
they run the bwauth themselves or not.

Cheers
Sebastian
___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev