|
North American Network Operators Group Date Prev | Date Next | Date Index | Thread Index | Author Index | Historical Re: soBGP deployment
On 21-mei-2005, at 20:25, Randy Bush wrote: [skip to the bottom for my reaction to Randy's post]If you are an operator, would you deploy soBGP or something like it? If 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. 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.something like it, for sure. but i vastly prefer the s-bgp approach as it maps closely to bgp operational reality, 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 failsoBGP 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. 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.)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.
|