On Jul 11, 2011, at 01:47 , Jeff Wheeler wrote: > On Sun, Jul 10, 2011 at 6:42 PM, Dino Farinacci <[email protected]> wrote: >> or people are too busy to respond. But we, the LISP authors take input very >> seriously. I can speak for myself, we do not want to ignore the mailing > > I suggest you read my post, linked below, discussing cache management > vulnerabilities, and a way to improve upon them. Darrel Lewis is the > only person who has showed any interest in this at all, and there has > been essentially zero public discussion of it. I have also swapped > email with the authors of the lisp-threats draft, who believe this > problem warrants precisely one vague sentence. >
As co-author of that draft, let me say that we acknowledged the problem and proposed to you to add more wording on it, but you were still unhappy. As we told you in our email exchange, the threat draft if is just an analysis. It is not the place where LISP specification should be changed. Indeed in your original email you refer to draft-ietf-lisp-ms-07, why should we modify the security analysis draft? We suggested you that if you feel the problem so important to jeopardize any further LISP deployment just come to the IETF and discuss with us. What would be very helpful is to focus on the technical part and help in design a solution. Let's avoid this continuos "LISP is a pet project", "LISP is broken", etc etc.... this is useless discussion. > http://www.ietf.org/mail-archive/web/lisp/current/msg02949.html > > You can imagine how my view of LISP as a pet project, consuming vendor > personnel / resources on something which may have, at best, VPN > application, came about. IMHO, you fail to see the real potential of LISP. > This is a very obvious problem with a great > deal of history -- many of the people I see working on LISP have been > around since flow-cache routing was popular, and unpopular, certainly > including yourself. Some have not been and have yet to learn some of > the lessons from the 90s. > >> Many researchers have looked at ITR caching and there are papers published >> that discuss pros and cons. > > An academic paper examining 20k macro-flows toward ETRs is far from > Internet-scale, and is in my opinion not useful. I am not sure which paper you refer to, but AFAIR there is no paper with 20K "macro-flows". > Perhaps I have not > read some more recent work on this topic; but all the LISP-specific > "research" I've seen in this area is nothing more than C.V. padding. > This is just your personal opinion not the truth. Luigi > It can easily be shown that an ITR must have a huge FIB, compared to > FIB sizes today, in order to operate normally under a DDoS designed to > exploit the vulnerable negative mapping cache, which must be able to > install same mappings into FIB to guard the control-plane against > excessive punts, or avoid simply dropping punts which would cause > resolution of mappings for positive/good destination mappings. Again, > see my mailing list post. > >> We are all wrong and we are all right. Let's start the technical discussion. > > I welcome such discussion. LISP is very much designed from an > "eyeball" perspective, with the intent of delivering increased traffic > engineering capabilities, and multi-homed connectivity, to SOHO-type > networks with less expensive hardware. The impact of this is, quite > simply, a shift of cost to the datacenter / content network, or a > shift of complexity to the actual content server, which may, and > probably should, become an ITR itself to avoid scaling problems with > ITRs in mixed-use datacenters. > > Making it cheaper and easier to multi-home a SOHO network must > ultimately have the affect of dramatically increasing the number of > such networks which are multi-homed. Not only is current LISP work > viewing the number of destination networks as substantially fewer than > those which already exist today -- it does not even attempt to account > for this growth. > > It certainly does not account for the possibility of DoS designed to > exploit cache churn. Even without any significant increase in the > number of destination networks today, and if you assumed each ASN had > only one ETR (obviously that will not be true), if LISP were really > deployed widely across the Internet, an ITR would need about 500k FIB > slots to manage just 50k destination networks, given current IPv6 > addressing strategy. An ETR intending to check the origin of traffic > before admitting it to the network will encounter a similar problem. > > These problems are obvious. Improvements can be made, but this has > not been done, and as far as I can tell, it has not been seriously > discussed. A test network is certainly useful to discover emergent > problems and implementation issues, but from my perspective, feeling a > little proud about having a pilot network deployed while gaping > protocol design problems are not being addressed is a deeply misguided > waste of time and resources. Scaling problems with ITR caches can be > shown with simple arithmetic -- they do not even require a working > router to discover. > > -- > Jeff S Wheeler <[email protected]> > Sr Network Operator / Innovative Network Concepts > _______________________________________________ > lisp mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/lisp _______________________________________________ lisp mailing list [email protected] https://www.ietf.org/mailman/listinfo/lisp
