do not filter your customers

Sat Feb 25 01:24:57 UTC 2012

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 at 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
> 