Re: [GROW] I-D Action: draft-ietf-grow-simple-leak-attack-bgpsec-no-help-03.txt

[Jared Mauch <[e-mail]>]

On Nov 26, 2013, at 4:24 PM, Geoff Huston <[e-mail]> wrote:

> I reviewed the mailing lists of all three WGs from November last year, when this came up.
> and I was searching for a proposed methodology of defining requirements, proposing mechanisms
> and standardising one of more candidate technologies relating to the issue of path
> control of the propagation of BGP announcements in order to allow BGP speakers
> to detect unintended announcements. My search of the list archives was unsuccessful.
> 
> As I seem to be the only one interested in an answer, I give up.

At $dayjob, we have a list of ASNs that we shouldn’t see from our customers.  We work to update
our AS_PATH filtering to match these as the network evolves.  Our AS_PATH filtering may be
different than your list.

The biggest problems I’ve seen/observed are:

a) People put stuff into an IRR and it never comes out
b) Routers lack sophistication in configuring policy (or the configured policy blows out its config/memory/structure space)
c) Customers will pay to not be filtered at all
d) Networks don’t care to address issues (e.g.: AS-FLAGT expands to how many routes?)

This is a hygiene issue like showering and brushing your teeth.  Vendors figure it’s an operator problem (then freak out when we show them the scale).  Customers and peers don’t address the tragedy of the commons.

We’re left with little traction to put ourselves on a trajectory for a fix as the average BGP speaker is an IOS devices that still today sends/receives all routes learned by default with no policy configured.

- Jared