[tor-bugs] #33898 [Core Tor/Tor]: Stop modifying addr on connections, and delete real_addr

[Tor Bug Tracker & Wiki]

#33898: Stop modifying addr on connections, and delete real_addr
-------------------------------------------+-------------------------------
 Reporter:  teor                           |          Owner:  nickm
     Type:  defect                         |         Status:  assigned
 Priority:  High                           |      Milestone:  Tor:
                                           |  0.4.4.x-final
Component:  Core Tor/Tor                   |        Version:
 Severity:  Normal                         |     Resolution:
 Keywords:  ipv6, technical-debt, prop311  |  Actual Points:
Parent ID:  #33048                         |         Points:  1
 Reviewer:                                 |        Sponsor:  Sponsor55-can
-------------------------------------------+-------------------------------

Comment (by teor):

 Replying to [comment:10 nickm]:
 > So what do we do at this point?  I think we need a long term plan for
 these fields and a plan for the OR fields specifically.
 >
 > As a long-term plan, I think we should move towards disabling "addr" as
 meaning anything other than "the network address we are connected to,
 possibly through a local proxy".  If we retain "address", it should be
 display-only.  Possibly we should rename these fields to avoid confusion.

 I think renaming is a good idea: a lot of the confusion with these fields
 comes from their generic names.

 > We should have a "display peer for logging" function that we use instead
 of addr/port/address in log messages.

 +1

 > We'll need additional fields for the following purposes:
 >    * Canonical address of peer, to use in OR connections.
 >    * Requested address and resolved address, to use in exit connections.
 >    * Address to re-bind to, for listeners.
 >    * Best guess at peer's real internet address, for tunneled directory
 connections, to be used for X-Your-Address-Is.
 >
 > So what parts of this do we do now?
 >
 > First I should solicit comment on this plan.  Then, I should open a
 ticket or three about this. Then, we should document all of this in the
 code, and create the "describe this peer" function.  Then finally we
 should adjust OR connections so that they use the fields in the intended
 manner.

 I think it's important to do the parts related to the Sponsor 55 work, to
 avoid subtle bugs. But it's not necessarily required work, so we should be
 conscious of the amount of time in the grant.

 Here are the related parts of your list above, and the relevant changes
 and proposals:

 >    * Canonical address of peer, to use in OR connections.

 Used to perform IPv6 extends in proposal 311.

 >    * Address to re-bind to, for listeners.

 Used to automatically open IPv6 ORPorts in proposal 312.

 >    * Best guess at peer's real internet address, for tunneled directory
 connections, to be used for X-Your-Address-Is.

 Optionally used to detect IPv6 addresses in proposal 312. This change
 might be out of scope because:
 * we don't guess our own IPv6 address using IPv6 addresses from remote
 relays, or
 * we use the addresses in NETINFO cells instead.

--
Ticket URL: <https://trac.torproject.org/projects/tor/ticket/33898#comment:12>
Tor Bug Tracker & Wiki <https://trac.torproject.org/>
The Tor Project: anonymity online