Re: [Sidrops] trying to limit RP processing variability

Claudio Jeker <cjeker@diehard.n-r-g.com> Tue, 14 April 2020 09:18 UTC

Return-Path: <cjeker@diehard.n-r-g.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 BFBD83A089D for <sidrops@ietfa.amsl.com>; Tue, 14 Apr 2020 02:18:22 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.918
X-Spam-Level:
X-Spam-Status: No, score=-1.918 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, 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 A1bIYe32-eLY for <sidrops@ietfa.amsl.com>; Tue, 14 Apr 2020 02:18:21 -0700 (PDT)
Received: from diehard.n-r-g.com (diehard.n-r-g.com [62.48.3.9]) (using TLSv1.2 with cipher ECDHE-RSA-CHACHA20-POLY1305 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CAD7A3A0899 for <sidrops@ietf.org>; Tue, 14 Apr 2020 02:18:20 -0700 (PDT)
Received: (qmail 3174 invoked by uid 1000); 14 Apr 2020 09:18:18 -0000
Date: Tue, 14 Apr 2020 11:18:18 +0200
From: Claudio Jeker <cjeker@diehard.n-r-g.com>
To: Robert Kisteleki <robert@ripe.net>
Cc: Stephen Kent <stkent=40verizon.net@dmarc.ietf.org>, "sidrops@ietf.org" <sidrops@ietf.org>
Message-ID: <20200414091818.GF72650@diehard.n-r-g.com>
References: <a9448e54-320f-300c-d4f9-d01aca2b6ef4.ref@verizon.net> <a9448e54-320f-300c-d4f9-d01aca2b6ef4@verizon.net> <63c18696-fe3b-c66f-d8ae-fb132f78ee9f@ripe.net> <a0067385-adb8-cadd-3a7f-3a362176d265@verizon.net> <e3bcba98-c664-0c27-850f-137251cc314a@ripe.net>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <e3bcba98-c664-0c27-850f-137251cc314a@ripe.net>
User-Agent: Mutt/1.10.1 (2018-07-13)
Archived-At: <https://mailarchive.ietf.org/arch/msg/sidrops/VoZDvPjEYeYBODtIl4p3t56UasQ>
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: Tue, 14 Apr 2020 09:18:23 -0000

On Tue, Apr 14, 2020 at 10:54:23AM +0200, Robert Kisteleki wrote:
> Hi Steve,
> 
> >> If, at the previous run, the RP fetched the relevant (now missing
> >> object, then I see no reason to not use it again. Think of the previous
> >> run as an object a cache if you will: if you're looking for an object
> >> mentioned in the manifest, and you have it already (hash / name / etc.
> >> matches) then you can reuse it.
> > I probably should have said that an RP views an object as "missing" if
> > the the object is not present in the RP's cache and cannot be retrieved
> > from the relevant PP. Because RPs retrieve objects only if the objects
> > have changed (newly added or updated), an RP would not be aware that an
> > object is not present at a PP if the object is present in the RP's
> > cache. I recall a famous quote about whether an object that has not been
> > updated makes any noise when it is deleted from a PP, or something like
> > that :-)
> 
> rsync has a flag (--delete) where it literally syncs, ie. not only
> fetches new/updated objects but also removes the local ones that no
> longer exist remotely. (Either this, or some other processes have to do
> cleanup, otherwise the local copy accumulates objects eternally.)
> 
> I believe the NLnetLabs routinator and the NCC's RPKI validator use
> --delete with rsync. Maybe this behaviour changes if/when not using
> rsync, I'm not sure.
> 
> >> Of course it can be useful to check if it still exists in the PP, but it
> >> seems to me the only benefit is to detect that it is missing from there
> >> and perhaps warn the PP operator. Otherwise the RP has a hard time
> >> arguing "no idea what this is since it's not there!".
> > I think I agree about the utility of detecting an object that has gone
> > missing from a PP, when the RP has the object locally cached. But, in my
> > experience, RP software was not designed to detect this case.
> 
> I believe the discussion here is about specifying how RP software should
> (or must) behave, so that their behaviour is consistent. IMO in order to
> achieve that, the behaviour around missing objects should be part of the
> specification.

This should not only be about RP software but also the RPKI CA software
and the operation of such software and repositories.
If the CA software publishes only consistent repos the problem would be
solved. Also the operators of rpki repositories should check their repos
before publishing them as part of monitoring.

If the CA software is sloppy then the RP software will always have a hard
time to get consitent behaviour. It is the typical garbage in garbage out
issue.

-- 
:wq Claudio