Re: [lisp] Restarting last call on LISP threats

[Dino Farinacci <[e-mail]>]

> Dino,
> 
> Today's Internet is not as fragile as you think. This mail traversed many routers between my house and yours. 

Ron, I know for a fact, it is fragile. I know most of the code that runs the Internet. And you said yourself that uRPF is not used in many places, so that, in and of itself, makes it fragile for spoofing.

> If those routers are well-managed, there is nothing that I can do from my house that will cause any of those routers to consume control plane resources. Therefore, there is nothing that I can do from my house that will cause a DoS attack against those routers' control planes.

My example, I wanted to take you out, not the PE router at AT&T that could take out all customers attached to that PE. Which has happned before by bad vendor code. LOL. So I don't have to play there. 

But I can use up all your resources at your house so your kids can get their homework assignments done on time.

It happens to me all the time at Starbucks when 15 people are watching videos and all I want is some decent response in my emacs window.  ;-)  That is not a DoS, in this case but normal usage. So DoSing something is as simple as bringing up an innocent applicaiton and lauching UDP streams to your home router.

> In LISP, separation between the forwarding and control plane is lost. As a matter of course, forwarding plane 

That is not true. And in most cases, when xTRs are behind NATs, there is NEVER a map-cache miss. I assume you are referring to that when you claim there is lost separation. If not, please clarify.

> activity causes control plane activity. Since forwarding plane bandwidth exceeds control plane bandwidth, DoS attacks against the control plane are possible.

Yes, for every protocol we have invented. But like I said, there are better ways to solve this with LISP. If you look at all the drafts in totality, you will see we have a decent toolbox of solutions that COULD fight this traditional problem.

You are merely (and continually) looking ONLY at the map-cache miss problem.

> In order to be complete, the threats document must describe the DoS threat. It should also describe mitigations, if any exist.

I agree with that. No one is arguing your point or Ross point. But rather than just documenting what they are, we want to fix them. So that is were we should put our attention. So let's have all of us work together and identify the problems and brainstorm about fixes. 

Rather than just saying what is wrong.

Dino