[tor-dev] Proposal 312: Automatic Relay IPv6 Addresses

[s7r]

Hi teor,

teor wrote:
> Hi s7r,
> 
> Thanks for bringing up IPv6 address privacy extensions.
> 
>> On 30 Jan 2020, at 02:19, s7r <s7r at 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-28c992d72bedaa9378a4f3627afb8694R816
> 
> (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

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 488 bytes
Desc: OpenPGP digital signature
URL: <http://lists.torproject.org/pipermail/tor-dev/attachments/20200203/84f5cbb4/attachment.sig>