[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]
Re: [tor-bugs] #25248 [Core Tor/Tor]: DoS mitgation: improve documentation
#25248: DoS mitgation: improve documentation
-------------------------------------------------+-------------------------
Reporter: cypherpunks | Owner: dgoulet
Type: enhancement | Status:
| needs_review
Priority: Medium | Milestone: Tor:
| 0.3.3.x-final
Component: Core Tor/Tor | Version:
Severity: Normal | Resolution:
Keywords: tor-dos, manpage, tor-doc, | Actual Points:
033-triage-20180320, fast-fix, |
033-included-20180326 |
Parent ID: | Points:
Reviewer: mikeperry | Sponsor:
-------------------------------------------------+-------------------------
Changes (by dgoulet):
* status: needs_revision => needs_review
Comment:
Replying to [comment:8 mikeperry]:
> Ok, I read the whole section and I have a few questions/comments:
>
> 0. "Tor has 3 build-in mitigation options" -> "Tor has three built-in
mitigation options"
Fixed! 3cca21d86b
> 1. It is not clear how DoSCircuitCreationBurst applies. Does that
counter get reset every time the values in DoSCircuitCreationRate and
DoSCircuitCreationMinConnections fall above/below their threshold? So that
first, a client IP has to exceed DoSCircuitCreationMinConnections, and
then exceed DoSCircuitCreationRate, and then we start counting to 90
circuits for that IP? If so, we should state that. If not, we should state
how bursts are counted and if/when that counter is reset.
It goes like this. If the relay reaches `DoSCircuitCreationMinConnections`
for a client IP address, the defense is activated that is we start looking
at the circuit rate. Before that, whatever rate you have, we let go.
The bucket value is set to `DoSCircuitCreationBurst`. We use the
`DoSCircuitCreationRate` to refill the bucket. If the bucket values goes
down to 0, we consider it a positive detection.
So the bucket is refilled opportunistically when a new CREATE cell is seen
using the timestamp we last refilled it. If you go down
`DoSCircuitCreationMinConnections`, the values stay as is if you ever go
up that threshold again, because the timestamp is further in the future,
you will max out your bucket at the first CREATE cell. But if you flap
very quickly, we'll still have the counters to what we were before so an
attacker can't game it by resetting the counter on purpose.
Not sure what you would like to see in the man page out of the above?
>
> 2. We should also state that the names for the consensus parameters are
the same as the torrc names. This is not always the case.
They are all the same that is torrc options and consensus parameter. And
they all specify that they also obey a parameter.
>
> 3. Can we include a statement about log lines people can check for to
see if these limits are being hit on their relay? If they are warns, then
just saying Tor will emit a warning is enough. If they are notices, then
maybe we should have either the log string, or something people can grep
for?
Good idea. Fixed. 3cca21d86b
>
> 4. This section should be right below the SERVER OPTIONS section, since
that is what they are. The first paragraph should also say that these
options are for Tor relays/servers (and not for onion services who may be
under DoS, which could be another point of confusion here).
Commit `2955e48ace`
>
> 5. Do we also want a dos-spec.txt with this info in torspec.git? I could
see some of this stuff being moved to such a place and being cited
instead. I don't feel super strongly about this, though.
Wouldn't be a stupid idea because then anyone can start from there to
propose DoS mitigation improvements in the form of a proposal.
Still in `ticket25248_033_01`
--
Ticket URL: <https://trac.torproject.org/projects/tor/ticket/25248#comment:9>
Tor Bug Tracker & Wiki <https://trac.torproject.org/>
The Tor Project: anonymity online
_______________________________________________
tor-bugs mailing list
tor-bugs@xxxxxxxxxxxxxxxxxxxx
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs