Changes between Initial Version and Version 1 of Ticket #23097


Ignore:
Timestamp:
Aug 3, 2017, 8:18:46 PM (2 years ago)
Author:
dgoulet
Comment:

Legend:

Unmodified
Added
Removed
Modified
  • Ticket #23097

    • Property Keywords 031-backport added
    • Property Priority changed from Medium to Very High
    • Property Component changed from - Select a component to Core Tor/Tor
    • Property Milestone changed from to Tor: 0.3.2.x-final
  • Ticket #23097 – Description

    initial v1  
    1 During prop224 service testing (#20657), I've encountered a weird behavior. Tor will start closing circuits with `circuit_expire_old_circuits_clientside()` and then open new one for internal use (prediction) but set their timeout to 1 sec which leads to closing the circuit 30 sec later (`NewCircuitPeriod` defaults to 30 sec).
     1During prop224 service testing (#20657), I've encountered a weird behavior. Tor will start closing circuits with `circuit_expire_old_circuits_clientside()` and then open new ones for internal use (prediction) but set their timeout to 1 sec which leads to closing the circuit 30 sec later (`NewCircuitPeriod` defaults to 30 sec).
    22
    33Condensed log info:
     
    1313}}}
    1414
    15 So notice the circuit 321 with a timeout of 1 sec and then being closed 30 sec later... Basically, it's looping like that non stop.
     15So notice the circuit 321 with a timeout of 1 sec and then being closed 30 sec later... Basically, it's looping like that non stop. What I think is happening is this:
    1616
    17 What I think is happening is this:
    18 
    19 1) `predicted_ports_prediction_time_remaining()` returns 0 so this computation always results in 1 sec (in `
     17`predicted_ports_prediction_time_remaining()` returns 0 so the following computation always results in 1 sec (in `origin_circuit_new()`):
    2018
    2119{{{
     
    2422    circ->circuit_idle_timeout = prediction_time_remaining+1+
    2523        crypto_rand_int(1+prediction_time_remaining/20);
     24}}}
    2625
     26We call `rep_hist_note_used_internal()` in the hs subsystem when we launch intro point and rendezvous circuits. That function sets `last_prediction_add_time = now`. Which is what we want because then `predicted_ports_prediction_time_remaining()` computes a `idle_delta` that is below the `prediction_timeout` (set between 30 and 60 mins by default, see `channelpadding_get_circuits_available_timeout()`).
     27
     28Which means that after let's say 61 min for a `prediction_timeout = 60min`, `idle_delta` becomes bigger than `prediction_timeout` and thus returning 0 everytime ultimately making every new circuit timeout to 1 sec. See why below:
     29
     30{{{
     31int
     32predicted_ports_prediction_time_remaining(time_t now)
     33{
     34  time_t idle_delta = now - last_prediction_add_time;
     35
     36  /* Protect against overflow of return value. This can happen if the clock
     37   * jumps backwards in time. Update the last prediction time (aka last
     38   * active time) to prevent it. This update is preferable to using monotonic
     39   * time because it prevents clock jumps into the past from simply causing
     40   * very long idle timeouts while the monotonic time stands still. */
     41  if (last_prediction_add_time > now) {
     42    last_prediction_add_time = now;
     43    idle_delta = 0;
     44  }
     45
     46  /* Protect against underflow of the return value. This can happen for very
     47   * large periods of inactivity/system sleep. */
     48  if (idle_delta > prediction_timeout)
     49    return 0;
     50    [RIGHT HERE, we return 0]
     51...
    2752}}}
     53
     54This is pretty bad because it means that every HS that sees no client for at least 30 to 60 min, will enter this loop of create/close circuits raising flags at the Guard but also putting pressure on the network.
     55
     56Seems that this was introduced with the channel padding in tor-0.3.1.1-alpha.