[tor-bugs] #24902 [Core Tor/Tor]: Denial of Service mitigation subsystem
Tor Bug Tracker & Wiki
blackhole at torproject.org
Mon Jan 29 17:15:13 UTC 2018
#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, |
review-group-31 |
Parent ID: | Points:
Reviewer: arma | Sponsor:
-------------------------------------------------+-------------------------
Changes (by dgoulet):
* reviewer: => arma
Comment:
First, I had to do a fixup unrelated to the review: `9d2699cad0`
Replying to [comment:43 arma]:
> Should we use END_CIRC_REASON_RESOURCELIMIT instead?
Good point. Fixup commit `2d9b285f98`.
> But it looks like the call to dos_should_refuse_single_hop_client()
doesn't care whether public_server_mode().
Agree. Fixup commit: `ab7b9581f3`
> get_circuit_rate_per_second() still isn't doing what I think you wanted.
Yah so thanks to Hello71 on IRC, I realized that there was an issue indeed
and all your "Edit:" were indeed discussed and proposed by Hello71 :).
I kind of think dropping the "tenths" would be good because, as you said,
at best we can fill the bucket every second (approx_time()). So everything
is rounded off to the second anyway. And a considerable time gap between
CREATE cell will make a small difference which probably won't matter at
that point.
Thus, going to a number of circuit per second instead of "tenths" seems
the improvement to do.
What about this commit? `2106a5eaa8`
> (a) should be "Number of allocated circuits remaining for this address",
i.e. it's not a rate, it's a size.
Fixup commit: `c7099765b4`
> (b) What's this about "plus a bit of random"? :)
Don't know what you are talking about, I can't find this string in the
code :S ...
> In the future, I plan to advocate for merging dos_cc_new_create_cell()
and dos_cc_get_defense_type() into a single function, which notes the
existence of the new create cell and also tells us whether to apply a
defense. And I plan to advocate for a second cc defense, which returns
DOS_CC_DEFENSE_REFUSE_CELL simply when stats->cc_stats.circuit_bucket ==
0, without any marking or checking of stats->concurrent_count. I think I
will want to instrument a real relay to see how often it would trigger
that new defense, though, and I am happy to delay my future plans so we
can get this patch out the door.
Agree on both! Once we get this merged, lets open tickets for that!
Final fixup on the man page (thanks to Hello71!): `1b8835fccd`
--
Ticket URL: <https://trac.torproject.org/projects/tor/ticket/24902#comment:48>
Tor Bug Tracker & Wiki <https://trac.torproject.org/>
The Tor Project: anonymity online
More information about the tor-bugs
mailing list