Opened 3 years ago

Closed 3 years ago

#13296 closed defect (fixed)

Drop or replace turtles

Reported by: atagar Owned by:
Priority: High Milestone: Tor: 0.2.6.x-final
Component: Core Tor/Tor Version:
Severity: Keywords:
Cc: Sebastian, mikeperry, tom@… Actual Points:
Parent ID: Points:
Reviewer: Sponsor:

Description

It just crossed my mind that we don't have anything tracking this. Lets fix that.

Mike lacks either the time or interest in maintaining turtles. He'd like to hand it off to somebody, but the status quo is not ok. We have a directory authority that's so unmaintained I've given up even reporting problems with it any longer.

We need to do one of the following...

  1. Find a new maintainer for turtles.
  2. Replace turtles with another authority.
  3. Just drop it from the authority list.

Option 'c' is obviously the easiest, but I suspect we'd rather 'a' or 'b' to maintain the odd authority count.

This issue isn't of terribly great urgency, but it has persisted for the better part of a year so we should finally track and fix it.

Cheers! -Damian

Child Tickets

Change History (39)

comment:1 Changed 3 years ago by atagar

Oh, on a side note turtles is presently using Tor 0.2.5.1-alpha-dev...

https://atlas.torproject.org/#details/F397038ADC51336135E7B80BD99CA3844360292B

That's evidently too old to participate in making the consensus.

comment:2 Changed 3 years ago by nickm

  • Milestone set to Tor: 0.2.6.x-final
  • Priority changed from normal to major

comment:3 Changed 3 years ago by Sebastian

  • Cc Sebastian added

I have started the discussion amongst dirauth operators, hopefully.

comment:4 follow-up: Changed 3 years ago by ioerror

I think we should ask for specific properties in a dir auth system and specific properties in a dir auth operator. Mike is someone that we trust very strongly and we must not disregard this aspect of his dir auth.

We should ask for specific properties from each operator - for example we - the community - want:

  1. A person that is trusted by the tor community
  2. A person who wants to run a dir auth
  3. A server on a fast connection with a very friendly ISP
  4. 99.999% up time
  5. Always running git tip or a recommended version
  6. We want a response to emails to dir-auth@ within 14 calendar days
  7. We want emergency contact information for each operator
  8. To know about planned downtime in advance
  9. To keep important data up to date (such as measurements, etc)
  10. ???

There is probably more - how would we rate the current set and not just Turtles? What other properties do we want or need?

Given the above list, urras is OK on all points except point 9. Is that true for all people who run dir-auths?

I think that if we remove turtles, we should add another dir-auth. If we don't do that, I think it is fine to leave his non-functioning dir-auth in the mix for everything except bootstrapping.

comment:5 Changed 3 years ago by toralf

to reach "99.999% up time" you'd need KSplice or an alternative method to keep the Linux kernel up to date.

comment:6 in reply to: ↑ 4 Changed 3 years ago by arma

Replying to ioerror:

We should ask for specific properties from each operator - for example we - the community - want:

For the original (I think mostly still valid) list, there is:
https://gitweb.torproject.org/torspec.git/blob/HEAD:/attic/authority-policy.txt

I think that if we remove turtles, we should add another dir-auth. If we don't do that, I think it is fine to leave his non-functioning dir-auth in the mix for everything except bootstrapping.

Sounds plausible to me. Having 8 vs having 9 with one always down is basically the same, from a consensus perspective. But you're right that it's not the same from a client bootstrapping perspective. It sure would be nice to get the FallbackDir feature going by default.

comment:7 follow-up: Changed 3 years ago by micah

At one point we discussed the overall imbalance of DirAuths in North America and Europe. This disproportionate number in a particular network geography results in heavier weighting for exits that are measured by those DirAuths as having good network connectivity. Those DirAuths will favor exits that are closer to them as having "better" bandwidth, than those far away. As an example, I had an exit in Cambodia that was on a 100mbit/sec connection, but because the DirAuths were so far away their measurements resulted in that exit being weighted much lower and thus the amount of traffic it served was significantly less than it could do (something like 2-5mbit/sec). This seems less than ideal, especially if we want to increase the usability of tor in areas of the world other than N. America/Europe.

I think having specific DirAuth criteria are important, but developing an overall strategy for strategic placement seems important as well. As the authority-policy that arma details, "It's good when authorities are not all in the same country." - I'd argue that this should be expanded beyond nation/state boundaries and consider network geography as a criteria as well.

On another note, I think that Riseup could offer to host a DirAuth, either in Hong Kong, possibly in Cambodia, or in Seattle.

comment:8 in reply to: ↑ 7 ; follow-up: Changed 3 years ago by arma

Replying to micah:

At one point we discussed the overall imbalance of DirAuths in North America and Europe. This disproportionate number in a particular network geography results in heavier weighting for exits that are measured by those DirAuths as having good network connectivity. Those DirAuths will favor exits that are closer to them as having "better" bandwidth, than those far away.

I agree with the sentiment here -- but I'll also note that Micah is referring to bandwidth authorities, which can be run next to directory authorities but don't have to be. That is, the bwauths are just scripts that can be run from anywhere, and they output a bwscan.V3BandwidthsFile file that a directory authority can use to influence its votes. So location diversity for the dir auths, and location diversity for the bwauths, are both fine goals but they can be achieved separately.

On another note, I think that Riseup could offer to host a DirAuth, either in Hong Kong, possibly in Cambodia, or in Seattle.

Intriguing! This idea would work best if it's run by a specific person (or small group of persons) that we know, that have come to a few dev meetings and met all the Tor people, etc.

comment:9 in reply to: ↑ 8 Changed 3 years ago by micah

Replying to arma:

Replying to micah:

I agree with the sentiment here -- but I'll also note that Micah is referring to bandwidth authorities, which can be run next to directory authorities but don't have to be. That is, the bwauths are just scripts that can be run from anywhere, and they output a bwscan.V3BandwidthsFile file that a directory authority can use to influence its votes. So location diversity for the dir auths, and location diversity for the bwauths, are both fine goals but they can be achieved separately.

Good point! I indeed was talking about bwauths, when this issue is about dir auths... apologies for the mixup.

On another note, I think that Riseup could offer to host a DirAuth, either in Hong Kong, possibly in Cambodia, or in Seattle.

Intriguing! This idea would work best if it's run by a specific person (or small group of persons) that we know, that have come to a few dev meetings and met all the Tor people, etc.

It would be primarily run by me, like all the other Tor-related things that Riseup does. Although I've never been to a dev meeting, I have met quite a few of the Tor people.

comment:10 Changed 3 years ago by Sebastian

The whole bwauth and exit measuring thing is completely brittle, and I don't think the relay in Cambodia will necessarily score much better just because a bwauth is located in Cambodia. The bwauth voting code uses the low median for its result, so nothing much will change. The other point is that the huge majority of relays is located in NA/Europe, so whenever you make an actual circuit through a node which isn't you'll get a slower result. Also, are we actually asking exits to fetch the bwauth files directly? I thought we used all nodes as middle node to avoid trivial cheating by increasing priority for bwauth traffic, but I'm not certain on this point.

comment:11 Changed 3 years ago by Sebastian

Erm. That said, turtles continues to be nonfunctional. If we could replace it, even with a dirauth in the US, we should do it asap.

comment:12 Changed 3 years ago by ioerror

I'd like to second Micah's offer to run a DirAuth. He is well known and great all around. His services with RiseUp are well run - he is one of the best SysAdmins that I've ever met (after weasel).

Micah - I'd love it if you could run your DirAuth in Asia - either in Hong Kong or elsewhere. I'd even donate some money to help make sure that the host has equipment for various kinds of protection.

Roger - what are the next steps for Micah to run a DirAuth?

comment:13 follow-up: Changed 3 years ago by micah

It seems, from the discussion above, that for a DirAuth it doesn't seem like putting it in Asia provides any additional benefit than anywhere else. If that is true, and a DirAuth is not that bandwidth intensive, I'd be more comfortable with running it in Seattle where we have more physical control, and would love to talk to ioerrror about additional protection equipment!

Can you provide me with details about the configuration, and bandwidth requirements that would be needed?

comment:14 follow-ups: Changed 3 years ago by micah

I've put the relay 'longclaw' online in Hong Kong, it can be found at:

https://atlas.torproject.org/#details/74A910646BCEEFBCD2E874FC1DC997430F968145

(a longclaw is a member of the Motacillidae family of small passerine birds with medium to long tails: https://en.wikipedia.org/wiki/Longclaw)

comment:15 in reply to: ↑ 13 ; follow-up: Changed 3 years ago by ioerror

Replying to micah:

It seems, from the discussion above, that for a DirAuth it doesn't seem like putting it in Asia provides any additional benefit than anywhere else.

Please put it in Asia - this will allow clients to bootstrap entirely from a node outside of the EU and US networks. This is important! It would also be nice to see the BW measurement running near the DirAuth. We need some actual diversity!

If that is true, and a DirAuth is not that bandwidth intensive, I'd be more comfortable with running it in Seattle where we have more physical control, and would love to talk to ioerrror about additional protection equipment!

I'm a big fan of mercury switches, hidden cameras and some other stuff. :)

Can you provide me with details about the configuration, and bandwidth requirements that would be needed?

We have git repo with dirauth configs. First up - your relay should stay up for a while and be stable. After it has been running for a while, I'd propose you write a patch to config.c (see previous diffs) and then Roger or someone else will merge it if/when they feel you meet the criteria.

comment:16 Changed 3 years ago by micah

What version should I run?

I notice that 'moria' runs an alpha, and 'tor26' runs an RC:

https://atlas.torproject.org/#details/9695DFC35FFEB861329B9F1AB04C46397020CE31
https://atlas.torproject.org/#details/847B1F850344D7876491A54892F904934E4EB85D

Should I use the one provided by:

http://deb.torproject.org/torproject.org tor-experimental-0.2.5.x-<DISTRIBUTION> main

?

comment:17 in reply to: ↑ 15 Changed 3 years ago by micah

Replying to ioerror:

Replying to micah:

It seems, from the discussion above, that for a DirAuth it doesn't seem like putting it in Asia provides any additional benefit than anywhere else.

Please put it in Asia - this will allow clients to bootstrap entirely from a node outside of the EU and US networks. This is important! It would also be nice to see the BW measurement running near the DirAuth. We need some actual diversity!

Ok, I'll focus on the DirAuth here, and take the BWAuth separately.

Can you provide me with details about the configuration, and bandwidth requirements that would be needed?

We have git repo with dirauth configs.

Can you provide me the URI for the git repo?

comment:18 Changed 3 years ago by micah

Just as an update - I've got the BWAuth setup, and it has successfully ran long enough to measure >60% of the network. I also have the ldap account and the DirAuth repository checked out.

comment:19 Changed 3 years ago by micah

I've made the necessary changes to config.c to resolve this issue, they are available in branch bug/13296 from here:

https://git.torproject.org/user/hacim/tor.git

There are two commits in this branch:

  1. adds longclaw as a v3 directory authority
  2. removal of turtles as a v3 directory authority

note that these commits are signed, so you can verify that they are actually from me, and that I am the one who controls the authkey to generate the certificate. You can verify the signatures by doing git log --show-signature, or individually as:

git show --show-signature 9c60ad5ed44a3809b7ff34ec38a31b0f626249a2
git show --show-signature efca0668bec8d043408e23cf93274d9a9b93ca35

Once these are merged in, I'll work with Sebastian to coordinate with the dirauth ops.

comment:20 Changed 3 years ago by micah

I've done the same commits on top of 0.2.4 as well, they can be found in my branch called 0.2.4/bug/13296, the commits are also signed:

git show --show-signature 1fcbb900a7b6fa0b4f9d2134025c84203a7f5244
git show --show-signature ffbb7e8cefe09225f088f0dd47be091c2077acd2

comment:21 Changed 3 years ago by Sebastian

  • Status changed from new to needs_review

comment:22 Changed 3 years ago by Sebastian

Please also see the mail I sent wrt the necessary coordination amongst dirauth ops for a timeframe.

comment:23 Changed 3 years ago by ioerror

Please do not remove Mike's DirAuth without him making the commit to remove it and without him talking here. It is absurd that he hasn't replied but it is also absurd that we'd remove it without him commenting here. It seems absurd to do this and replace it with a new relay at the same time.

Let us just add Micah's new DirAuth and *not* remove Turtles at this time.

comment:24 Changed 3 years ago by Sebastian

Strongly disagree. Adding a 10th dirauth makes voting more fragile, without any need. I'm happy to delay everything until Mike has said his final goodbyes to turtles, but we should not add longclaw before turtles is gone.

comment:25 Changed 3 years ago by micah

  • Cc mikeperry added

comment:26 follow-up: Changed 3 years ago by mikeperry

I fully support transitioning my directory authority to Micah. I am willing to ensure it does not come back up after we add Micah's node, or keep it up for older clients, or however we want to do this.

I am not sure we buy a whole lot by ensuring the node is in Asia.. I'd be happier if we had better physical security for it, but I'm not sure I feel so strongly about this that it is worth arguing.

comment:27 in reply to: ↑ 14 Changed 3 years ago by ln5

Replying to micah:

I've put the relay 'longclaw' online in Hong Kong, it can be found at:

Did you avoid a DNS PTR on purpose? I think that having one adds to the transparency of the host and its service.

comment:28 in reply to: ↑ 14 Changed 3 years ago by ln5

Replying to micah:

I've put the relay 'longclaw' online in Hong Kong, it can be found at:

Does the host have IPv6 connectivity? If so, please add another ORPort with the IPv6 address within square brackets (leaving the port number and the ':' outside of the brackets). Here's how maatuska configure IPv6:

ORPort [2001:67c:289c::9]:80

comment:29 Changed 3 years ago by tom

  • Cc tom@… added

comment:30 Changed 3 years ago by atagar

Updated Stem, so by extension DocTor is now tracking longclaw rather than turtles.

comment:31 Changed 3 years ago by tom

The new consensus-health codebase is using tip-of-stem. I'm not sure when the consensus-health.torproject.org webpage will be cut over, but the new codebase is running and viewable at http://utternoncesense.com/ and includes longclaw. (It is omitted from the top 'Signatures' section because it lacks the Authority flag, and therefore it's signature is not included in the consensus.)

comment:32 Changed 3 years ago by nickm

Patch looks good; will merge when the switch-over happens. But could somebody please write a changes file for this?

comment:33 Changed 3 years ago by nickm

(actually, if it's happening tomorrow, I might merge earlier... if a changes file exists.)

comment:34 Changed 3 years ago by Sebastian

bug13926 in my repo.

comment:35 Changed 3 years ago by arma

I think merging anytime is fine.

It won't hurt users much, because they'll swap out a dir auth that isn't up for a dir auth that isn't signing the current consensus.

And authority operators are hopefully now paying attention to when and whether they should upgrade, and having them just be able to move to git if that's easy for them will be a plus.

comment:36 in reply to: ↑ 26 Changed 3 years ago by arma

Replying to mikeperry:

I am willing to [...] keep it up for older clients, or however we want to do this.

Mike: I think the right answer here is to keep it up at the old address, with the old relay identity key, and not configured as a directory authority. That way it'll be a nice dir cache and provide answers to clients that happen to try to bootstrap from it.

comment:37 follow-up: Changed 3 years ago by nickm

I've cherry-picked those three commits to maint-0.2.4. (They seem to have been against release-0.2.4, which is not what we do: see doc/HACKING.)

comment:38 in reply to: ↑ 37 Changed 3 years ago by micah

Replying to nickm:

I've cherry-picked those three commits to maint-0.2.4. (They seem to have been against release-0.2.4, which is not what we do: see doc/HACKING.)

Ok, sorry about that. I made the originals on top of the original master, didn't realize about the other branch, thanks for pointing me to the doc/HACKING.

comment:39 Changed 3 years ago by Sebastian

  • Resolution set to fixed
  • Status changed from needs_review to closed

Thanks all.

Note: See TracTickets for help on using tickets.