Hi,
On 4 Feb 2020, at 07:17, s7r s7r@sky-ip.org wrote:
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...
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).
I've made this change to the proposal, using similar wording to what you wrote in your previous email:
https://github.com/torproject/torspec/pull/105/commits/ca8dfa983ad78d67f68a6...
Here's why I didn't make it a mandatory change:
Tor supports address detection using DNS, and detection of the public address of any NAT box between tor and the internet. Therefore, the address tor publishes in its descriptor may not be on the local machine.
Here are the relevant address detection methods:
1. Address hostname 2. ORPort hostname (method 3 only uses local information) 4. auto hostname 5. auto dir header
Therefore, it's not possible for tor to reliably find out the IPv6 address privacy extensions status of these addresses.
(Some operators also use sandboxes that block the relevant APIs.)
In the current form of this proposal, it looks kind of optional ("We propose this optional change, to improve...").
IPv6 privacy extensions are an optional change for Sponsor 55.
Sponsor 55 covers relay IPv6 reachability checks, address auto-detection, and basic IPv6 statistics. It's a small sponsor, so we need to focus on the changes that are required to achieve these goals.
We'll choose which optional changes we implement and test, after all the required changes are implemented and tested.
As I wrote to Nick:
I'm trying to keep a clear distinction in this proposal, to keep the sponsor 55 scope manageable. So I am keeping different sections for:
- required changes: changes that we must make to achieve the objectives of sponsor 55
- optional changes: good ideas that we can implement if we have time left in sponsor 55, or in future IPv6 work
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.
I don't think we'll be back porting any code changes that make relays avoid IPv6 privacy extensions addresses.
Also, any IPv6 privacy extensions code probably won't work on all of our supported platforms: https://trac.torproject.org/projects/tor/wiki/org/teams/NetworkTeam/Supporte...
So sbws will have to support relays which use IPv6 privacy extensions.
(sbws changes are out of scope for Sponsor 55, but we're looking for other funding.)
##### 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.
Feel free to open a ticket for this feature.
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.
I opened a ticket for this security issue here: https://trac.torproject.org/projects/tor/ticket/33156
I've also cc'd David, so he can take a look at this DoS subsystem bug.
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 ;)
Yes, we're looking for funding for further IPv6 work. But we really need more IPv6 relays, before we can make any IPv6 changes on clients.
T