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

 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.

 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?)
 * 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.
 We could increase the cbtmintimeout consensus parameter to a really high
 value. (Which seemed to work well on my relays.) But the client's timeout
 would only stay high if almost all relays delayed almost all circuits
 created by these clients.

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