Re: [tor-dev] Proposal 312: Automatic Relay IPv6 Addresses
Hi,
> On 4 Feb 2020, at 07:17, s7r wrote:
>
> teor wrote:
>> Hi s7r,
>>
>> Thanks for bringing up IPv6 address privacy extensions.
>>
>>> On 30 Jan 2020, at 02:19, s7r 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
Re: [tor-dev] Proposal 312: Automatic Relay IPv6 Addresses
Hi Nick, Thanks so much for your review! I've made most of the changes you've suggested, you can see the latest version of the proposal here: https://github.com/torproject/torspec/pull/105/files I've also made changes in response to s7r's feedback about IPv6 privacy extensions. Since sending the draft, I've also noticed some missing information, and some things that could be explained better. 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 There's some flexibility, particularly if we decide that an optional change is the fastest way to get something implemented. I'll send another full text to the list when all the reviews are done. I've also responded to your comments below individually: > On 31 Jan 2020, at 08:08, Nick Mathewson wrote: > > On Wed, Jan 29, 2020 at 9:04 AM teor wrote: > > Hello again! This looks like another fine proposal. I'm leaving > comments inline, and clipping sections that I'm not commenting on. > >> Filename: 312-relay-auto-ipv6-addr.txt >> Title: Tor Relays Automatically Find Their IPv6 Address >> Author: teor >> Created: 28-January-2020 >> Status: Draft >> Ticket: #33073 >> >> 0. Abstract >> >> We propose that Tor relays (and bridges) should automatically find their >> IPv6 address, and use it to publish an IPv6 ORPort. For some relays to find >> their IPv6 address, they may need to fetch some directory documents from >> directory authorities over IPv6. (For anonymity reasons, bridges are unable >> to fetch directory documents over IPv6, until clients start to do so.) >> >> 1. Introduction >> >> Tor relays (and bridges) currently find their IPv4 address, and use it as >> their ORPort and DirPort address when publishing their descriptor. But >> relays and bridges do not automatically find their IPv6 address. > > At the beginning of this document, we should be a bit more clear about > which address specifically we're trying to find. If we wanted _some_ > address, or if NAT and firewalls didn't exist, we could just open a > socket, call getsockname(), and be done with it. What we are looking > for specifically is an address that we can advertise to the rest of > the world in our server descriptor. [I know you know this, but we > should say so.] Thanks, that's a great reminder. I've explained how we use the detected IP addresses, and what kind of addresses we are looking for. I've left a detailed description of how we ignore private addresses, and use other methods, to later in the proposal. Please see this commit: https://github.com/torproject/torspec/pull/105/commits/dff29ec0424a31147c040a8d8b6724df4d2dfc25 > [...] >> 3. Finding Relay IPv6 Addresses >> >> We propose that tor relays (and bridges) automatically find their IPv6 >> address, and use it to publish an IPv6 ORPort. >> >> For some relays to find their IPv6 address, they may need to fetch some >> directory documents from directory authorities over IPv6. (For anonymity >> reasons, bridges are unable to fetch directory documents over IPv6, until >> clients start to do so.) >> >> 3.1. Current Relay IPv4 Address Implementation >> >> Currently, all relays (and bridges) must have an IPv4 address. IPv6 >> addresses are optional for relays. >> >> Tor currently tries to find relay IPv4 addresses in this order: >> 1. the Address torrc option >> 2. the address of the hostname (resolved using DNS, if needed) >> 3. a local interface address >>(by making a self-connected socket, if needed) >> 4. an address reported by a directory server (using X-Your-Address-Is) > > Any server, or only an authority? Over any connection, or only an > authenticated one? Thanks for picking up on this inconsistency. In the current implementation, when a tor relay doesn't know its address, it tried to fetch from directory authorities. But it will believe an addresses from any directory server. Relays try to use DirPorts, even if they don't know their own IP address. But if they select a directory mirror that only has an ORPort, they will use its ORPort. I've fixed this particular inconsistency in this commit: https://github.com/torproject/torspec/pull/105/commits/dff29ec0424a31147c040a8d8b6724df4d2dfc25 Ideally, relays should use authenticated directory authorities to discover their addresses. But it's not a simple change, because it affects directory authority load balancing. So I've put it in the "optional changes" section of the proposal. If we have time, we should make these changes, with high priority. For more details, see sections 3.5.1, 3.5.2, and 3.5.3 in: https://github.com/torproject/torspec/pull/105/files > [...] >>
Re: [tor-dev] Proposal 312: Automatic Relay IPv6 Addresses
On 02/04/2020 03:13 PM, s7r wrote: > These privacy extensions IPv6 addresses might be good for outbound bind > exit addresses (for Exit relays), and maybe (not sure) for regular > clients that could connect to their entry guards or bridges using a > temporary IPv6 address. Thanks. Those are the two situations I had in mind. > We only refer in this proposal to Tor in _relay mode_. That wasn't clear to me, and that's arguably my fault. ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
Re: [tor-dev] Proposal 312: Automatic Relay IPv6 Addresses
Mirimir wrote:
> On 02/03/2020 02:17 PM, s7r wrote:
>
>
>
>> 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.
>
> What's the downside of using "temporary" IPv6 addresses from privacy
> extensions?
>
> I mean, isn't better privacy a good thing?
>
>
Not really.
These privacy extensions IPv6 addresses might be good for outbound bind
exit addresses (for Exit relays), and maybe (not sure) for regular
clients that could connect to their entry guards or bridges using a
temporary IPv6 address.
We only refer in this proposal to Tor in _relay mode_. When in relay
mode, it is desirable to bind to a static IPv6 address that does not
change, so bandwidth authorities can measure its bandwidth and directory
authorities and maintain its history, uptime statistics and flags as
well as not upload descriptors too often that will make them unusuable
for clients that have an older consensus which is still valid, and so on.
Usually it is not desirable for a 'server' of any kind (Tor relay
included of course) to have an expiring / temporary / dynamic IP
address. It is the other way around actually.
So, we don't plan to throw poison on privacy extensions IPv6 addresses,
might actually use them for the purposes explained at the beginning of
this email, but in this particular case of Proposal 312 when we are
discussing automatic address discovery for *relays* they are bad for us
- we wouldn't want to code Tor to discovery and gladly use a temporary
IPv6 address that was designed to *not* be used in server mode.
signature.asc
Description: OpenPGP digital signature
___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
Re: [tor-dev] Proposal 312: Automatic Relay IPv6 Addresses
On 02/03/2020 02:17 PM, s7r wrote:
> 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.
What's the downside of using "temporary" IPv6 addresses from privacy
extensions?
I mean, isn't better privacy a good thing?
___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
Re: [tor-dev] Proposal 312: Automatic Relay IPv6 Addresses
Hi teor,
teor wrote:
> Hi s7r,
>
> Thanks for bringing up IPv6 address privacy extensions.
>
>> On 30 Jan 2020, at 02:19, s7r 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
signature.asc
Description: OpenPGP digital signature
___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
Re: [tor-dev] Proposal 312: Automatic Relay IPv6 Addresses
Hi s7r, Thanks for bringing up IPv6 address privacy extensions. > On 30 Jan 2020, at 02:19, s7r 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 signature.asc Description: Message signed with OpenPGP ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
Re: [tor-dev] Proposal 312: Automatic Relay IPv6 Addresses
On Wed, Jan 29, 2020 at 9:04 AM teor wrote: Hello again! This looks like another fine proposal. I'm leaving comments inline, and clipping sections that I'm not commenting on. > > Filename: 312-relay-auto-ipv6-addr.txt > Title: Tor Relays Automatically Find Their IPv6 Address > Author: teor > Created: 28-January-2020 > Status: Draft > Ticket: #33073 > > 0. Abstract > >We propose that Tor relays (and bridges) should automatically find their >IPv6 address, and use it to publish an IPv6 ORPort. For some relays to find >their IPv6 address, they may need to fetch some directory documents from >directory authorities over IPv6. (For anonymity reasons, bridges are unable >to fetch directory documents over IPv6, until clients start to do so.) > > 1. Introduction > >Tor relays (and bridges) currently find their IPv4 address, and use it as >their ORPort and DirPort address when publishing their descriptor. But >relays and bridges do not automatically find their IPv6 address. At the beginning of this document, we should be a bit more clear about which address specifically we're trying to find. If we wanted _some_ address, or if NAT and firewalls didn't exist, we could just open a socket, call getsockname(), and be done with it. What we are looking for specifically is an address that we can advertise to the rest of the world in our server descriptor. [I know you know this, but we should say so.] [...] > 3. Finding Relay IPv6 Addresses > >We propose that tor relays (and bridges) automatically find their IPv6 >address, and use it to publish an IPv6 ORPort. > >For some relays to find their IPv6 address, they may need to fetch some >directory documents from directory authorities over IPv6. (For anonymity >reasons, bridges are unable to fetch directory documents over IPv6, until >clients start to do so.) > > 3.1. Current Relay IPv4 Address Implementation > >Currently, all relays (and bridges) must have an IPv4 address. IPv6 >addresses are optional for relays. > >Tor currently tries to find relay IPv4 addresses in this order: > 1. the Address torrc option > 2. the address of the hostname (resolved using DNS, if needed) > 3. a local interface address > (by making a self-connected socket, if needed) > 4. an address reported by a directory server (using X-Your-Address-Is) Any server, or only an authority? Over any connection, or only an authenticated one? [...] > 3.2. Finding Relay IPv6 Addresses > >We propose that relays (and bridges) try to find their IPv6 address. For >consistency, we also propose to change the address resolution order for >IPv4 addresses. > >We use the following general principles to choose the order of IP address >methods: > * Explicit is better than Implicit, > * Local Information is better than a Remote Dependency, > * Trusted is better than Untrusted, and > * Reliable is better than Unreliable. >Within these constraints, we try to find the simplest working design. We should make sure to be clear about the impact of using an untrusted source. Anybody who can fool a relay about its IP can effectively MITM that relay's incoming connections (traffic patterns only), so using a non-trusted source can be risky for anonymity. [...] >(Each of these address resolution steps is described in more detail, in its >own subsection.) > >While making these changes, we want to preserve tor's existing behaviour: > * resolve Address using the local resolver, if needed, > * ignore private addresses on public tor networks, and > * when there are multiple valid addresses, choose the first or latest >address, as appropriate. Instead of "first or latest" I suggest "first-listed or most recently received" here, to help non-native speakers. > 3.2.1. Make the Address torrc Option Support IPv6 [...] >It is an error to configure an Address option with a private IPv4 or IPv6 >address, or with a hostname that does not resolve to any publicly routable >IPv4 or IPv6 addresses. We should say "on a public network" here -- private addresses are fine on private networks. Also, this seems to mean that if the relay's DNS resolver goes down, the relay should give an error and exit, even if it was already running. That seems undesired. [...] > 3.2.2. Use the Advertised ORPort IPv4 and IPv6 Addresses > >Next, we propose that relays (and bridges) use the first advertised ORPort >IPv4 and IPv6 addresses, as configured in their torrc. > >The ORPort address may be a hostname. If it is, tor should try to use it to >resolve an IPv4 and IPv6 address, and open ORPorts on the first available >IPv4 and IPv6 address. Tor should respect the IPv4Only and IPv6Only port >flags, if specified. (Tor currently resolves IPv4 addresses in ORPort >lines. It may not look for an IPv6 address.) > >Relays (and bridges) currently
Re: [tor-dev] Proposal 312: Automatic Relay IPv6 Addresses
Hi again, Apologies, a quick follow-up: 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: > Hi teor, > > Thanks for this epic work, some lecture for me to deeply go over this > weekend. > > 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? > signature.asc Description: OpenPGP digital signature ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
Re: [tor-dev] Proposal 312: Automatic Relay IPv6 Addresses
Hi teor, Thanks for this epic work, some lecture for me to deeply go over this weekend. 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? teor wrote: > Hi, > > Here is an initial draft of Proposal 312: Automatic Relay IPv6 Addresses. > > This proposal includes: > * relay auto IPv6 addresses, and > * relay auto IPv6 ORPorts. > > This is the second of 3 proposals: > * Proposal 311: Relay IPv6 Reachability > * Proposal 312: Automatic Relay IPv6 Addresses > * Proposal 313: Relay IPv6 Statistics > (I haven't written the final one yet.) > > I also want to make some minor changes to Proposal 306, so that bridge > IPv6 behaviour stays in sync with client IPv6 behaviour. (See section > 7 of this proposal for details.) > signature.asc Description: OpenPGP digital signature ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
