Jeff, what you are describing is nothing new and is not limited to LISP. Hence I do not understand the alarmist tone of your emails.
If you want to propose text describing the issue for the next version of the threats draft, I will be happy to include it. (please do not include any solution since it is not the place to document it. Please be concise.) Thanks Luigi On Jul 11, 2011, at 21:25 , Jeff Wheeler wrote: > On Mon, Jul 11, 2011 at 6:01 AM, Luigi Iannone > <[email protected]> wrote: >> Can you provide real numbers instead of just example? Have you ever counted >> the holes? > > Luigi, the holes in the IPv6 space are there due to RIR allocation > strategy. If I am an ISP and request a /32 for my customers, they > will give me a /32 aligned to a /23 boundary, and not allocate any > other blocks out of that /23 (at least not yet) in case I need to grow > my address space. This is what produces the holes that are guaranteed > to allow attacking the vulnerable negative mapping cache, if LISP were > widely-deployed on the Internet. So you can see that it is not just a > hypothetical "what if the address space had lots of holes..." problem, > but a practical "there are lots of holes and LISP will perform badly > due to this as it scales up." > >> Isn't possible to avoid this by filtering? The ITR can avoid sending any >> request for IPv6 unallocated space. > > You must understand how routers work to see why this is possible, but > requires 10x more FIB space than the number of possible positive > mapping entries (for the case of IPv6, given current allocation > strategy.) > > How does the ITR learn about a mapping for a newly-arrived > packet/flow? Packets bound for a yet-unknown destination must be > punted from the data-plane to the control-plane, where the router's > CPU can check its potentially larger mapping cache (if control-plane > cache is larger than FIB.) This punting is itself the problem. In > order to filter punts for unallocated space, you must install > something into the data-plane / FIB to match them -- this means you > can either install all positive mappings, or you can load negative > mappings on-demand, or you can not filter them at all and punt garbage > look-ups to the CPU. > > There is no easy way to "avoid sending any request for unallocated > space" at a granular level that would protect the CPU in an > Internet-scale LISP deployment. Simply increasing the size of the > control-plane cache, and not turning the punts into MS queries, is not > enough. The MS will be able to service a very high rate of requests > and is fairly easy and inexpensive to scale up. The problem is the > router CPU cannot receive an infinite number of punts before failing, > and the data-plane cannot churn its FIB at an infinite rate either. > On modern routers, the limit of these functions is on the order of > 20,000 punts or FIB updates per second. > > This is why it would be trivial to disable an ITR, because the > filtering you suggest is not possible without a huge FIB, defeating > the purpose of using a cache at all. > > I believe the only way for LISP to scale up in a dense, mixed-use > data-center environment, where the hosts may be untrustworthy, is for > the hosts themselves to be their own ITR. However, modifying the > mapping service spec to allow for a different way of handling negative > responses can significantly improve the situation, to the point where > the ITR only needs enough FIB to hold approximately the whole possible > routing table, not 10x more entries due to negative "filter" entries > as you suggest. > > If you do not consider how the ITR actually works, and this seems to > be the case with a lot of the work on LISP today, it is easy to focus > your efforts on interactions within the LISP signalling infrastructure > without ever realizing that the data-plane has vulnerabilities. > > -- > Jeff S Wheeler <[email protected]> > Sr Network Operator / Innovative Network Concepts _______________________________________________ lisp mailing list [email protected] https://www.ietf.org/mailman/listinfo/lisp
