Opened 5 years ago

Closed 16 months ago

#12201 closed defect (wontfix)

Don't weight by bandwidth when selecting among bridges

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

Description

In choose_random_entry_impl() we have:

choose_and_finish:
  if (entry_list_is_constrained(options)) {
    /* We need to weight by bandwidth, because our bridges or entryguards
     * were not already selected proportional to their bandwidth. */
    node = node_sl_choose_by_bandwidth(live_entry_guards, WEIGHT_FOR_GUARD);

This means that bridges are also selected proportional to their bandwidth. However, since there is no bandwidth authorities for bridges their bandwidth is self-reported and potentially a lie. For this reason, it's probably not a good idea to use those values during path selection, since an evil bridge can try to dominate the guard probability.

Fortunately, we also have bridge_get_advertised_bandwidth_bounded() which bounds bridges bandwidth between 20kB/s and 100kB/s. So the danger can't be that great.

Still, it might be a better idea to pick amongst bridges in a uniform random way.

Child Tickets

Change History (10)

comment:1 Changed 5 years ago by asn

Milestone: Tor: 0.2.6.x-final

comment:2 Changed 5 years ago by asn

I'm wondering if there is a future where we will actually be doing bandwidth testing to bridges, and we will have to re-install this feature? Maybe as part of the hypothetical bridge reachability infrastructure?

As part of this ticket we will probably also have to dispose of bridge_get_advertised_bandwidth_bounded() and see what should be done with it in compute_weighted_bandwidths().

comment:3 Changed 5 years ago by arma

We set up bridge_get_advertised_bandwidth_bounded() exactly to handle the worry you have. Basically if you're a good enough bridge you'll have equal weight with the other such bridges, and if you're a quite bad bridge you'll have lower than equal weight. I think that's a fine heuristic.

comment:4 Changed 5 years ago by asn

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

Since this is not particularly dangerous, I'm downgrading its milestone to ?? so that only important guard node tickets are marked for 0.2.6.

comment:5 Changed 5 years ago by isis

Cc: isis added
Status: newneeds_information

Could we potentially up the maximum of 100KB/s in bridge_get_advertised_bandwidth_bounded() to the (now colloquially recommended for relays) bandwidth rate of 250KB/s? As far as I can see, "good" relays (those >=250KB/s) would still be considered "good", and it would increase the scale for which bridges are considered sub-par… is this correct?

Should I make a separate ticket for this suggestion, since this is concerning not weighting by bandwidth at all?


Also, FWIW, I think the current solution of marginally believing the self-reported bandwidth of the bridge is the best we have… and there are now plans to have official bridge BW measurements in the future (meaning that we should obviously continue weighting by bandwidth, albeit with changes to believe the reported bandwidths even more). Would it actually be okay to close this ticket, and open a new ticket for the above suggestion to increase bandwidth?

comment:6 Changed 3 years ago by teor

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

Milestone renamed

comment:7 Changed 3 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:8 Changed 2 years ago by nickm

Keywords: tor-03-unspecified-201612 removed

Remove an old triaging keyword.

comment:9 Changed 2 years ago by nickm

Keywords: needs-design fairness added
Severity: Normal

comment:10 Changed 16 months ago by teor

Resolution: wontfix
Status: needs_informationclosed

Isis, I think you will fix this issue by implementing a bridge bandwidth scanner, and then increasing the weights that clients believe.

But we may still want to have these limits for unmeasured bridges, like the Tor Browser default bridges?

Note: See TracTickets for help on using tickets.