On 05/16/2013 03:31 PM, Matthijs Mekking wrote:
On 05/16/2013 02:54 PM, Vernon Schryver wrote:
From: Matthijs Mekking <[email protected]>
https://indico.dns-oarc.net/indico/getFile.py/access?contribId=4&resId=0&materialId=slides&confId=0
Page #12
I also wonder about the definition of "false positive." There are many
plausible candidates.
I agree. Basically it is a query from an attacker that is not being
dropped.
That sounds like a "false negative" instead of a "false positive."
That was my first thought as well, but then I thought "what is a
positive?" I consider an attack packet to be a positive that needs
handling. A true positive would then be "dropping an attack packet". A
false positive would then be "letting an attack packet through".
Given the example of a false positive that is on the wikipedia page (a
patient has a disease being tested for when really the patient does not
have the disease), I think I should have sticked with my first thought
and your definitions are correct. So a false positive would be "a packet
is identified as an attack query, when really the packet is legitimate".
A "false positive" would be dropping or "slipping" a legitimate or
non-attack query.
So, I would say a "false positive" is the failure to identify and deal
with an attack packet.
A "true positive" is correctly identifying and dealing with an
attack packet.
Yes.
A "true negative" is correctly identifying and not harming a
non-attack packet.
Yes.
And finally a "false negative" would be incorrectly identifying and
harming a non-attack packet.
https://www.google.com/search?q=false+positive
http://www.mathsisfun.com/data/probability-false-negatives-positives.html
https://en.wikipedia.org/wiki/Type_I_and_type_II_errors
So a false positive is a type I error, aka "the incorrect rejection of a
true". Putting that back in RRL perspective, I translate that to a false
positive is "the failure to identify and deal with an attack packet"
(like above).
Perhaps "Slip 1" on page #12 refers to the RRL parameter. If I assume
"False positives" means "truncated responses" (which are true positives
instead of false positives), then all of the table except the "TCP
responses" column makes sense. I have no idea what "TCP response"
column means.
Yes. This table tries to say (amongst other things) that if you set the
slip parameter to 1, there are zero false positives. Given my
definitions above, this should be zero false *negatives*. In other
words, if you would configure RRL with slip: 1, no packets will be
dropped (all will be responded or slipped) and each non-attack query is
able to get a response.
I know it has more to it than that. It might be a good idea to
define the term in the technical note. I can write some initial text, if
that is appreciated.
I would a appreciate a few words here.
I struggle too with the terminology. During the research I thought of a
positive to be the legitimate packets. Reading on type I and type II, I
think thinking of a positive to be an attack packet makes more sense. I
will send some initial text to the ratelimits list.
Best regards,
Matthijs
I don't understand the graphs and tables, but I agree with the
conclusions on page #20.
Vernon Schryver [email protected]
_______________________________________________
dns-operations mailing list
[email protected]
https://lists.dns-oarc.net/mailman/listinfo/dns-operations
dns-jobs mailing list
https://lists.dns-oarc.net/mailman/listinfo/dns-jobs
_______________________________________________
dns-operations mailing list
[email protected]
https://lists.dns-oarc.net/mailman/listinfo/dns-operations
dns-jobs mailing list
https://lists.dns-oarc.net/mailman/listinfo/dns-jobs
_______________________________________________
dns-operations mailing list
[email protected]
https://lists.dns-oarc.net/mailman/listinfo/dns-operations
dns-jobs mailing list
https://lists.dns-oarc.net/mailman/listinfo/dns-jobs
