[ratelimits] rrl mention in an nlnetlabs tech report

[Marek Vavruša]

On 26 August 2013 09:52, Matthijs Mekking <matthijs at nlnetlabs.nl> wrote:

> Hi,
>
> On 08/23/2013 10:13 AM, Yasuhiro Orange Morishita wrote:
> > Hello,
> >
> > I've found a presentation slides made by the author.  Thanks for google.
> > <http://rp.delaat.net/2012-2013/p92/presentation.pdf>
>
> This presentation is not about the RRL measurements. This is a small
> research done by on of our other interns, and is about using Visual
> Analytics to discover DNS abuse.
>

This piqued my interest, is there any research in progress about flow
identification in real time?
I wonder if we could (with some accepted error) differentiate an attack
flow from legitimate queries.
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.
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).


>
> The presentation on the RRL report is here:
>
>     http://rp.delaat.net/2012-2013/p29/presentation.pdf
>
> >
> >> Made by one of our interns.
> >
> > Your intern is great.
>
> To be precise, the research was done by two interns.
>
> Best regards,
>   Matthijs
>

Best,
Marek


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