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

[Matthijs Mekking]

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".

> 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
>