BGP (in)security makes the AP wire

Leo Bicknell bicknell at ufp.org
Tue May 11 10:03:49 CDT 2010


In a message written on Sun, May 09, 2010 at 09:32:57AM -0400, Steven Bellovin wrote:
> http://www.nytimes.com/aponline/2010/05/08/business/AP-US-TEC-Fragile-Internet.html
> 
> It's a pretty reasonable article, too, though I don't know that I agree about the "simplicity of the routing system"....

I had avoided this topic at first, but some of the follow on comments
make me feel compelled to post.

Deep down inside every industry are things that on the surface seem
dangerous; particularly to someone outside of the industry.  These
make for excellent press headlines "Entire xyz one keystroke from
collapse!", but these stories do not understand even the smallest
fraction of the interaction.

Did you know there are no safeguards to prevent the pilot of your
next airplane from flying it into a building?

Least you think it's just nutjobs,
http://en.wikipedia.org/wiki/B-25_Empire_State_Building_crash

Did you know tanker trunks with 10,000 gallons of fuel are allowed
to drive in front of your kids school?

One truck took out a significant part of the MacArthur Maze in
Oakland,
http://articles.sfgate.com/2007-04-29/bay-area/17239903_1_tanker-truck-roadway-firefighters

Did you know that one operator of a nuclear power plant could cause
the entire thing to melt down, simply because they weren't trained?

http://en.wikipedia.org/wiki/Three_Mile_Island_accident

The problem with any of these situations is that they are in fact
complex systems.  There is no "one cause", ever.  The article
suggests that the lack of route authentication on peering is the
issue; it is not, it is one part of a majorly complex issue.  Adding
a filter to every peering session will not prevent prefix hijacking,
it will merely change how it is done.

I agree with Randy that we, as an industry, need to take steps to
prevent prefix hijacking.  I don't think letting a reporter dictate
the method from some scare article is the right answer.  But we
also need to realize there is a cost/benefit trade off.  We can so
lock things down and mire them up in change control that it costs
the economy (us and our customers) millions of dollars every day
in lost productivity, but we never have a hijack.  The real shame
is that no one is explaining that side of things.

So I disagree completely with Steven, this was an under-informed
reporter trying to scare people into thinking the Internet is a
massive house of cards that needs deeper regulation, oversight, or
something.  It's not reasonable in any sense of the word, and is
not a balanced, engineering based assessment of the risks and costs.

If we want to get this right, we need to quantify the effect of a
route leak in dollars, and the cost of detecting and preventing a
route leak in dollars.  We can then mix in some moral and ethical
views of the group and make sane engineering decisions with known
risks that everyone is comfortable implementing.

I will say this, my upstreams mucking up routing registry filters
have caused me outages hundreds of times.  I've had sites down for
days because of filtering issues.  I've also run into many cases
where I found routes taking suboptimal paths due to mis-entered
filters along the way; problems that those in the middle could not
even detect because they were being filtered!  I think if major
ISP's tried to implement routing registry filters on their PNI's
we would have weeks of outages and suboptimal routing, and the cure
would be far worse than the disease.

I hope that work on things like RPKI and SOBGP provide us a better,
more workable framework.  However, the jury is very much still out
in my opinion.

-- 
       Leo Bicknell - bicknell at ufp.org - CCIE 3440
        PGP keys at http://www.ufp.org/~bicknell/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 826 bytes
Desc: not available
URL: <http://mailman.nanog.org/pipermail/nanog/attachments/20100511/09b3e532/attachment.bin>


More information about the NANOG mailing list