[126310] in North American Network Operators' Group
Re: BGP (in)security makes the AP wire
daemon@ATHENA.MIT.EDU (Leo Bicknell)
Tue May 11 11:04:29 2010
Date: Tue, 11 May 2010 08:03:49 -0700
From: Leo Bicknell <bicknell@ufp.org>
To: NANOG list <nanog@nanog.org>
Mail-Followup-To: NANOG list <nanog@nanog.org>
In-Reply-To: <308599F2-201F-4C34-862B-4E4B6BF4C875@cs.columbia.edu>
Errors-To: nanog-bounces+nanog.discuss=bloom-picayune.mit.edu@nanog.org
--VbJkn9YxBvnuCH5J
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable
In a message written on Sun, May 09, 2010 at 09:32:57AM -0400, Steven Bello=
vin wrote:
> http://www.nytimes.com/aponline/2010/05/08/business/AP-US-TEC-Fragile-Int=
ernet.html
>=20
> It's a pretty reasonable article, too, though I don't know that I agree a=
bout 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-road=
way-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.
--=20
Leo Bicknell - bicknell@ufp.org - CCIE 3440
PGP keys at http://www.ufp.org/~bicknell/
--VbJkn9YxBvnuCH5J
Content-Type: application/pgp-signature
Content-Disposition: inline
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.13 (FreeBSD)
iQIVAwUBS+lx1bN3O8aJIdTMAQJ/Gw/+IVbm4D+fS/diYFXdvznpiJS7laObf8BJ
YOJNAIQ3G9a8PACYkqcFKxPg974Yf15whI1IQIICKpRkA3yL34fLNrboJysbbrQE
t230HE8cI3lBgCP3FVlMkQykMOHpMw37gWpo0AZSSNbtH4rL8Q/oKwjTpf1uQCbg
kI2SzXqyCYeUAmtLEIjfyAkg6Jqa74913Gs0kiUKS+i6cKYVxax8jeJiCmJa7hmq
HG18IsyJsverU8FuyOkyyyte3o3s68OA4FP6qZdNt7Rjttc4JNZ3doG6RvvoEmtH
XTRMh9CKJMl4qYWx11OUXRCHEWJtoO9WtUpraN6iunHd7ycdubJpXt1+NETIw+x5
BTC78b9Bs3scZMI8UHAE2dyEk/ddRqT+o5GqX7/SAPR9ejBpzIreFAeCdkl3fxS5
F7n7pueOxCjqV7pXrDz0vlGYrk0d8gk0gZadd2oe/qUwxvmwLeiif2D/R+aqqTBe
uqfzqPhVDSOD6MGELGnEk0VEXAlrW7dJCcGOiFx2DSLFruEq92dKvTYoS3BzOIJ/
ikgbAZs9VE92kAMfykYU3Al6/7LQSLgZojGYuix9SzSFvTZd4IUi5iRxt28wJ+uQ
nrbCgwAIk4Ek+EbA0oU6CyVFeZVed1b3HyjeZhVeQ1gfqgkUgmfu1Vi/VX09ba+S
yfBkuY1304A=
=5eCr
-----END PGP SIGNATURE-----
--VbJkn9YxBvnuCH5J--
