do not filter your customers

Sat Feb 25 01:59:18 UTC 2012

On Fri, Feb 24, 2012 at 8:24 PM, Jeffrey S. Young <young at jsyoung.net> wrote:
> 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?)

not a big provider, but ras at e-gerbil did release irr-tools no?

> 2.  Implement the "1-hop" hack to protect your BGP peering.
>
> 98% of problem solved on the Internet today
>

which problem? GTSH only protects your actual bgp session, not the
content of the session(s) or the content across the larger network.

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

max-prefix already exists... sometimes it works, sometimes it's a
burden. It doesnt' tell you anything about the content of the session
though (the YT routes example doesn't actually work that way)

> 99.9% of problem solved.

? not sure about that number

> 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

there are folks working on the #4 problem, not academics even. It's
not been particularly sexy though :(

> 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 missing something here... it's not clear to me that 'tier1'
providers matter a whole lot in the discussion. Many of them have
spoken up saying: "Figuring out the downstream matrix in order to put
a prefix-list on my SFP peer is not trivial, and probably not workable
on gear today." (shane I think has even said this here...)

> 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

right, so today you have to do a lot of math/work to figure out if
your customer's prefixes are hers, and if they should be permitted
into your RIB. Tomorrow you COULD get a better end result with less
work and more assurance given a populated resource certification
system.

Extending some into the land of BGPSEC you COULD also know that the
route you hear originated from the correct ASN and later you'd be able
to tell that path the route travel was the same as the ASPATH in the
route...

-chris