> From: "Joel M. Halpern" <[email protected]>
> By assumption, the cache is not big enough to hold the whole mapping
> table (otherwise it would not be subject to overflow).
I'm not sure this is accurate (but I concede it will depend on the
implementation).
The chief reason (at least, in my mind) that LISP uses a pull-based control
plane is not the sheer size of the mapping database (memory is, after all,
cheap and plentiful these days), but rather the control traffic overhead
implications - in particular, the issue of the overhead required to maintain
(in particlar, updating, which is not a one-time-only cost) never-used
entries.
The local copy of mapping information in the ITRs is described as a cache
because it is demand-loaded. Many (most?) caches that people come across are
size-limited, so I think there is an _assumption_ on people's parts that the
LISP cache is also size-limited, but I don't think there is any particular
reason that this must always be so.
If nothing else, size-limiting the cache means one has to code up a discard
algorithm, etc. Now, it may be that the wise programmer will have some
mechanism for running out of memory for the cache (and I wonder what, e.g.,
BGP implementations do for this circumstance), and perhaps forcing a box into
that operating regime is an attack vector.
Can people who maintain existing implementation tell us if they do in fact
have a maximum cache size, and if so, something about what their
retention/discard algorithm is? Also, how do they deal with running out of
memory?
Also, there was an extensive discussion on the mailing list about a year or
so ago of cache designs, for size-limited caches, which would avoid knocking
the 'real' entries out (in favour of the attacker's 'not-really-used'
entries); if the document didn't pick up some of that (sorry, haven't had the
time to read it yet), it could probably usefully do so.
The other consideration is that even if the box does not hit a memory limit,
an attack of the kind you describe will increase the load on the control
plane (for loading all the extra mappings) above and beyond its normal load.
this may be worth mentioning, and exploring (if it's not already discussed
- again, sorry, haven't read the ID yet).
I seem to recall that there are already rate limits on the control traffic
from any given ITR? If so, one would expect that the primary 'victim' of such
rate limiting would be the 'bad guy' (unless an attack of this sort happens
as a box is starting), since most of the 'new' requests will be those of the
attacker, so it will mostly be their mapping requests which are dropped.
Yes, this may interfere with the operation of the ITR for real users who are
going 'new' places - if that turns out _in practice_ to be a problem, perhaps
there is some way to isolate such traffic? If we assume that only one (or a
small number) of hosts inside the LISP region (served by that ITR) are the
source of bogus traffic (intended to overflow/dilute the cache), then if an
ITR keeps a 'request count' per source host (yes, more state, and more work
to maintain it, but...), it could rate-limit requests per source.
Since this does not require any _protocol_ changes, we can probably put off
implementing such measures until it proves to be an actual problem in service
- but its probably worth mentioning all this in the I-D.
Noel
_______________________________________________
lisp mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/lisp
