On Mon, Aug 28, 2017 at 03:48:44PM +0000, someone wrote:

Damn you Google.. yup.

I am not sure it is fair to say "damn you Google", because accidents happen (be it through human error or software defects). All of us have entered commands at some point and subsequently https://media.giphy.com/media/bI5BEfwbdVPcA/giphy.gif Software defects are a real risk as well: Major BGP implementations have had bugs which caused NO_EXPORT functionality to malfunction, or bugs where random pieces of your configuration are ignored (for instance the part of the configuration which contains a prefix-filter). Allegedly the famous AS 7007 incident was also caused by a software defect. The key concept here is that, since we know accidents an happen, we ought to look out for each other and impose multiple layers of protection for our mutual benefit. Mechanisms that come to mind are maximum prefix limits and coarse as-path filters. At NANOG67 I described a few of these tricks https://www.youtube.com/watch?v=CSLpWBrHy10 / https://www.nanog.org/sites/default/files/Snijders_Everyday_Practical_Bgp.pd... To further reduce the risk surface, it may be good to ask your BGP vendor for specific behaviour applicable to EBGP sessions: ask for RFC 8212 support. RFC 8212 defines that when you configure an EBGP session without any routing policy associated with that neighbor, no routes will be exchanged until it is explicitly instructed to do so. Finally, it may be worthwhile exploring if we can standardize and promote maximum prefix limits applied on the the _sending_ side. This way you protect your neighbor (and the Internet at large) by self-destructing when you inadvertently announce more than what you'd expect to announce. BIRD has this functionality http://bird.network.cz/?get_doc&f=bird-3.html#proto-export-limit however I am not aware of other implementations. Feedback welcome! Kind regards, Job

On Mon, 28 Aug 2017, Marcus Josephson wrote:

Damn you Google.. yup. Thanks for links.

A public post-mortem would be highly appreciated (from all parties). -- Mikael Abrahamsson email: swmike@swm.pp.se

Good use-case for https://datatracker.ietf.org/doc/draft-ietf-grow-bmp-adj-rib-out and snapshot auditing before and after changes. Leak didn't last long but it could have been caught within milliseconds verses minutes via oh sh** alarms. --Tim On 8/29/17, 6:46 PM, "NANOG on behalf of Randy Bush" <nanog-bounces@nanog.org on behalf of randy@psg.com> wrote: >> Damn you Google.. yup. Thanks for links. > A public post-mortem would be highly appreciated (from all parties). there has been more press hysteria on this than actual packet droppage. goog fat fingered or otherwise misannounced a numer of large consumer isp's prefixes. the leak was for aybe 20 minutes. almost no one over here noticed. but the press, isoc, ... said "japan knocked off the internet." take that as a calibration of the press, isoc, ... randy