[ratelimits] false positive text
Matthijs Mekking
matthijs at nlnetlabs.nl
Thu May 16 14:38:40 UTC 2013
To avoid confusion about what a false/true positive/negative is, it
might be good to write down the definitions within the context of RRL.
This is a first stab.
Response rate limit tries to limit the amount of DNS responses triggered
by attack queries. Identifying an attack query is a nontrivial task and
implementations may suffer from false positives and false negatives.
A false positive is a packet that is identified as an attack query, when
really the packet is legitimate. The legitimate user does not get a
response, or it gets a truncated response.
A true positive is a packet that is correctly identified as an attack
query. Again, the response is dropped, or a truncated response is sent
to the victim.
A false negative is a packet that is identified as a legitimate query,
when really the packet is an attack query. The (amplified) response is
being reflected to the victim. The first queries at the start of an
attack will most likely always be false negatives.
A true negative is a packet that is correctly identified as a legitimate
query. The response is sent to the legitimate user.
To mitigate the effect of a false positive, truncated responses can be
sent instead of dropping the responses. This will reduce the
amplification of the attack. The SLIP parameter can be used to set the
ratio of truncated responses per dropped responses.
[I just saw that the technical note has replaced SLIP with LEAK-RATE and
TC-RATE]
[Might need text on how much false positives/negatives are acceptable or
expected]
More information about the ratelimits
mailing list