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

["Tor Bug Tracker & Wiki" <blackhole@xxxxxxxxxxxxxx>]

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

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

 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.

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

_______________________________________________
tor-bugs mailing list
tor-bugs@xxxxxxxxxxxxxxxxxxxx
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs