Re: do not filter your customers

[Shane Amante <shane () castlepoint net>]

Steve,

On Feb 24, 2012, at 11:10 AM, Steven Bellovin wrote:
> On Feb 24, 2012, at 7:46 40AM, Danny McPherson wrote:
> > On Feb 23, 2012, at 10:42 PM, Randy Bush wrote:
> > > the problem is that you have yet to rigorously define it and how to
> > > unambiguously and rigorously detect it.  lack of that will prevent
> > > anyone from helping you prevent it.
> >
> > You referred to this incident as a "leak" in your message:
> >
> > "a customer leaked a full table"
> >
> > I was simply agreeing with you -- i.e., looked like a "leak", smelled 
> > like a "leak" - let's call it a leak.
> >
> > I'm optimistic that all the good folks focusing on this in their day
> > jobs, and expressly funded and resourced to do so, will eventually
> > recognize what I'm calling "leaks" is part of the routing security 
> > problem.
> Sure; I don't disagree, and I don't think that Randy does.  But just
> because we can't solve the whole problem, does that mean we shouldn't
> solve any of it?

Solving for route leaks is /the/ "killer app" for BGPSEC.  I can't understand why people keep ignoring this.

As has been discussed in the SIDR WG, BGPSEC will _increase_ state in BGP, (more DRAM needed in PE's and RR's, crypto 
processors to verify sigs, more UPDATE traffic for beaconing).  And, at the end of the day, ISP's are going to go to 
their customers and say to them:
- BGP convergence may be slower than in the past, because we're shipping sigs around in BGP now
- we can prevent a malicious attack from a random third-party (in the right part of the topology);
- *but* I can't protect you from a 20+ year old problem of a transit customer accidentally -or- maliciously 
stealing/dropping your traffic if they leak routes from one provider to another provider?


> As Randy said, we can't even try for a strong technical solution
> until we have a definition that's better than "I know it when I see it".

The first step is admitting that we have a problem, then discussing it collectively to try to determine a way to 
prevent said problem from happening.

-shane