Subject: Re: [lisp] Need comments on LISP Threats Analysis

From: [email-masked] (Noel Chiappa)
Date: Wed, 20 Mar 2013 21:47:37 -0400 (EDT)

> From: Ronald Bonica <[email-masked]>

    > 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.

	Noel

---

From: Darrel Lewis <[email-masked]>
Date: Thu, 21 Mar 2013 08:27:35 -0700

> 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

---

From: Ronald Bonica <[email-masked]>
Date: Thu, 21 Mar 2013 17:18:19 +0000

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-masked] [mailto:[email-masked]] On Behalf Of
> Darrel Lewis
> Sent: Thursday, March 21, 2013 11:28 AM
> To: Noel Chiappa
> Cc: [email-masked]
> Subject: Re: [lisp] Need comments on LISP Threats Analysis
> 
> 
> > 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):
> >
> > 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'
> 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.
> 
> _______________________________________________
> lisp mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/lisp