I agree that having a fixed cache-size can always result in an overflow, even from legitimate traffic.
Then IMHO we should try to answer two questions: 1) What is legitimate traffic? If any node behind an xTR is legitimate to generate traffic and hence, trigger Map-Requests, then we should stick to the best-effort policy, and when the limited cache-size is overflown drop entries in the map-cache. In this context we have published a paper than analyzes the hit rate vs. the cache-size considering internet-like traffic. http://personals.ac.upc.edu/acabello/Albert_Cabellos/Publications_files/LISP%20Cache.pdf 2) How can we mitigate such "attacks"? For this, there is a huge amount of literature dealing with cache eviction policies. Besides that, we are also preparing a study on this, for the specific case of LISP and considering Internet-like traffic, I´ll be happy to share it when it´s ready. However I agree that different solutions should be considered for different scenarios. Albert On Mar 20, 2013, at 3:02 PM, Joel M. Halpern <[email protected]> wrote: > 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 _______________________________________________ lisp mailing list [email protected] https://www.ietf.org/mailman/listinfo/lisp
