Hello Jeff, I thought about the problem and think that there is deployment solution that could correct the problem. Here I am supposing that the mappings are secured (which is a must for me as u can see from my drafts). Of course it would work without secure mapping but then it would be dangerous (see LISP-SEC Fabio's draft).
Currently, when a map-request is sent, you receive the mapping for the longest-match prefix corresponding. So why not changing to receive a Map-Reply that contains as today the reply to the request + the a negative-mapping with the longest-match prefix of the RIR that contains this. The RIR knows how it assigns the prefixes, so it is easy to provide this. In your example, you just have to send fc00:9000::/32 positive mappings and the corresponding negative /23 with a TTL lasting the time the RIR is subject to assign a new sub-prefix of this /23. There is plenty of solutions to ensure this mechanism (MS bases, mapping system bases, ETR based), I will not propose them here, but I am open to start a draft with you that present the issue and the solution. Or you can ask for a slot @IETF81 to present the problem and I would also ask for a slot with the solution. Thank you, Damien Saucez On 12 Jul 2011, at 10:45, Jeff Wheeler wrote: > 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
