Hi,
> On 4 Feb 2020, at 07:17, s7r <s7r@xxxxxxxxxx> wrote:
>
> teor wrote:
>> Hi s7r,
>>
>> Thanks for bringing up IPv6 address privacy extensions.
>>
>>> On 30 Jan 2020, at 02:19, s7r <s7r@xxxxxxxxxx> 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-28c992d72bedaa9378a4f3627afb8694R816
>
> 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/ca8dfa983ad78d67f68a6f0fff0a9dd90ec8c5f2
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/SupportedPlatforms
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
Attachment:
signature.asc
Description: Message signed with OpenPGP
_______________________________________________ tor-dev mailing list tor-dev@xxxxxxxxxxxxxxxxxxxx https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev