Re: [Sidrops] AD Review: draft-ietf-sidrops-roa-considerations

[Tim Bruijnzeels <[e-mail]>]

Hi,

> On 7 Feb 2023, at 19:15, Job Snijders <job=[e-mail]> wrote:
> 
> On Mon, Feb 06, 2023 at 01:37:31PM -0800, Warren Kumari wrote:
>> I could not easily find a statistic showing the total number of
>> prefixes and total number of ROAs. I did start trying to write a
>> script to calculate this, but got distracted / ran out of time.
>> WG / authors: does anyone have this info handy?
> 
>     TA      ROAs      Pfxs   Unique Pfxs   UPfxs/ROAs   Avg ROA (bytes)
> --------+---------+---------+-------------+------------+----------------
> AFRINIC |   3,020 |   4,341 |       4,210 |      1.394 |     1937
>   ARIN |  60,077 |  73,851 |      69,841 |      1.162 |     2132   
>  APNIC |  23,288 | 104,337 |     104,035 |      4.467 |     1914
> LACNIC |  17,564 |  33,878 |      31,284 |      1.781 |     1969
>   RIPE |  36,365 | 189,446 |     189,444 |      5.210 |     1867
> --------+---------+---------+-------------+------------+----------------
> GLOBAL | 140,313 | 405,857 |     398,818 |      2.842 |     2003
>                         (as of 2023-02-07)
> 
>   [ There seems to be an incredibly strong association between
>     the letter 'P' being present in the Trust Anchor name and
>     the number of ROAIPAddress instances per ROA. ;-) ]
> 
> The size of a ROA (in bytes) seems to mostly be a function of the length
> of the Information Access instances (SIA, AIA, CRL), rather than the
> space the (binary encoded) ROAIPAddress instances occupy in a ROA.
> 
> If everyone would follow the '1 prefix per ROA' rule, the current RPKI
> would roughly triple in size; if all prefixes in DFZ are covered by a
> ROA, it would roughly double again. Doesn't seem too bad to me?

What I like about the draft is that it is permissive - CAs can still
decide to combine prefixes. What I don't like is that to me the
considerations for combining prefixes are vaguely phrased and incomplete.

So, while I still agree with the general advice to use a 1 prefix per
ROA, I think the considerations for not doing so are not worked out in
enough detail. I think this is unfortunate, because I would like this
document to be more useful to resolve discussions about this choice.

As it stands I am afraid that this document will not serve to resolve
discussions about this, but may even turn out to be divisive. Let me
illustrate two cases:


Case A: RIRs with co-hosted member CAs

I believe that the paragraph starting with "In some special scenarios,"
in section 4 does not call out a case that I believe I and others have
raised a number of times wrt the RIR systems with co-hosted parent and
child CAs.

The fate sharing issue is not an issue for e.g. the RIPE NCC system.

The parent CA and child CA are hosted in the same system. This is different
from the RFC 6492 child -> parent polling process used by remote CAs, in
that in this *co-hosted* system the child CAs can be instructed to shrink
their ROAs before the parent CA reduces resources. I know that this is
how the RIPE NCC was coded years ago, because at the time I was involved.

Insisting that the RIPE NCC changes their implementation to use one ROA
per prefix will lead to a big increase in their repository size, but it
will do nothing of value with regards to the fate-sharing problem raised
here. Remember that these CAs also share the same repository, so the parent
(re-issued certificate) and child (re-issued ROAs) will be seen at the
same time at worst - or the child ROA shrink will be seen before the
certificate shrink.


Case B: ROA prefix threshold

Another point: the consideration section does say this: "or a CA has
operational problems producing increased number of individual ROAs".
I mentioned that this is not really an issue for my CA implementation,
but this can cause an issue for RP software. The reason why I implemented
the option to combine prefixes in the first place, was to prevent 14000
individual ROAs to be created for an AS0 ROA as issued by APNIC.

It seems that at some point, but which point is unclear, there is a
tradeoff between fate-sharing and space used.

Currently my software uses a default threshold of 100 configured ROA
prefixes before deciding to start combining them in order to save resources
for RPs. This number is configurable, but people will use defaults..

I have asked this working group for guidance on this default [1]. I am
perfectly happy to increase the default, or even to make it a complete
opt-in setting: i.e. never aggregate prefixes on a single ROA unless
this is explicitly enabled by the operator. But, I got no response to
this particular question.

While I understand that draft-ietf-sidrops-roa-considerations may not
wish to call out any explicit "magic" threshold value, I also get no
closer to an answer to my question about what default behaviour would
be preferred after reading this document.



Kind regards,
Tim






[1]: https://mailarchive.ietf.org/arch/msg/sidrops/iBWgNEN9d03tGdTABYofuZKjwK4/

> 
> Kind regards,
> 
> Job
> 
> _______________________________________________
> Sidrops mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/sidrops