Opened 7 years ago

Closed 6 years ago

#8710 closed defect (wontfix)

Sybil selection should prefer measured over advertised bw

Reported by: nickm Owned by:
Priority: Medium Milestone: Tor: 0.2.5.x-final
Component: Core Tor/Tor Version:
Severity: Keywords: tor-auth 024-deferrable
Cc: Actual Points:
Parent ID: Points:
Reviewer: Sponsor:

Description

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.

Child Tickets

Change History (9)

comment:1 Changed 7 years ago by nickm

Status: newneeds_review

Fix in branch bug8710

comment:2 Changed 7 years ago by arma

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?

comment:3 Changed 7 years ago by nickm

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."

comment:4 Changed 7 years ago by 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.

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.

comment:5 Changed 7 years ago by nickm

Keywords: 024-deferrable added

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 , but rather that leaving this ticket unfixed is not the solution for #8163.

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

comment:6 in reply to:  4 ; Changed 7 years ago by 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.

!!?!??!

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 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

comment:7 in reply to:  6 Changed 7 years ago by arma

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.

comment:8 Changed 6 years ago by nickm

Milestone: Tor: 0.2.4.x-finalTor: 0.2.5.x-final

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

comment:9 Changed 6 years ago by nickm

Resolution: wontfix
Status: needs_reviewclosed

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 .

Note: See TracTickets for help on using tickets.