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

[Yingying Su <[e-mail]>]

Hello Tim

I’ve added some comments in-line.

> -----原始邮件-----
> 发件人: "Tim Bruijnzeels" <[e-mail]>
> 发送时间:2024-10-14 22:15:19 (星期一)
> 收件人: "Yingying Su" <suyy=[e-mail]>
> 抄送: "Job Snijders" <job=[e-mail]>, [e-mail]
> 主题: [Sidrops] Re: [Sidrops] draft-li-sidrops-rpki-repository-problem-statement-00-scalability issues
> 
> 
> 
> > On 14 Oct 2024, at 13:07, Yingying Su <suyy=[e-mail]> wrote:
> > 
> >>   330     Similarly, it is also challenging for RP
> >>   331    softwares to clearly limit the maximum number of accessible
> >>   332    repositories.  In addition, a series of recent academic works have
> >>   341    emerged that exploit repository vulnerabilities to cause repository
> >>   342    downtime, thereby preventing it from providing normal services to RPs
> >>   343    [behind-the-scenes].  There are also works [beyond-limits][stalloris]
> >>   344    that manipulate malicious repositories to attack RPs, thus
> >>   345    obstructing the synchronization of RPKI data.
> >> 
> >> The papers referenced here are not entirely without controversy.
> > 
> > What is the specific controversy?
> 
> To name one one thing the [behind-the-scenes] paper seems to claim that operators
> can only choose between:
> - A CA and Repository hosted by their RIR/NIR
> - A self-hosted CA and Repository
> 
> There is a third option where a self-hosted CA uses a publication service provided
> by a third party, typically the organisation's RIR or NIR.
> 
> There are over 2500 self hosted CAs in Brazil that use a publication service
> provided by nic.br <http://nic.br/>. This number is this high because nic.br <http://nic.br/> members cannot use a
> self-hosted CA, they have to use a delegated CA, but they can publish at nic.br.

These 2,500 self-hosted CAs still controlling their private keys and being able to use their private keys to sign subordinate CAs or ROAs, correct? In other words, they are still running the CA engine, but not operating the repository publication point, and instead, they are publishing their certificates to the repository hosted by nic.br?

> Looking at RIPE NCC, the majority of its members choose a hosted CA and repo, but
> some run their own CA and we see more than 150 of those using the publication
> service provided by the RIPE NCC.

Does RIPE NCC also allow CAs to run the CA engine but use their publication point for data publication? How did you measure and find that 150 CAs run their own CA engine but use RIPE NCC's publication point? Because I feel it’s difficult to distinguish, from the data synchronized from RIPE NCC, whether a CA is fully using hosted RPKI or is still able to sign subordinate CAs or ROAs but hosts the signed RPKI data objects in RIPE NCC’PP.

> Missing that this option exists (and is in fact widespread) means that at least
> one of the fundamental assumptions in this [behind-the-scenes] work is flawed.

The author of [behind-the-scenes] describes in lines 10-12 of section 3, “The publication points are operated either in a hosted mode, e.g., by the RIRs, or in a delegated mode by an owner AS.”  Indeed, they did not consider cases like nic.br, where the CA engine is operated but not the repository PP (This is neither a purely hosted RPKI model nor a purely delegated RPKI model). However, the differences in understanding the actual operational modes of the CA and repository do not seem to affect their experimental conclusions, as they are analyzing the weakness of the DNS component that the RPs in RPKI use to look up the PPs.

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