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. > 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. > 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 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. -- Jeff S Wheeler <[email protected]> Sr Network Operator / Innovative Network Concepts _______________________________________________ lisp mailing list [email protected] https://www.ietf.org/mailman/listinfo/lisp
