Re: [sidr] BGPSec scaling (was RE: beacons and bgpsec)

----- Original Message -----
From: "Rob Shakir" <rjs@rob.sh>
To: "Jakob Heitz" <jakob.heitz@ericsson.com>
Cc: "sidr wg list" <sidr@ietf.org>
Sent: Wednesday, September 07, 2011 4:48 PM
>
> On 7 Sep 2011, at 14:12, Jakob Heitz wrote:
>
> > While a router that performs BGPSEC may not be more expensive in 5 years
than one that does not today, that is not relevant. A router that performs
BGPSEC in 5 years will most definitely cost more to produce as well as cost more
to run than a router that does not perform BGPSEC in 5 years.
> >
> > So, a question for you Rob. Will your customers pay the premium for BGP
security?
>
> Hi Jakob,
>
> This is of course an interesting question - which comes down to the question
of whether the threats that are being addressed by bgpsec are common-place. I
definitely have customers that would pay a premium to mitigate this as a DoS
vector, or malicious interception mechanism, but equally, have customers who
would not, based on their current experience.
>
> From what I have seen of the demand for origin validation at the current time,
I would say that my personal opinion (and no dataset to support this, sorry) is
that any willingness to pay a premium will grow relatively slowly. As such, this
makes the point about trying to ensure that we have a deployable protocol that
attempts to represent the smallest step change it can in terms of computational
requirements more important to me - since this will mean that it is easier to
begin deploying, and meeting the demand.
>

My own experience of promoting security (and for that matter resilience) is that
very few organisations are willing to spend until after disaster strikes.  And
when that happens, anyone without a solution ready is in trouble, so the onus on
us is to have specified a viable solution, the implementation of which is as
cheap as possible but no cheaper.  Then, when the evil empires turn to Internet
routing, as opposed to, say, e-mail, at least we can say that we did our part to
prevent it.

Promoting new functionality that turns straightaway into more revenue is the
easy part and it is rare for security to come in that category.

Tom Petch

> Kind regards,
> r.
> _______________________________________________
> sidr mailing list
> sidr@ietf.org
> https://www.ietf.org/mailman/listinfo/sidr