Dear Jeff,
> 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. > Actually, the very nature of Internet traffic make this a non-problem. Indeed, the heavy tail nature of the spacial locality distribution in the Internet ensures that, in general, only the big networks will have to deal with a huge number of client. And if your network is big, it is very likely that it will have many entry points and that these entry point are topologically close to the clients meaning that each entry point will actually not have to deal with millions of clients. Don't forget that you have to think in term of locality with LISP. If you don't you will kill the paradigm. Not because it is bad but because your interepretation is incorrect. LISP is not BGP! So if you don't believe me about how the traffic is on the Internet, I think you can believe the harbor study (data from hexabytes of traffic in real networks). What does the study show? Simply that the traffic converges to a few buch of CDNs (actually the study shows much more than that, but only this point is important for now). So yes you will see a lot of SOHOs but only the big CDNs will have to deal with an important amount of entries, not the other networks and for the CDN, believe me or not, but the routers they are using will be able to deal with even millions of mappings (which is unlikelly as the load is spread over several routers). Actually, a SOHO has in general a xTR (ITR and ETR merged) and the traffic is relativerly symetric in term destinations/sources (not volume but we don't care for the cache) as basically flows are bi-directional. In addition, the SOHO tend to communicate with CDNs not with other SOHOs. Feel free to provide me data that prove the opposite. > 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. > 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! > 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) see above... > 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. > And I showed that it was not a so big problem if you are deploying the system in a smart way. > 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. RIR was an example, please be constructive in your remarks. > > 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. 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. Again if you have data to give us to proof your thoughts, feel free to provide me them and I will work on them to see if we really are as stupid as you pretend. I would be the first happy to show a negative result, my work is not to provide positive of negative results but simply to provide facts. > 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. > 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 then I consider the security implications with LISP. We have internal documents that explore the different ways to secure the mappings and to avoid spoofing and we are still studying what is the best OPERATIONAL vs REALISTIC solution. I am also the author and co-author of several IETF drafts and scientific papers about the LISP security and the impact of scans on LISP. You are probably not aware of that but a draft becomes a WG document if and only if the majority of people in the WG consider that it is worth working on it (many of my drafts have been dropped, this is the life of an IETF draft). As several WG drafts are about security in the LISP WG, it means that a majority of the people working in the LISP WG consider that security is worth working on. 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. Thank you for you interest in LISP Regards, Damien Saucez > -- > Jeff S Wheeler <[email protected]> > Sr Network Operator / Innovative Network Concepts > _______________________________________________ > lisp mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/lisp > _______________________________________________ lisp mailing list [email protected] https://www.ietf.org/mailman/listinfo/lisp
