<html><head>
<meta content="text/html; charset=ISO-8859-2" http-equiv="Content-Type">
</head><body text="#000000" bgcolor="#FFFFFF">can i ask, as before, that
we all implement the same idea for now, just to give our deployers a
chance to have all of their servers work the same way? if there's a flaw
in the rrl spec, let's discuss it immediately. if there are better
ideas, let's discuss those less immediately.<br>
<br>
in particular, any rrl attempt that uses simple buckets rather than
bucket chains, is going to alias many tuples into one set of counters,
and thus be incorrect per the current spec. the spec does not call for
hashing at all, but what it does say is that the set of counters shall
be denoted by a certain tuple. if you're denoting by a shorter tuple,
you're not implementing rrl.<br>
<br>
bands, classifiers, separate limits for large responses, are all ideas
worth considering... later, after we've got feature parity.<br>
<br>
paul<br>
<br>
re:<br>
<br>
Marek Vavruša wrote:
<blockquote
cite="mid:CACgotOQQQS17B5i=YRfGwYXpU-VOTGOMe8PSFLd_rD53+ysxVA@mail.gmail.com"
type="cite">
<pre wrap="">Hi Matthijs,
at first, I was thinking of having multiple bands instead of just
"positive" response.
Similar to a traffic shaping problem where you prioritize smaller packets.
I currently use 1k as a threshold for large packets.
The original idea was - the "smaller" class yields larger portion of
the rate and vice versa.
Thinking about it, it seems quite reasonable and trivial to classify.
Marek
On 4 March 2013 13:50, Matthijs Mekking <a class="moz-txt-link-rfc2396E" href="mailto:matthijs@nlnetlabs.nl"><matthijs@nlnetlabs.nl></a> wrote:
</pre>
<blockquote type="cite"><pre wrap="">Hi Marek,
I like the idea of having a classification of large responses. It seems
that the current RRL algorithm does not perform well if an attack is
able to trigger various positive responses[1]. I agree that such
performing such an attack is more complex than an ANY or NXDOMAIN
attack, but it is certainly feasible (especially with NSEC).
What do you consider large?
Adding weight to the classes is a direction that we should definitely
can look into. I guess the "penalty points" used in the Dampening
proposal can form a good base for that.
[1]
<a class="moz-txt-link-freetext" href="http://www.nlnetlabs.nl/downloads/publications/report-rrl-dekoning-rozekrans.pdf">http://www.nlnetlabs.nl/downloads/publications/report-rrl-dekoning-rozekrans.pdf</a>
Best regards,
Matthijs
On 03/01/2013 06:11 PM, Marek Vavruša wrote:
</pre><blockquote type="cite"><pre wrap="">Hi again,
regarding the previous announcement, I also have some remarks I'd like
to share and a few questions open to discussion.
As it's based on the RRL memo, it shares all the common traits - token
bucket algorithm, hashtable for buckets etc., so I'll just name what's
different. We classify responses into a several groups like positive
answers, empty, errors, nxdomain, wildcard, ANY and also
DNSSEC-related (like when the qtype is for RRSIG, DNSKEY etc.). We
also have a class for large answers (if it doesn't fall into any
special class), as the attacker may exploit basically any type in the
zone depending on the contents (TXT for example). I also thought about
the idea of adding some weights to the classes (like "small response"
class could get better rate than a large packet, amplification factor
could be a good metric for this).
But it didn't get implemented, as I wasn't sure whether it would be
worth the extra complexity. Any thoughts?
Rest is probably more/less quite similar.
Second thing is, how are the buckets stored. We chose a fixed-size
hashtable as in the NSD with no chaining, but handle the collisions
differently.
Because, if the seed (for hashing) is known in advance and the
attacker knows a sufficient number of names in the zone, it is
possible to precalculate the colliding packets and constantly reset
the rate in a bucket, avoiding being limited. Neat hashtable size
and a weaker hash function also doesn't help. We introduced a
randomized seed in a hash and also, when a collision occurs,
bucket enters a "slow-start" mode in which it receives a lesser rate
and cannot reset again for a 1 time frame. This is to avoid subsequent
collisions like described. Did anyone experience this? Another
question is whether this is worth bothering, as there are other
inherent and easier weaknesses.
Ugh, sorry for the long post.
Have a nice weekend,
Marek
--
Marek Vavrusa Knot DNS
CZ.NIC Labs <a class="moz-txt-link-freetext" href="http://www.knot-dns.cz">http://www.knot-dns.cz</a>
-------------------------------------------
Americka 23, 120 00 Praha 2, Czech Republic
WWW: <a class="moz-txt-link-freetext" href="http://labs.nic.cz">http://labs.nic.cz</a> <a class="moz-txt-link-freetext" href="http://www.nic.cz">http://www.nic.cz</a>
_______________________________________________
ratelimits mailing list
<a class="moz-txt-link-abbreviated" href="mailto:ratelimits@lists.redbarn.org">ratelimits@lists.redbarn.org</a>
<a class="moz-txt-link-freetext" href="http://lists.redbarn.org/mailman/listinfo/ratelimits">http://lists.redbarn.org/mailman/listinfo/ratelimits</a>
</pre></blockquote><pre wrap="">
</pre></blockquote>
<pre wrap=""><!---->_______________________________________________
ratelimits mailing list
<a class="moz-txt-link-abbreviated" href="mailto:ratelimits@lists.redbarn.org">ratelimits@lists.redbarn.org</a>
<a class="moz-txt-link-freetext" href="http://lists.redbarn.org/mailman/listinfo/ratelimits">http://lists.redbarn.org/mailman/listinfo/ratelimits</a>
</pre>
</blockquote>
</body></html>