Noel, Good discussion, I don't mean to be exhaustive here, because first of all there is so much research (and practical implementations) of these algorithms that I don't feel its possible, and second, I think trying to appear exhaustive might preclude further innovation by implementers.
I encourage everyone actively thinking about this to investigate the information that Albert posted to the list, I find the work that his team of researchers have been working on very interesting. One comment inline: <snip> > > Interesting. > > This again would make the mapping entries larger, but it is probably worth > doing, because it would allow one to actually cut out the control plane load > from such DoS attacks, a significant cost. (The control plane load is > probably actually the worst part of such attacks, actually.) > > You'd have to build a database of requestors, and in each entry, have a count > of the number of mappings that were discarded after a while, without a > significant usage count (this count too should probably be aged). Once a host > had tripped a certain level, it would go in a 'request rate limited' penalty > box. > > Although I guess if you have the requestor database, you could just use it to > count mapping requests directly (again, aged) which will avoid the overhead > of per-mapping-entry source information - too-active requestors could be > individually rate-limited (as above). An ITR must have to have a request database (in order to match replies to request nonce's if nothing else) so extending that to include the things you talk about above seems straightforward. > > And if you did that, you could probably avoid the 'load time' thing above; > rate-limiting requestors directly would be the primary line of defence, and > the cache would only need a simple aged usage count to filter out the (fewer) > DoS'd entries. You got it. Again, products such as Arbor and (now, regrettably, gone) Riverhead have been using such algorithms to protect state machines for more than a decade. -Darrel _______________________________________________ lisp mailing list [email protected] https://www.ietf.org/mailman/listinfo/lisp
