Jeff, on one point we agree, there is value in continuing this thread. 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 <luigi@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 <jsw@inconcepts.biz> Sr Network Operator / Innovative Network Concepts