[tor-bugs] #33747 [Core Tor/Tor]: If the ExtORPort doesn't report an external IP address, Tor won't apply rate limiting or account for bandwidth on that connection

[Tor Bug Tracker & Wiki]

#33747: If the ExtORPort doesn't report an external IP address, Tor won't apply
rate limiting or account for bandwidth on that connection
------------------------------+--------------------
     Reporter:  arma          |      Owner:  (none)
         Type:  defect        |     Status:  new
     Priority:  Medium        |  Milestone:
    Component:  Core Tor/Tor  |    Version:
     Severity:  Normal        |   Keywords:
Actual Points:                |  Parent ID:
       Points:                |   Reviewer:
      Sponsor:                |
------------------------------+--------------------
 In the early days of Tor pluggable transports, on the server side you
 would run the bridge and the server component of the pluggable transport
 next to each other, and from Tor's perspective the connection would come
 in from 127.0.0.1 (i.e. "from the obfs4 server sitting next to the
 bridge"). And because Tor doesn't apply rate limiting to connections from
 localhost, it wouldn't rate limit connections coming in via the pluggable
 transport, and also it wouldn't count bytes to/from that connection in its
 extrainfo counts or in its BW controller events.

 We improved the situation by inventing the "ExtORPort", or "Extended
 ORPort", which has a quick handshake at the front that specifies e.g. what
 address the connection is "really" from, and then Tor treats the
 or_connection_t as though it came directly from that external address. So
 far so good.

 But if the ExtORPort handshake doesn't specify an address, then Tor
 defaults to 127.0.0.1 (or wherever the server-side of the PT actually is),
 meaning it resumes having the "no rate limit, no bandwidth accounting"
 original behavior. That's no good, and we've hit this bug in practice
 because of a Snowflake bug (#33157).

 I propose three fixes:

 (A) In our documentation for setting up bridges, make it clear that
 setting an ExtORPort to go with your server-side PT is not just for user
 count statistics, but it is needed if you want rate limiting and proper
 bandwidth accounting and reporting.

 (B) We could go farther here and tell server-side pluggable transports to
 demand an ExtORPort from Tor (i.e. refuse to start if you aren't given
 one). I think this is a good idea, but let me know if you see downsides.

 (C) Do something smart with connections over the ExtORPort if they show up
 without a USERADDR command. I don't know of any concrete reasons why
 picking a dummy non-internal probably-not-routable address like
 255.255.255.255 would break things, but also this is a fine opportunity to
 do something that doesn't leave future generations shaking their fist at
 us. For example: add a flag to connection_t called
 is_external_for_rate_limiting (or a catchier paint color name) where if
 it's 1 then yes it's external, and if it's 0 then you have to go check the
 address like before. And then eventually we'd transition more of Tor to
 use that flag, rather than recomputing whether to apply rate limiting many
 times over the course of a connection's lifetime.

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