On Thu, Jul 14, 2011 at 4:03 AM, Damien Saucez <[email protected]> wrote: > On 14 Jul 2011, at 04:55, Ross Callon wrote: >> To me it seems highly unlikely that this assumption is within an order of >> magnitude of being correct. > > At a first glance, the assumption might look bad, but I believe it is not the > case. Indeed, the evaluation are made
You forget that a feature of LISP is to make multi-homing SOHO sites cheaper and easier, therefore increasing their number dramatically. If I can multi-home using LISP with my cable modem and my DSL, I will. Many "power users" will at their homes, to say nothing of branch offices and small businesses, which today do not warrant multiple, expensive ISP connections that offer speed, economy, and the capability for multi-homing. To assume the number of multi-homed end-sites won't grow by 10x is foolish. I believe we would see more than 100x growth, but even 10x, plus the cache problems identified, make LISP very much impractical for content providers. On Thu, Jul 14, 2011 at 1:55 AM, Damien Saucez <[email protected]> wrote: > With "simple arithmetic", BGP cannot work, however, it works in practice > because > theory and practice are not the same. LISP is not perfect, and none of the > protocols 360k prefixes, 360k FIB slots. Yes, if you have a flow-based BGP router in the DFZ, depending on its implementation, it may work poorly (Foundry IronCore, for example) and it may be trivial to disable with DoS traffic. However, LISP proposes to create a situation where the ITR should never know all mappings, must be able to hold negative replies from the MS, and thus increases the amount of FIB required (in worst case, which is real-world for content networks, they do receive DoS and have to deal with it) beyond the maximum number of possible mappings. As I have shown, this is problematic even if the number of mappings wouldn't explode due to SOHO multi-homing. On Thu, Jul 14, 2011 at 1:20 AM, Damien Saucez <[email protected]> wrote: > 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. 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. On Thu, Jul 14, 2011 at 1:41 AM, Eliot Lear <[email protected]> wrote: > In the first instance, let me suggest that the whole point of LISP is to > disentangle memory consumption from number of reachable points on the > Internet, but rather bound it to the number of sites actually being > reached. That is what induces the concern that Jeff has raised with the > 2nd discussion. What Jeff has described is a variation of the classic > reflection attack. This is, IMHO, probably worth noting more > explicitly, as an area for future work. 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. On Thu, Jul 14, 2011 at 1:55 AM, Damien Saucez <[email protected]> wrote: > LISP is definitely more than just a new way of doing VPNs. I am really sorry > if > you cannot see the fundamentals changes that a Map-and-Encap paradigm > brings to the way networks are managed. LISP is just an instantiation of this I simply see that a hard, underlying problem has not been addressed. Touting the potential for LISP to bring new capabilities, on Internet-scale, without having considered the implications of Internet-scale DDoS, is either ignorant or irresponsible. -- Jeff S Wheeler <[email protected]> Sr Network Operator / Innovative Network Concepts _______________________________________________ lisp mailing list [email protected] https://www.ietf.org/mailman/listinfo/lisp
