Changes between Initial Version and Version 1 of Ticket #27471, comment 2


Ignore:
Timestamp:
Sep 18, 2018, 3:19:03 PM (14 months ago)
Author:
dgoulet
Comment:

Legend:

Unmodified
Added
Removed
Modified
  • Ticket #27471, comment 2

    initial v1  
    11One theory right now that seems to be plausible but kind of a corner case:
    22
    3 1) When we lookup the intro circuit in `connection_ap_handshake_attach_circuit()`, we go over all circuits and try to figure out which is the best for this connection. We use `circuit_matches_with_rend_stream()` to check if the circuit is acceptable by comparing the .onion requested by the SOCKS connection with the .onion on the intro circuit (`hs_ident`).
     3~~1) When we lookup the intro circuit in `connection_ap_handshake_attach_circuit()`, we go over all circuits and try to figure out which is the best for this connection. We use `circuit_matches_with_rend_stream()` to check if the circuit is acceptable by comparing the .onion requested by the SOCKS connection with the .onion on the intro circuit (`hs_ident`).~~
    44
    5 What if we had a set of intro points that aren't used by the service anymore so the client got NACK on all of them, then fetches a new descriptor with new intro points, then a new intro circuit is launched and finally the lookup function when the RP acked selected an old intro circuits but still for the same service.
     5~~What if we had a set of intro points that aren't used by the service anymore so the client got NACK on all of them, then fetches a new descriptor with new intro points, then a new intro circuit is launched and finally the lookup function when the RP acked selected an old intro circuits but still for the same service.~~
     6
     7(Edit: theory doesn't hold up. Once a client gets a NACK, it either re-extend to a new IP or close the circuit.)~~~~