On 26 Sep 2016, at 05:43, René Mayrhofer rm@ins.jku.at wrote:
That is exactly what we have patched our local Tor node to do, although with a different (slightly hacky, so the patch will be an RFC type) approach by marking real exit traffic with a ToS flag to leave the decision of what to do with it to the next layer (in our setup Linux kernel based policy routing on the same host). There may be a much better approach do achieve this goal. I plan on writing up our setup (and the rationale behind it) along with the "works for me but is not ready for upstream inclusion" patch tomorrow.
I'm not sure if we want to tag Tor traffic with QoS values at Exits. Any tagging carries some degree of risk, because it makes traffic look more unique. I'm not sure how much of a risk QoS tagging represents.
Fully agreed. That is why - if this turns out to be the best approach - we would remove the QoS tag again before the packets leave the host (and only use it for local policy routing decisions).
I would prefer to add config options OutboundBindAddressOR and OutboundBindAddressExit, which would default to OutboundBindAddress when not set. (And could be specified twice, once for IPv4, and once for IPv6.)
The one concern I have about this is that Tor-over-Tor would stick out more, as it would look like Tor coming out the OutboundBindAddressExit IP. But we don't encourage Tor-over-Tor anyway.
I'd recommend a patch that modifies this section in connection_connect to use OutboundBindAddressOR and OutboundBindAddressExit, preferably with the Exit/OR/(all) and IPv4/IPv6 logic refactored into its own function.
if (!tor_addr_is_loopback(addr)) { const tor_addr_t *ext_addr = NULL; if (protocol_family == AF_INET && !tor_addr_is_null(&options->OutboundBindAddressIPv4_)) ext_addr = &options->OutboundBindAddressIPv4_; else if (protocol_family == AF_INET6 && !tor_addr_is_null(&options->OutboundBindAddressIPv6_)) ext_addr = &options->OutboundBindAddressIPv6_; if (ext_addr) { memset(&bind_addr_ss, 0, sizeof(bind_addr_ss)); bind_addr_len = tor_addr_to_sockaddr(ext_addr, 0, (struct sockaddr *) &bind_addr_ss, sizeof(bind_addr_ss)); if (bind_addr_len == 0) { log_warn(LD_NET, "Error converting OutboundBindAddress %s into sockaddr. " "Ignoring.", fmt_and_decorate_addr(ext_addr)); } else { bind_addr = (struct sockaddr *)&bind_addr_ss; } } }
<snip> > Binding to different IP addresses can also be used for filtering and > traffic redirection. Does having separate bind addresses for OR and Exit > traffic work for your use case? Yes, separate IP addresses for OutboundBindAddressOR (which we would set to our "incoming" interface address) and OutboundBindAddressExit (which we would set to our "outgoing" interface address) would work for our use case. One caveat is that we would then no longer have the mixing of relay and exit traffic (which overlaps e.g. on common ports like 80) on our outgoing interface/IP address. Without having analyzed it in detail, our gut feeling was that this mixing (if the QoS flag is removed) may actually be beneficial against traffic correlation attacks and/or filtering/scanning the exit traffic by upstream providers (because it would required DPI as the more costly version to distinguish e.g. Tor relay from HTTPS traffic). If this assumption is unwarranted and you don't see additional information leakage by separating relay and exit traffic by IP (and as mentioned, we have not thought about this systematically enough yet), then this patch would solve our issue.
I can't see it being too much of an issue. Tor does not attempt to defend against DPI of plain-text traffic.
And, as of 0.2.8, Tor clients will only ever make encrypted connections, even to fetch directory documents. This means that there will be very little unencrypted client traffic on port 80 by the time any patch like this is merged and appears on a lot of relays. (And it would only be useful to Exit operators with multiple IP addresses.)
I assume it would need additional changes to add the new OutboundBindAddressOR and OutboundBindAddressExit options to the config parser?
Yes. The config parser is table-driven, and populates a struct. You will need to add lines to the table and variables to the struct.
Reading the existing code for OutboundBindAddress should help, although it is a complex option, because it can be specified twice, and an IPv4 address is parsed to OutboundBindAddressIPv4_, but an IPv6 address is parsed to OutboundBindAddressIPv6_.
It would be best to refactor this parsing code, rather than duplicating it twice for the OutboundBindAddressOR and OutboundBindAddressExit options.
Tim
best regards, Rene
tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
T
-- Tim Wilson-Brown (teor)
teor2345 at gmail dot com PGP C855 6CED 5D90 A0C5 29F6 4D43 450C BA7F 968F 094B ricochet:ekmygaiu4rzgsk6n xmpp: teor at torproject dot org