Home page logo
/

nanog logo nanog mailing list archives

Re: do not filter your customers
From: "Jeffrey S. Young" <young () jsyoung net>
Date: Sat, 25 Feb 2012 12:24:57 +1100

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?)

2.  Implement the "1-hop" hack to protect your BGP peering.

98% of problem solved on the Internet today

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...).

99.9% of problem solved.

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
a shame that tier one peering agreements didn't evolve with
a 'filter your customers' clause (aka do the right thing) as well
as a 'like for like' (similar investments) clause in them.

I'm not downplaying the BGP-SEC work, I think it's valid and
may one day save us from some smart bunny who wants to
make a name for himself by bringing the Internet to a halt.  I
don't believe that's what we're battling here.  We're battling the
operational cost of doing the right thing with the toolset we have
versus waiting for a utopian solution (foolproof and free) that may 
never come.

jy

ps. my personal view.

On 25/02/2012, at 6:26 AM, Danny McPherson <danny () tcb net> wrote:


On Feb 24, 2012, at 1:10 PM, Steven Bellovin wrote:

But just because we can't solve the whole problem, does that
mean we shouldn't solve any of it?

Nope, we most certainly should decompose the problem into 
addressable elements, that's core to engineering and operations.

However, simply because the currently envisaged solution 
doesn't solve this problem doesn't mean we shouldn't 
acknowledge it exists.

The IETF's BGP security threats document [1]  "describes a threat 
model for BGP path security", which constrains itself to the 
carefully worded SIDR WG charter, which addresses route origin 
authorization and AS_PATH "semantics" -- i.e., this "leak" 
problem is expressly out of scope of a threats document
discussing BGP path security - eh? 

How the heck we can talk about BGP path security and not 
consider this incident a threat is beyond me, particularly when it 
happens by accident all the time.  How we can justify putting all 
that BGPSEC and RPKI machinery in place and not address this 
"leak" issue somewhere in the mix is, err.., telling.

Alas, I suspect we can all agree that experiments are good and 
the market will ultimately decide.

-danny

[1] draft-ietf-sidr-bgpsec-threats-02



  By Date           By Thread  

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