[tor-bugs] #24902 [Core Tor/Tor]: Denial of Service mitigation subsystem

[Tor Bug Tracker & Wiki]

#24902: Denial of Service mitigation subsystem
-------------------------------------------------+-------------------------
 Reporter:  dgoulet                              |          Owner:  dgoulet
     Type:  enhancement                          |         Status:
                                                 |  needs_review
 Priority:  Very High                            |      Milestone:  Tor:
                                                 |  0.3.3.x-final
Component:  Core Tor/Tor                         |        Version:
 Severity:  Normal                               |     Resolution:
 Keywords:  ddos, tor-relay, review-group-30,    |  Actual Points:
  029-backport, 031-backport, 032-backport       |
Parent ID:                                       |         Points:
 Reviewer:                                       |        Sponsor:
-------------------------------------------------+-------------------------

Comment (by dgoulet):

 Replying to [comment:24 teor]:
 > > What I'm wondering is if the fact that we don't send CREATED back
 makes the client switch Guard faster?
 >
 > Tor2web clients don't use guards for any HS circuits. They're all direct
 connections to a randomly selected rend point. With no bandwidth
 weighting.

 This was not about tor2web clients. The largest part of the DoS is actual
 regular clients doing large amount of circuits and thus EXTEND2 arrive at
 the Guard in huge numbers. Previously, we would reject and close the
 circuit once we see a first cell. Now, this branch doesn't send back
 CREATED.

 >
 > Replying to [comment:23 dgoulet]:
 > > Just did an experiment with a tor2web client with my relay pinned as
 the RP. Because it is the only RP available, the tor client happily
 retries *non* stop to connect to a working RP until the `SocksTimeout`
 that is 120 seconds by default. In this case, it creates many circuits to
 the same RP.
 > >
 > > I think Roger opened a ticket recently about making tor client try to
 remember failing relays for specific things.
 > >
 > > So just keep in mind that we'll have a _lot_ of tor2web clients trying
 every relays on the network if this defense becomes a thing everywhere.
 >
 > Maybe avoiding the CREATED cell is not the best defence.

 For the tor2web defense, right now it is refusing `ESTABLISH_RENDEZVOUS`
 from client connections and closing the circuit.

 >
 > Reading circuit_expire_building(), Tor2web should time out on a
 rendezvous after 15 seconds:
 > {{{
 > SET_CUTOFF(stream_cutoff, MAX(options->CircuitStreamTimeout,15)*1000 +
 1000);
 > }}}
 >
 > We need to find a Tor2web defence that triggers some kind of delay on
 the client side. Our options are:
 > * close the connection immediately (no delay?)

 This is what is happening at the `ESTABLISH_RDV` cell is seen.

 > * ignore all cells (min 500ms, initial 1500ms or cbtmintimeout consensus
 parameter)
 > * ignore CREATE cells (min 500ms, initial 1500ms or cbtmintimeout
 consensus parameter)
 > * ignore ESTABLISH_RENDEZVOUS cells (min 15s)
 >
 > I think we should send back CREATED, and ignore the
 ESTABLISH_RENDEZVOUS, because that gets us a guaranteed minimum 15 second
 timeout.

 Hmmm so dropping the cell instead of sending back a DESTROY. Sounds
 promising! And if these are in large numbers of connections, the second
 defense will kick in that is the "max concurrent connection".

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