Introduce OutboundExitAddress to enable exit-only traffic to go via a different IP address
There are use cases of Tor where the inbound IP address of the Tor Relay is not the Tor Relay traffic, that's managed trough the use of OutBoundBindAddress directive.
However in multi-homed environments, it could provide much more flexibility to be able to specify a specific IP address to be used only for Tor Exit Traffic, with a directive that could be "OutboundExitAddress" .
With such an approach a family of Tor Nodes, handling inbound/outbound OR traffic, could implement custom routing architecture only for Tor Exit traffic (that's the one generating abuses), by tunnelling it across more "abuse resilient servers" .
If the assumption that 66.66% of traffic is non-exit OR traffic (i'm dividing by 3), then only 33.33% would go trough a more resilient "Exit Gateway" that could also not be at all a Tor Relay.
If such information would stay in the Consensus, it would be possible to map which Tor Relay is explicitly doing that kind "asymmetric routing" vs. who's doing it "implicitly" (and thus, it maybe a pattern of suspicious activity) .
Activity
changed milestone to %Tor: 0.3.0.x-final
This has been implemented in: https://lists.torproject.org/pipermail/tor-dev/2016-October/011585.html
But needs review.
Trac:
Milestone: Tor: 0.2.??? to Tor: 0.3.0.x-final
Status: new to needs_review
Notes:
-
Changes file should mention the ticket number.
-
Commit message should mention the author.
-
parse_outbound_addresses has gotten really complicated, and full of duplicate code. Maybe it's possible to refactor it to be cleaner? This "adr_found[i]" stuff is fairly inelegant.
-
Would it make more sense to have the syntax be "OutboundBindAddress Exit 1.2.3.4" ?
-
conn_get_outbound_address falls back to the Exit address when the OR address is null. That doesn't make sense to me. Why did the user say OutboundBindAddressExit if they meant OutboundBindAddress?
-
Other outbound connection types are possible. For example, directory connections, DNS lookups, and local connections to hidden services. Should those get handled too? Should they get treated as if they were exit?
Trac:
Status: needs_review to needs_revision-
Replying to nickm:
Notes: ...
- conn_get_outbound_address falls back to the Exit address when the OR address is null. That doesn't make sense to me. Why did the user say OutboundBindAddressExit if they meant OutboundBindAddress?
+1
- Other outbound connection types are possible. For example, directory connections, DNS lookups, and local connections to hidden services. Should those get handled too? Should they get treated as if they were exit?
I would say: Directory -> OR DNS -> Exit HS (non-localhost) -> Exit????
-
parse_outbound_address is complicated, because it is complex. All cases are different. There is the (old) general option affecting both OR and exit traffic, as well as the separation between IPv4 and IPv6 and the random sequence any of these options may appear. Therefore I don't think factoring out is really going to be useful (e.g. checking for no duplicate settings and providing helpful error messages while checking for one/two conflicting options). The "adr_found" array could be changed to a two-dimensional array with constants as index (OR, EXIT; IPv4, IPv6) - this would render it extensions easier.
-
conn_get_outbound_address falls back to the exit address if OR is null, because the user explicitly specified something, so this should be honored (better something than nothing). But it can also be left to the default address.
-
Other outbound connection types: the following seem to exist: #define CONN_TYPE_OR_LISTENER 3 #define CONN_TYPE_OR 4 These are relay connections, so should not be sent over the "exit" interface
#define CONN_TYPE_EXIT 5 Actual exit connection, should use the "exit" interface
#define CONN_TYPE_AP_LISTENER 6 #define CONN_TYPE_AP 7 Socks proxy connections. This is "input" and should therefore not use the "exit" interface.
#define CONN_TYPE_DIR_LISTENER 8 #define CONN_TYPE_DIR 9 Directory server, i.e. internal communication going into this or another node. It should not use the "exit" interface.
#define CONN_TYPE_CONTROL_LISTENER 11 #define CONN_TYPE_CONTROL 12 Connection to a user interface - should be locally only and is definitely not "exit" traffic.
#define CONN_TYPE_AP_TRANS_LISTENER 13 #define CONN_TYPE_AP_NATD_LISTENER 14 Traffic redirected into tor, so incoming connections and should not use the "exit" interface.
#define CONN_TYPE_AP_DNS_LISTENER 15 Listen for DNS requests from clients; like SOCKS so no exit traffic.
#define CONN_TYPE_EXT_OR 16 #define CONN_TYPE_EXT_OR_LISTENER 17 Relay connections, should not be sent over the "exit" interface
- DNS request nameservers seem to be configured in or/dns.c:1355 (configure_nameservers). However, in my configuration I could not find any position where HAVE_EVDNS_SET_DEFAULT_OUTGOING_BIND_ADDRESS is set/defined (remnant of old library?). Generally: DNS requests are problematic. The local host or some internal server might be used for DNS resolving. Then another option for configuring DNS would be necessary, as these may not be reachable from the "exit" interface.
Trac:
Username: michaelsonntag-
-
Trac:
Username: michaelsonntag 
I can't apply this patch on 0.2.8.8 (which is specifically made for that version). Can you resubmit it to either upstream master or not depending on a specific directory name (
tor-0.2.8.8/) ?patch: **** malformed patch at line 209: diff --git a/tor-0.2.8.8/src/or/connection.c b/tor-0.2.8.8_new/src/or/connection.cTrac:
Status: needs_review to needs_revision
