On Mar 20, 2013, at 6:47 PM, Noel Chiappa wrote: >> From: Ronald Bonica <[email protected]> > >> So far in our discussion, we have mention a few possible mitigations. > > Forgive me if I'm being repetitive, but is the following on the list (sorry, > a bit distracted at the moment, not keeping up with the thread): > > - A fixed size cache, with a 'good' cache management algorithm. > > Simple LRU would not be 'good', as if the cache is being thrashed fast > enough, you might lose useful entries. > > When this first came up a couple of years back (too lazy to look for it in > the archives, sorry), I had suggested (IIRC) a two-level cache, where entries > were only promoted to the second level when they'd been used a certain number > of times; that way, only the first level could be thrashed by a DoS attack. > > But in retrospect, that's probably more complex than it needs to be: an aged > usage counter system would probably be good enough. Entries that got loaded > as part of a DoS attack would presumably not be used as much as 'real' > entries, and would be preferentially discarded.
Another useful piece of information would be _which EID instigated_ the map request. If a host behind an ITR is under a randomly sourced syn flood, all the map-requests generated by that host could be treated as a lower priority (and aged out faster) than those cache entries instigated by other hosts. There are, literally, dozens of techniques to optimize a cache that is under pressure from DoS attacks. -Darrel _______________________________________________ lisp mailing list [email protected] https://www.ietf.org/mailman/listinfo/lisp
