[142781] in North American Network Operators' Group
Re: Anybody can participate in the IETF (Was: Why is IPv6 broken?)
daemon@ATHENA.MIT.EDU (Damien Saucez)
Wed Jul 13 04:46:43 2011
From: Damien Saucez <damien.saucez@uclouvain.be>
In-Reply-To: <DB32CF0C-432D-4EB8-810C-1FAC7C218B2A@net.t-labs.tu-berlin.de>
Date: Wed, 13 Jul 2011 10:45:19 +0200
To: Jeff Wheeler <jsw@inconcepts.biz>
X-SGSI-From: damien.saucez@uclouvain.be
Cc: nanog@nanog.org
Errors-To: nanog-bounces+nanog.discuss=bloom-picayune.mit.edu@nanog.org
Hello Jeff,
On 13 Jul 2011, at 10:08, Luigi Iannone wrote:
> Jeff,
>=20
>=20
> On Jul 12, 2011, at 20:13 , Jeff Wheeler wrote:
>=20
>> On Tue, Jul 12, 2011 at 11:42 AM, Leo Bicknell <bicknell@ufp.org> =
wrote:
>>> I'll pick on LISP as an example, since many operators are at least
>>> aware of it. Some operators have said we need a locator and =
identifier
>>> split. Interesting feedback. The IETF has gone off and started
>>> playing in the sandbox, trying to figure out how to make that go.
>>=20
>> As an operator (who understands how most things work in very great
>> detail),
> Granted. You are the real world expert. Now can you stop repeating =
this in each email and move on?
>=20
>> I found the LISP folks very much uninterested in my concerns
>> about if LISP can ever be made to scale up to "Internet-scale," with
>> respect to a specific DDoS vector.
>=20
> This is completely false. Several people gave credit to you about the =
existence of the threat you pointed out.
>=20
Definitely, since 2007 we are working on LISP and always keep =
scalability in mind. All our researches are always
constrained by the scalability. What you pointed out is very interesting =
and we are working on it. Nevertheless, and
I am just repeating myself now, the problem you expose is an operational =
problem that can also have security
implications. This is why we proposed you several time to expose the =
problem at next IETF such that we can
all discuss the problem and propose solutions to be added in the main =
specs. The cache management problem is
really interesting and we could even imagine a draft like =
"implementation guidelines" that would explain how to
implement the caches in a smart way. The solution to the problem you are =
pointing-out can also be proposed in
the deployment draft as it could be alleviate with the help of filters.
>=20
>> I also think that an explosion of
>> small, multi-homed SOHO networks would be a disaster, because we =
might
>> have 3 million FIB instead of 360k FIB after a few years. These
>> things are directly related to each-other, too.
>>=20
>> So I emailed some LISP gurus off-list and discussed my concern. I =
was
>> encouraged to post to the LISP IETF list, which I did. To my great
>> surprise, not one single person was interested in my problem. =20
>=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
Among the people that are interesting by the problem, you have the =
threats authors. You received personal
replies from me on Jul 6th @2:08pm and Jul 7th @1:13 am. In our SVN, the =
draft is already updated with your
comments and you are in the acks. The version will be submitted just =
after the IETF with the comments that will
come from the presentation we will make during IETF81. I understand that =
you would like to have the comment
addresses immediately when you are thinking about them but sometime it =
is nice to take a few days to think
about the problem in order to problem a more robust description and thus =
build more sustainable ways to a
solution.
>=20
>> If you
>> think it is a small problem, well, you should try going back to
>> late-1990s flow-cache routing in your data-center networks and see
>> what happens when you get DDoS. I am sure most of us remember some =
of
>> those painful experiences.
>>=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
>> same issue, if some bad guy had enable on a big enough network that
>> their peers/transits don't filter their routes, they could do a lot =
of
>> damage before they were stopped. =20
>=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
Some people like Randy Bush try to find solutions for BGP not to be =
destroyed in presence
of malicious guys. For BGP as for LISP, things take time just become the =
problem is definitely
more complex as we always have to make tradeoffs between various =
contradictory elements.
>=20
>> This sometimes happens even by
>> accident, for example, some poor guy accidentally announcing 12/9 and
>> giving AT&T a really bad day.
>>=20
>> What it doesn't contain is anything relevant to the special-case DDoS
>> that all LISP sites would be vulnerable to, due to the IMO bad
>> flow-cache management system that is specified.
>=20
> If you still think that LISP is using a flow-cache you should have a =
second read to the set of drafts.
>=20
>=20
Depends you definition of flow. If a flow is defined by the destination =
prefix, then yes, LISP has a flow-cache ;-)
>> I am having a very
>> great deal of trouble getting the authors of the "threats" document =
to
>> even understand what the problem is,
>=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 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.
fully agree, our draft is already updated, and I know exactly the =
sentence that has been
added in Sec 6.2.2 of the draft. We have not submitted the draft yet as =
we are following the
"rules" of the WG. We will present the draft and present the =
modifications we want to have and
ask the WG to accept them. Then we will add them in the draft.=20
>=20
>> because as one of them put it, he
>> is "just a researcher." I am sure he and his colleagues are very
>> smart guys, but they clearly do not remember our 1990s pains.
>>=20
>> That is the "not an operator" problem. It is understandable.
>>=20
>> Others who have been around long enough simply dismiss this problem,
>> because they believe the unparalleled benefits of LISP for mobility
>> and multi-homing SOHO sites must greatly out-weigh the fact that,
>> well, if you are a content provider and you receive a DDoS, your site
>> will be down and there isn't a damn thing you can do about it, other
>> than spec routers that have way, way more FIB than the number of
>> possible routes, again due to the bad caching scheme.
>>=20
>> The above is what I think is the "ego-invested" problem, where =
certain
>> pretty smart, well-intentioned people have a lot of time, and
>> professional credibility, invested in making LISP work. I'm sure it
>> isn't pleasing for these guys to defend their project against my
>> argument that it may never be able to reach Internet-scale, and that
>> they have missed what I claim is a show-stopping problem with an easy
>> way to improve it through several years of development. Especially
>> since I am a guy who did not ever participate in the IETF before,
>> someone they don't know from a random guy on the street.
>>=20
>> I am glad that this NANOG discussion has got some of these LISP folks
>> to pay more attention to my argument, and my suggested improvement (I
>> am not only bashing their project; I have positive input, too.)
>> Simply posting to their mailing list once and emailing a few draft
>> authors did not cause any movement at all. Evidently it does get
>> attention, though, to jump up and down on a different list. Go
>> figure!
>>=20
>> If operators don't provide input and *perspective* to things like
>> LISP, we will end up with bad results.
>>=20
>=20
> True. That technical feedback is the most welcome.
Sure, please provide your feedback. What about deploying LISP in your =
test
network and provide us all the information you got from this deployment?
For you information, we are currently working with operators that are =
testing
LISP stuff so be sure that operators are listened!
>=20
> Let me now ask a simple question: why are you so strongly against =
LISP?
>=20
> You do not like it? Fine, other people do.
> You do not believe in it and do not see any value? Fine, other people =
do.
> 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
> As I said before, your technical experience and feedback is the most =
welcome, but let's try to focus only on the technical level. =20
>=20
Maybe you could write a draft with all the points you don't like in LISP =
and why. This
document could be a starting point to improve LISP from an operational =
viewpoint.
Tank you for providing us all the technical details.
Damien Saucez
> thanks=20
>=20
> Luigi Iannone
>=20
>=20
>=20
>=20
