<div dir="ltr">On 26 August 2013 09:52, Matthijs Mekking <span dir="ltr"><<a href="mailto:matthijs@nlnetlabs.nl" target="_blank">matthijs@nlnetlabs.nl</a>></span> wrote:<br><div class="gmail_extra"><div class="gmail_quote">

<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi,<br>
<div class="im"><br>
On 08/23/2013 10:13 AM, Yasuhiro Orange Morishita wrote:<br>
> Hello,<br>
><br>
> I've found a presentation slides made by the author.  Thanks for google.<br>
> <<a href="http://rp.delaat.net/2012-2013/p92/presentation.pdf" target="_blank">http://rp.delaat.net/2012-2013/p92/presentation.pdf</a>><br>
<br>
</div>This presentation is not about the RRL measurements. This is a small<br>
research done by on of our other interns, and is about using Visual<br>
Analytics to discover DNS abuse.<br></blockquote><div><br></div><div>This piqued my interest, is there any research in progress about flow identification in real time?</div><div>I wonder if we could (with some accepted error) differentiate an attack flow from legitimate queries.</div>

<div>I mean, assuming that the spoofed packets flow through the same path, the frequency of the the incoming packets should be quite regular + there could be other markers in the IP header.</div><div>All this could be used to calculate the probability of the "slip" (i.e. query that is likely to be a part of the attack would be more likely to be discarded without slipping an answer).</div>

<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
The presentation on the RRL report is here:<br>
<br>
    <a href="http://rp.delaat.net/2012-2013/p29/presentation.pdf" target="_blank">http://rp.delaat.net/2012-2013/p29/presentation.pdf</a><br>
<div class="im"><br>
><br>
>> Made by one of our interns.<br>
><br>
> Your intern is great.<br>
<br>
</div>To be precise, the research was done by two interns.<br>
<br>
Best regards,<br>
  Matthijs<br></blockquote><div><br></div><div>Best,</div><div>Marek</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="HOEnZb"><div class="h5"><br>
><br>
> -- Orange<br>
><br>
>> --Olaf<br>
>><br>
>> PS. other related intern work: <a href="http://www.nlnetlabs.nl/downloads/publications/report-rrl-dekoning-rozekrans.pdf" target="_blank">http://www.nlnetlabs.nl/downloads/publications/report-rrl-dekoning-rozekrans.pdf</a><br>


>><br>
><br>
> From: Olaf Kolkman <olaf@NLnetLabs.nl><br>
> Date: Fri, 23 Aug 2013 10:01:24 +0200<br>
>><br>
>><br>
>><br>
>><br>
>> On 22 aug. 2013, at 20:02, Paul Vixie <<a href="mailto:paul@redbarn.org">paul@redbarn.org</a>> wrote:<br>
>><br>
>>> saw this:<br>
>>><br>
>>>> Another pro-active technique is Response Rate<br>
>>>> Limiting (RRL) [29]. It limits the number of unique<br>
>>>> responses sent by the authoritative server. Roughly,<br>
>>>> it works by keeping track of of several pieces of<br>
>>>> information of the responses. With every subsequent<br>
>>>> request, the name server checks whether the<br>
>>>> response that would be sent exceeds the set limit<br>
>>>> of responses per second per set of information. If<br>
>>>> this is the case, it either responds only once in a<br>
>>>> number of queries (configurable) or it sends a<br>
>>>> truncated (TC-flag set) answer, forcing a legitimate<br>
>>>> resolver to retry the query over TCP. RRL is currently<br>
>>>> the most promising technique and is implemented<br>
>>>> in the most popular name server software like<br>
>>>> BIND [14], NSD [20] and Knot [17]. The effectiveness<br>
>>>> of RRL is debated, it stops unsophisticated<br>
>>>> attacks using reflection.<br>
>>><br>
>>> here:<br>
>>><br>
>>> <a href="http://www.nlnetlabs.nl/downloads/publications/report-rp2-lexis.pdf" target="_blank">http://www.nlnetlabs.nl/downloads/publications/report-rp2-lexis.pdf</a><br>
>><br>
>><br>
>> Made by one of our interns.<br>
>><br>
>> I wonder if you wanted to express something more than "look at this" with the specific quote?<br>
>><br>
>> --Olaf<br>
>><br>
>> PS. other related intern work: <a href="http://www.nlnetlabs.nl/downloads/publications/report-rrl-dekoning-rozekrans.pdf" target="_blank">http://www.nlnetlabs.nl/downloads/publications/report-rrl-dekoning-rozekrans.pdf</a><br>


>><br>
>><br>
> _______________________________________________<br>
> ratelimits mailing list<br>
> <a href="mailto:ratelimits@lists.redbarn.org">ratelimits@lists.redbarn.org</a><br>
> <a href="http://lists.redbarn.org/mailman/listinfo/ratelimits" target="_blank">http://lists.redbarn.org/mailman/listinfo/ratelimits</a><br>
><br>
<br>
_______________________________________________<br>
ratelimits mailing list<br>
<a href="mailto:ratelimits@lists.redbarn.org">ratelimits@lists.redbarn.org</a><br>
<a href="http://lists.redbarn.org/mailman/listinfo/ratelimits" target="_blank">http://lists.redbarn.org/mailman/listinfo/ratelimits</a><br>
</div></div></blockquote></div><br></div></div>