[tor-bugs] #19919 [Core Tor/Tor]: If ORPort address is publicly routable, use it to guess Address

[Tor Bug Tracker & Wiki]

#19919: If ORPort address is publicly routable, use it to guess Address
--------------------------+-------------------------------
 Reporter:  teor          |          Owner:
     Type:  defect        |         Status:  new
 Priority:  Medium        |      Milestone:  Tor: 0.2.???
Component:  Core Tor/Tor  |        Version:  Tor: 0.2.5.10
 Severity:  Normal        |     Resolution:
 Keywords:  030-proposed  |  Actual Points:
Parent ID:                |         Points:  1
 Reviewer:                |        Sponsor:
--------------------------+-------------------------------

Comment (by s7r):

 Replying to [comment:4 teor]:
 > Let's just use ORPort for consistency between IPv4 and IPv6.
 > If the user sets a different DirPort address, #13953 in 0.2.9 will warn
 them.
 > And if they set the same one, that's perfectly ok.
 >
 Agreed.

 > > Also, I think it's fine to also assume `OutboundBindAddress` is the
 same IP address (first publicly routable Advertised ORPort), unless
 otherwise explicitly set in torrc. This can apply to both IPv4 and IPv6
 without any problems.
 >
 > Not when the relay is behind a NAT: OutboundBindAddress is the
 *internal* address.
 > And if we use this default, there's no way to specify "your default
 interface", which is the current default behaviour. Unless there's a
 specific issue here that's causing confusion, let's just leave this alone.
 Or tackle it in a separate ticket.
 >
 Also true. So we need more cases:
 1. Simple ORPort (where user just enters ORPort 9001)
 2. Flagged ORPort (where user enters ORPort 9001 NoListen OR NoAdvertise)
 3. Explicit ORPort (where user enters ORPort public.ip:9001)
 4. Explicit flagged ORPort (where user enters ORPort public.ip:9001
 NoListen OR NoAdvertise)
 5. Explicit NAT ORPort (where user enters ORPort nat.ip:9001)
 6. Explicit flagged NAT ORPort (where user enters ORPort nat.ip:9001
 NoListen or NoAdvertise)

 Obviously for cases 1,2,5,6 and 4 if flagged NoListen we cannot make any
 assumption about `OutboundBindAddress` and that should remain as it is set
 now (equal to `Address` guessed by Tor via current methods).

 But for case 3 and case 4 if it's not NoListen, we can assume that IP
 address is also `Address` and also `OutboundBindAddress` (it's publicly
 routable and it's being listened on).

 > > If there's no IP address set with ORPort, and Address is not set,
 maintain the current behavior to guess `Address` and build the descriptor
 - the current behavior to guess `Address` is not broken in any way, to the
 contrary it works good, we just need to add this improvement for boxes
 with multiple public IP addresses and/or multiple Tor instances.
 >
 > We can do this, it just involves adding a small amount of code to
 `resolve_my_address()`, right before we use `get_interface_address()` to
 do the guess, we should instead use the first advertised IPv4 ORPort
 address from `get_first_advertised_addr_by_type_af(CONN_TYPE_OR_LISTENER,
 AF_INET);`
 >
 > (There's some duplicate code in `resolve_my_address()`, let's refactor
 it out before changing it.)
 >
 > The code might be similar to
 `router_check_descriptor_address_port_consistency()`, but will likely be
 much simpler.
 Neat ! Sounds like a clean and simple approach that will do the job just
 fine. `resolve_my_address()` should check if there's anything publicly
 routable manually configured by user with ORPort before starting the
 current algorithm to guess `Address`, that's all.

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