> From: "Joel M. Halpern" <[email protected]>
> Well, there are regular reports of folks taking down BGP sessions
> because they exceed the number of prefixes they can handle.
> And LISP EIDs are more granular and varied than BGP prefixes usually
> are. So it does seem a reasonable question to ask how we will protect
> ourselves against this sort of problem.
Sure, but cache overflow (of a fixed size cache) might happen in _regular_
operation, too, not just under attack. Not that that's a real answer, I know,
but this whole notion of it being looked at only as an attack vector seems
slightly horse-blinkered to me.
More importantly, a cache is considerably more robust than a table, where
correct operation demands that one _must_ have the entire table at hand; cache
overflow just means the cache hit rate goes down some, and the control traffic
rate goes up some. Sure, an attack will thrash the cache, but it's not clear
what effect this will have - a well designed cache might show only a slight
performance degradation.
And I don't think there would be any _protocol_ changes needed to deal with
such a thing, just implementation changes. And since we don't normally
mandate implementation details, why can't we just say 'here's this thing -
make sure your implementation deals with it if it happens'.
> It is true that a device with enough local memory for the whole mapping
> table is, by definition, not subject to this kind of attack. But it
> seems doubtful that we can expect most ITRs or ETRs to have that much
> memory.
Really? At one point in time, serious discussion was given to approaches that
mandated holding the whole table (NERD). And we just had a discussion about
pull versus push, which kind of implies that push was a viable option - and
push requires a complete table.
Which is part of why I have this virtual 'roll my eyes' reaction whenever this
point comes around yet again...
Noel
_______________________________________________
lisp mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/lisp
