Opened 7 years ago

Last modified 3 years ago

#10024 new enhancement

Close and open sockets on IP change, tracking

Reported by: grarpamp Owned by:
Priority: Medium Milestone: Tor: unspecified
Component: Core Tor/Tor Version: Tor:
Severity: Normal Keywords: tor-client roaming network
Cc: Actual Points:
Parent ID: Points:
Reviewer: Sponsor:


For hosts that have dynamic/roaming/dhcp/manual IP changes, is there
a controller toggle that will cause Tor to shut down all external
TCP/UDP connections and state... and then start fresh ones upon the
user toggling Tor back up after an IP change? Seems that
without that, having TCP/UDP retransmit could lead to flow and finer
(seq num, etc) matching to the user's former IP. It wouldn't
necessarily have to change the guards, but that could be an extended

eg: Is there anything to be done for the Tor instance itself to not
be trackable across an IP change?

If so, is monitoring the interface using some OS provided interface API
possible versus a dhcp/user driven controller toggle? Note multiple stacks,
multiple interfaces, secondary addresses, and vm's etc.

DHCP's unpredictable IP changes and complex state machine / scripts
would make dhcp hard for the typical user to hook into.

A controller toggle would still be needed anyway for those who
manually change their IP.

There may be some small network or client/server benefit to maintaining
things like descriptors in core as opposed to just restarting Tor.

And should this tie in to sighup actions?

I think this may have been discussed recently, if so just pull
from and close this.

Child Tickets

Change History (7)

comment:1 Changed 7 years ago by arma

You might like the DisableNetwork torrc option (which the controller can set and unset)?

That works if the controller can magically discern network state (like apparently is possible on Android).

But you're right that in general, Tor only notices that the network has changed by continuing to try to interact with it (see the various places that call ip_address_changed()) and in some cases it could leak something from its previous network behavior onto the new network while doing that.

comment:2 Changed 7 years ago by grarpamp

DisableNetwork 0|1

When this option is set, we don't listen for or accept any
connections other than controller connections, and we don't make
any outbound connections. Controllers sometimes use this option to
avoid using the network until Tor is fully configured. (Default: 0)

That seems like it might handle the interface-post-change (wake tor up),
but doesn't mention any interface-pre-change context (ie: put tor to sleep).

I'd wonder about the reaction speed of application based 'magical discernment'.
Whereas monitoring/handling a kernel provided OS API (an interrupt delivered
to tor by the kernel), if one existed, would give instant change notices.

I'm not sure if this is of much importance...

Since the user was/is still behind encrypted hops to the guards. And the
crypto would prevent mitm / games at the client to guard boundary. So
the state/content itself seems safe there.

If a user's IP changed while passing traffic as an exit relay,
there might be some kind of minor issue there. The common case for
that might be residential dhcp via cable/dsl/fiber. The ISP
would surely have dhcp-to-residence-level logs, so that is moot.
However whatever is beyond the ISP, such as the destinations
of that exit traffic, should not be able to piece an IP change
together. That is somewhat mooted if the relay descriptor keeps the
same fingerprint/keys across such a change since they could poll
that instead.

Any monitoring-to-sleep/wake solution is moot if tor is behind a nat...
it can't detect the farside ip change at the nat in time and so
continues retransmitting through the nat till then, which happily
nats it out. Only manual toggle would work there.

comment:3 Changed 7 years ago by nickm

Milestone: Tor: 0.2.5.x-finalTor: 0.2.???

comment:4 Changed 4 years ago by teor

Milestone: Tor: 0.2.???Tor: 0.3.???

Milestone renamed

comment:5 Changed 4 years ago by nickm

Keywords: tor-03-unspecified-201612 added
Milestone: Tor: 0.3.???Tor: unspecified

Finally admitting that 0.3.??? was a euphemism for Tor: unspecified all along.

comment:6 Changed 3 years ago by nickm

Keywords: tor-03-unspecified-201612 removed

Remove an old triaging keyword.

comment:7 Changed 3 years ago by nickm

Keywords: tor-client roaming network added
Severity: Normal
Note: See TracTickets for help on using tickets.