On Sat, Jul 16, 2011 at 10:17 AM, Damien Saucez <[email protected]> wrote: > Actually, the very nature of Internet traffic make this a non-problem.
This is incorrect, because *any* content network, and any subscriber access platform, must be able to deal with the threat of DoS attacks. If you re-design the Internet in such a way that it becomes trivial to disable any service or any end-user with a relatively small DoS, and that is the direct impact of LISP on a large scale, then every network which wishes to avoid being subject to regular outages must build the large xTR infrastructure you say a few CDNs will build. DoS attacks > 10Gbps are so common today, they do not even attract attention. This can be handled by today's networks simply by having enough capacity, but without xTR infrastructure able to support all possible mappings in FIB without a need for cache, DoS attacks in a scaled-out LISP future would be measured by flow-churn rate. A router that can do > 15M FIB updates/second does not exist, and in fact, FIB update rates would have to go up by three orders of magnitude to handle a worst-case scenario where the cache hit rate is near zero. If you scale up the number of prefixes / end-sites from 360k to 36M, as I suggest is likely if SOHO multi-homing becomes trivial for the end-sites, even routers with large FIB by today's standards will have quite low cache hit rate when subject to DoS (or simply a large amount of end-user traffic.) The folks who often quip that vendors can easily increase the size of FIB to deal with the increasing BGP DFZ generally mean vendors can easily and inexpensively double the FIB. They certainly cannot grow it by 100x on today's IC fabrication processes. If you assume most of the Internet is only having to deal with a few tens of thousands of flows and a high cache hit rate, it is easy to imagine that LISP is a wonderful idea. These assumptions completely break down when faced with the reality of DoS, and get far worse when the number of end-sites scales up. You continue to ignore both of these problems, which are directly related to the fact that LISP has not addressed the fundamental issue of an increasing number of end-sites. > Pointless remark. It is trivial that if you are not doing a good > implementation your router will blow out. We are obviously considering > that state of the art techniques will be used by the guys in charge of > implementing LISP! LISP has not advanced the state of the art in flow cache management. It has not produced a way of reducing the ultimate number of end-sites, either; and in fact should increase them significantly if LISP is successful. > And I showed that it was not a so big problem if you are deploying the > system in a smart way. >> Your idea is similar to my proposed fix and would reduce the "waste" >> caused by negative mappings. I don't agree that it is savvy to make >> the reply necessarily based on RIR assignment strategy (one can >> imagine many reasons where this may not be ideal) but think the router >> should be able to request what portion of the possible routing table >> it wants. Flexibility in the protocol specification, so vendors can >> implement what they choose, would be beneficial. > > RIR was an example, please be constructive in your remarks. If you don't think the above paragraph is constructive, then you have closed yourself to feedback. This exemplifies the problem operators perceive with "the IETF." Perhaps I should have said: * more negative cache optimization is possible if not limiting that to RIR assignment strategy * RIR assignment strategy may chance and require implementation updates (at worst) or configuration changes that may not be performed by operators: see problems getting new RIR IP blocks "de-bogoned" over the past few years * not all platforms need these complexities, for example, the SOHO xTR with a relatively low-speed connection that cannot be subject to a high flow churn rate, or is implemented on a general-purpose computing platform e.g. x86 >> I encourage you to also keep in mind that, if an ETR should be able to >> verify that an ITR is a legitimate origin point for traffic sourced >> from a given address, ETRs will also be subject to the same cache >> problems. Except the ETR will be worse / more vulnerable, because you >> don't need any packet reflection to exploit it. I understand that the >> ideas for possibly preventing spoofing of packets are not well evolved >> yet, but they must take this into account. You are not even able to >> do loose uRPF checking on the inner-source-address of incoming packets >> without exposing the ETR to trivial DoS. > > Jeff, please, before shouting everywhere that we are dumb, read ALL the > documents related to LISP. In the draft about security threats we explain > that ETR should make sanity checks to protect against spoofing. We even > present different type of spoofing and ways to protect the routers. And in > a paper in Networking'11 the authors show that in a (real!) network, > activating such sanity check at the ETRs is not an issue and the caches do > not blow out. Yes, the caches do blow out, due to the same problem with DoS reflecting out an ITR. The difference here is the act of attempting to verify source address (or even do loose uRPF) "blows out" the ETR cache, and there is no possibility to defend against it. Your analyses of "real" traffic are not based in reality without the inclusion of Internet-scale DDoS. In addition, they are further made worse because your group has not envisioned the "worst case LISP DoS" that specifically exploits cache vulnerabilities. These types of attack will not be represented by your analyses because of two reasons: * no LISP deployments yet and thus no real-world attacks against it yet, but they will come in the future if LISP ever becomes widely-deployed * no huge increase in the number of end-sites due to SOHO multi-homing, because that is not currently practical, but LISP promises to make it practical > Again if you have data to give us to proof your thoughts, feel free to You need to stop relying on traffic captures. Of course you won't see DoS specifically designed to exploit a vulnerability that does not exist in today's networks, but will with LISP deployed. And if you simply assume that only a few ultra-large CDNs will need to handle millions of flows, and all other sites are trivial, you are assuming that no other sites will ever see millions of flows due to DoS. That is wrong. > Since we never heard about you before a few weeks, I think that you just > discovered LISP. On my side, I started working on LISP in '07 and since I have been aware of LISP development for many years. I only took more interest in it recently, when a colleague told me what great progress had been made. I examined the current work in more detail, and found that the same fundamental problems which existed years ago are still here. The reason why is simple: your group has a great deal of vision about how a future LISP-based Internet could function, but you continually fail to consider the negative effects of DoS, and you do not have a basic understanding of how the data-plane actually works, which is necessary to envision how the xTR will perform when subject to such DoS. The reason I care is because IPv6 gave us an identical problem on a more limited scope, by setting the expectation that LANs (or all networks) should be /64. Unfortunately, a parallel problem exists with IPv6 ND cache exploits when deploying /64 networks in the real world. It is possible to fix this (SeND, more router/switch knobs, etc.) and it is possible to simply deploy networks differently to avoid the problem. However, with LISP, the problem is of global scope and it may not be possible to fix if LISP scales up. > Could you please provide arguments and proofs of what you claim and try > also to know the LISP state of the art to be sure that it is not already > done? If you do not provide more argumented discussion, I will have to > stop answering your mails. How do you expect an ETR to validate the origin of packets when subject to an attack designed to cause mapping churn? Imagine that you have an Internet-scale LISP network, with perhaps 3M or 30M end-sites and possible mappings, and I am sending you 15Mpps of packets which all appear to originate from different end-sites. No router today will be able to mange this in FIB, so cache churn will result. Now reduce the size of that attack from 15Mpps (trivial today) to an even smaller 200Kpps. This is still 10x faster than modern routers can handle FIB churn, at a rate of around 20K updates/second. How will the ETR be able to validate source addresses under this tiny assault, which may originate from literally one co-located server with a GbE connection, without even fully utilizing such connection? The answer is it cannot. Not only can the ETR not validate source addresses, it can't even discard packets which originate from impossible source addresses (loose uRPF check) because it is not able to determine whether or not these source addresses are even present in the mapping system quickly enough. That is the state-of-the-art today. -- Jeff S Wheeler <[email protected]> Sr Network Operator / Innovative Network Concepts _______________________________________________ lisp mailing list [email protected] https://www.ietf.org/mailman/listinfo/lisp
