Re: [tor-bugs] #15942 [Core Tor/Tor]: Make tor connection failures random-exponential-backoff

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

#15942: Make tor connection failures random-exponential-backoff
-------------------------------------------------+-------------------------
 Reporter:  teor                                 |          Owner:  andrea
     Type:  defect                               |         Status:
 Priority:  High                                 |  assigned
Component:  Core Tor/Tor                         |      Milestone:  Tor:
 Severity:  Normal                               |  0.2.9.x-final
 Keywords:  SponsorS, 028-triage, tor-dos,       |        Version:
  TorCoreTeam201606                              |     Resolution:
Parent ID:  #17293                               |  Actual Points:
 Reviewer:                                       |         Points:  3
                                                 |        Sponsor:
                                                 |  SponsorU-can
-------------------------------------------------+-------------------------

Comment (by andrea):

 Connection failures are detected in connection_handle_read_impl() /
 connection_handle_write_impl(), which call, generically,
 connection_close_immediate()/connection_mark_for_close_internal(), but
 also in the case of orconns, call connection_or_notify_error(), and call
 connection_edge_end_errno() for edge connections.

 The connection_close_immediate()/connection_mark_for_close_internal() path
 flows to connection_about_to_close_connection(), which can call
 connection_dir_about_to_close(), connection_or_about_to_close(),
 connection_ap_about_to_close() or connection_exit_about_to_close().  In
 the case of orconns and edge connections everything interesting happens
 from connection_or_notify_error() and connection_edge_end_errno(), but
 connection_dir_about_to_close() is the trigger point for retrying
 downloads from the directory servers.

 Edge connections are either outgoing from the exit, in which case we just
 send an END cell down the circuit on failure, from
 connection_edge_end_errno() -> connection_edge_end() ->
 connection_edge_send_command(), or incoming from the client, in which case
 we don't get any choices about retrying.  There's no retry policy to
 change there.

 Orconn failures cause circuits to die or fail to attach, and these flow
 through circuit_n_chan_done() and circuit_unlink_all_from_channel() from
 channel_closed().  Ultimately, connection failures end up in
 circuit_about_to_free(), and then for origin circuits in
 circuit_build_failed() when handling a circuit closed for error.

 Since all of these possible failure cases are ultimately driven from
 somewhere else (e.g., exit connection fails) and trigger reporting back to
 the cause of that connection (e.g. send END cell) rather than retrying, or
 are on the client side and become a matter of general circuit-building
 policy, for this ticket I'll be focusing attention on retries of failed
 downloads from the directory servers.  We should think about backoffs for
 circuit building at some point perhaps, but it seems to be largely
 separable from the question of directories, less critical for DoS-
 resistance since there aren't analogous heavily loaded elements like the
 authorities, and more security-sensitive because of potential implications
 for behavior when we fail to connect to our preferred entry guard.

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