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

Tor Bug Tracker & Wiki blackhole at torproject.org
Thu Jan 18 12:57:03 UTC 2018


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

Comment (by asn):

 OK I did a basic review of the code and the design.

 I think the current code complexity stems from the slot/bucket design, and
 splitting the time periods into slots, marking them, and assessing the
 circuits based on slots. I think without the slot system the logic could
 be as simple as:

 {{{
 -> for every new circuit of this IP, nr_of_circuits++;
 -> every N seconds, reset nr_of_circuits for this IP.
 if (nr_of_circuits > magic_number) {
    return DROP;
 }
    return GOOD;
 }}}

 I understand that the slot design can eventually allow us to even block
 attackers with a single connection while allowing normal clients to do
 circuits bursts, but I'm questioning whether the complexity is worth it.
 Furthermore, it's possible that the slot system can be exploited by
 attackers, by really going all out during some 30 second slots, and
 staying more chill for the rest of them, and still getting a pass for the
 entire time period.

 If we kill the slot system, we will get a '''very''' simple system but it
 will be less versatile, and we will need to have a bigger `magic_number`
 to be able to keep our false positives at a reasonable rate.

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


More information about the tor-bugs mailing list