Darrel,
It sounds like there is an Option #7, Use such-and-such cache management
algorithm.
So far, I am happy with Options #4, #5, #6, and #7. We should capture them in
the document.
Ron
> -----Original Message-----
> From: [email protected] [mailto:[email protected]] On Behalf Of
> Darrel Lewis
> Sent: Thursday, March 21, 2013 11:28 AM
> To: Noel Chiappa
> Cc: [email protected]
> Subject: Re: [lisp] Need comments on LISP Threats Analysis
>
>
> 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
_______________________________________________
lisp mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/lisp
