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 >