Re: [Sidrops] 6486bis: referenced object validation

Tim Bruijnzeels <tim@nlnetlabs.nl> Fri, 04 December 2020 11:06 UTC

Return-Path: <tim@nlnetlabs.nl>
X-Original-To: sidrops@ietfa.amsl.com
Delivered-To: sidrops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CE5E53A09C3 for <sidrops@ietfa.amsl.com>; Fri, 4 Dec 2020 03:06:49 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.1
X-Spam-Level:
X-Spam-Status: No, score=-2.1 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=nlnetlabs.nl
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cc_oG24Jyqnk for <sidrops@ietfa.amsl.com>; Fri, 4 Dec 2020 03:06:48 -0800 (PST)
Received: from outbound.soverin.net (outbound.soverin.net [116.202.65.215]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D18E03A09C4 for <sidrops@ietf.org>; Fri, 4 Dec 2020 03:06:47 -0800 (PST)
Received: from smtp.soverin.net (unknown [10.10.3.28]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) (No client certificate requested) by outbound.soverin.net (Postfix) with ESMTPS id 86FDE60294; Fri, 4 Dec 2020 11:06:45 +0000 (UTC)
Received: from smtp.soverin.net (smtp.soverin.net [159.69.232.142]) by soverin.net
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nlnetlabs.nl; s=soverin; t=1607080004; bh=paHluVr/ZYRbKLVJcUCUB7xmBluKMGrzC+oihk3Vd2E=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From; b=WxV7uoG7fFIyc9WLZ5STyWD9MWIqbcUyEqaiBC0YMJjPzXT82qFzF2aDMaIWD+6Pi X2MP57IMD7vMDQjlSnJGYt9DPZk8ZV+lLqFMDrp78fpOg6Q540zIox4wHxF6u1AU6/ jm28zLYrgP6zci5xwjA3TrPQex0OLEE+8VWtHfs7aPkoShydsikQEdUTrp6NoAcdWP zKACpoitSdna1/yqW3PLos3ThEP52OxcJDdwHqwYcv2CPltxgur3vIz5pk7NDyI1Xi /T6xhRZrbLFBamM1TNyoUvDbsVFefLI0tao3ugYJIWa/+1N7FTNc5F0ZFPuSlOMWti 4mduQk0E2v75Q==
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.4\))
From: Tim Bruijnzeels <tim@nlnetlabs.nl>
In-Reply-To: <78C30B6C-820E-49E9-BE88-6137A26F38E2@ripe.net>
Date: Fri, 4 Dec 2020 12:06:40 +0100
Cc: Job Snijders <job@ntt.net>, SIDR Operations WG <sidrops@ietf.org>, Martin Hoffmann <martin@opennetlabs.com>, Ben Maddison <benm=40workonline.africa@dmarc.ietf.org>
Content-Transfer-Encoding: quoted-printable
Message-Id: <35CF44B7-5C04-460F-9E67-03F6E659A093@nlnetlabs.nl>
References: <20201203224213.gnb2nawujxm7a32q@benm-laptop> <20201204111651.4e865d7d@glaurung.nlnetlabs.nl> <X8oSBlR1pDhX83nH@bench.sobornost.net> <EF03D4E0-83EE-4C70-8E81-002DC8C38B95@ripe.net> <X8oUr+zsCbHk0Q3a@bench.sobornost.net> <78C30B6C-820E-49E9-BE88-6137A26F38E2@ripe.net>
To: Ties de Kock <tdekock@ripe.net>
Archived-At: <https://mailarchive.ietf.org/arch/msg/sidrops/NBgbdkMbyAG7X4eEOhgnih3vx5U>
Subject: Re: [Sidrops] 6486bis: referenced object validation
X-BeenThere: sidrops@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: A list for the SIDR Operations WG <sidrops.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/sidrops>, <mailto:sidrops-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/sidrops/>
List-Post: <mailto:sidrops@ietf.org>
List-Help: <mailto:sidrops-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/sidrops>, <mailto:sidrops-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 04 Dec 2020 11:06:50 -0000

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