[Sidrops] Re: Introduction: draft for the Null Scheme

[Tim Bruijnzeels <[e-mail]>]

> On 9 Oct 2025, at 21:35, Christopher Morrow <[e-mail]> wrote:
> 
> On Thu, Oct 9, 2025 at 3:17 PM <[e-mail]> wrote:
>> 
>> Hi Christopher and Tim,
> 
> hey there :) ('chris' is fine, long ago gmail selection of names got me :( boo)
> 
>>> Why are the sizes here important?
>> 
>> I might misunderstand your question, but: indeed these things are part of the RPKI data.
>> RPKI signed objects are not shipped *between routers* through BGP (where sizes are strict; this will be very tough for post-quantum BGPsec).
>> But they are downloaded by Relying Parties (validating caches) all the time. While performance there is less critical than in BGP, sizes are important for various reasons:
>> 
>> - They influence the time it takes an RP to validate data, and hence the latency between ROA creation and its propagation into routing.
>> - The RPKI size costs bandwidth (and hence hosting costs) for both RPs and Publication Server operators.
>> - The same applies to archival projects like https://rpki-study.github.io/rpki-archive/.
>> 
>> With the current RSA-2048, sizes are manageable, but performance is nonetheless a relevant topic that is often discussed.
>> When considering post-quantum signatures, the sizes increase significantly, such that having a measure like the Null Scheme to compensate is desirable.
> 
> I get that we're asking RPs and publication points/servers to
> serve/download 'larger files', but I don't think the size here is
> really relevant.
> I don't even thing the verification timing is relevant, and i don't
> think it's actually changing the real time between "i gotta new
> prefix!" and "everyone has my roa!"

It's true that this is only one step in the chain, but I believe that
all the bits (or well.. time) can help in the end. It's early days but
I think the Erik protocol has potential for delivering content faster
as well. But yes, this still leaves other bits in the whole CA to router
chain.

> 
> Or, perhaps said another way, it seems nice that we can shrink the
> content some, i just don't think that shrinking actually matters.
> Is there some study work that shows how 4% (22 of 592 ~3.7%) reduction
> in size translates into something meaningful in the overall pipeline
> here?

That's the reduction if ECC is used.

For the null scheme Dirk mentions 170MB saving out of 840MB. Though I
am not entirely clear on the calculation an total size here that is a
20% reduction which is fairly significant in terms of CDN data cost and
download times, escpecially for full re-syncs (like an RRDP session reset).



> 
> _______________________________________________
> Sidrops mailing list -- [e-mail]
> To unsubscribe send an email to [e-mail]