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.
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.
One of my concerns with the categorization is that the various practices
needed to counter different threats are not inherently consistent. or
are they always generally applicable. (Some of them are just plain good
advice. Some of them are good advice for internet deployment. Some are
good advice for VPN deployments.) So will the reader be able to tell
whether he is at risk for a given attack, and what he should be doing
for his problem space while still keeping an effective and operable LISP
infrastructure?
Yours,
Joel
On 3/20/2013 2:55 PM, Dino Farinacci wrote:
From: Ronald Bonica <[email protected]>
3) query the map cache for each packet. If no entry exists, discard the
packet and query the map server
If you choose Option 3, won't the victim ETR map cache overflow?
We've been over this ground about 18 times, haven't we?
Answer #5: Don't have a fixed-sized cache. Then it cannot overflow.
Yep, you are right Noel.
Just like the BGP RIB does not have a fixed-size cache. So what happens when
there is no memory for BGP, ditto for LISP. There is no magic here folks.
Dino
Noel
_______________________________________________
lisp mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/lisp
_______________________________________________
lisp mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/lisp
_______________________________________________
lisp mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/lisp
