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

Wed Jul 13 08:45:19 UTC 2011

Hello Jeff,

On 13 Jul 2011, at 10:08, Luigi Iannone wrote:

> Jeff,
> 
> 
> On Jul 12, 2011, at 20:13 , Jeff Wheeler wrote:
> 
>> On Tue, Jul 12, 2011 at 11:42 AM, Leo Bicknell <bicknell at 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.
>> 
>> 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?
> 
>> 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.
> 
> This is completely false. Several people gave credit to you about the existence of the threat you pointed out.
> 

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.

> 
>>  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.
>> 
>> 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.  
> 
> 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.
> 

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.

> 
>> 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.
>> 
>> 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.  
> 
> 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...
> 

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.

> 
>> This sometimes happens even by
>> accident, for example, some poor guy accidentally announcing 12/9 and
>> giving AT&T a really bad day.
>> 
>> 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.
> 
> If you still think that LISP is using a flow-cache you should have a second read to the set of drafts.
> 
> 

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,
> 
> 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. 

> 
>> 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.
>> 
>> That is the "not an operator" problem.  It is understandable.
>> 
>> 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.
>> 
>> 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.
>> 
>> 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!
>> 
>> If operators don't provide input and *perspective* to things like
>> LISP, we will end up with bad results.
>> 
> 
> 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!
> 
> Let me now ask a simple question: why are you so strongly against LISP?
> 
> 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.
> 
> As I said before, your technical experience and feedback is the most welcome, but let's try to focus only on the technical level.   
> 

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 
> 
> Luigi Iannone
> 
> 
> 
> 