Re: [Sidrops] trying to limit RP processing variability

Job Snijders <job@ntt.net> Wed, 08 April 2020 00:35 UTC

Return-Path: <job@instituut.net>
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 A497B3A0FCD for <sidrops@ietfa.amsl.com>; Tue, 7 Apr 2020 17:35:27 -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, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, UNPARSEABLE_RELAY=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 A-bgqAbSd206 for <sidrops@ietfa.amsl.com>; Tue, 7 Apr 2020 17:35:26 -0700 (PDT)
Received: from mail-wm1-f41.google.com (mail-wm1-f41.google.com [209.85.128.41]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 41AAA3A0FC7 for <sidrops@ietf.org>; Tue, 7 Apr 2020 17:35:25 -0700 (PDT)
Received: by mail-wm1-f41.google.com with SMTP id a81so3662225wmf.5 for <sidrops@ietf.org>; Tue, 07 Apr 2020 17:35:25 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:content-transfer-encoding :in-reply-to; bh=qJiKqd1GmYMTMKTc8maGCm6e7NJE8H9hOnH/yQir0EU=; b=o55gyVDN49zJ1VnpoihVJ18uxFLtz3aSPjRHHAc7bt5I9ivhYq9oXjRVLcbO/11/r1 8qbkdT1ArfH4kYjYUA+crLlCPOUaM+cdSJjIPKPpm7mur/skSsVUQGvf7+nnaBs1sudA 7IFecf2BTVzFqSgN+ioSNLLwFyT2ZF6QhYShPRgM7nAsK9yPVkAAt8qdI1+naptxg9ZM 22ZsedbOzCs62GEL2y7qAfMumM1i86kyLa4IgCnMBOAPDgiQzJoaXNC3l/Jd2watWHYQ AqGFc4sYFAd1guUiUS8OQleM86TplG83TEh2wn0/LsDgJJEjA53faWUdwJypLRR4HZYQ DfjA==
X-Gm-Message-State: AGi0PuZL+Kad4dQ8OJiMxKeanFHCKcKwbLxuVCkralH5cMrbWtKimi/v wMC4SUR2ENnHa3vnMmXx3egm9CWPdPc=
X-Google-Smtp-Source: APiQypK5MmqXCw36dF8im0F16L1tyDRjTGmzg5h1qhGizA5VTXA3+GpiH1PqeOa7diy8rrSQ0GshKw==
X-Received: by 2002:a1c:ed18:: with SMTP id l24mr1810265wmh.122.1586306123760; Tue, 07 Apr 2020 17:35:23 -0700 (PDT)
Received: from vurt.meerval.net (vurt.meerval.net. [192.147.168.22]) by smtp.gmail.com with ESMTPSA id b5sm21674598wrs.16.2020.04.07.17.35.22 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 07 Apr 2020 17:35:22 -0700 (PDT)
Received: from localhost (vurt.meerval.net [local]) by vurt.meerval.net (OpenSMTPD) with ESMTPA id cd0521a4; Wed, 8 Apr 2020 00:35:21 +0000 (UTC)
Date: Wed, 8 Apr 2020 00:35:21 +0000
From: Job Snijders <job@ntt.net>
To: Stephen Kent <stkent=40verizon.net@dmarc.ietf.org>
Cc: "sidrops@ietf.org" <sidrops@ietf.org>
Message-ID: <20200408003521.GV68514@vurt.meerval.net>
References: <a9448e54-320f-300c-d4f9-d01aca2b6ef4.ref@verizon.net> <a9448e54-320f-300c-d4f9-d01aca2b6ef4@verizon.net>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <a9448e54-320f-300c-d4f9-d01aca2b6ef4@verizon.net>
X-Clacks-Overhead: GNU Terry Pratchett
Archived-At: <https://mailarchive.ietf.org/arch/msg/sidrops/9oQDVUTdhTgBwVHl860B5YvI2_E>
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, 08 Apr 2020 00:35:28 -0000

Hi,

On Fri, Apr 03, 2020 at 11:40:10AM -0400, Stephen Kent wrote:
> *Terminology*
> 
> Valid: a signed object (other than a certificate or CRL) is deemed
> *valid* if it is encoded in a fashion consistent with the relevant
> RPKI RFCs (i.e., 6482, 6486, 6487, 6488, 6493) and the signed object’s
> signature can be verified consistent with RFC 6488.
> 
> Current: A CRL or Manifest is *current* if the current date & time is
> before the Next Update date and the CRLNumber (or ManifestNumber) is
> greater than any prior, valid CRLs or Manifests processed by the RP.
> 
> Stale: A CRL or Manifest is stale if the current date & time is later
> than the Next Update date. A stale CRL or Manifest is not “expired”
> it’s just not as current as it is supposed to be. The case analysis
> below examines what to do when a Manifest, or CRL, or both are stale.
> 
> Missing: an object named in a Manifest, but not available for download
> from a PP, is termed *missing*. An RP has no obvious way to acquire
> missing objects, but operators SHOULD be warned about which objects
> are missing.
> 
> Corrupted: if an object named in a Manifest, is available for download
> from a PP, but it’s hash does not match the corresponding value in the
> Manifest, the object is termed *corrupted* and the object SHOULD be
> ignored.
> 
> *Case analysis*
> 
> If we can agree to ignore any objects at a PP that do not appear on
> the current manifest, the case analysis is easier. (The discussion of
> corrupted objects above addresses the case where an object is named on
> the Manifest, but the hash does not match.)
> 
> Below is a proposed outline for the cases. The group needs to decide
> what action is to be taken in each case.
> 
> 
> 1.Manifest present, valid, current
> 1.1.CRL present, valid, current

pass. all lights are green.

> [ snip lots of variants ]

All cases we can come up with (except the 'all green') probably require
some mailinglist back and forth as to why it is that we can safely
ignore one or another validation check. If nobody steps up to advocate a
particular case, perhaps we don't need it.

My suggestion to the group is that we go through Kent's list and start
with a justification for the simplest of cases (as described above), and
then construct justifications for any other variants, if they exist.

I imagine some of the cases have already been discussed in years prior,
but RPKI OV deployment on the Internet at scale is still fairly new,
taking a fresh look at things is exciting :)

Kind regards,

Job