Opened 3 years ago

Closed 3 years ago

Last modified 3 years ago

#21493 closed defect (fixed)

When reachable addresses change, mark connections using those addresses

Reported by: teor Owned by:
Priority: Medium Milestone: Tor: 0.3.0.x-final
Component: Core Tor/Tor Version:
Severity: Normal Keywords: ipv6
Cc: Actual Points: 0
Parent ID: Points: 1
Reviewer: Sponsor:

Description

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).

Child Tickets

Change History (9)

comment:1 in reply to:  description ; Changed 3 years ago by 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.

comment:2 in reply to:  1 ; Changed 3 years ago by 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.

comment:3 in reply to:  2 ; Changed 3 years ago by 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.

comment:4 in reply to:  3 ; Changed 3 years ago by 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.

comment:5 in reply to:  4 ; Changed 3 years ago by 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.

comment:6 in reply to:  5 Changed 3 years ago by teor

Actual Points: 0
Milestone: Tor: unspecifiedTor: 0.3.0.x-final
Resolution: fixed
Status: newclosed

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.

comment:7 Changed 3 years ago by 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.

Last edited 3 years ago by cypherpunks (previous) (diff)

comment:8 in reply to:  7 ; Changed 3 years ago by 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

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.

comment:9 in reply to:  8 Changed 3 years ago by 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.

Note: See TracTickets for help on using tickets.