[tor-bugs] #18460 [Tor]: Relays and bridges are not counting directory requests coming in via IPv6

[Tor Bug Tracker & Wiki]

#18460: Relays and bridges are not counting directory requests coming in via IPv6
-------------------------------------------------+-------------------------
 Reporter:  karsten                              |          Owner:
     Type:  defect                               |         Status:
 Priority:  Medium                               |  needs_review
Component:  Tor                                  |      Milestone:  Tor:
 Severity:  Normal                               |  0.2.8.x-final
 Keywords:  tor-relay tor-bridge 026-backport    |        Version:  Tor:
  027-backport                                   |  0.2.8.1-alpha
Parent ID:                                       |     Resolution:
 Reviewer:                                       |  Actual Points:
                                                 |         Points:
                                                 |        Sponsor:
-------------------------------------------------+-------------------------

Comment (by karsten):

 Okay, I took the painful route of renaming `address` and `addr` in
 `connection_t` (to `ADDRESS` and `ADDR`) and looking for the compile
 errors appearing from that.  I also annotated all places where either of
 the two fields are set or modified with a `/* XXX18460 */` comment.  I'm
 pushing my branch as
 [https://gitweb.torproject.org/karsten/tor.git/log/?h=task-18460
 -annotations-dont-merge task-18460-annotations-dont-merge to my public
 repository], but please don't merge that anywhere.

 I'm counting 16 functions where either or both of the two fields are set
 or modified, however, I cannot rule out that I forgot some cases.  But
 let's use this as a start.

 Let's go through these cases by filtering out all where `addr` is copied
 from another `addr` using `tor_addr_copy()` and `address` is set to a
 string representation of that same `addr` using `tor_dup_addr()`.  That's
 the ideal case in the context of this ticket where we could use either
 `addr` or `address` and get the exact same result:

  - connection_listener_new()
  - connection_exit_connect_dir()
  - directory_initiate_command_rend()
  - evdns_server_callback()
  - connection_ext_or_handle_cmd_useraddr()

 Let's move on to the more complicated cases.  One of them is where
 `address` ''may'' be set to a const string like `"(Tor_internal)"` or
 `"(rendezvous)"` rather than a string representation of `addr`.  This
 would make it impossible to use `address`, but we most likely don't care
 about these addresses anyway:

  - connection_ap_make_link()
  - connection_exit_begin_conn()
  - dnsserv_launch_request()

 Let's look at the case that teor refers to above, which is where we're
 parsing a `"Forwarded-For:"` HTTP header and writing the parsed address to
 `address` but not to `addr`.  This case makes it difficult to use `addr`
 instead of `address`, because the former is not updated but only the
 latter:

  - http_set_address_origin()

 That leaves us with 7 more places in the code where either `addr` or
 `address` is set, which I didn't classify further and which I'm mostly
 listing here in case somebody else wants to take a look:

  - connection_handle_listener_read()
  - connection_ap_handshake_send_resolve()
  - connection_exit_begin_resolve()
  - connection_or_init_conn_from_address()
  - dns_resolve_impl()
  - set_unix_port()
  - rend_service_set_connection_addr_port()

 My preliminary conclusion for this ticket is that we should stick to
 `address` and extend the code towards also supporting string
 representations of IPv6 addresses.  I could imagine that we can simply use
 `tor_addr_parse()` rather than `tor_inet_aton()` and
 `tor_addr_from_ipv4h()` to convert the `address` to an `addr` which would
 support both v4 and v6.  I can write a patch and changes file for this and
 test it in a local Chutney network.  But I'd first like to hear whether
 this makes sense at all.  Thanks!

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