Verizon 701 Route leak?

Mon Aug 28 17:34:14 UTC 2017

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

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