Hi,
Matt Lepinski wrote:
2) The second question is: If we make a recommendation regarding
frequency with which relying parties should pull updates, what frequency
should we recommend.
Here, I understand that "everyone hitting the repository system at once"
is a bad outcome regardless of the frequency that we recommend. That is,
regardless of whether we recommend "once per day", "once per month", or
"eight times daily" we will likely see problems with too much server
load at midnight. If anyone can recommend text to avoid this phenomena
(i.e., to encourage people to spread out their queries to the repository
system), please send text.
Keep in mind that "midnight" is a relative term, so this is not as bad as it
sounds.
I agree that there are roughly 30,000 AS numbers visible in BGP, so it's
reasonable to assume on the order of 30,000 relying parties who will be
routinely querying the repository system. We might also assume that
30,000 is a reasonable order of magnitude for the number of CAs in the
RPKI (we might easily average 2 CAs per AS, but surely not 10 CAs per AS).
Do you have any supporting evidence to this claim "but surely not 10 CAs per
AS"?
In any case, I believe the way forward (with regards to server load) is
to answer the question, "How many simultaneous connections are
reasonable for a server that hosts publication points for X CAs?" and
then work backwards from there to determine if a given interval of
relying party requests is reasonable from the server standpoint. I admit
that I haven't completely thought through re-key, but I'll try to dig up
some rough connection-time numbers based on our relying party software,
and do a few back-of-the envolope computations.
There are other inputs to this calculation, not just the number of CAs. For
example, the number of certificates issued per CA, and in close relation,
the frequency with which the set of issued certificates changes, can vary
wildly (for a potential single root it's probably a few, for an RIR it's
thousands, for an LIR/ISP it's likely only a few).
With regards to client load, I'm not convinced that there's any problem
with frequent queries to the repository system. If the relying party
queries a publication point and rsync determines that nothing has
changed, then no changes are required to ethe relying party's local
cache and no cryptographic calculations are required. If something has
While this in itself is true, you have to keep in mind that manifests and
CRLs have to be regularly re-issued, so even if nothing substantial has
changed, you do have to validate objects (and _then_ you'll realize that
nothing really changed).
changed, then the relying party has to perform validation (which
includes cryptographic signature verification) on the manifest and any
new objects that have been added. (Additionally, there may be resulting
changes to the client's local cache ... e.g., if a new CRL revokes a
previously valid certificate ... but such changes don't require new
cryptographic computations, and so I believe the bottleneck is going to
be the one or two signature verifications per object changed [1]). Now
the point from the relying party side is that if 5,000 manifests change
and 10,000 signed objects are added to the repository system on a given
day, then the relying party needs to do roughly 30,000 signature
verifications regardless of whether it learns of all these changes at
once, or whether it learns of them in small batches throughout the
course of the day. Therefore, I don't see how making frequent checks for
new data has a significant impact on the relying party's processing load.
That depends on how expensive the null operation is (ie. rsync figuring out
that nothing has changed). I have no idea, but for a popular repository,
such as an RIR's might be, it is probably not trivial. So experiencing it
less frequently is useful.
In any case, it's good to know that we'll have plenty to talk about in
Hiroshima.
Indeed!
Robert
- Matt Lepinski
_______________________________________________
sidr mailing list
sidr@ietf.org
https://www.ietf.org/mailman/listinfo/sidr
