Re: [Sidrops] trying to limit RP processing variability

Jay Borkenhagen <jayb@braeburn.org> Wed, 15 April 2020 15:50 UTC

Return-Path: <jayb@oz.mt.att.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 E093F3A0B1C for <sidrops@ietfa.amsl.com>; Wed, 15 Apr 2020 08:50:26 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.65
X-Spam-Level:
X-Spam-Status: No, score=-1.65 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.248, SPF_HELO_NONE=0.001, SPF_NONE=0.001] autolearn=no 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 oTO_4dLRx_3K for <sidrops@ietfa.amsl.com>; Wed, 15 Apr 2020 08:50:25 -0700 (PDT)
Received: from hrabosky.cbbtier3.att.net (braeburn.org [12.0.1.25]) by ietfa.amsl.com (Postfix) with ESMTP id F15D43A0CFF for <sidrops@ietf.org>; Wed, 15 Apr 2020 08:49:57 -0700 (PDT)
Received: from oz.mt.att.com (zoe.cbbtier3.att.net [12.0.1.45]) by hrabosky.cbbtier3.att.net (Postfix) with ESMTP id 8E9FC31843 for <sidrops@ietf.org>; Wed, 15 Apr 2020 15:49:56 +0000 (UTC)
Received: by oz.mt.att.com (Postfix, from userid 1000) id 67A14A408AC; Wed, 15 Apr 2020 11:49:56 -0400 (EDT)
X-Mailer: emacs 24.3.1 (via feedmail 11-beta-1 I); VM 8.2.0b under 24.3.1 (x86_64-pc-linux-gnu)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID: <24215.11555.329412.270610@oz.mt.att.com>
Date: Wed, 15 Apr 2020 11:49:55 -0400
From: Jay Borkenhagen <jayb@braeburn.org>
To: sidrops@ietf.org
In-Reply-To: <974eeeaa-32e6-45b2-860f-6b1408ae14e6@www.fastmail.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> <a1c7b748-6dda-c555-0ab7-3727d34bc672@verizon.net> <20200415124611.7af291b1@glaurung.nlnetlabs.nl> <974eeeaa-32e6-45b2-860f-6b1408ae14e6@www.fastmail.com>
Reply-To: Jay Borkenhagen <jayb@braeburn.org>
X-GPG-Fingerprint: DDDB 542E D988 94D0 82D3 D198 7DED 6648 2308 D3C0
Archived-At: <https://mailarchive.ietf.org/arch/msg/sidrops/ZPq3kxqT0E8PCK_5LYJ-9lYtwRk>
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: Wed, 15 Apr 2020 15:50:27 -0000

Job Snijders writes:
 > On Wed, Apr 15, 2020, at 12:46, Martin Hoffmann wrote:
 > > An attacker who can delete files can as easily replace them with
 > > something else with the same result. So I am not sure the added code
 > > complexity is worth it.
 > 
 > Agreed. 
 > 
 > fwiw: rpki-client runs as "openrsync -rlt --delete rsync://xxx/repository xxx/repository"
 > 

I agree with this behavior as well.

Further, it leads me to make a new straw man proposal for our
pre-Interim/Virtual meeting discussion.

Earlier in a related thread I wrote "[...] in the context of the RPKI,
we need to reach a point where all RFC-compliant RPs will generate
identical sets of VRPs when presented with the same input."  That
statement did not generate any pushback (but feel free to disagree now
if you want). 

Now I would like to push to see if we can take it further.  Please
bash this proposed goal:

 Each validation run of each RFC-compliant RP will generate the same
 set of VRPs when presented with identical input, using unexpired
 records from previous retrievals to deal with only complete failure
 to retrieve from a PP.

This implies that the "cache" aspects of an RP serve two purposes: 

 (1) reducing the amount of data to be downloaded on subsequent runs

and:

 (2) addressing the case of a PP that is temporarily completely
 unreachable, for only as long as those retrieved records have not
 expired. 

In other words, RPs should assume an empty cache, except in the case
where a previously-reached PP is now temporarily completely
unreachable. 

Commence bashing. :)

						Jay B.