add support for multiple OutboundBindAddressExit IP(ranges)

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

changed milestone to %Tor: unspecified in legacy/trac

added censorship in Legacy / Trac component::core tor/tor in Legacy / Trac ipv6 in Legacy / Trac milestone::Tor: unspecified in Legacy / Trac needs-proposal in Legacy / Trac outreachy-ipv6 in Legacy / Trac priority::medium in Legacy / Trac severity::normal in Legacy / Trac status::assigned in Legacy / Trac tor-exit in Legacy / Trac type::enhancement in Legacy / Trac labels

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

Trac:
Milestone: N/A to Tor: unspecified
Keywords: N/A deleted, tor-exit, censorship, needs-proposal, ipv6 added

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.

I support this 100%.

Trac:
Username: niftybunny

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?

To answer nickm's "Is there demand?" question in legacy/trac#3847 (moved): yes, there definitely is.

Trac:
Cc: N/A to gk

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

Trac:
Keywords: N/A deleted, outreachy-ipv6 added

Trac:
Status: new to assigned
Owner: N/A to MrSquanchee

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.

Trac:
Owner: MrSquanchee to N/A

moved from legacy/trac#26646 (moved)

added Feature label and removed 1 deleted label

added IPv6 Needs Proposal labels and removed 1 deleted label

removed Needs Proposal label

mentioned in issue #29339 (closed)

removed milestone

Started to try to add this feature. Added a PoC patch for IPv4 outbound ranges.

how are the ranges specified in the torrc

For testing, I added two new option:

OutboundBindAddressRangeBegin

OutboundBindAddressRangeEnd

how are the new IPs chosen from the range

In this test, I choose them randomly from the range. But perhaps it could give clients with TrackHostsExpire unexpected results.

OutboundBindAddress.patch

added Needs Review label

mentioned in issue #40676 (closed)

The lack of this feature (no support for multiple IPs for OutboundBindAddressExit) causes our exits to run out of free source ports because more than 65k outbound connections are established.

Our logs get flooded with:

Error binding network socket: Address already in use

and the service for tor users is severely degraded.

Please add support for multiple IPs to OutboundBindAddressExit.

@cypherpunks What you really need is !579 (merged)

Do you need to require different IP for OutboundBindAddressExit and OutboundBindAddress? If not, you could give a try to my patch.

Because while OutboundBindAddressExit is not set explicitly, it will be use OutboundBindAddress for exiting.

Not using OutboundBindAddressExit would make it worse because that would mean that all exits on the server will use the same default source IP.

Yes, in vanilla tor.

OutboundBindAddressExit overrides OutboundBindAddress

My patch allows to bind outbound connections randomly to multiple interfaces, by IPv4, if in range.

added Icebox label

removed Icebox label

mentioned in issue #40194 (closed)

@pseudonymisaTor could you do this patch as an MR with a changes file? I think we would need v6 support as well before it can be included though?

changed milestone to %Tor: 0.4.8.x-freeze

added Relay Ops Community Request label

assigned to @ahf

removed milestone %Tor: 0.4.8.x-freeze

added Backlog label

changed milestone to %Tor: 0.4.9.x-freeze

This may still be needed before Arti Relays.