Anybody can participate in the IETF (Was: Why is IPv6 broken?)

Wed Jul 13 11:03:14 UTC 2011

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 at 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 at inconcepts.biz>
> Sr Network Operator  /  Innovative Network Concepts