#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@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs