[tor-bugs] #25347 [Core Tor/Tor]: Tor stops building circuits, and doesn't start when it has enough directory information

[Tor Bug Tracker & Wiki]

#25347: Tor stops building circuits, and doesn't start when it has enough directory
information
-------------------------------------------------+-------------------------
 Reporter:  teor                                 |          Owner:  asn
     Type:  defect                               |         Status:
                                                 |  needs_revision
 Priority:  Medium                               |      Milestone:  Tor:
                                                 |  0.3.3.x-final
Component:  Core Tor/Tor                         |        Version:  Tor:
                                                 |  0.3.0.6
 Severity:  Normal                               |     Resolution:
 Keywords:  031-backport, 032-backport,          |  Actual Points:
  033-must, tor-guard, tor-client, tbb-          |
  usability-website, tbb-needs,                  |
  033-triage-20180320, 033-included-20180320     |
Parent ID:  #21969                               |         Points:  1
 Reviewer:                                       |        Sponsor:
-------------------------------------------------+-------------------------

Comment (by mikeperry):

 Replying to [comment:28 asn]:
 > Replying to [comment:25 mikeperry]:
 > > A couple comments here:
 > >
 > > 1. We already treat non-destroy failures at the guard as rotate-away
 failures in circuit_build_failed(). Note that there is an explicit check
 to not blame the guard if circ->base_.received_destroy is set. If we
 remove that check in circuit_build_failed(), we should not need asn's
 patch, as the behavior would then be equivalent (or actually a superset,
 since it would cover all destroy reasons). (I think this is what arma
 meant in his point H?). This would be a simpler patch.
 > >
 >
 > Seems like a reasonable plan. Let's proceed like that.

 Ok. Note that after talking to arma, I decided to file #25705. In that
 refactor I could also fix this issue. I guess it depends on if we want to
 backport that.

 > > 2. Roger's point G is scary. I like the solution in E, though, and I
 think it actually fixes G. I would implement E by setting an is_predicted
 flag in circuit_predict_and_launch_new(), and then check that flag in
 select_entry_guard_for_circuit() to completely ignore the is_reachable
 status there if it is set. Then if any of those predicted circuits
 succeed, entry_guards_node_success() will get called, which will clear the
 is_uneachable flag and allow us to resume using the guard. For guards that
 fail only a non-zero but small portion of their circuits, this should
 allow us to keep using them rather than rotating away. I am a fan of this
 plan, and could write a patch for it if we like it.
 > >
 >
 > Hmm, I can see how the solution of E can help with G, by making Alice
 try her primary guards more aggressively in cases of predicted circuits,
 but if Alice is a busy hidden service (like Roger describes in E) most of
 her circs are not gonna be predicted.

 But a client/service will always keep building predicted circuits such
 that it has 3 of each type available. This means even a busy hidden
 service will keep making predicted circuits, which, any time they succeed,
 will reset the fact that the guard is reachable for use by other circuits.
 So, so long as some circuits are succeeding through that guard, the
 service should keep going back to it fairly quickly.

 > Furthermore, I wonder if it can completely address the problem in
 actually ''mischievous'' scenarios, where the adversary overloads all 3
 primary guards of Alice (targeting them using guard discovery attacks) to
 make her switch to other guards in her sampled set.

 This case is tricky. I am not sure what to do with predicted circuits if
 all primary guards get into the unreachable state. One option is to toss a
 coin and pick primary vs sampled for predicted circuits, if all primary
 are down.

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