North American Network Operators Group

Date Prev | Date Next | Date Index | Thread Index | Author Index | Historical

Re: soBGP deployment

  • From: Geoff Huston
  • Date: Mon May 23 15:12:42 2005

At 04:00 AM 24/05/2005, Daniel Golding wrote:


I suspect the right thing to do is to ask why soBGP and sBGP have failed?

And yes, they've failed. Just like DNSSec, we aren't seeing even limited
adoption. Why? Too complex, too many moving parts, too much reliance on iffy
third parties and requires mass adoption.
Or maybe, jut maybe, because we've never had the tools to deploy it. Lets face it, larger operators, and probably small operators, are not protocol or code developers by nature. Operational skills are strongly honed on process definition and subsequent adherence to process, as well as skills in box opening ( :-) ). However, I suspect that this circular argument of vendors claiming customers never demanded it and customers saying that vendors never supplied it is largely an irrelevancy, and to infer from it that the entire activity space is moribund is perhaps stretching this particular set of excuses relating to inactivity a bit too far.

The issue is that we all really do not appear to appreciate the disturbing nature of the risks here, and consequently we really don't value measures that attempt to address these risks.

Generating authentic and trustable routing information to inject into the inter-domain routing system is one of those things that have to fit into an ISP's cost and revenue equation, and its often the case that this is not any easy fit. I'd contend that any robust form of certificate infrastructure that is strongly rooted in a trust anchor is far far better than what we have now (oh, please not the ring of trust stuff - it really is not enough in this case!) http://www.potaroo.net/ispcol/2005-02/index.html is one of many enumerations of the risks involved here. The IETF work in routing protocol security (RPSEC) has been working in this area for some time now and their documents about risks do not make comforting reading.

And then theres the mechanisms for inserting the validation elements into the inter-domain routing protocol. Again http://www.potaroo.net/ispcol/2005-03/route-sec-2-ispcol.html is one of a number of commentaries on the topic.

Why not do something simple?
Probably because you need to cross over a threshold from doing something just to make you feel better about yourself into an industry collectively deploying a technology that can provide all of us with reliable indications as to the validity of the information we are passing about, as well as the authority to allow you and I to pass it around.

The essential difference as far as I can see today between soBGP and sBGP in this space is that, as a 2 liner:

- sBGP allows the receiver to validate that the update indeed traversed the path described in the AS Path Update as part of the local acceptance of the update.

- soBGP allows the receiver to determine that the AS Path describes a plausible traversal across the network, but cannot validate that the update itself traversed this path.

In looking at this what I personally saw was a design tradeoff, where soBGP attempted to lighten the update load and the certification load by making one part of the BGP update message unprotected by a certificate set, while sBGP attempts to provide the receiver with sufficient information so as to allow the receiver to validate the entire update.

Unfortunately I doubt whether we can ultimately afford the luxury of allowing each operator to select their favourite form of validation of routing information. It would be preferable, or at least useful, to have some guidance provided by a standards body as to what is a useful and reasonable security framework for securing inter-domain routing, together with a protocol specification for doing the same. Indeed I would've thought it was core business for a standards body to assist the industry in this manner. And, hopefully, it will happen soon in this case, rather than way too late.

regards,

Geoff