[ratelimits] rrl mention in an nlnetlabs tech report

[Yasuhiro Orange Morishita / 森下泰宏]

Hello, Matthijs-san,

> The presentation on the RRL report is here:
>     http://rp.delaat.net/2012-2013/p29/presentation.pdf

Thank you for your pointed out.  I will read it.

BTW, I've read your presentation already.
<http://www.guug.de/veranstaltungen/ffg2013/talks/DNS_Rate_Limiting__Matthijs_Mekking.pdf>

I think it's one of the best presentation for describing and
understanding RRL.

We have cited your presentation as [MEKKING2013] on our technical
document about DNS reflector attacks and RRL (it's written in Japanese).
<http://jprs.jp/tech/notice/2013-04-18-reflector-attacks.html>

Thanks and regards,

-- Orange

From: Matthijs Mekking <matthijs at nlnetlabs.nl>
Date: Mon, 26 Aug 2013 09:52:14 +0200

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