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

["Sriram, Kotikalapudi" <[e-mail]>]

Brian,

Thanks. I bring this back on the SIDR list as others may be having the same questions. 

I have no grasp of the details of your method based on crypto fundamentals yet,
but at a different level I have some performance questions based on the descriptions
that you have provided.

Per your explanation below, the validating router or the OOB validator is doing query/response per update.
That would entail one or more round-trip messaging delays (between the validating entity
and each of the signing ASes or "sources-of-truth") in the validation processing time of each update. 
These delays would need to be factored into processing speed estimate for update validation,
which may be slowed down considerably as a result. Would you agree?

For the signing speed, earlier you had estimated 400,000/(0.09 sec) = 4.4 million (approx.) signings per second.
Now you are saying, "Software-based signing at 10,000/sec is still able to produce
adequate results at very low costs."
What caused the drastic lowering of the signing speed estimate from 4.4 million to 10,000 per sec
(or perhaps I misunderstood something)?

Sriram 

>
>From: Brian Dickson [mailto:[e-mail]]
>Sent: Monday, May 07, 2012 6:21 PM
>To: Sriram, Kotikalapudi
>Subject: Re: [sidr] Keys and algorithms for Updates - feasibility analysis? (was Re:
>RPKI and private keys)
>
>Yes, per update.
>
>The router would spew its incoming updates (or pieces of them) to the OOB
>validator, who would be responsible for looking them up, doing retries/time-
>out/caching, etc.
>
>The router would not be doing the queries, per se. But it would pass on the bulk
>update data, and the validator would need to possible/probably do multiple
>queries per update.
>
>E.g. If there was a single update with AS path of "3 2 1"  (originated by AS 1), and
>nonces "N3 N2 N1", the router would send a request to the validator, saying
>"isvalid:3,2,1:N3,N2,N1", and the validator would then look up N3 at the source-
>of-truth for AS 3, as well as looking up N2 at AS 2's source-of-truth, and N1 at AS
>1's source of truth.
>
>Depending on how the system was built and operated, any number of things
>could optimize look-ups:
>- the OOB validator (for this router) might have cached values for any or all of N1,
>N2, N3
>- the lookup for N2 might start with asking the source-of-truth for AS 3, if that
>host had a cached value for N2
>- if a cached value is used, the cached value might need some other validation
>processing (e.g. DNSSEC validation, if the data is in DNS)
>
>DNS authoritative servers are known to be able to serve up data at rates >>
>100K/s.
>DNS hardware-based DNSSEC signers can sign-on-the-fly Even if an AS has a
>bunch of routers, and each router has a bunch of peers, the DNSSEC data would
>likely be served out of a single DNSSEC zone (simplifies signing considerably).
>Hardware-based signing with a small number of keys, with redundant hardware
>and redundant geographical locations, is a solved problem.
>Hardware modules can be configured to make keys unrecoverable, i.e. strictly
>kept inside the hardware, hardened against any kind of inspection.
>
>Managed (by a third party) DNS with DNSSEC is a viable option here. The signing
>of data does not require exposing the private key, if the private key is inside
>hardware and is not recoverable.
>
>Nobody queries the signing router directly, ever.
>
>The signing router sends a unidirectional feed of what range of current sequences
>are, and what updates have been over-ridden or withdrawn, over a secure
>channel to the "source of truth".
>
>The workload of the signing router is extremely small.
>The workload of the validator (OOB) is moderate, but scales well when handling
>multiple routers (since many of the updates will share some ancestry).
>The workload of the source-of-truth is also moderate, mostly because it is looking
>up fixed values in a hash table and quickly giving an answer.
>The scope of the source-of-truth is its own ASN, plus perhaps any other ASNs on
>whose behalf it is operating the service (third party customer).
>A validator would potentially need to have all the public keys of all the ASNs in
>existence, but that is not excessively large, and will generally not change much at
>all.
>The keys can either be pre-loaded, or cached as needed, depending on the
>performance characteristics of the local AS.
>
>The design is deliberately lightweight, and scalable. The traffic levels (packet/sec)
>might be low or high, the capacity offered performance-wise (to handle worst
>case scenarios) should be very high, and would be low cost.
>
>Hardware-based DNSSEC signing would be an optimization, not a mandatory
>requirement. Software-based signing at 10,000/sec is still able to produce
>adequate results at very low costs.
>
>Brian
>
>>On Mon, May 7, 2012 at 5:49 PM, Sriram, Kotikalapudi
>><[e-mail]> wrote:
>>
>>>The validator would need to talk to the source-of-truth, using a query/answer
>>>type protocol, preferably with cacheable answers, preferably over some secured
>>>channel (e.g. using DH shared secret).
>>
>>Brian,
>>
>>Are these query/answer per update?
>>Does the validating router make a query to each signing router (or AS) for each
>>update?
>>
>>Sriram