North American Network Operators Group|
Date Prev | Date Next | Date Index | Thread Index | Author Index | Historical
Re: soBGP deployment
I don't understand this assertion. I get the feeling there's not a lot of understanding about how soBGP actually works....1) Keep the security ancillary data nearby. You might need it when the source of the data is unreachable (perhaps because of an incident like a flood).That is why in my view soBGP is something that can only be deployed as an after-filter (i.e. ones full BGP mesh is in for decisions about if the routing data is to be passed along to other peers or to IGP).
An AS _does not_ connect to a centralized location of any type with soBGP. You receive certificates through one of several possible sources, including a new message type within BGP itself--so you can receive certificates through "set aside" BGP sessions, or through "normal" peering, whichever way makes more sense for your architecture.
Once you have these certificates, you build a database of validated certificates that attest to specific information, including origination authentication and paths, and you _can_ (though no-one is forcing anyone to) also hang policy off this database. This operates in exactly the same way as BGP does today. It's distributed, peer to peer. As long as your interface to all your external peers is consistent, it will work, no matter how you implement it internally--just like you can use confeds, route reflectors, full mesh iBGP, route servers, or anything you like within your AS with BGP today.
AFAIK, you can't strip sig's out of S-BGP because of the way the sigs are built. You can't strip sig's out of soBGP because they simply aren't there. soBGP does not touch, in any way, shape, or form, the current BGP packets. There are additional message types proposed, but these in no way impact any current NLRI information, at all.2) Appending signatures is dicey. It has to be all public key and there's never a guarantee that the latest signer hasn't stripped out previous entries. (That could make a longer path seem shorter in order to redirect traffic.)
This is exactly how link state protocols work, no? They talk to their nearest set of neighbors, but then they build a complete SPF from the information they gain through this discussion. This is, precisely, how soBGP validates paths.IMHO - the inherent problem is that a router is trying to work inside the plane of activity (meaning it can only talk to it's nearest neighbors), but it takes the view point of something with ubiquitous knowledge to know if every thing is cool. How can you do this without a trusted third party involved somewhere, in a way that is not obtrusive (whether at registration time or at run time)?
email@example.com CCIE <>< Grace Alone