soBGP deployment

Mon May 23 19:11:35 UTC 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