Opened 2 years ago

Last modified 8 weeks ago

#26646 assigned 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, outreachy-ipv6, tor-exit, ipv6, censorship
Cc: gk 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 (9)

comment:1 in reply to:  description Changed 2 years 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 14 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.

comment:3 Changed 3 months ago by niftybunny

I support this 100%.

comment:4 Changed 3 months ago by nusenu

I believe this feature request is becoming increasingly important
as more platforms (i.e. youtube) are more strictly blocking IPs with bad
reputation, this would be a crucial feature to make the internet more accessible
to Tor users.

Would it help to write a short proposal to move this forward?

Would there be someone to actually implement it?

According to nickm: "This wouldn't be too hard, actually."

teor, would you review and comment on a proposal if I would write one?

comment:5 Changed 3 months ago by gk

Cc: gk added

To answer nickm's "Is there demand?" question in #3847: yes, there definitely is.

comment:6 Changed 3 months ago by teor

Yes, a short proposal would be helpful.

I'd like to see a sketch of the design:

  • how are the ranges specified in the torrc
  • how does the exit decide when to use a new IP
  • how are the new IPs chosen from the range

And also a discussion of the risks:

  • clients use the same circuit and exit for the same website, because some broken websites expect the same user to have the same IP for different connections
    • do clients deliberately use the same exit through different circuits? I don't think so, but I'm not sure
  • some circuits can be distinguished, because they come from different IP addresses
  • does the new syntax also apply to outbound OR connections?
    • if relays use a different address to their published address for directory requests, authorities may refuse those requests
    • relays try to keep canonical connections open with other relays, and different addresses make them rotate connections faster

comment:7 Changed 3 months ago by teor

Keywords: outreachy-ipv6 added

comment:8 Changed 8 weeks ago by MrSquanchee

Owner: set to MrSquanchee
Status: newassigned

comment:9 Changed 8 weeks ago by teor

Owner: MrSquanchee deleted

We haven't selected a GSOC or Outreachy applicant yet.

To be fair to all applicants, we should only assign tickets to people who are actively working on that ticket.

Note: See TracTickets for help on using tickets.