Home page logo

nanog logo nanog mailing list archives

Re: do not filter your customers
From: Jeff Young <young () jsyoung net>
Date: Sat, 25 Feb 2012 14:53:21 +1100

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


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

  By Date           By Thread  

Current thread:
[ Nmap | Sec Tools | Mailing Lists | Site News | About/Contact | Advertising | Privacy ]