Sybil selection should prefer measured over advertised bw

When choosing between two nodes on the same IP, we based the choice on bandwidth. But right now, we use dirserv_get_bandwidth_for_router(), which looks at measured bw and falls back to advertised when measured isn't present. Probably it makes more sense, if there are two nodes, one of which has measured bw and one of which doesn't, to prefer the one with measured bw.

changed milestone to %Tor: 0.2.5.x-final

added 024-deferrable component::core tor/tor milestone::Tor: 0.2.5.x-final priority::medium resolution::wontfix status::closed tor-auth type::defect labels

Fix in branch bug8710

Trac:
Status: new to needs_review

since different bwauths will have different opinions, won't this increase the chance that different authorities pick different of the sybils to be the winners?

Possibly. But isn't letting an advertised bandwidth override a measured bandwidth ridiculous?

We don't have a great solution right now for the "make sybils converge better" problem. But whatever it is, I sure hope it isn't "break ties in favor of whichever Sybil has the most bandwidth, or whichever Sybil lies and says it has the most bandwidth."

The sybil tie-breaker decision is meant to let us take the most useful relays from the set, and add those to the network. The choice of relay is not meant to be a security thing.

So I'll grant that maybe looking at the measured bandwidth will give us a better heuristic for picking the 'more useful' relay. But if it causes oscillations, meaning we periodically zero out the history of all relays in the set, then it would seem to be the worse choice. And it seems like it should produce oscillations, since whichever relay in the set we didn't choose lately is sure going to have some spare bandwidth (and thus measure better).

What security-related attacks are we worried about here? "We could end up picking a relay with lower measured bandwidth" is the failure mode that I see?

I'm tempted to suggest a nuke-it-from-orbit approach of erasing history from all relays whenever you have three reachable relays from a given IP address. But then I'm reminded of the reason we added this whole complexity in the first place -- to get what we were willing to take from people who accidentally sign up more relays than we want.

What security-related attacks are we worried about here? "We could end up picking a relay with lower measured bandwidth" is the failure mode that I see?

Well, the current behavior lets the sybil-attacker pick which node they would like to have appear in the consensus. It also destabilizes the consensus if the nodes' measured values are less than their advertised values, since as soon as a new node shows up, it will seem preferable to all measured nodes.

These don't seem immediately exploitable in any scary way, but I'm not comfortable leaving in calculations that lead to our making decisions based on advertised bandwidth. It doesn't have a great track record.

This isn't to say we don't want a solution for #8163 (moved) , but rather that leaving this ticket unfixed is not the solution for #8163 (moved).

I guess we could defer this to 0.2.5 along with #8163 (moved)?

Trac:
Keywords: tor-auth deleted, tor-auth 024-deferrable added

Replying to arma:

The sybil tie-breaker decision is meant to let us take the most useful relays from the set, and add those to the network. The choice of relay is not meant to be a security thing.

!!?!??!

That's a response to this sentence as a general comment. For the specific context, just as an off the top of the head example, wouldn't the concern you raised in #8163 (moved) apply? That is, run a node at the same IP address (not trivial I know but still could be in the same apartment building, etc. as you suggested). Then lie about the bandwidth and simultaneously add a hostile node while knocking a targeted honest node offline. Lots of attacks to build off that capability.

-Paul

Replying to cypherpunks:

Replying to arma:

The sybil tie-breaker decision is meant to let us take the most useful relays from the set, and add those to the network. The choice of relay is not meant to be a security thing.

!!?!??!

Replace "is" with "has never to this point been".

If we're trying to protect against some sort of security issue, we've been doing it wrong.

And this proposed change would probably still be doing it wrong -- first because totally unloaded nodes will look good on their bandwidth measurements, and second because the bandwidth measurements are still gameable.

If your adversary can run a relay on your IP address, that's bad news as you say.

Deferring to 0.2.5, since it's easier to patch authorities in an alpha series.

Trac:
Milestone: Tor: 0.2.4.x-final to Tor: 0.2.5.x-final

Roger's right above: when there are multiple verified-as-really-connectable nodes running on one IP, it doesn't much matter which ones we pick... or at least, picking them based on measured bandwidth isn't right.

I'm not convinced that advertised bandwidth is right, though, so I opened #11207 (moved) .

Trac:
Status: needs_review to closed
Resolution: N/A to wontfix

closed

mentioned in issue #11207 (moved)

moved to tpo/core/tor#8710 (closed)

mentioned in issue tpo/core/tor#11207 (moved)

mentioned in issue tpo/core/torspec#139