Re: [Sidrops] 6486bis: referenced object validation

Hi,

> On 4 Dec 2020, at 11:57, Ties de Kock <tdekock@ripe.net> wrote:
> 
> 
>> On 4 Dec 2020, at 11:51, Job Snijders <job@ntt.net> wrote:
>> 
>> On Fri, Dec 04, 2020 at 11:47:17AM +0100, Ties de Kock wrote:
>>>> On 4 Dec 2020, at 11:40, Job Snijders <job@ntt.net> wrote:
>>>> On Fri, Dec 04, 2020 at 11:16:51AM +0100, Martin Hoffmann wrote:
>>>>> Under this approach, the manifest expresses which objects the CA
>>>>> intended to publish. If all the objects listed on the manifest are
>>>>> present with a matching hash, the publication point reflects the
>>>>> intent of the CA and can be processed. If it contains invalid objects,
>>>>> these can be discarded individually.
>>>> 
>>>> Indeed, I believe you've now captured the essence of why manifests
>>>> exists at all. This is what rpki-client & FORT seem to have implemented.
>>>> 
>>>> Other than the hashes matching & files being present, additional
>>>> conditions apply: the manifest & EE certificate need to be valid,
>>>> current, latest, correctly encoded, part of the cert chain, CRL present,
>>>> etc.
>>> 
>>> However, validating these requirements for just CMS objects (as per
>>> -03, instead of for CAs as well as per -00) leaves open the situation
>>> where only part of the objects for a CA apply. When the ROAs are
>>> correct, but the sub-CA is not, this can cause outages.
>>> 
>>> I don't have a preference on which way to go, but I would propose that
>>> we treat invalidation (time, c.f. because of semantic errors) for both
>>> CA certificates and other objects similarly.
>> 
>> I am not sure I follow, can you construct an example data set where the
>> 'situation left open' you describe appears?
>> 
> 
> Thanks for asking for clarification. I'll try to explain the scenario:
> 
> CA certificate with <AS64496, 192.0.2.0/24>
>   * Manifest, containing
> 	  * ROA: AS0, 192.0.2.0/24
> 	  * sub-CA, resources: <AS64496, 192.0.2.0/24>
> 	  	* Manifest, containing:
> 			  * ROA: <AS64496, 192.0.2.0/24>
> 
> We have "all or nothing" for ROAs. I argue that a similar situation is present
> for sub-CAs if the sub-CA expires.

Indeed there are many such corner cases.

Imho this discussion is complicated because we are conflating object validation and the impact of encountering invalid objects on the resulting VRP set and ultimately routing decisions.

I think it could help to separate these issues. Keep RPKI object tree validation itself simple, but track invalid / rejected objects and discuss how to deal with the VRP set as a separate issue. E.g. we could track all resources that are under some dispute (intersection of what is issued to a CA and issues with objects by the CA) and filter VRPs based on that.

Tim

> 
> Kind regards,
> Ties
> _______________________________________________
> Sidrops mailing list
> Sidrops@ietf.org
> https://www.ietf.org/mailman/listinfo/sidrops