Re: do not filter your customers

["Jeffrey S. Young" <young () jsyoung net>]

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