[ratelimits] Remarks regarding the Knot DNS 1.2.0 RRL implementation

Matthijs Mekking matthijs at nlnetlabs.nl
Mon Mar 4 12:50:01 UTC 2013


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]
http://www.nlnetlabs.nl/downloads/publications/report-rrl-dekoning-rozekrans.pdf

Best regards,
  Matthijs


On 03/01/2013 06:11 PM, Marek Vavruša wrote:
> 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 http://www.knot-dns.cz
>  -------------------------------------------
>  Americka 23, 120 00 Praha 2, Czech Republic
>  WWW: http://labs.nic.cz http://www.nic.cz
> _______________________________________________
> ratelimits mailing list
> ratelimits at lists.redbarn.org
> http://lists.redbarn.org/mailman/listinfo/ratelimits
> 


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 553 bytes
Desc: OpenPGP digital signature
URL: <http://lists.redbarn.org/pipermail/ratelimits/attachments/20130304/8f1154ff/attachment.pgp>


More information about the ratelimits mailing list