> On Mon, Jul 25, 2011 at 9:12 AM, Dino Farinacci <[email protected]> wrote: >> For your reference to "transition state", there isn't this same issue on a >> PITR because it receives and forwards packets from non-LISP sites, where >> there is one IP header in the packet, and the source address is subject to >> uRPF and forwarding rules as it is today. > > The reason I mention "transition state" is you seem to be gravitating > towards ideas that require new inspection capabilities at > substantially all "legacy Internet" access providers in order to > protect the new LISP infrastructure. If I can use any source IP > address I want when sending crafted packets, including crafted LISP > outer-header, to your LISP site, then the chances are good that I can > disable your site as long as I can generate enough PPS and there are > enough mappings in the system to produce cache churn in your xTR. > > So relying on ITRs to prevent "bad traffic" from ever entering the > system will not work because there will be a large, legacy Internet > with no ability to prevent that traffic from reaching your site.
How many times do I have to say we should not solve this on the ETR? >> Right, so you have some hard decisions to make. The ETR can do lookup in its >> cache to figure out if the (source-RLOC, source-EID) is in its cache and if >> not, drop the packet, then do a lookup so subsequent packets can have the >> cache populated so the check can pass. > > Except the ETR is bounded by the same cache scaling limits as an ITR > subject to a reflection attack, meaning its cache can churn, and > substantially all traffic needing to be decapsulated by that ETR would > be dropped. Right, agree. Don't do this on the ETR. DO NOT SOLVE THIS ON THE ETR. >> I call this the "needle in the haystack" problem. And we have had to deal >> with this with hardware packet punting for a number of decades. > > Even if you imagine that the xTR control-plane is not a bottleneck, > presuming that the data-plane can generate MS queries directly and can Why do you want to presume that? > update its FIB at an unlimited rate, the result of having a limited > FIB size plus an attack designed to take advantage of that means the > MS infrastructure will be required to have very low latency and very > high throughput to keep up with an xTR experiencing high PPS and low > cache hit rate because of churn. This essentially would mean that the > MS infrastructure is directly involved in a substantial fraction of > packet forwarding decisions on that xTR. That doesn't follow at all and I don't know why you want to make this conclusion. Dino > > -- > 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
