[Sidrops] Re: draft-li-sidrops-rpki-repository-problem-statement-00

[Tim Bruijnzeels <[e-mail]>]

Hi all,

I agree with Job’s comments.

I could add some footnotes here and there, but won’t do that for now, except on
this:

> On 30 Sep 2024, at 18:59, Job Snijders <job=[e-mail]> wrote:
> 
> 
>   437 5.2.  P2: RPKI Repository is costly in RP refreshing.
>   438 
>   439    Refreshing the local cache of each RP involves traversing all
>   440    repositories to fetch the updated RPKI objects.  However, the binding
>   441    of the repository PP to the CA causes the number of repository
>   442    instances to increase dramatically with the further deployment of ROA
>   443    (as the number of CAs that hold RCs increase).  Furthermore, as AS
>   444    administrators gain a deeper understanding of RPKI technology,
>   453    delegated RPKI has emerged as a trend, CAs are more willing to
>   454    maintain the repository PP themselves to achieve more flexible
>   455    certificate signing and management.  The growth in the number of
>   456    repository instances increases the cost of RP refreshes, the growth
>   457    in the number of RPs brings burdens to repositories, and both will
>   458    threaten the scalability of RPKI.
> 
> Delegated RPKI has not emerged as a trend.

As Job mentioned in between the lines as well, delegated CAs can use a Publication
Server that is provided by a third party. E.g. NIC.BR provides this to more than
2500 delegated CAs operated by their members, and APNIC, ARIN and RIPE NCC also
provide publication as a service to their members.

In my experience, and I think the data agrees with me, most delegated CAs are
perfectly happy to outsource their publication service to their parent CA. This
still allows them to have a local delegated CAs where they have full control over
the keys, access, delegation. And this allows them to use one CA implementation in
case they have resources under multiple parents. The trust relationship with
such publication servers already exists because that is typically the same
organisation which signs (one of) their CA certificate(s). In other words, there
is little or no extra risk to the child CA in trusing them with publication.

In short, delegated RPKI can easily take off without this resulting in a large
number of (unreliable) repositories. Incidentally, this point appears to be
completely overlooked by the “Behind the Scenes of RPKI” research cited in this
draft.

Kind regards,

Tim