[tor-bugs] #4631 [Core Tor/Tor]: Idea to make consensus voting more resistant

[Tor Bug Tracker & Wiki]

#4631: Idea to make consensus voting more resistant
-------------------------------------------------+-------------------------
 Reporter:  Sebastian                            |          Owner:  teor
     Type:  defect                               |         Status:
                                                 |  needs_review
 Priority:  Medium                               |      Milestone:  Tor:
                                                 |  0.4.4.x-final
Component:  Core Tor/Tor                         |        Version:
 Severity:  Normal                               |     Resolution:
 Keywords:  needs-dirauth-email needs-torspec-   |  Actual Points:  0.2
  update tor-dirauth robustness voting           |
Parent ID:  #33050                               |         Points:  0.5
 Reviewer:                                       |        Sponsor:
                                                 |  Sponsor55-can
-------------------------------------------------+-------------------------
Changes (by teor):

 * status:  assigned => needs_review
 * type:  enhancement => defect
 * actualpoints:   => 0.2


Old description:

> This is an idea how to improve the current situation, where sometimes a
> directory authority is slow to get its vote out to the other dirauths,
> and so the dirauths don't all have the same sets of votes. To simplify,
> I'm illustrating with an example of three dirauths:
>
> at :50, all dirauths make their vote and start uploading. auth1 and auth2
> get their vote to all auths, but auth3 doesn't. it cannot publish a vote
> to auth1 at all, and it takes more than 2.5 minutes to publish its vote
> to auth2. at :52:30, all auths try fetching the votes they're missing
> from the other auths, so auth1 asks auth2 for auth3's vote, and auth2
> asks auth1 for auth3's vote. auth3 asks nobody, and nobody asks auth3. At
> this point, neither auth1 nor auth2 have auth3's vote. auth3 now (at, for
> example, :53:30) succeeds publishing to auth2, so auth1 now has a vote
> from auth1 and auth2, auth2 and auth3 have a vote from auth1, auth2, and
> auth3. At :55 the auths try to make a consensus, but auth1 will end up
> with a different consensus than auth2 and auth3.
>
> My idea to make this less of a problem would be that only for two minutes
> will we accept a vote that gets pushed to us, and anything we get later
> than that is considered "too late" and will be dropped. At :52:30
> minutes, we still go ahead and try and fetch all votes from all the other
> authorities, and if they have a vote we will accept it. We repeat that
> fetching of all votes that we don't have at 53:00, 53:30, 54:00 and
> 54:30. That way, a delayed publication of the original vote will not
> cause this kind of split, where the dirauths have different opinions on
> who has voted, so only the dirauth that took more than 2 minutes to
> publish its descriptor to any of the other dirauths will be affected.
> There's still a race condition here, which is when a dirauth (within two
> minutes) only publishes to one other dirauth, and then that dirauth gets
> so slow it cannot get the vote to any of the other votes. But since it
> was fast enough to get the vote the first time, hopefully that's rather
> rare.
>
> Does this all sound viable? Am I overlooking something?

New description:

 This is an idea how to improve the current situation, where sometimes a
 directory authority is slow to get its vote out to the other dirauths, and
 so the dirauths don't all have the same sets of votes. To simplify, I'm
 illustrating with an example of three dirauths:

 at :50, all dirauths make their vote and start uploading. auth1 and auth2
 get their vote to all auths, but auth3 doesn't. it cannot publish a vote
 to auth1 at all, and it takes more than 2.5 minutes to publish its vote to
 auth2. at :52:30, all auths try fetching the votes they're missing from
 the other auths, so auth1 asks auth2 for auth3's vote, and auth2 asks
 auth1 for auth3's vote. auth3 asks nobody, and nobody asks auth3. At this
 point, neither auth1 nor auth2 have auth3's vote. auth3 now (at, for
 example, :53:30) succeeds publishing to auth2, so auth1 now has a vote
 from auth1 and auth2, auth2 and auth3 have a vote from auth1, auth2, and
 auth3. At :55 the auths try to make a consensus, but auth1 will end up
 with a different consensus than auth2 and auth3.

 My idea to make this less of a problem would be that only for two minutes
 will we accept a vote that gets pushed to us, and anything we get later
 than that is considered "too late" and will be dropped. At :52:30 minutes,
 we still go ahead and try and fetch all votes from all the other
 authorities, and if they have a vote we will accept it. We repeat that
 fetching of all votes that we don't have at 53:00, 53:30, 54:00 and 54:30.
 That way, a delayed publication of the original vote will not cause this
 kind of split, where the dirauths have different opinions on who has
 voted, so only the dirauth that took more than 2 minutes to publish its
 descriptor to any of the other dirauths will be affected. There's still a
 race condition here, which is when a dirauth (within two minutes) only
 publishes to one other dirauth, and then that dirauth gets so slow it
 cannot get the vote to any of the other votes. But since it was fast
 enough to get the vote the first time, hopefully that's rather rare.

 Does this all sound viable? Am I overlooking something?

 Update: This bug was introduced in Tor 0.2.0.5-alpha, with the v3
 authority voting code.

--

Comment:

 See my PR:
 * master: https://github.com/torproject/tor/pull/1747

 I don't think we should backport this change, it's medium-risk, and it's
 also very hard to test. We would need to get authorities under severe
 load, or with bad clock skew.

 That said, it resolves at least one common issue in chutney, so it is a
 definite improvement.

 I'll open a child ticket for the spec patch.

--
Ticket URL: <https://trac.torproject.org/projects/tor/ticket/4631#comment:18>
Tor Bug Tracker & Wiki <https://trac.torproject.org/>
The Tor Project: anonymity online