Re: [tor-dev] [tor-relays] BitTorrent complaint

[grarpamp <grarpamp@xxxxxxxxx>]

Swiped from the 'BitTorrent complaint' thread over on relays...

> If an exit relay then drops that
> connection silently, Tor (and the user) cannot know it needs to select a
> different exit. The connections simply fail.
> ...
> What you do with that iptables rule (or similar rules) is block a bunch
> of URLs.

There may be room to take and work this capability further...

Instead of populating the directory with the actual exit policies, offload
this into a client poll of a set of live exits the client wishes to
queuing up for
rotation into for common ports, or even ports it's recently seen in use.
Plus a general random poll to ensure N number of exits are held
that will be able to service the full matrix of 65536 ports M-times redundantly,
sortof like tor_exitlist.py function.
Then like Tor transparent proxy to the host's packet filter, there can be a
way the exit can read, API, or be fed the host's current rules to
then be polled for it by the client. Plus an expected ruleset
lite/timeout value.
Users of custom policies would need to
use separate rule tables, interfaces, or be smart about about any sensitive
rule data if they care.
Directories would still carry all exits. But only predefined policies
efficiently marked by an 8 bit label.
0) non-exit 1) fully open 2) pollme 3) reduced 4) std set A 5) std set B, etc.
Client releases hold the policy label map, including revoked and
reserved label definitions. Or the map can be held in realtime dht or alikes.
_______________________________________________
tor-dev mailing list
tor-dev@xxxxxxxxxxxxxxxxxxxx
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev