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

[Jeff Wheeler <jsw () inconcepts biz>]

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