|
North American Network Operators Group Date Prev | Date Next | Date Index | Thread Index | Author Index | Historical Re: soBGP deployment
With SBGP, each node signs the BGP statements it's about to send out. The accuracy of the security statement is thus linked to the transmission process. With SO-BGP, the security against in-path attacks (or cut-and-paste attacks; see below) relies on a secure version of the routing registry. If an AS forgets to update its routing registry to reflect new BGP adjacencies, paths containing them will be dropped by SO-BGP listeners. If old adjacencies aren't deleted, routes that shouldn't be accepted will be. In other words, there's a lot less coupling between the transmission process and its security properties. Look at it this way: do you think that (a) most sites will publish their policies in the registry, and (b) they'll remember to update them? As Randy has noted, we have a decade of experience suggesting that neither is true.There is no "registry." Each AS distributes set of certificates carrying a list of who they're connected to. You can, as an option, list who you allow to transit, and who you don't allow to transit, and other policies (nothing longer than prefix length x within this address block, etc). But, there's nothing saying you _must_ send any sort of _policy_ out. It's even possible to build the certificates so you can "hide" peering relationships you don't want to be known about by anyone other than the specific peers involved (by building multiple certificates of specific types, and filtering who you send them to). As for updating the information--each AS originates it's own piece, just like they do routes today. If they keep their routes up to date, there's no reason not to update your peering information in a certificate you're originating. It's not as if you have to make a phone call to the local RR, and have them update their database, etc.... Huh? :-) Since soBGP doesn't put anything in the existing BGP packets at all, there's nothing to "cut and paste" from one packet to another (?). You can "make up" paths, I suppose, but you'd have to make one up that:Let me add a word about cut-and-paste attacks. A signed origin statement asserts that some AS owns some prefix. That statement will be readily available. A nefarious site could cut that statement from some actual BGP session and prepend it to its own path announcement. That would add a hop, but many ASs will still prefer it and route towards the apparent owner through the nefarious site. The nefarious site wouldn't forward such packets, of course; it would treat the packets as its own. -- already exists -- has one end anchored at the receiving AS -- has the other end anchored at the originating AS That's a pretty narrow range of "made up paths." When you start factoring in aggregation of routing information, you quickly realize there are much larger holes in aggregation than the "hole" of replacing one path that exists with another path that exists. As for deploying this on a 2500--well, that's never been envisioned. The entire architecture has always been envisioned as running either on _or_ off box, where you could do the crypto part once on an "soBGP server," and then let the routers on the edges ask this "server" about the routes they receive. This is explicitely called out as the most likely deployment possibility in the current architecture draft, and also in evvery presentation we've ever given on it. Of course, you can always do it on box, as well, given the box in question has the resources available. It's also possible, with the current architecture, to spread the certificate processing (the crypto part) across all the edges of an autonomous system. I don't know how well thought that part is, at this point, but we've always intended to allow that sort of thing to be done, as long as we can figure out how to do it and not break anything. :-) :-) Russ __________________________________ [email protected] CCIE <>< Grace Alone
|