Re: do not filter your customers

[Jeff Young <young () jsyoung net>]

On 25/02/2012, at 12:59 PM, Christopher Morrow wrote:

> On Fri, Feb 24, 2012 at 8:24 PM, Jeffrey S. Young <young () jsyoung net> wrote:
> > 1.  Make your customers register routes, then filter them.
> >     (may be time for big providers to put routing tools into
> >     open source for the good of the community - make it
> >     less hard?)
>
> not a big provider, but ras@e-gerbil did release irr-tools no?

And other providers out there have extensive tool sets from which
we could all benefit.  I'll let them chime in if they choose.

> > 2.  Implement the "1-hop" hack to protect your BGP peering.
> >
> > 98% of problem solved on the Internet today
>
> which problem? GTSH only protects your actual bgp session, not the
> content of the session(s) or the content across the larger network.

The security problem, but it was a hedge on my part.

> > 3.  Implement a "# of routes-type" filter to make your peers
> >     (and transit customers) phone you if they really do want
> >     to add 500,000 routes to your session ( or the wrong set
> >     of YouTube routes...).
>
> max-prefix already exists... sometimes it works, sometimes it's a
> burden. It doesnt' tell you anything about the content of the session
> though (the YT routes example doesn't actually work that way)

Depends on how many /24's the Pakistan(?) Telecom guy let into the 
network to block the YT content...  but you're right, the example would 
have been better in support of #1.  
(had PT been forced to register routes before sending them and his 
upstream been filtering based on those routes we'd have never heard 
about it.)

> > 99.9% of problem solved.
>
> ? not sure about that number

> > 4.  Implement BGP-Sec
> >
> > 99.91% of "this" problem solved.
> >
> > Because #1 is 'just too hard' and because #4 is just too sexy
> > as an academic pursuit we all suffer the consequences.  It's
>
> there are folks working on the #4 problem, not academics even. It's
> not been particularly sexy though :(

Point was that the problem is mostly operational.  We have tools
to deal with the problem but the operational costs are high.  For 
fifteen (below) years we've treated this (route leak) as "not my problem"
because it's too costly.   Every 6-12 months it comes back to bite
us.  If the cost of an outage every 6 months+ is low compared to
solving the problem, the community will endure the outage. If we 
want it to stop today we can make it stop but stopping it has a cost.

“...a glitch at a small ISP... triggered a major outage in Internet access 
across the country. The problem started when MAI Network Services
...passed bad router information from one of its customers onto Sprint.”
-- news.com, April 25, 1997

jy

Attachment: PGP.sig
Description: This is a digitally signed message part