[dns-operations] bind-9.9.3rc2 ANY+TCP patch

[Matthijs Mekking]

On 05/16/2013 03:31 PM, Matthijs Mekking wrote:
> On 05/16/2013 02:54 PM, Vernon Schryver wrote:
>>> From: Matthijs Mekking <matthijs at nlnetlabs.nl>
>>
>>>>> 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    vjs at rhyolite.com
>> _______________________________________________
>> dns-operations mailing list
>> dns-operations at lists.dns-oarc.net
>> 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
> dns-operations at lists.dns-oarc.net
> https://lists.dns-oarc.net/mailman/listinfo/dns-operations
> dns-jobs mailing list
> https://lists.dns-oarc.net/mailman/listinfo/dns-jobs