Re: [Sidrops] [WGLC] draft-ietf-sidrops-roa-considerations-01 - Ends 28/November/2022

[YAN Zhiwei <[e-mail]>]

Hello, Tim,
Thank you very much for you comments and please see my in-line responses.
BR,



YAN Zhiwei
 
From: Tim Bruijnzeels
Date: 2022-11-15 04:23
To: Keyur Patel
CC: SIDR Operations WG
Subject: Re: [Sidrops] [WGLC] draft-ietf-sidrops-roa-considerations-01 - Ends 28/November/2022
Dear chairs and authors,
 
> On 13 Nov 2022, at 23:19, Keyur Patel <[e-mail]> wrote:
> 
> Hi Folks:
>  
> A working group last call has been re-issued for draft-ietf-sidrops-roa- considerations-03, “Avoidance for ROA containing Multiple Prefixes”. Please reply to the list with your comments. The WGLC will end on November 28th, 2022.
 
I agree with the idea behind this document. But, I do not think it's ready.
 
I believe that as written assumptions are made that are not true for all RPKI CA implementations. I also believe that the analysis regarding ROA validity times is not relevant to the issue that is being discussed. Furthermore, the tradeoff of space used by many ROAs objects under the same CA - and reducing the risk of over-claims vs reducing that space by aggregating prefixes and accepting the risk of over-claims should be discussed explicitly.
 
Detailed comments below. Comments are intended to help improve, from my perspective at least, the quality of the document and the suggestions. So please bear with me. I know it's long..
 
 
Problem Statement 1/4
=====================
 
The Problem Statement section starts with:
 
   For a Certification Authority (CA) issuing ROAs containing multiple
   IP prefixes, adding or deleting one <AS, IP_Prefix> pair causes the
   (single) ROA for an AS to be withdrawn and reissued.  All IP prefixes
   for an AS share the same validation state and then this may affect
   the stability and security of RPKI.
 
For the above to be an issue the following would need to happen:
1) a large ROA is withdrawn and a new manifest is published with the ROA removed
2) a new ROA is issued and published, together with an updated manifest are published
 
I.e. the operator or their software is using a break-before-remake strategy. It would be good to warn against that specifically.
 
Yan: Yepp, this risk will be warned.

For some RPKI CA implementations this issue may be more likely to happen in case multiple prefixes are combined on a ROA, but for many other implementations this is not the case.
 
Many RPKI CA implementations do not let operators create ROA objects directly. Instead, they ask the user to configure which prefixes should be authorised, and often they will accept a delta of authorisations to be processed as a single update. The RPKI CA will then create/update/withdraw ROA objects as needed, and will publish them as a single multi-element publication (RFC 8181). RPs will accept this delta as a single update, or reject it if they only see a part (see failed fetch in RFC 9286). RPs will exclude duplicates and send a delta of IPv4 or IPv6 PDUs to routers (RFC 8210).

Yan: multi-element publication could guarantee the synchronization of a create/update/withdraw operation set, but sharing fates with unnecessary prefixes during these operations can also induce risks due to mis-operation or mis-configuration.  
[Moreover, how RP works may be also implementation-dependent]

 
In the latter case problems can still occur if operators choose to remove prefix authorisations first, let their CA update an publish ROAs, to only then re-add some of the same prefixes, and let the CA publish those ROAs.
 
So, generically speaking I believe the advice here should be to warn operators and CA implementations against break-before-make update strategies. The correlation with multi/single prefix ROAs is in this context is specific to certain RPKI CA implementations only, and irrelevant to others.

Yan: It's considerate to warn this operation strategy in the draft.
 
Problem Statement 2/4
=====================
 
The second paragraph talks about the risk of over-claiming ROAs. I share the concern and I believe it is the most important reason why single prefix ROAs are preferred.
 
However, I believe the premise of this paragraph to be incorrect. Current text:
 
   By default, ROAs have an extended validity period.  Resource changes
   can happen at any time during this validity period.  A certificate
   change can affect all ROAs using IP prefixes from the issuing
   certificate.  CAs should carefully coordinate ROA updates with
   resource certificate updates.  A CA can automate this process if a
   single entity manages both the parent CA and the CA issuing the ROAs
   (scenario D [[RFC8211] section 3]).  However, in other deployment
   scenarios, this coordination becomes more complex.  Furthermore, for
   the ROA containing multiple IP prefixes, the IP prefixes share the
   same expiry configuration.  If the ROA is not reissued timely, the
   whole set of IP prefixes will be affected after expiry.
 
The problem is not the validity period of the ROA.
 
Yan: The reason to mention "validity period" here is mainly to stress that the resource is likely to change because the ROA has an extended validity period. If the ROA validity period is always shorter than the resource certificate, things may be easier.

The problem is that a CA issuing ROAs may not be aware that resources are no longer validly held in their CA certificate, as published by their parent.
 
This problem can arise in case the parent pro-actively shrinks the CA certificate of the child before the child has found out (by sending an RFC 6492 resource class list query), and before the child has had a chance to clean up its ROAs.
 
This problem can also arise in case the parent issues a new resource to the child, as requested through RFC 6492, and the child then issues a ROA including the new resource *before* the parent has published the new CA certificate and/or *before* RPs have discovered that new CA certificate.
 
Using a single prefix per ROA will make these events less impactful, as only actually over-claiming ROA objects would become invalid.
 
Note though, that this issue can also affect CA certificates in the delegation chain, and in single prefix ROA objects would still ALL be considered invalid if the issuing CA certificate would be considered invalid because of an over-claim.
 
So, while I agree that the single prefix per ROA strategy is better, I believe that talking about the ROA validity time in this context is confusing and irrelevant. Furthermore, this over-claiming issue is not solved completely by this strategy.
 
To avoid this issue more generally we should also look at: a) validation-reconsidered - but I know that there is opposition to this approach, or b) better in-band signalling about resource changes and CA certificate publication - as I mentioned in my talk during the WG session at the IETF last week.
 
Yan: Agree with you, we are also discussing some in-band or out-band schemes to refine the coordination between parent and child nodes, as shown in the following figure. 
[Just mention it, this is another issue to be discussed later if anyone has interest.]
 
Problem Statement 3/4
=====================
 
This third paragraph:
 
   Using multiple ROA objects with single IP prefix also allows a CA
   to affect routing over time based on certificate expiry.  For
   example, a prefix could be allowed to be originated from an AS only
   for a specific period of time, such as some IP prefix was leased out
   temporarily.
 
This is not actually a problem, but an RPKI CA implementation specific advice on how ROA object validity times can be used to achieve a specific goal.
 
I am not -at all- against the of this strategy in those CAs, but other implementations that want to achieve similar behaviour could achieve this in other ways. E.g. by setting an end time for a configured authorization and updating ROAs and CRLs accordingly when that time comes.
 
Yan: Although this is mainly the implementation-dependent issue, it's better to mention it to avoid the related risk. 
 
Problem Statement 4/4
=====================
 
What I miss in the problem statement is a mention of the trade-off that exists between a) reducing the risk of over-claiming ROAs and accepting that there may be many objects amounting to significant overhead in size (roughly amounting to a EE cert per prefix) versus b) aggregating prefixes to reduce the amount of objects and size, and accepting the risk of over-claims.
 
In some contexts the risk of over-claims is next to 0%, e.g. the AS0 ROA used by at least one RIR. But even in other contexts there may be something to be said for reducing space.
 
I understand that it would be hard to quantify this. The text under suggestion #2 alludes to it. But it's not specific enough for my taste.
 
To be very specific. In my CA implementation I currently have a default threshold of 100 prefixes - after which the system will start aggregating prefixes per ROA in order to save space. This number is user configurable.
 
I am looking at this draft for advice on whether that number is in the right ball-park, or that it should be higher, or even that the default should be to *never* aggregate *regardless* of the space that will use unless the operator explicitly sets an aggregation threshold.
 
And, yes, I would be perfectly fine with the latter outcome - but the suggestion should be more explicit and the argumentation leading up to it more nuanced.
 
Yan: This is a problem we discussed a lot. It’s difficult to give the specific number, because of the complexity of different scenarios and situations (based on management, business requirements and implementation strategies), though it's a great idea. Then give a "threshold" will be rude and rigid. Thus in the current version(03), we give the following suggestion: 2) In some special scenarios, where the resource is very stable or a CA has operational problems producing increased number of individual ROAs, multiple IP prefixes may be aggregated in one ROA. This may include the case of ROA0. 

Appendix A
==========
 
There is no reference to this appendix in the document. And the numbers listed here may actually not be that relevant to the discussion in this document simply because many, if not all, ROAs with multiple prefixes fall into the suggestion #2 category.
 
If there would be an analysis that could flag the number of occasions where a single prefix really should have been used, but wasn't, then it would serve better to illustrate the scope of the problem this document is trying to address.
 
As it is I think it could be omitted in the final document.
 
Yan: During the initial phase, we use this appendix to illustrate that aggregation of IP prefixes in one ROA is very common and the ROA validity period is always very long. This is used to support the problem analysis, we think this appendix will be omitted in the final document as you said. 

Kind regards,
 
Tim
 
 
 
 
 
>  
> The draft can be found at: https://datatracker.ietf.org/doc/draft-ietf-sidrops-roa-considerations/. Authors, please reply indicating whether you're aware of any relevant IPR that hasn't been disclosed.
>  
> Regards,
> Nathalie, Chris & Keyur
>  
>  
> _______________________________________________
> Sidrops mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/sidrops