#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


 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

 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

Reply via email to