[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 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.

 >
 > 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.

 ok


 > I think randomising the sockets we close is the hardest algorithm to
 exploit, because the attacker can't know which sockets were going to close
 next.

 sure, agree next comment above

 > 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?

 > We should also assign a threshold value, so we keep a few directory
 sockets. (150 seems like a good threshold for relays, because they do
 approximately 7000 relays / 96 descriptors per request * 2 requests for
 descriptors, when they don't have any cached descriptors.)

 Have some hard data that suggest this may be unnecessary, can share
 privately.

 > 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.

 > We should also try to think of any other kinds of essential sockets,
 that we don't want to close.

 In the current implementation, only OR, DIR and EXIT connection types are
 considered--all other types are exempt.

 Please take a fifteen minutes to read the one function pick_oos_victims().

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