On Tue, Jul 12, 2011 at 4:06 AM, Damien Saucez <[email protected]> wrote: > However, in our mail exchanges, I said that the cache management was more > than a security problem > and was more important than just negative replies. You can inject a lot of > entries with positive replies as > well, particularly in IPv6. You can have this by massively de aggregating the > prefixes. Again, this is
As I have mentioned, a malicious person does not need access to any LISP infrastructure. They will not need to inject new prefixes. All an attacker must do is send packets in a systemic manner to exploit the way LISP MS negative replies work -- by sending back non-overlapping negative responses, which may be more numerous than the possible number of positive mappings (especially for IPv6.) >> flexibility. Quite simply, a 50k entry IPv6 table would indeed >> consume 500k entries when negative entries are included. > > Could you provide more information about the numbers? From where is the 10 > factor coming? Again, you must read my original post on this subject. An example may be helpful. Imagine I wish to attack your ITR, which can learn about two routes, fc00:9000::/32 and fc00:9200::/32. There is a large hole between these two routes, due to RIR allocation strategy. In order to use up more MS cache entries on your ITR, I can send one packet each within the following prefixes, all of which will cause an MS query, negative response, and use up resources in the ITR: fc00:9001::/32 fc00:9002::/31 fc00:9004::/30 fc00:9008::/29 fc00:9010::/28 fc00:9020::/27 fc00:9040::/26 fc00:9080::/25 fc00:9100::/24 So you can see that there are two (2) positive mapping entries and nine (9) negative entries. Now add a third positive mapping at fc00:9400::/32 and you gain another nine negative entries. That continues to be the case for every possible /32 allocation aligned on a /23 boundary, thus producing a hole which requires nine VLSM list entries to be represented. If you have 50k positive mappings in the system, you will have 450k negatives making up those holes, requiring a 500k entry state database on the ITR to avoid churn. Obviously the goal of such a DoS will be to exploit either bad behavior during excess churning, cripple the CPU due to excess punts, or use up all the cache so the correct ETR destination for legitimate traffic can't be learned. The reason for this is the Mapping Server is not allowed to send a negative response which overlaps a possible positive response. The hole can't be aggregated into "hole + one longer positive" even though this would be easy for the router to understand, and indeed, to install into FIB if necessary (to guard the CPU against punts.) There will most likely be 50k actual IPv6 destination prefixes within a few years, if each ASN active today receives about one IPv6 allocation. If LISP were implemented widely on the Internet, it would know about 50k mappings and be subject to learning about 450k holes when abused. This means the affect of caching is actually that a bigger FIB is required when the router is subjected to this attack, than if it wasn't able to cache at all, and simply learned all routes from the mapping system. If an ETR wants to be able to verify that ingress traffic is coming from a legitimate ITR for the source, I believe ETRs will also have a scaling problem here, which I think will be easier to exploit than the ITR. -- Jeff S Wheeler <[email protected]> Sr Network Operator / Innovative Network Concepts _______________________________________________ lisp mailing list [email protected] https://www.ietf.org/mailman/listinfo/lisp
