do not filter your customers
young at jsyoung.net
Sat Feb 25 03:53:21 UTC 2012
On 25/02/2012, at 12:59 PM, Christopher Morrow wrote:
> On Fri, Feb 24, 2012 at 8:24 PM, Jeffrey S. Young <young at 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 at 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
>> 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
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 235 bytes
Desc: This is a digitally signed message part
More information about the NANOG