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 <da...@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
>
