On 21-mei-2005, at 20:25, Randy Bush wrote:
If you are an operator, would you deploy soBGP or something like
it? If
not, why not.
[skip to the bottom for my reaction to Randy's post]
I think it would be a very good idea to start experimenting with this
as soon as there are decent implementations.
The operational problem that soBGP will hopefully solve for me is
peering with lots of relatively small peers, some of whom may be clue-
challenged with regard to inter-domain routing. (AS number
consumption seems to be higher than BGP book consumption...)
It's not the really small networks that are the biggest problem, BTW.
It's the ones that have a few BGP customers but not enough to really
know how to filter them properly that are the most dangerous.
The trouble is that today, I basically have three choices:
1. Generate filters from a routing registry. Here in RIPE country, we
have a pretty good routing registry, because it's also the RIR
database. Still, many people don't register their stuff, or don't
register it correctly. And the tools necessary to generate
configurations are _very_ hard to use. Also, if something goes wrong,
my filters are zapped with unpredictable results. So basically I'd
have to work very hard to get something that doesn't work properly
and will kill my network if it fails.
2. Maintain filters manually. That won't scale, so the fact that
peers usually don't inform you when they have new announcements etc
doesn't even matter.
3. Use max-prefix and push a virgin into the volcano once in a while.
The nice thing about something like soBGP is that it makes it
possible to work together to solve this problem rather than everyone
having to do it on their own. For instance, if I know that networks X
and Y have very high standards and when they say something is ok, it
is, I could accept certificates signed by X or Y. This only requires
the bare minimum of clue from the origin AS: they need to include the
signed certificate, not much more. When something goes wrong, the
worst thing that can happen when (for instance) Y screws up, is that
I lose some peering routes, or I potentially allow some routes that
shouldn't be allowed. The former case isn't all that bad: I still
have all the routes for which I don't depend on Y. The latter case
could be problematic, but it would be hard for an attacker to abuse
this situation as she still has to corrupt the source or neighbor
ASes in question.
I'm not saying this will solve all our problems, but I think there is
a lot of potential here, and we need some operational experience to
guide further development.
something like it, for sure. but i vastly prefer the s-bgp
approach as it maps closely to bgp operational reality,
S-BGP signs every update. This is problematic in several ways. A
receiver needs to check all AS hops in each AS path (that would be
~500k for a full BGP table), which means you are pretty much forced
to have a crypto accelerator on board. Also, no more peer group
update optimization, so when you have a lot of peers you're going to
burn much more CPU time for every update.
Last but not least: because S-BGP signs updates, a secret key must be
present inside the router, making physical security much more important.
and does not rely on a published policy database, which we have
seen fail
for over a decade, etc.
soBGP and S-BGP aren't different in this regard, AFAIK. I don't think
either needs a "published policy database" but obviously they need
some trust anchors and access to policy information in some way.
we should learn from the decade-long problems with the deployment
issues in dnssec, and map routing security as closely as possible
to operational protocol and reality.
If you give people an incentive to use a technology, you'll see the
use of that technology increase over the situation prior to the
incentive. :-) (See MD5 last year.)
