Re: [Sidrops] trying to limit RP processing variability

Martin Hoffmann <martin@opennetlabs.com> Fri, 17 April 2020 08:26 UTC

Return-Path: <martin@opennetlabs.com>
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 6BFE73A108F for <sidrops@ietfa.amsl.com>; Fri, 17 Apr 2020 01:26:10 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.898
X-Spam-Level:
X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_NONE=0.001] autolearn=ham autolearn_force=no
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 69kfo6u78vpS for <sidrops@ietfa.amsl.com>; Fri, 17 Apr 2020 01:26:09 -0700 (PDT)
Received: from dicht.nlnetlabs.nl (dicht.nlnetlabs.nl [185.49.140.10]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0617B3A108B for <sidrops@ietf.org>; Fri, 17 Apr 2020 01:26:08 -0700 (PDT)
Received: from glaurung.nlnetlabs.nl (82-197-214-124.dsl.cambrium.nl [82.197.214.124]) by dicht.nlnetlabs.nl (Postfix) with ESMTPSA id 8EAE31E64D; Fri, 17 Apr 2020 10:26:06 +0200 (CEST)
Authentication-Results: dicht.nlnetlabs.nl; dmarc=none (p=none dis=none) header.from=opennetlabs.com
Authentication-Results: dicht.nlnetlabs.nl; spf=none smtp.mailfrom=martin@opennetlabs.com
Date: Fri, 17 Apr 2020 10:26:06 +0200
From: Martin Hoffmann <martin@opennetlabs.com>
To: George Michaelson <ggm@algebras.org>
Cc: Stephen Kent <stkent=40verizon.net@dmarc.ietf.org>, Job Snijders <job@ntt.net>, "sidrops@ietf.org" <sidrops@ietf.org>, Claudio Jeker <cjeker@diehard.n-r-g.com>
Message-ID: <20200417102606.76583e78@glaurung.nlnetlabs.nl>
In-Reply-To: <CAKr6gn3CHpL_hWuvTh+y5OsPLeS8U8bv46=xEcxDQXdFvvvPog@mail.gmail.com>
References: <a9448e54-320f-300c-d4f9-d01aca2b6ef4.ref@verizon.net> <a9448e54-320f-300c-d4f9-d01aca2b6ef4@verizon.net> <20200415150141.016d021d@glaurung.nlnetlabs.nl> <20200415140012.GB30412@vurt.meerval.net> <20200415161415.29c49f4e@glaurung.nlnetlabs.nl> <20200415143321.GM72650@diehard.n-r-g.com> <9d7a9500-2ff8-e9d2-f3a5-89eeaa4a90e8@verizon.net> <20200416154509.GT72650@diehard.n-r-g.com> <8ffd835c-cd11-5af0-81bf-d8935e0e2190@verizon.net> <CAKr6gn3CHpL_hWuvTh+y5OsPLeS8U8bv46=xEcxDQXdFvvvPog@mail.gmail.com>
Organization: Open Netlabs
X-Mailer: Claws Mail 3.17.5 (GTK+ 2.24.32; x86_64-pc-linux-gnu)
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/sidrops/doFCiwqrW6FiAs6pc_L09zpoDg0>
Subject: Re: [Sidrops] trying to limit RP processing variability
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, 17 Apr 2020 08:26:11 -0000

George Michaelson wrote:
> If a ROA object can be removed and a manifest proves it has been
> removed, and a CRL confirms it has not been revoked, the unknown
> question is:
> 
>  * what was the semantic intent of the ROA?
> 
> If you have a previously acquired state of the ROA which meets the
> manifest checksum/sig and its not in the current CRL *ITS NOT MISSING*
> and you know its semantic intent. All is good. This is what
> maintenance of local cached state of fetching achieves.

A problem with this strategy is that it makes the resulting set of
validated data depend on the point in time a cache did its last
synchronisation. That is, a cache which has seen the ROA before it went
off the manifest will produce a set of VRPs different from one that has
either never synchronised the repository before or due to some sequence
of updates at the publication point had removed the ROA as legitimately
deleted.

The question is: Are we fine with that? I am speaking from a
perspective of someone who has to maintain and in particular test
software and I would rather we had a validation strategy that depended
only and exclusively on the data present after the last synchronisation.

That also motivates my proposal that an object counts as revoked as
soon as it disappears from the manifest.

Kind regards,
Martin