Re: [Sidrops] trying to limit RP processing variability

Claudio Jeker <cjeker@diehard.n-r-g.com> Wed, 15 April 2020 14:33 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 86BA03A091C for <sidrops@ietfa.amsl.com>; Wed, 15 Apr 2020 07:33:25 -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 Y-1SXZ329U3j for <sidrops@ietfa.amsl.com>; Wed, 15 Apr 2020 07:33:24 -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 545633A08EB for <sidrops@ietf.org>; Wed, 15 Apr 2020 07:33:23 -0700 (PDT)
Received: (qmail 86396 invoked by uid 1000); 15 Apr 2020 14:33:21 -0000
Date: Wed, 15 Apr 2020 16:33:21 +0200
From: Claudio Jeker <cjeker@diehard.n-r-g.com>
To: Martin Hoffmann <martin@opennetlabs.com>
Cc: Job Snijders <job@ntt.net>, Stephen Kent <stkent=40verizon.net@dmarc.ietf.org>, "sidrops@ietf.org" <sidrops@ietf.org>
Message-ID: <20200415143321.GM72650@diehard.n-r-g.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>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <20200415161415.29c49f4e@glaurung.nlnetlabs.nl>
User-Agent: Mutt/1.10.1 (2018-07-13)
Archived-At: <https://mailarchive.ietf.org/arch/msg/sidrops/EOzHRrlz6Hq0QbbaoM4X9rG36xA>
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 14:33:26 -0000

On Wed, Apr 15, 2020 at 04:14:15PM +0200, Martin Hoffmann wrote:
> Job Snijders wrote:
> > On Wed, Apr 15, 2020 at 03:01:41PM +0200, Martin Hoffmann wrote:
> > >
> > > > 1.Manifest present, valid, current  
> > > 
> > > If there is a present, valid, and current manifest, the CRL can
> > > safely be ignored for all objects.  
> > 
> > I'd like to ask you for some clarification, Stephen Kent listed 4
> > different cases, I parapharsed here:
> > 
> > 1.1. Manifest present, valid, current AND CRL present, valid, current
> > 1.2. Manifest present, valid, current AND CRL present, stale
> > 1.3. Manifest present, valid, current AND CRL present, invalid
> > 1.4. Manifest present, valid, current AND CRL missing
> > 
> > When you say "can safely be ignored", do you mean, MAY be ignored,
> > SHOULD be ignored? or MUST be ignored? In all four cases?
> 
> In all cases. Since it is ignored, it doesn’t really matter whether it
> is good or bad or ugly. 
> 
> I suppose I would go with "SHOULD be ignored" here.

Which CRL are we talking about? The ones listed in the manifest or the one
referenced by the manifest certificate?
I agree that the CRL for manifests is ignored mainly because of the chicken
and egg situation (the manifest holds the CRL fileAndHash which is uses by
the manifest itself).

For CRL listed in manifests I think the situation is different. If a CRL,
ROA or CERT in a manifest is missing then the manifest must be considered
invalid and everything under it ignored. This is so that missing ROA would
not suddenly result in RPKI invalid routes because only part of a set was
processed.
 
> > > In order to avoid using partial sets of information, the entire
> > > content of the PP is ignored if any object is missing, corrupted, or
> > > invalid.  
> > 
> > It appears we are inching towards consensus on avoiding to use partial
> > sets, I think that's good news.
> 
> Keep in mind that there is still a possibility that partial sets are
> created if a resource is delegated to two separate entities and one of
> them goes kaputt. I have no idea how likely that is in practice. This
> rule should, however, cover the rather more likely case of partial sets
> because of partial breakage of a single publication point.

-- 
:wq Claudio