Re: [tor-bugs] #25347 [Core Tor/Tor]: Tor keeps on trying the same overloaded guard over and over

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

#25347: Tor keeps on trying the same overloaded guard over and over
-------------------------------------------------+-------------------------
 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:28 asn]:
 > Replying to [comment:25 mikeperry]:
 > > 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.

 FWIW, I discussed the above ''mischievous'' case with Nickm and discussed
 whether we should handle this "attacker can make you switch guards"
 congestion-attack case specially. Nick pointed out that this is the reason
 that the max sample size mechanism of prop271 was introduced (so that it's
 impossible for an adversary to make you try all the guards). If we are
 unhappy with how the sampled set of prop271 works we should refactor that
 instead of engineering special solutions for this ticket.

 tl;dr: I think we should be OK with switching guards in the case of
 `RESOURCELIMIT`, and rely on prop271 to defend against malicious attacks
 of this type. If we don't like the prop271 behavior, we should improve
 prop271.

--
Ticket URL: <https://trac.torproject.org/projects/tor/ticket/25347#comment:31>
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