[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_

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: OpenPGP digital signature
URL: <http://lists.torproject.org/pipermail/tor-dev/attachments/20180325/35a33c53/attachment.sig>