[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]
Re: [tor-bugs] #33898 [Core Tor/Tor]: Stop modifying addr on connections, and delete real_addr
#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
_______________________________________________
tor-bugs mailing list
tor-bugs@xxxxxxxxxxxxxxxxxxxx
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs