Skip to content
Snippets Groups Projects
New look: Off

When reachable addresses change, mark connections using those addresses

    • Closed (moved) Issue created by teor @teor

    When a client's reachable addresses change, we should:

    • close connections that are on newly unreachable addresses,
    • mark connections that are on non-preferred connections as "not for new streams".

    This implements user intent faster than the current code (which essentially does nothing, and waits for old unreachable connections to die naturally, and new reachable connections to replace them).

    To upload designs, you'll need to enable LFS and have an admin enable hashed storage. More information

    Child items ...

    • Activity

    • teor changed milestone to %Tor: 0.3.0.x-final

      changed milestone to %Tor: 0.3.0.x-final

    • teor added actualpoints::0 component::core tor/tor ipv6 milestone::Tor: 0.3.0.x-final points::1 priority::medium resolution::fixed severity::normal status::closed type::defect labels

      added actualpoints::0 component::core tor/tor ipv6 milestone::Tor: 0.3.0.x-final points::1 priority::medium resolution::fixed severity::normal status::closed type::defect labels

    • C
      cypherpunks @cypherpunks ·

      Replying to teor: Are you sure about both? Personally,

      When a client's reachable addresses change, we should:

      • mark connections that are on non-preferred connections as "not for new streams". this seems fine to me
      • close connections that are on newly unreachable addresses not so sure about this.

      There are situations when it's preferable to leave existing streams be, but fewer (I can't think of any) when it would be bothersome to leave them alone.

    • T
      teor @teor ·
      Author

      Replying to cypherpunks:

      Replying to teor: Are you sure about both? Personally,

      When a client's reachable addresses change, we should:

      • mark connections that are on non-preferred connections as "not for new streams". this seems fine to me
      • close connections that are on newly unreachable addresses not so sure about this.

      There are situations when it's preferable to leave existing streams be, but fewer (I can't think of any) when it would be bothersome to leave them alone.

      I can think of several, in approximate order of prevalence:

      • the client wants their unreachable connections to fail and be reestablished, rather than waiting for them to time out,
      • the client has moved to a network where data to some IP addresses is restricted or costly, and they want to avoid those addresses,
      • the client has moved to a network where connecting to certain IP addresses is bad for their anonymity.
    • C
      cypherpunks @cypherpunks ·

      Replying to teor:

      Replying to cypherpunks:

      Replying to teor: Are you sure about both? Personally,

      When a client's reachable addresses change, we should:

      • mark connections that are on non-preferred connections as "not for new streams". this seems fine to me
      • close connections that are on newly unreachable addresses not so sure about this.

      There are situations when it's preferable to leave existing streams be, but fewer (I can't think of any) when it would be bothersome to leave them alone.

      I can think of several, in approximate order of prevalence:

      • the client wants their unreachable connections to fail and be reestablished, rather than waiting for them to time out,
      • the client has moved to a network where data to some IP addresses is restricted or costly, and they want to avoid those addresses,
      • the client has moved to a network where connecting to certain IP addresses is bad for their anonymity. Good points. Additionally, keeping in mind things like long-running non-resumable transfers, IRC, and similar applications where a broken connection is a nuisance, and times when the client wants to keep a change in their reachable addresses (that could be due to changing location) private, it seems best for this behavior to be configurable.
    • T
      teor @teor ·
      Author

      Replying to cypherpunks:

      Replying to teor:

      Replying to cypherpunks:

      Replying to teor: Are you sure about both? Personally,

      When a client's reachable addresses change, we should:

      • mark connections that are on non-preferred connections as "not for new streams". this seems fine to me
      • close connections that are on newly unreachable addresses not so sure about this.

      There are situations when it's preferable to leave existing streams be, but fewer (I can't think of any) when it would be bothersome to leave them alone.

      I can think of several, in approximate order of prevalence:

      • the client wants their unreachable connections to fail and be reestablished, rather than waiting for them to time out,
      • the client has moved to a network where data to some IP addresses is restricted or costly, and they want to avoid those addresses,
      • the client has moved to a network where connecting to certain IP addresses is bad for their anonymity. Good points. Additionally, keeping in mind things like long-running non-resumable transfers, IRC, and similar applications where a broken connection is a nuisance, and times when the client wants to keep a change in their reachable addresses (that could be due to changing location) private, it seems best for this behavior to be configurable.

      The behaviour is configurable in this design: if you don't want tor to terminate your connections, don't tell it that those addresses are unreachable. Anything else changes the semantics of reachable addresses.

      If you want to be able to prefer smaller sets of addresses than the whole of IPv4 or IPv6, that's another feature ticket - please feel free to open it.

    • C
      cypherpunks @cypherpunks ·

      Replying to teor:

      Replying to cypherpunks:

      Replying to teor:

      Replying to cypherpunks:

      Replying to teor: Are you sure about both? Personally,

      When a client's reachable addresses change, we should:

      • mark connections that are on non-preferred connections as "not for new streams". this seems fine to me
      • close connections that are on newly unreachable addresses not so sure about this.

      There are situations when it's preferable to leave existing streams be, but fewer (I can't think of any) when it would be bothersome to leave them alone.

      I can think of several, in approximate order of prevalence:

      • the client wants their unreachable connections to fail and be reestablished, rather than waiting for them to time out,
      • the client has moved to a network where data to some IP addresses is restricted or costly, and they want to avoid those addresses,
      • the client has moved to a network where connecting to certain IP addresses is bad for their anonymity. Good points. Additionally, keeping in mind things like long-running non-resumable transfers, IRC, and similar applications where a broken connection is a nuisance, and times when the client wants to keep a change in their reachable addresses (that could be due to changing location) private, it seems best for this behavior to be configurable.

      The behaviour is configurable in this design: if you don't want tor to terminate your connections, don't tell it that those addresses are unreachable. Anything else changes the semantics of reachable addresses.

      If you want to be able to prefer smaller sets of addresses than the whole of IPv4 or IPv6, that's another feature ticket - please feel free to open it. The option needed is for when the client wants to modify their reachable addresses and seamlessly move new streams to better circuits, consistent with how changes in ExitNodes, and so on, affect existing streams.

    • T
      teor @teor ·
      Author

      Replying to cypherpunks:

      Replying to teor:

      Replying to cypherpunks:

      ... keeping in mind things like long-running non-resumable transfers, IRC, and similar applications where a broken connection is a nuisance, and times when the client wants to keep a change in their reachable addresses (that could be due to changing location) private, it seems best for this behavior to be configurable.

      The behaviour is configurable in this design: if you don't want tor to terminate your connections, don't tell it that those addresses are unreachable. Anything else changes the semantics of reachable addresses.

      If you want to be able to prefer smaller sets of addresses than the whole of IPv4 or IPv6, that's another feature ticket - please feel free to open it. The option needed is for when the client wants to modify their reachable addresses and seamlessly move new streams to better circuits, consistent with how changes in ExitNodes, and so on, affect existing streams.

      Entry guard changes are different, and have always been different. Turns out this feature was implemented as I described as part of prop271.

      Please feel free to open a feature ticket for the transition you describe: but be aware that we don't tend to add new options for rare use cases, particularly if they have security implications.

      Trac:
      Milestone: Tor: unspecified to Tor: 0.3.0.x-final
      Status: new to closed
      Actualpoints: N/A to 0
      Resolution: N/A to fixed

    • C
      cypherpunks @cypherpunks ·

      In any codebase, subtle changes, like this, being practically undocumented, and evidently hidden from both users and developers, is a source of confusion and a hindrance to future debugging.

    • T
      teor @teor ·
      Author

      Replying to cypherpunks:

      In any codebase, subtle changes, like this, being practically undocumented, and evidently hidden from both users and developers, is a source of confusion and a hindrance to future debugging.

      There are a lot of subtle changes when a subsystem is rewritten. That's just how it works.

      This change was implemented in a recent alpha: "to better support unreliable networks and restrictive sets of entry nodes" https://gitweb.torproject.org/tor.git/tree/ChangeLog?id=ac04fcd2e758c2258cbde8c8f31586695cb5d666#n12

      And it was fully documented in proposal 271: https://gitweb.torproject.org/torspec.git/tree/proposals/271-another-guard-selection.txt#n648 https://gitweb.torproject.org/torspec.git/tree/proposals/271-another-guard-selection.txt#n114

      And no, the earlier bug in almost all versions of tor was much harder to debug. (I've debugged ReachableAddresses errors while implementing IPv6 support.) This fix will make it much easier.

    • C
      cypherpunks @cypherpunks ·

      Replying to teor:

      Replying to cypherpunks:

      In any codebase, subtle changes, like this, being practically undocumented, and evidently hidden from both users and developers, is a source of confusion and a hindrance to future debugging.

      There are a lot of subtle changes when a subsystem is rewritten. That's just how it works.

      This change was implemented in a recent alpha: "to better support unreliable networks and restrictive sets of entry nodes" https://gitweb.torproject.org/tor.git/tree/ChangeLog?id=ac04fcd2e758c2258cbde8c8f31586695cb5d666#n12 That entry makes no reference to this change.

      And it was fully documented in proposal 271: https://gitweb.torproject.org/torspec.git/tree/proposals/271-another-guard-selection.txt#n648 https://gitweb.torproject.org/torspec.git/tree/proposals/271-another-guard-selection.txt#n114 That is no explicit documentation, and was not enough for a user or system integrator, or a developer, to decode and guess that the change had taken place.

    • Trac closed

      closed

    • Trac changed time estimate to 8h

      changed time estimate to 8h

    • Trac moved to tpo/core/tor#21493 (closed)

      moved to tpo/core/tor#21493 (closed)

    Please register or sign in to reply