[142784] in North American Network Operators' Group
Re: Anybody can participate in the IETF (Was: Why is IPv6 broken?)
daemon@ATHENA.MIT.EDU (Luigi Iannone)
Wed Jul 13 07:09:30 2011
From: Luigi Iannone <luigi@net.t-labs.tu-berlin.de>
In-Reply-To: <CA263B00-6237-4188-9233-B0A2930A2A12@net.t-labs.tu-berlin.de>
Date: Wed, 13 Jul 2011 13:08:35 +0200
To: Luigi Iannone <luigi@net.t-labs.tu-berlin.de>
Cc: nanog@nanog.org
Errors-To: nanog-bounces+nanog.discuss=bloom-picayune.mit.edu@nanog.org
On Jul 13, 2011, at 13:03 , Luigi Iannone wrote:
> Jeff,
>=20
> 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.
>=20
> 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.
>=20
> For me this thread is closed.
>=20
> Have a nice day
>=20
> Luigi
>=20
> On Jul 13, 2011, at 11:21 , Jeff Wheeler wrote:
>=20
>> 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.
>>=20
>> 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?
>>=20
>> 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.
>>=20
>>> This is completely false. Several people gave credit to you about =
the
>>> existence of the threat you pointed out.
>>=20
>> 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.
>>=20
>>> 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.
>>=20
>> 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.
>>=20
>>>> 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
>>>=20
>>> 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...
>>=20
>> 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.
>>=20
>>> If you still think that LISP is using a flow-cache you should have a =
second
>>> read to the set of drafts.
>>=20
>> 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.
>>=20
>> 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.
>>=20
>>> 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
>>=20
>> 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.
>>=20
>>> 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.
>>=20
>> Substantially all operators are "stuck" there. They should =
participate more.
>>=20
>>> Let me now ask a simple question: why are you so strongly against =
LISP?
>>=20
>> 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.
>>=20
>> 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?
>>=20
>> 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.
>>=20
>>> You do not believe in it and do not see any value? Fine, other =
people do.
>>=20
>> 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.
>>=20
>> 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.
>>=20
>>> 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.
>>=20
>> 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.
>>=20
>> 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.)
>>=20
>> --=20
>> Jeff S Wheeler <jsw@inconcepts.biz>
>> Sr Network Operator / Innovative Network Concepts
>=20
>=20
