Re: [sidr] Keys and algorithms for Updates - feasibility analysis? (was Re: RPKI and private keys)

[Brian Dickson <[e-mail]>]

On Fri, May 11, 2012 at 2:00 PM, Murphy, Sandra <[e-mail]>wrote:

> Before we get too involved in discussing performance and different methods
> of measuring performance, I think it is very important to address the
> features of what Brian is suggesting;
>
>
Would you be so kind as to explain why you believe this is important? It's
not like the WG mailing list is overloaded or the participants doing much
(or even responding very much, it would seem.)
I was asked about this at the interim meeting, and there were many SIDR
participants who were not at the meeting (physically or remotely.) My
follow-up is pretty much required, just to inform the rest of the
participants.

We have not had, to the best of my knowledge, any (or much at all if there
was some) in-SIDR discussion of performance metrics on the proposed
mechanisms, when implemented in software, or when implemented in hardware.

It has been proposed that a roadmap timeframe of 5-7 years is acceptable,
in order that vendors provide hardware-based implementations. No
justification for this has been offered, beyond "well, it is common sense".

The requirements doc explicitly calls out hardware-based solutions as
acceptable, without any cost analysis or cost/benefit analysis, or absolute
performance metrics for requirements.

I think the starting point should have been previously, and in the context
of the current suggestions should be, performance numbers based on actual
experiments using the protocols in question (and alternatives where
alternatives have been suggested). In fact, the results from such testing
should help inform discussion on acceptable performance, and those
acceptable levels should be based on real-world observations of absolute
rates.



> such as:
>
> what security services are being supplied?
> who is involved in the service - where is the service applied and where
> validated?
> what is being protected?
> what are the components and the architecture?
>
> etc.
>

This can be addressed, for the moment, in a "Napoleon Dynamite" fashion.
- whatever is needed
- whoever wants to  & what do you mean by "service being validated"?
- bgp paths vs threats
- whatever they need to be, and whatever works

The basic thing here is, I'm asking the question, "Why is the heavy-duty
crypto needed?".
When I start using formal logic, I take a bunch of axioms, and rules based
off those axioms.
Then, take a hypothetical additional piece of logic (rule or assumption),
and see what it can be reduced to, in terms of which axioms or rules are
violated.

Working backwards, it appears the crypto is needed because all the
validation is based on information passed in-band.
Without the crypto, anyone can take part of another update, and forge
additions to it, or changes to it, trivially. (That's the case with vanilla
BGP, too.)

The additional assumption is, assume some OOB validation process, e.g.
suing an outside-of-BGP communication path of some sort.

And my question was, if we start the analysis by ignoring the details of
the OOB system, but merely presume it exists as an adjunct, what are the
minimum things we can do to tie into that system by adding _something_ to
BGP updates, and how does that change the performance (and thus cost) of
on-router stuff?

The reason it is fair to ignore the OOB element is, that unlike on-router
stuff, the possibility of achieving scaling benefits exists, since multiple
routers could conceivably use a shared OOB black box.

By definition, on-router stuff can't achieve scaling benefits of this sort.

And, also by definition, there is no requirement that the OOB component
look anything like the in-band stuff. The OOB could conceivably be anything
under the sun, and be implemented by any existing or new technology. It
could use DNSSEC, it could use IPSEC, it could use LDAP, it could use
Kerberos (how, I don't know, but it could), it could even use carrier
pigeons or SMTP or SNMP or quantum encryption.

And systemically, any number of topologies are possible, since they are not
fundamentally tied to the topology of the BGP infrastructure itself.



>
> --Sandy, speaking as wg co-chair
>
>

When you speak as wg co-chair, I think it is important to be clear on the
rationale for any attempt to moderate on-topic discussion. No offense
intended, but not providing rationale looks to WG participants as political.

Thanks,
Brian


>

________________________________________
> From: [e-mail] [[e-mail]] on behalf of Sriram,
> Kotikalapudi [[e-mail]]
> Sent: Thursday, May 10, 2012 9:05 AM
> To: [e-mail]
> Cc: sidr wg list ([e-mail])
> Subject: Re: [sidr] Keys and algorithms for Updates - feasibility
> analysis? (was Re: RPKI and private keys)
>
> Hi Ross,
>
> The 10,000/s number is Brian Dickson's and
> it is not related to ECDSA (or RSA) signing/verification of BGPSEC updates.
>
> In my work on performance modeling of BGPSEC, I have used the basic
> signing/verification measurement data from the eBACS benchmarking effort:
> http://bench.cr.yp.to/results-sign.html
> The measurement numbers they report are in the same ballpark as yours for
> RSA signing.
> However, the BGPSEC spec draft specifies ECDSA-P256, which is much faster
> than RSA-2048 for signing.
> (Side note: ECDSA-P256 was also preferred because it results in a much
> lower size for BGPSEC updates
> and hence lower router RIB memory size.
> http://www.nist.gov/itl/antd/upload/BGPSEC_RIB_Estimation.pdf  )
>
> Regarding how the eBACS measurement data were used to model BGPSEC CPU
> performance,
> please see:
> http://ripe63.ripe.net/presentations/127-111102.ripe-crypto-cost.pdf
> (slides 10 and 11 summarize signing/verification speeds for various latest
> Intel and Cavium processors)
> or see,
> http://www.ietf.org/proceedings/83/slides/slides-83-sidr-7.pdf
> (slides 7 and 8).
>
> The performance modeling and measurement work is still evolving and there
> is still ways to go
> w.r.t. prototyping of BGPSEC and measurements with actual signed updates,
> etc.
>
> Sriram
>
> ________________________________________
> From: [e-mail] [[e-mail]]
> Sent: Thursday, May 10, 2012 4:35 AM
> To: Sriram, Kotikalapudi
> Cc: Brian Dickson ([e-mail]) sidr wg list (
> [e-mail])
> Subject: Re: [sidr] Keys and algorithms for Updates - feasibility
> analysis? (was Re: RPKI and private keys)
>
> Sriram
>
> You can't get 10,000 signature creations and verifications a second on
> a standard Intel core. You can get maybe 100.
>
> Your colleagues who work on smart grid standards have experience of
> this. The IEC working group assumed that all LAN traffic in
> electricity substations could be authenticated by digital signatures.
> This turned out to not work, and caused a major stall in the smart
> grid security program. Some substation LAN traffic has a hard
> end-to-end latency bound of 4ms, and that simply can't be achieved on
> standard cores using 1024-bit RSA signatures. You need custom
> hardware, which brings serious export control headaches as well as
> significant costs. We wrote this up in
>
>  http://www.cl.cam.ac.uk/~sf392/publications/S4-1010.pdf
>
> Ross
> _______________________________________________
> sidr mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/sidr
> _______________________________________________
> sidr mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/sidr
>