Hi teor,
teor wrote:
Hi s7r,
Thanks for bringing up IPv6 address privacy extensions.
On 30 Jan 2020, at 02:19, s7r s7r@sky-ip.org wrote:
I read RFCs 4941 and 3041, looked at the tor directory spec, and did some analysis:
- tor clients get new relay addresses within 4.5 hours
- IPv6 privacy extensions rotate addresses every day (by default)
- IPv6 privacy extensions remove old addresses after a week (by default)
(And applications have to opt-in to IPv6 privacy extensions addresses, by default, according to the RFC.)
Therefore, I don't think tor relays or clients will be affected by relays using IPv6 privacy extensions.
See my detailed analysis here: https://github.com/torproject/torspec/pull/105/files#diff-28c992d72bedaa9378...
(I still have to revise proposal 312 based on Nick's review, I hope to do that today or tomorrow.)
T
Thanks for looking into it!
I agree with your analysis fully. However, I just think it would be better if we mention in proposal 312 explicitly that Tor should try hard to get an IPv6 address that has the desired state, and use that. It is true that this is different on each operating system, but the operating systems we most care about should be pretty trivial to patch for this change.
IPv6 addresses have multiple states. We simply request for one that has state `public` and not `temporary`. (https://tools.ietf.org/html/rfc3484).
In the current form of this proposal, it looks kind of optional ("We propose this optional change, to improve..."). I propose removing the line which contains "this optional change" and changing the following:
In practice, each operating system has a different way of detecting IPv6 address privacy extensions. And some operating systems may not tell applications if a particular address is using privacy extensions. So implementing this change may be difficult.
to
In practice, each operating system has a different way of indicating if an IPv6 address comes from a privacy extension or not. Usually the operating system also returns the state of each available address: "public" - the ones that does not change, and which Tor should use "temporary" - the ones that come from privacy extensions Tor should always ask for and use a "public" IPv6 addresses to build relay descriptor.
Might not be the most explicit wording, but feel free to rephrase, we just need to make it clear that we will try as hard as possible to NOT use a temporary IPv6 address, and might only use one in small isolated cases where operating systems do not report to Tor properly the states of the available IPv6 addresses.
This shouldn't be too hard - apache and most properly coded server apps do not bind to temporary IPv6 addresses. Also, all the IPv6 related RFCs make it mandatory for server type applications (like Tor in relay mode) to request `public` IPv6 addresses, not `temporary` ones.
sbws of course should account relays per IPv6 prefix, and not per address. Usually we should be able to determine if an address is in the same /64 IPv6 subnet and not reset the bandwidth measurement because most probably it is the same relay. A /64 is standard, however there are ISPs that do now follow the standard in assigning /64 to end users and sometimes assign /112 or strange things like that. So this can become complicated again. Which is why it is more simple to always ask for a `public` IPv6 address and ignore `temporary` ones. I think it's simpler and more efficient than changing sbws.
##### NOT DIRECTLY RELATED TO PROPOSAL 312 SECTION ##### These privacy extensions IPv6 addresses might be good for outgoing IPv6 exit connections, like changing per circuit or per destination to get rid of captchas and blacklists, but this is something different.
Our internal DoS defense subsystem should also treat prefixes instead of addresses, because right now with a client with a /64 public IPv6 prefix assigned to it I could hammer via IPv6 guards without triggering the DoS defense. This is is something different as well.
From my point of view all these should go under the same big `Tor-IPv6` project, and get funded as well. So, there's quite some work ahead ;) ##### END OF NOT DIRECTLY RELATED TO PROPOSAL 312 SECTION #####
-s7r