[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