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. 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. 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. 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. 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
