Opened 16 months ago

Last modified 6 months ago

#26646 new enhancement

add support for multiple OutboundBindAddressExit IP(ranges)

Reported by: nusenu Owned by:
Priority: Medium Milestone: Tor: unspecified
Component: Core Tor/Tor Version:
Severity: Normal Keywords: needs-proposal, tor-exit, ipv6, censorship
Cc: Actual Points:
Parent ID: Points:
Reviewer: Sponsor:

Description

tor has support for dedicated outbound IP addresses
for on exit relays via OutboundBindAddressExit.
This parameter supports only a single IPv4 and a single IPv6 address.

I propose to add an extension of this feature to support IPv4 and IPv6
ranges/prefixes.

The idea is to assign an IP address to each tor circuit. The exit IP
address must never change during the lifetime of the circuit.

Exit IP addresses would be randomly assigned to circuits. Once
the exit runs out of IPs it cycles through his pool of IPs again.
With IPv6 address space availability this can take a long time
with IPv4 it will be limited.

This aims to reduce the negative impact of few "bad" users on many "good"
users since they will not share the same IP address on the exit.

This might also have some negative? side effect since
it demultiplexes tor clients to multiple source IPs on the exit
and an external observer (not running the exit itself)
can tell clients apart by looking at source IPs.

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

https://lists.torproject.org/pipermail/tor-dev/2018-March/013036.html

Child Tickets

TicketTypeStatusOwnerSummary
#3847enhancementclosedProvide ability to round robin outgoing exit connections on multiple interfaces

Change History (2)

comment:1 in reply to:  description Changed 16 months ago by teor

Keywords: needs-proposal tor-exit ipv6 censorship added
Milestone: Tor: unspecified

Replying to nusenu:

tor has support for dedicated outbound IP addresses
for on exit relays via OutboundBindAddressExit.
This parameter supports only a single IPv4 and a single IPv6 address.

I propose to add an extension of this feature to support IPv4 and IPv6
ranges/prefixes.

Ideally, operators should be able to specify mutliple OutboundBindAddress options, with masks.

The idea is to assign an IP address to each tor circuit. The exit IP
address must never change during the lifetime of the circuit.

Exit IP addresses would be randomly assigned to circuits. Once
the exit runs out of IPs it cycles through his pool of IPs again.

Non-replacement is complicated, and has some nasty failure modes.
Instead, just choose an address at random.

With IPv6 address space availability this can take a long time
with IPv4 it will be limited.

This aims to reduce the negative impact of few "bad" users on many "good"
users since they will not share the same IP address on the exit.

This might also have some negative? side effect since
it demultiplexes tor clients to multiple source IPs on the exit
and an external observer (not running the exit itself)
can tell clients apart by looking at source IPs.

Perhaps we could limit the number of source IPs with a consensus parameter?

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

I don't know which design is better: changing the exit IP address based on time makes old circuits easier to identify. If we do use time, I suggest we use 10 minutes, because it's the default circuit rotation time.

https://lists.torproject.org/pipermail/tor-dev/2018-March/013036.html

This feature is complicated enough that it needs a (short) proposal:
https://gitweb.torproject.org/torspec.git/tree/proposals/001-process.txt

comment:2 Changed 6 months ago by cypherpunks

it would make high capacity relays more stable and reliable. i suggest for "least connection" algo instead round robin circuits across different outgoing interfaces.
2nd sounds like TrackHostsExpire for outgoing Exit connections.

Note: See TracTickets for help on using tickets.