soBGP deployment

Steve Gibbard scg at gibbard.org
Wed May 25 18:59:32 UTC 2005


On Mon, 23 May 2005, Tony Li wrote:

> Which is EXACTLY why we need to remember that we are NOT trying to come
> up with the perfect solution.  We have operational issues *TODAY* that
> we are trying to address.
>
> - We have people (admittedly accidentally) advertising prefixes that
>  they do not own and thereby overloading BGP.  See the talk at the
>  latest NANOG.
>
> - We have people intentionally out there forging /24's as an attack.
>
> - We have OTHER people out there flooding the networks with their /24's
>  so that they are less vulnerable to attack by forged /24's, and
>  thereby exacerbating the BGP overload problem.
>
> Almost any of the popular proposals (and some of the really old ones)
> will address all of these issues.  But only if they are deployed.  We,

Speaking as one network operator who is less than excited about these 
efforts, here's my reasoning:

I know all the issues up there are real, since I've occasionally heard 
about them happening.  I understand the devastating consequences of 
somebody finding a sufficiently well connected unfiltered BGP session and 
using it to announce some important prefixes.  I fully agree that it 
should be fixed.

And yet, in the nine or so years I've been working on network 
infrastructure stuff, spoofed BGP announcements have never been a major 
cause of problems for me.  What I do see problems with on a fairly regular 
basis are legitimate routes getting deleted from filters and causing 
outages.

Therefore, when somebody tells me they're going to make the Internet more 
reliable by adding more things that need to be done right to make a BGP 
announcement work, I get a bit apprehensive.  When they further tell me 
it's going to get centralized, such that I'd no longer be dealing with 
multiple peers or upstreams maintaining multiple sets of filters that can 
be expected to not all break at the same time, I get even more nervous.

I hope any solution that finally gets settled on for this is done with the 
recognition that the goal is to reduce outages overall, rather than 
trading one outage cause for another.

-Steve



More information about the NANOG mailing list