Re: [Sidrops] trying to limit RP processing variability

Claudio Jeker <cjeker@diehard.n-r-g.com> Thu, 16 April 2020 15:45 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 12ADF3A0CB3 for <sidrops@ietfa.amsl.com>; Thu, 16 Apr 2020 08:45:15 -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=unavailable 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 qv2W0Uni20gz for <sidrops@ietfa.amsl.com>; Thu, 16 Apr 2020 08:45:12 -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 2885F3A0CA7 for <sidrops@ietf.org>; Thu, 16 Apr 2020 08:45:11 -0700 (PDT)
Received: (qmail 85511 invoked by uid 1000); 16 Apr 2020 15:45:09 -0000
Date: Thu, 16 Apr 2020 17:45:09 +0200
From: Claudio Jeker <cjeker@diehard.n-r-g.com>
To: Stephen Kent <stkent=40verizon.net@dmarc.ietf.org>
Cc: Martin Hoffmann <martin@opennetlabs.com>, "sidrops@ietf.org" <sidrops@ietf.org>, Job Snijders <job@ntt.net>
Message-ID: <20200416154509.GT72650@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> <20200415143321.GM72650@diehard.n-r-g.com> <9d7a9500-2ff8-e9d2-f3a5-89eeaa4a90e8@verizon.net>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <9d7a9500-2ff8-e9d2-f3a5-89eeaa4a90e8@verizon.net>
User-Agent: Mutt/1.10.1 (2018-07-13)
Archived-At: <https://mailarchive.ietf.org/arch/msg/sidrops/fknYBboh6f0e2a25gaUpnDuHOLQ>
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: Thu, 16 Apr 2020 15:45:15 -0000

On Thu, Apr 16, 2020 at 10:54:34AM -0400, Stephen Kent wrote:
> Claudio,
> > ...
> > > 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).
> 
> See my earlier comment that I believe there really is not a chicken and egg
> problem here re CRLs. I don't see any indication in 6486 that the CRLDP in
> an EE cert for a manifest is different from that of the EE certs appearing
> in ROAs.

My point was that the CRL referenced by the MFT is part of the MFT
FileAndHash list and is therefor not yet verified and loaded. So either
one must verify the EE cert of the MFT without checking the CRL or one
must load a not yet verified CRL file to be able to do proper full EE cert
verification. This is the chicken and egg situation I was referring to.
 
> > 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.
> 
> Could you elaborate on this last comment?

I think Job Snijders showed this very well with his examples where removal
of one roa file would result in the insertion of an AS 0 VRP covering a
large part of Germany's IP space unless all of the manifest data is
ignored.

-- 
:wq Claudio