Joel, Think that you have hit the nail on the head. So far in our discussion, we have mention a few possible mitigations. These are:
- Option #3, as mentioned in the threats document - Option #4, as mentioned by Dino - Option #5, as mentioned by Noel - possibly an Option #6, as proposed by Dino in http://www.ietf.org/mail-archive/web/lisp/current/msg04417.html Ideally, we know which option is best in each deployment scenario. If this is the case, we should capture what we know in the threats document. However, it is possible that we aren't in a position to give such concrete guidance, but, as Noel suggests: "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'. If so, we should say that in the document. (Naturally, we will need to polish the language before capturing it in a document.) IMHO, making neither of the statement above leaves the reader with a false sense of understanding (and security). Ron > -----Original Message----- > From: [email protected] [mailto:[email protected]] On Behalf Of > Joel M. Halpern > Sent: Wednesday, March 20, 2013 3:03 PM > To: Dino Farinacci > Cc: Noel Chiappa; [email protected] > Subject: Re: [lisp] Need comments on LISP Threats Analysis > > 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
