On Jul 13, 2011, at 13:03 , Luigi Iannone wrote: > Jeff, > > on one point we agree, there is value in continuing this thread.
There is _no_ value..... my mistake... Luigi > I've tried to bring the discussion back to the technical issues, but I failed. > > Personally, I find your emails aggressive and close to offensive in some > sentences. > Differently from you, in my replies (all of them public) I never judged your > competences. > > For me this thread is closed. > > Have a nice day > > Luigi > > On Jul 13, 2011, at 11:21 , Jeff Wheeler wrote: > >> Luigi, you have mis-understood quite a bit of the content of my >> message. I'm not sure if this is of any further interest to NANOG >> readers, but as it is basically what seems to go on a lot, from my >> observations of IETF list activity, I'll copy my reply to the list as >> you have done. >> >> On Wed, Jul 13, 2011 at 4:08 AM, Luigi Iannone >> <lu...@net.t-labs.tu-berlin.de> wrote: >>> Granted. You are the real world expert. Now can you stop repeating this in >>> each email and move on? >> >> No. This is a point that needs to be not only made, but driven home. >> You do not understand how routers work, which is why you are having >> such difficulty understanding the severity of this problem. The >> lisp-threats work you have done is basically all control-plane / >> signalling issues, and no data-plane issues. This is not a >> coincidence; it is because your knowledge of the control-plane side is >> good and of the data-plane is weak. >> >>> This is completely false. Several people gave credit to you about the >>> existence of the threat you pointed out. >> >> Really? In April, when I posted a serious problem, and received no >> replies? Now, the original folks who I discussed this with, before >> ever posting to the IETF LISP list, are finally seeking clarification, >> because apparently there may have been some confusion in April, >> possibly leading to their total dismissal of this as a practical >> concern. >> >>> This is again false. We had mail exchange both privately and on the >>> mailinglist. We proposed to you text to be added to the threats draft but >>> you did not like it. We are asking to propose text but we have no answer >>> from you on this point. >> >> Actually, you classified this as an implementation concern, which is >> false. You have said yourself that this is why you believe it >> deserves just one sentence, if that, in the lisp-threats draft. This >> is not an implementation-specific concern, it is a design flaw in the >> MS negative response scheme, which emerges to produce a trivial DoS >> threat if LISP ever scales up. >> >>>> Now there is a LISP "threats" draft which the working group mandates >>>> they produce, discussing various security problems. The current paper >>>> is a laundry list of "what if" scenarios, like, what if a malicious >>>> person could fill the LISP control-plane with garbage. BGP has the >>> >>> So you are saying that BGP can be victim of similar attacks/problem.... >>> still... if you are reading this email it means that the Internet is still >>> running... >> >> This is where I believe you are mis-reading my message. Your threats >> draft covers legitimate concerns which also exist in the current >> system that is widely deployed, which is largely, BGP plus big FIB. >> What you don't cover, at all, is an IMO critical new threat that >> emerges in the data-plane from the design of the MS protocol. >> >>> If you still think that LISP is using a flow-cache you should have a second >>> read to the set of drafts. >> >> This language may appear unclear if you haven't read it in the context >> of my other postings. LISP routing most certainly is a flow-cache, >> however, the definition of "flow" is different. Some platforms and >> routing schemes see a flow as a layer-3 destination /32 or similar >> (some 90s routers), others more granular (firewalls, where flows are >> usually layer-4 and often stateful), and with LISP, the "flow" the >> address space routed from your ITR to a remote ETR, which may cover a >> large amount of address space and many smaller flows. >> >> The LISP drafts also refer to these flows as "tunnels," but that >> language could easily be confused to mean much more permanent, static >> tunnels, or MPLS-like tunnels which are signaled throughout the >> network of P routers. So there are clear semantic issues of >> importance when talking about LISP, and all these terms must be read >> in the correct context. >> >>> For the third time: this is false. We got the problem, we were asking for >>> more specific information in order to quantify the risk. We asked you help >> >> You haven't "got it," or you would already understand the risk very >> well. It is not my intention to fault you and your colleagues for >> failing to understand this; but to demonstrate clearly that the right >> kind of expertise is absolutely not being applied to LISP, and there >> is a huge and possibly intractable threat that was completely >> overlooked when producing what is meant to be an authoritative >> document on currently-known "threats" to LISP. >> >>> to state the problem and explained to you where the solution should be >>> addressed. But you seem to be stuck on the operator vs. researcher >>> discussion, which IMHO is just pointless. >> >> Substantially all operators are "stuck" there. They should participate more. >> >>> Let me now ask a simple question: why are you so strongly against LISP? >> >> No new work has been done to address the problem of scaling up the >> number of locators or multi-homed end-sites. However, the *claims* >> being made by LISP advocates is that the caching scheme you have, >> which is not novel, does solve this problem. It does not. It cannot >> as there has been no novel work on this. >> >> It is very unfortunate that LISP folks point to an academic paper that >> studied the affect of 20k nominal flows. This is not Internet-scale, >> but a lot of you who are working hard on LISP don't seem to understand >> that. DoS attacks are a real world concern that we all have to live >> with when deploying things for Internet use (as opposed to enterprise >> VPN, etc.) If you don't even consider their impact, how would you >> expect content to be available over a LISP infrastructure? How could >> a large subscriber-access ITR platform work, if a trivial DoS against >> it would impact all connected subscribers? >> >> The root problem remains that as you scale up the number of locators >> and destination prefixes, you need to scale up the hardware. This is >> made 10x worse, as I have demonstrated, by the inflexible and foolish >> negative mapping reply scheme that is specified for LISP. >> >>> You do not believe in it and do not see any value? Fine, other people do. >> >> As I have said, I believe the value of LISP is limited to >> VPN-over-Internet. It can never scale up for large-scale, Internet >> use. This is an opinion shared by virtually all operators I've spoken >> to who have followed LISP. Why? Again, pet project, ego, and >> academia vs operational reality. >> >> Get some other opinions. I'm not the only guy who thinks this way, >> I'm just the only one bothering to jump up and down, because I think >> LISP is a really good example of what is being discussed in this NANOG >> thread (IETF brokenness due to lack of operator participation), and a >> waste of vendor resources. >> >>> You think that there are issues that cannot be solved? Fine, other people >>> believe those issues can be solved and are scratching their head to find >>> deployable solutions. >> >> I've seen the "LISP Youtube Video." It looks clever, but it'll never, >> ever work at large scale. Would you like to know what actually does >> work, has existing code, and just needs some killer app? SCTP. It >> does the mobility that LISP promises, and removes the need to even >> have loc/ID separation, because applications perceive a socket which >> the OS (SCTP stack) at each end can multi-home, and port across >> changing IP addresses, and so on. >> >> SCTP isn't going to sell any routers, but it solves all those problems >> that LISP would like to solve (but can't at scale.) >> >> -- >> Jeff S Wheeler <j...@inconcepts.biz> >> Sr Network Operator / Innovative Network Concepts > >
