On Tue, 30 Jun 2015, Sandra Murphy wrote:
On Jun 30, 2015, at 10:39 AM, "Justin M. Streiner" <[email protected]>
wrote:
At a minimum, AS-PATH filtering of outgoing routes to just your ASN(s)
and your downstream customer ASNs. Whether this is done manually,
built using AS-SETs from your route registry of choice, or through some
other automated means is another story.
That sort of AS_PATH filtering would not have helped in this case. The
AS originated the routes, it did not propagate an upstream route.
I didn't realise they offending AS was originating those routes, rather
than propagating the existing ones.
So an AS_PATH filter to just its own AS would have passed these routes.
That's why I suggested it as a minimum precaution. When I worked in the
service provider world, we did prefix + AS-PATH filtering + max-prefix,
which was pretty effective in keeping BGP-borne madness down to a dull
roar. Would that stop everything? No, but it did help a lot. I still
work in a BGP-speaking organization - just not one that has downstream
BGP-speaking customers at this point.
You would need origin validation on your outbound routes. Job
suggested prefix filters on outbound routes. (If you are doing prefix
filters on your inbound customer links, it might be excessive caution to
also prefix filter customers prefixes on outbound links? Or is it: you
can never be too careful, belt-and-suspenders, measure twice, etc?)
It depends on how much automation can be done to update the
necessary filters and AS-PATH ACLs, and how much you trust both the
automation method and the data source for those filters.
jms