Subject: Re: [sidr] comments on the repository analysis I-D

From: Oleg Muravskiy <[email-masked]>
Date: Fri, 05 Apr 2013 11:18:50 +0200

Stephen Kent wrote:
> Oleg,
>> ...
>>
>> I'm not opposed to the 1AS = 1CA idea. It's just that in my mind RPKI associates with IP space holders,  not AS operators, 
>> because this is how we do RPKI on RIR level. And on this level we already have more distinct IP space holders than the number of 
>> active AS. I don't know much about LIR to end user level, maybe the number of CAs there will be insignificant.
> The RPKI is about who holds both sets of resources: addresses and AS#s. So, yes, as an RIR issuing certs
> for address space, the focus is on address space holders. When we discuss using AS#'s to estimate the
> number of CAs it is just because that seems like a reasonable estimator, not because it is the basis
> for the management of address space.

But RIRs will issue certificates to IP numbers holders, no matter how many AS# they have. This is a fact, not an estimator.
And it already makes the number of CAs created by RIRs bigger than the number of ASes. So I do not see why you still insist that the 
total number of CAs is reasonably equal to the number of ASes.

But the difference is not that big, so maybe we should mention in the requirements document all different estimations and stop this 
discussion.

> I am curious, though. When RIPE acts as a CA on behalf of 1300+ entities with address space, have you
> included the AS#s in the CA certs you issued, when the address space holders have AS#'s from RIPE?

No, we do not include AS# in our certificates.

-- 
Oleg Muravskiy
RIPE NCC

---

From: Tim Bruijnzeels <[email-masked]>
Date: Fri, 5 Apr 2013 15:46:35 +0200

On 27 Mar, 2013, at 6:24 PM, Randy Bush <[email-masked]> wrote:

>> 	Yes, I assume
>> http://tools.ietf.org/agenda/86/slides/slides-86-sidr-1.pdf slide 3.
>> 	Which I think is a good estimate.
> 
> actually, i think the number of pub points will be closer to the number
> of entries in the rir's datamesses, as they will be issuing the certs
> based on their data messes.

Indeed.

I disagree that the number of AS#s is a good estimator for the number of publication points.

As OIeg, and others, also mentioned the RIRs issue certificates based on the resources they know are held by organisations. Resources can be any combination of 0 or more AS#, 0 or more IPv4 prefixes and 0 or more IPv6 prefixes. So the number of distinct resource holders that the RIRs see is the estimator that is suitable here. There is a group of organisations that hold IP prefixes, but do not run their own AS. This group is missing from the slide.

Oleg made this estimate based on current stats:

> From the RIR stats files that RIRs publish daily we could get the numbers of distinct resource holders. They are:
> 
> AFRINIC  1310
> APNIC    7957
> ARIN     35380
> LACNIC   4278
> 
> For the RIPE NCC you could not get this data from stats files, and the exact number is difficult to get because of our model of provider-independent end users. But in our registry I could count that it is at least 28912.
> That brings the total to 77837.

After comments by Randy and John Curran it seems that the number for ARIN obtained here is too high. John suggested 50%. So then the total number would be roughly 60000. (no not trying to be more exact than the error term here, it's the ball park that matters)

So that's roughly 60k certificates that are going to published and, associated, 60k mfts + 60k crls.

Note, this is the boilerplate RPKI, just the 'publication points' and the objects necessary to support that.

The, more useful, content is a different story. I was looking for ballpark total numbers for ghostbusters, roas and router certs, but I don't believe that the number of publication points (~certified organisations) is the most important variable in each case. See below.

= ghostbusters

Okay, in this case I actually do believe that it will correlate most strongly with the number of publication points.. It seems a reasonable estimate be that each publication point will publish one record for all their resources. But, there is room for error here.. maybe some organisations will publish many records for specific resources they have. Others may just have one with everything. Yet others may publish none…

My current best guess is 1 per publication point, on average. So roughly 60k in total.

I am more than happy to change this number in the model with a better estimate.

Another approach could be to look at the current RIR databases and model this after the number of equivalent contacts found there now.

= roas

I am not convinced by the 1 ROA per AS. Aggregating all possible routes for an AS on a single ROA is not feasible. As mentioned above it's the prefix holders that make these ROAs. They may, or may not be holder of the AS. In practice there is a sizeable group of organisation who do not run their own AS.

In our document we figured that looking at the number of announcements in the current routing table, and the maximum aggregation factor of prefixes per ROA that we see today gives a reasonable estimate for the amount of ROAs needed to make all intended announcements appear valid. But the aggregation factor is quite fuzzy.. in particular it's difficult to deal with max length this way...

I just thought of another much simpler approach that seems better to me...

Based on the RIPE NCC router collector dumps:
http://www.ris.ripe.net/dumps/

And validation we do on the current RIR datasets.

We see:
= 479608 total announcements
= 10692 valid announcements
= 1197 ROA objects

So, average number of routes made valid by a ROA: 10692 / 1197 => 8.9 something.

So to get the number of ROAs needed to make all 479k announcements valid: 497608 / 8.9 => 53693

= router certificates

We explicitly mention this in our document:
> All in all it is not entirely clear to the authors how many certified keys may be, but on list numbers as high as 2,000,000 have been mentioned.

Router certificates are used by ASes. So the model proposed by Stephen en Sririam seems reasonable to me:

   # non-stub ASes * avg certs per non-stub AS + # stub ASes * avg certs per stub AS.

Or with values:
   36,120 non-stub AS * 10 + 6,880 stub AS * 2 = 374960.

Open to suggestions..

Tim

-- Back from long holidays..