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

[teor]

Hi s7r,

Thanks for bringing up IPv6 address privacy extensions.

> On 30 Jan 2020, at 02:19, s7r <s7r at sky-ip.org> wrote:
> 
> There is another RFC (older), that is in use by Debian apparently:
> RFC3041. https://tools.ietf.org/rfc/rfc3041.txt
> 
> From:
> https://manpages.debian.org/buster/iproute2/ip-address.8.en.html
> see `mngtmpaddr`
> 
> RFC4941 is newer and with some improvements, however it does not mention
> its purpose is to update / deprecate RFC3041. Actually it mentions the
> differences / improvements.
> 
> Anyway, the point still fully stands, I just thought both RFCs should be
> mentioned. Bottom line still is temporary (expiring) but otherwise
> public and reachable IPv6 addresses in relay descriptor.
> 
> s7r wrote:
>> 
>> 
>> By briefly reviewing I've noticed something important is missing that
>> should be a part of this proposal.
>> 
>> I am not sure under which section it should go under. I guess `3.2.2.
>> Use the Advertised ORPort IPv4 and IPv6 Addresses`, or maybe it's
>> important enough that we should make its own section.
>> 
>> In IPv6, besides publicly routable and non-publicly routable addresses
>> (fe80:// etc.) which are documented in the proposal, we have temporary
>> IPv6 addresses coming from Privacy extensions or RFC4941 IPv6 addresses.
>> 
>> https://tools.ietf.org/rfc/rfc4941.txt
>> 
>> These addresses are publicly routable, they can appear as reachable from
>> the directory authorities or from directory data fetches, but they have
>> limited lifetime and change over time. I am not sure if one  such
>> address becomes deprecated if already in use (say by Tor), as the RFC
>> states MAY _if not in use by applications  or upper layers_:
>> 
>>   "As an optional optimization, an implementation MAY remove a
>>   deprecated temporary address that is not in use by applications or
>>   upper layers as detailed in Section 6."
>> 
>> But since this is implementation dependent, we cannot be sure about the
>> behavior across different platforms that relays might run on.
>> 
>> It is up to the operating system if such addresses are used or not. In
>> Debian they are disabled by default net.ipv6.conf.eth0.use_tempaddr=0
>> (unless some desktop packages that use network manager with different
>> settings change it). In Windows (at least Windows 10) apparently they
>> are enabled by default.
>> 
>> The question is, do we want such addresses in relay descriptors? I think
>> such addresses will behave similar to dynamic IPv4 addresses, or even
>> worse since these ones really change when they want, not just when we
>> disconnect and reconnect the network interface. So maybe Tor should
>> detect such behavior and log an error or something?
>> 
>> Actually I'll setup a vm this weekend and give it a native, static /64
>> IPv6 prefix, enable privacy extension to use temporary addresses and
>> spin up a Tor process on it. Then disconnect the internet a couple of
>> times and see how it behaves, how often it changes.
>> 
>> What do you think?

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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: Message signed with OpenPGP
URL: <http://lists.torproject.org/pipermail/tor-dev/attachments/20200203/0c57fa93/attachment.sig>