[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_review
 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 arma):

 Five thoughts:

 (A) if I were designing that patch, I would put the "if
 circuit_get_cpath_opened_len is 0" clause up in
 command_process_destroy_cell(), and then rename the function to the more
 certain entry_guard_sent_destroy_cell(), or maybe something like
 entry_guard_responded_with_destroy_cell(). That way the function is clear
 what it's doing, and it's clear how you're deciding whether to call it,
 and those are kept separate.

 (B) Note that in the ddos mitigation stuff, we refuse circuits from
 overloaders with reason resource-limit (see DOS_CC_DEFENSE_REFUSE_CELL).
 And at least at the time, the goal was to soak up their overload circuits
 at the guard level, i.e. keep them occupied at a point where we're able to
 limit the damage they do. If we implement this ticket, overloader clients
 will immediately skip off to hassle some other guard. Maybe that's ok? Or
 maybe it would be a sad side effect? Maybe we should change the ddos
 mitigation to use some other destroy reason, so we don't trigger
 overloaders to move? I'm not sure what's best, but let's intentionally
 choose something.

 (C) I think you're right that END_CIRC_REASON_HIBERNATING is a good reason
 to include if we're doing this ticket.

 (D) You're fine with circuit_get_cpath_opened_len here, but for your
 future knowledge: I believe clients only get a destroy cell from the guard
 when the guard has failed to establish the first hop. If the circuit fails
 after the guard, clients get a relay truncated cell back. That is,
 destroys currently don't chain back to the client -- if the guard gets a
 destroy from the middle relay, it keeps the circuit open at itself, and
 converts the destroy into a truncated cell to send back. In theory this
 design is to allow clients to say "well ok, how about extending to this
 other relay then", but in practice clients just say "well screw that,
 here's a destroy" and start over.

 (E) For the advanced challenge mode of the game: I wonder if it would be
 useful to distinguish between preemptive circuits that we tried to make,
 where it's actually fine if we don't have them quite yet, vs reactive
 circuits that we tried to make because we have some user request that
 we're trying to handle right now. In the latter case we would want to try
 another guard because we need things to work. But in the former case I
 could imagine waiting for a second or two and *not* falling back to a
 different guard immediately.

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