[102713] in North American Network Operators' Group
Secure BGP (Was: YouTube IP Hijacking)
daemon@ATHENA.MIT.EDU (michael.dillon@bt.com)
Mon Feb 25 05:56:15 2008
Date: Mon, 25 Feb 2008 10:55:31 -0000
In-Reply-To: <20080225074554.501a7d90@cs.columbia.edu>
From: <michael.dillon@bt.com>
To: <nanog@merit.edu>
Errors-To: owner-nanog@merit.edu
> Right. Everyone makes mistakes, but not everyone is malicious. And
> the RIRs and the big ISPs are *generally* more clueful than=20
> the little guys and the newcomers. Note also that secured=20
> BGP limits the kinds of mistakes people can make. If I have=20
> a certificate from my RIR for 192.0.2.0/24, I can't neither=20
> announce 10.0.0.0/8 nor delegate it to you, no matter how=20
> badly I type. Secured BGP still strikes me as a net win.
I suspect that a major part of the problem with implementing
Secured BGP is that it is put forth as a solution that you implement
in your routers. Network Operators are very careful about the
stuff that goes into routers, even to the extent that many
of them do not use SSH to manage them. Instead, they run
SSH on trusted and secured servers inside their PoPs and=20
configure their routers to only accept telnet sessions from
those trusted and secured servers.=20
Is there some way of deploying a solution like Secure BGP without
actually requiring that it go into the routers? Perhaps something
that allows the routers to still maintain BGP sessions that
can withdraw routes, or announce routes which were recently
withdrawn, but require a separate encrypted session between
two servers, each one in a trust relationship with one of the
BGP speaking routers, to handle announcements of new routes?
Pushing this task off to a server that does not have packet-forwarding
duties also allows for flexible interfaces to network management
systems including the possibility of asking for human confirmation
before announcing a new route.
--Michael Dillon
=20
