Opened 5 years ago

Last modified 22 months ago

#10968 new task

Authorities should use past consensuses to decide how to vote on relay flags

Reported by: asn Owned by:
Priority: Medium Milestone: Tor: unspecified
Component: Core Tor/Tor Version:
Severity: Normal Keywords: tor-dirauth needs-design reliability
Cc: Actual Points:
Parent ID: Points:
Reviewer: Sponsor:

Description

At the moment, each authority decides what flags to assign to each node based on its own memory. This means that authorities that have been started recently have a different impression -- compared to more long-lived authorities -- about some relays .

Something that might make more sense is if authorities used past consensuses to get a better idea about the stability and speed of relays.

Since authorities don't keep past consensuses around, a way to do the above might be to create a script that each authority runs, downloads the past consensuses, calculates statistics about all nodes, and then it creates a file with those statistics. Then the authority loads that file, and uses it to update its knowledge base.

There might be better approaches.

Child Tickets

Change History (14)

comment:1 Changed 5 years ago by asn

Karsten points out that it might make sense to use past votes instead of pastt consensuses here. The idea is that each auth bases its opinion on its previous opinions, and not on previous group opinions.

Another question is, if only a subset of auths run this script, should that subset be the only group that expresses opinions on relay flags?

comment:2 Changed 5 years ago by karsten

Another random note: the external script running on directory authority must verify its own vote documents before believing them. Just mentioning this here, because it may not be trivial to add the crypto code for this and to provide all necessary keys for the authority to import years of data.

comment:3 Changed 5 years ago by karsten

One more random thought from discussing this with atagar: if we want to bootstrap new directory authorities, there will be no old votes from that authority. Maybe that means we'll want to use consensuses as data basis and not votes.

(Please tell me if this ticket was not intended to be a place to brainstorm and collect ideas, and I'll stop adding random thoughts.)

comment:4 Changed 5 years ago by nickm

Milestone: Tor: 0.2.5.x-finalTor: 0.2.???

comment:5 Changed 5 years ago by arma

Which flags did you have in mind here?

For the Guard flag (#11328), I think we definitely want consensus values, not votes. The question is actually "what fraction of the past interval was this relay choosable?" If one authority thought it was choosable but the others didn't, then it wasn't.

I think Fast is more subjective and not dependent on history (it's about speed, not stability, but see #11327 for how they should listen to the consensus if they don't have their own opinion about speed).

Running is also subjective and not based on past history.

For HSDir, I could totally see an argument for using recent consensus values.

For Stable, it's about whether it has restarted. We look for restarts by seeing a descriptor with an unexpected uptime, or by failing three reachability tests in a row. I guess if we wanted we could change this to either looking for an unexpected uptime, or seeing whether there's ever a consensus where it's missing the Running flag -- an hour is approximately three reachability tests, give or take.

comment:6 in reply to:  5 ; Changed 5 years ago by karsten

Replying to arma:

Which flags did you have in mind here?

For the Guard flag (#11328), I think we definitely want consensus values, not votes. The question is actually "what fraction of the past interval was this relay choosable?" If one authority thought it was choosable but the others didn't, then it wasn't.

I'm still having problems understanding how the result of the consensus process can feed back as input into the same process. The idea behind the consensus process was that the majority of authorities sure must be right. Like democracy. But when you suggest that citizens should base their vote on past election results, that doesn't sound very democratic to me. In fact, what's the purpose of voting on this flag when everyone bases their vote on the very same data?

comment:7 in reply to:  6 Changed 5 years ago by asn

Replying to karsten:

Replying to arma:

Which flags did you have in mind here?

For the Guard flag (#11328), I think we definitely want consensus values, not votes. The question is actually "what fraction of the past interval was this relay choosable?" If one authority thought it was choosable but the others didn't, then it wasn't.

I'm still having problems understanding how the result of the consensus process can feed back as input into the same process. The idea behind the consensus process was that the majority of authorities sure must be right. Like democracy. But when you suggest that citizens should base their vote on past election results, that doesn't sound very democratic to me. In fact, what's the purpose of voting on this flag when everyone bases their vote on the very same data?

Hm. I think I see what you are saying but I don't entirely understand the concern. Could you describe an attack?

At least for the guard case, as detailed in the new single guard node proposal ( https://gitweb.torproject.org/torspec.git/blob/HEAD:/proposals/236-single-guard-node.txt#l101 ) we care about how long clients have been considering this relay to be a guard. The only place to get this information is the consesus, since this is what clients use.

comment:8 Changed 5 years ago by asn

[Please ignore this comment. Ended up asking the questions in comment:4:ticket:11480]

Last edited 5 years ago by asn (previous) (diff)

comment:9 Changed 5 years ago by karsten

The following is not an attack, but an example why basing individual opinions on past group opinions is a bad idea. Assume we have 9 authorities in the network, and 5 of them vote for a set of relays being suitable guards whereas the other 4 vote against that. The result is that the consensus says these relays should be guards. At some point 2 of the first 5 authorities are removed from the network, so now it's 3 to 4, and the relays shouldn't be marked as possible guards anymore. But with the suggested change, the remaining 7 authorities have to base their opinion on past consensuses, which means the relays in question will still be guards, at least for a while. This seems wrong to me.

Why not base an authority's opinion on its past opinions by parsing its own past votes? If it was wrong all the time, the other authorities will overrule it anyway. That's what the whole voting stuff is for, right?

comment:10 Changed 2 years ago by teor

Milestone: Tor: 0.2.???Tor: 0.3.???

Milestone renamed

comment:11 Changed 2 years ago by nickm

Keywords: tor-03-unspecified-201612 added
Milestone: Tor: 0.3.???Tor: unspecified

Finally admitting that 0.3.??? was a euphemism for Tor: unspecified all along.

comment:12 Changed 22 months ago by nickm

Keywords: tor-03-unspecified-201612 removed

Remove an old triaging keyword.

comment:13 Changed 22 months ago by dgoulet

Keywords: tor-dirauth added; tor-auth removed

Turns out that tor-auth is for directory authority so make it clearer with tor-dirauth

comment:14 Changed 22 months ago by nickm

Keywords: needs-design reliability added
Severity: Normal
Summary: Authorities should use past consensuses to assign relay flagsAuthorities should use past consensuses to decide how to vote on relay flags
Note: See TracTickets for help on using tickets.