[tor-bugs] #32794 [Core Tor/Tor]: improve OOS (out-of-sockets) handler victim selection and more

[Tor Bug Tracker & Wiki]

#32794: improve OOS (out-of-sockets) handler victim selection and more
--------------------------+------------------------------------
 Reporter:  starlight     |          Owner:  starlight
     Type:  defect        |         Status:  assigned
 Priority:  Medium        |      Milestone:  Tor: 0.4.4.x-final
Component:  Core Tor/Tor  |        Version:  Tor: 0.4.2.5
 Severity:  Normal        |     Resolution:
 Keywords:  security      |  Actual Points:
Parent ID:                |         Points:
 Reviewer:  nickm         |        Sponsor:
--------------------------+------------------------------------

Comment (by teor):

 Replying to [comment:22 starlight]:
 > Replying to [comment:19 teor]:
 > > It's also worth thinking about onion services and single onion
 services here. A busy onion service may look similar to a bridge, from the
 perspective of the upstream hop: both open lots of circuits.
 >
 > Will appreciate some big picture help on how to figure bridges and
 single onions services, can drill into the details on my own if I have a
 general picture.

 Bridges and onion services try to look like clients, for anonymity
 reasons. If you find a reliable distinguisher, we'll try to fix it,
 because it's a security issue:

 Replying to [comment:17 nickm]:
 > 2. Checking whether a connection's identity_digest is zero will not
 always do what we want.  First, bridges do not set their identity digest,
 even though a bridge may have circuits from multiple users.

 However, busy bridges and onion services should only have one connection
 to your relay. So they shouldn't be taking up very many sockets at all.

 I think it's ok to have a bucket that's [client-OR (including onion
 services, bridges), exit, dir, OR-OR low consensus weight]. We just need
 to document where the onion services and bridges go, so people don't
 assume they're protected (like [OR-OR good consensus weight]).

 Replying to [comment:22 starlight]:
 > Replying to [comment:19 teor]:
 > > Also, bridges and onion services can experience a socket DoS, too. We
 should think about how this algorithm might work for them, even if we
 don't activate it right now.

 Bridges can use two buckets: [bridge-OR outbound] and [OR-bridge inbound,
 clients, onion services]. Bridges don't support exiting or DirPorts. OR-
 bridge inbound connections are reachability circuits, or a DoS via another
 relay. So they are not important.

 Onion services shouldn't have socket issues, because they use guards.

 Single onion services could also use two buckets: [long-term intro,
 directory fetches, HSDir posts] and [rendezvous]. Rendezvous connections
 are a big DoS risk. Keeping the long-term intro connections, directory
 fetches, and HSDir posts is important to keep the service online.

 You don't have to make these changes, but the code should be designed so
 it's easy to change the way we filter connections. (You don't have to do a
 redesign, either - we can do that if we decided to merge.)

 > > We may want to assign a lower probability to sockets that we have
 recently opened to fetch directory documents, and connections on which we
 are currently fetching directory documents. (Attackers can occupy these
 sockets using a slowloris attack, so we should still be prepared to close
 them, if we have a lot of them open.)
 >
 > something like a time-decaying rate as a negative priority factor, with
 a countervailing longer-horizon-and-higher-consumption positive priority
 factor?

 Directory fetches will either be OR-OR, or be an outbound directory fetch.

 So we could do:

 [OR-OR good consensus weight, outbound directory fetches], and [client-OR
 (including onion services, bridges), exit, inbound DirPort, OR-OR low
 consensus weight].

 > > Remember, relays can use remote DirPorts and ORPorts for directory
 fetches, the code should handle both.
 >
 > Again, a few big picture hints on how to figure will help.

 I think dir_connection_t.dirconn_direct is pretty much what you want here:

 https://github.com/torproject/tor/blob/master/src/feature/dircommon/dir_connection_st.h#L31

 Again, you don't have to make that change, be we should make it before we
 merge.

 Replying to [comment:23 starlight]:
 > Replying to [comment:21 teor]:
 > > Is there an overview of this design somewhere?
 >
 > above in comment:6
 >
 > > It sounds like this change needs a proposal, or a good description of
 the algorithm used for choosing sockets.
 >
 > I'm a write code that works, then write the RFC kind -- similar to the
 folks who created the Internet (and Tor).

 Fair enough, but tor does have a proposals process now :-)

 You don't have to write the proposal, or the documentation. But someone
 should at least summarise the design before we merge.

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