[tor-bugs] #8240 [Tor]: Raise our guard rotation period

[Tor Bug Tracker & Wiki]

#8240: Raise our guard rotation period
----------------------------------------------------+-----------------------
 Reporter:  arma                                    |          Owner:                    
     Type:  defect                                  |         Status:  needs_review      
 Priority:  major                                   |      Milestone:  Tor: 0.2.4.x-final
Component:  Tor                                     |        Version:                    
 Keywords:  tor-client needs-proposal 023-backport  |         Parent:                    
   Points:                                          |   Actualpoints:                    
----------------------------------------------------+-----------------------

Comment(by arma):

 Replying to [comment:9 mikeperry]:
 > Replying to [comment:7 arma]:
 > > I like the notion of changing the weights, but I feel like inflating
 the Bandwidth= weight is the wrong way to do it. I increasingly think we
 need a per-relay thing to say "how much of a guard it is".
 >
 > Correct, this would be a change to the authority consensus process that
 computes these weights:
 https://gitweb.torproject.org/torspec.git/blob/HEAD:/dir-spec.txt#l1482

 I guess I'm not being clear. Here's an attack, if we continue having only
 one weight per relay in the consensus. Let's say a new mid-sized
 adversarial exit relay shows up. It has the Exit flag, no guard flag, and
 not a very high Bandwidth= number on the w line, since it's being used as
 an Exit and a Middle, so it isn't super-impressive with its download
 speeds.

 When it earns the Guard flag, clients will back off from using it as the
 middle hop, and partially back off from using it as the exit hop, since
 they assume other clients will be using it as a guard. So its usage will
 go way down.

 In this ticket we remark several times that we hope the bwauths will then
 find it to be much faster, and give it a larger Bandwidth= weight, so
 clients will more quickly pick it as a Guard.

 But as a side effect, we have just inflated the chance that clients will
 pick it as an Exit too, since it's the same Bandwidth= weight that tells
 how useful it 'should' be for either position. So an adversary can arrange
 to run lots of these newly-got-the-Guard-flag relays and get more than his
 fair share of exit traffic.

 Instead I'm suggesting that we have a second weight on that w line, which
 shows, for each guard, how much of his steady-state client quota we think
 he should have by now. And then clients would use this number to treat a
 half-way-there guard as having more available capacity for other path
 positions than an all-the-way-there guard.

 I agree that this complicates things. I don't see a way of doing it
 without having a new parameter, per relay, though.

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