If you are an operator, would you deploy soBGP or something like it? If not, why not.
/vijay
As far as answering the "First Goal" of the article, I really don't see much here that isn't handled today by route registries, except for the TLS certificate stuff. Not sure how much security that adds, practically; how often do people see their route objects jacked by hax0rs?
For the "Second Goal" part, this is somewhat intriguing, although I would like to know how often "fake" as-paths get leaked and if it really happens often enough to justify a new BGP infrastructure in order to prevent it. Maybe as part of BGPv5, where there are other benefits to migrating to the new protocol (32-bit ASNs, anyone?)
In short, the goals seem laudable, but it seems that this solution seems a bit, well, extreme, and I'm not sure if the disease if worse than the cure. That said, I'm curious how much of this can be implemented realistically at the single-peer level the paper mentions. Just don't ask me to run it on a GRP-B.
-C
I think it'd be running on even your customer's 2500... and your 7500 and
your 7200. 
hurray!
Unfortunately it doesn't really matter how unlikely or how infrequent
people hijack routes. The hijack of one high profile prefix is going to
cause a lot of damage, which could number in the multi-millions of dollars.
I also don't see routing registries today really providing highly accurate
information. Sure most of the time it is pretty good but you really don't
know for sure. Yes securing BGP is a lot of work, but I believe something
is going to have to happen as time goes on. There is just too much risk
for not preventing hijacking of address space. We as operators can decide
to secure the network or after some 'incident' occurs a government will
mandate something that may not be fully baked and could be a lot more work.
Andrew
If you are an operator, would you deploy soBGP or something like it? If
not, why not.
as smb has said for years, routing and dns are the two largest
vulnerabilities.
something like it, for sure. but i vastly prefer the s-bgp
approach as it maps closely to bgp operational reality, and does
not rely on a published policy database, which we have seen fail
for over a decade, etc.
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.
randy
something like it, for sure. but i vastly prefer the s-bgp
approach as it maps closely to bgp operational reality, and does
not rely on a published policy database, which we have seen fail
for over a decade, etc.
So, can someone point out the important operational differences between the two?
From 10K feet view, the only major difference seems to be that sBGP
also wants to protect the BGP sessions w/ IPsec all in one solution. (Personally, I don't care about that all that much, and I have some doubts whether this is a good approach for deployability in mind.)
Maybe the important operational differences are only observable from 1K feet view ?
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.)