[tor-bugs] #7157 [Tor]: "Low circuit success rate %u/%u for guard %s=%s."

[Tor Bug Tracker & Wiki]

#7157: "Low circuit success rate %u/%u for guard %s=%s."
-----------------------------------------+----------------------------------
 Reporter:  arma                         |          Owner:                    
     Type:  enhancement                  |         Status:  needs_revision    
 Priority:  normal                       |      Milestone:  Tor: 0.2.4.x-final
Component:  Tor                          |        Version:                    
 Keywords:  tor-client, MikePerry201212  |         Parent:  #5456             
   Points:                               |   Actualpoints:  19                
-----------------------------------------+----------------------------------

Comment(by mikeperry):

 Replying to [comment:18 nickm]:
 > Okay, part two (which covers the rest of the branch up to
 ccaeef22e168af34e9b6a63d65ce17e58dd702e2) is much shorter:
 >
 > Setting timestamp_dirty in circuit_extend_to_new_exit seems wrong.
 > The circuit *isn't* dirty!  Maybe overloading timestamp_dirty in this
 > way, rather than grabbing a new bit, is a mistake?

 Hrmm. Both codepaths that cause circuit_extend_to_new_exit to fire seem to
 indicate it's dirty to me: We're either re-extending an intro circ, or
 cannibalizing an existing circuit to send it to a specific new exit. In
 neither of these cases do we really want to re-use this circuit for some
 random new traffic, right?

 You'll note that I also added a dirty timestamp in
 rend_service_rendezvous_has_opened() for similar reasons..

 However, if this bit causes the code that did the re-extending/opening to
 suddenly decide "Eww, a dirty circuit. Better make a fresh one!" once the
 extend completes, that could be bad. It didn't *seem* to do this, but some
 of those cannibalization corner cases are certainly screwy...

 > 04866055e8dadc9eb5b09773 freaks me out.  This feels like a significant
 > redesign of the whole concept, and I didn't see it mentioned on
 > tor-dev anywhere or on the tickets.  "As long as end-to-end tagging is
 > possible, we assume the adversary will use it over hop-to-hop
 > failure"?  Is there any discussion of this anyplace?  (The idea here
 > seems to be that entry nodes are allowed to filter for the second hop
 > as much as they like, and the pathbias code won't care, but that if
 > they start tagging/filtering for the third hop or later, they need to
 > be called out. Is that right?)

 Yes, this is the idea, but there has been no discussion yet. I added it
 after watching the end-to-end circuit success rate repeatedly fluctuate
 between 90% and 50%, due almost entirely to per-hop onionskin failure (CPU
 overload). In fact, what was more worrying was my own aggressive testing
 seemed to be what was driving the network into these overload conditions,
 so there is seemingly not very much load margin between "fine-and-dandy"
 and "overload" right now.

 Waiting until the second hop completes removes a lot of the effect of this
 without impacting what we're looking for (guard-to-exit bias). In fact,
 this is the part of the branch most likely to make the most impact on
 Roger's original complaint about the frequency of the logline in the
 ticket title. To see why, imagine that each node occasionally experiences
 as much as 25% circuit failure. If we count after the first hop in such a
 network, that's a success rate of only (1-.25)*(1-.25) = 0.56, which
 triggers our notice alarm (set at 70%). However, if we wait until two
 hops, the alarm should not trigger in this same scenario.

 Further, because of this squaring of the success rates, per-hop failure is
 way less appealing than end-to-end tagging for the same amount of network
 compromise. An adversary that controls 30% of the network would have to
 drive the end-to-end circuit success rate down to 9% for per-hop failure,
 but only 30% for end-to-end tagging-based failure. In either case, we'd
 still catch the per-hop adversary as they failed their last hop, just as
 the end-to-end tagger would.

 > In general: use %f to printf a double, but %lf to scanf a double.  At
 > least one compiler we care about complains when it sees %lf in a
 > printf format string.

 Bleh, this is a painfully messy one to find+clean up. I'll do my best.

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