Re: [Sidrops] what to do when the CRL is hosed?

Martin Hoffmann <martin@opennetlabs.com> Fri, 03 April 2020 08:32 UTC

Return-Path: <martin@opennetlabs.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 853203A0CFA for <sidrops@ietfa.amsl.com>; Fri, 3 Apr 2020 01:32:57 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.898
X-Spam-Level:
X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 yfbPp1_ulppR for <sidrops@ietfa.amsl.com>; Fri, 3 Apr 2020 01:32:56 -0700 (PDT)
Received: from dicht.nlnetlabs.nl (dicht.nlnetlabs.nl [IPv6:2a04:b900::1:0:0:10]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1954A3A0C95 for <sidrops@ietf.org>; Fri, 3 Apr 2020 01:32:55 -0700 (PDT)
Received: from glaurung.nlnetlabs.nl (82-197-214-124.dsl.cambrium.nl [82.197.214.124]) by dicht.nlnetlabs.nl (Postfix) with ESMTPSA id 6E8FE31412; Fri, 3 Apr 2020 10:32:53 +0200 (CEST)
Authentication-Results: dicht.nlnetlabs.nl; dmarc=none (p=none dis=none) header.from=opennetlabs.com
Authentication-Results: dicht.nlnetlabs.nl; spf=none smtp.mailfrom=martin@opennetlabs.com
Date: Fri, 03 Apr 2020 10:32:53 +0200
From: Martin Hoffmann <martin@opennetlabs.com>
To: Robert Kisteleki <robert@ripe.net>
Cc: Tim Bruijnzeels <tim@nlnetlabs.nl>, sidrops@ietf.org
Message-ID: <20200403103253.23ec1020@glaurung.nlnetlabs.nl>
In-Reply-To: <b029ffa1-903d-46c7-d37d-a6a8330c1bd4@ripe.net>
References: <20200224151532.GD19221@vurt.meerval.net> <20200224211531.GB60925@vurt.meerval.net> <20200225090338.10464b1a@glaurung.nlnetlabs.nl> <9cc3a6a5-f9c8-23df-588e-48dee5db62d4@verizon.net> <3B7006DE-5366-47E7-9CD6-AF392F9ED0CC@nlnetlabs.nl> <6602d1a7-ecbf-73a0-21d8-1254fb2aff97@verizon.net> <20200226173935.GE72144@vurt.meerval.net> <2db8d19a-6f91-d2fc-36c3-65742ba77e6c@ripe.net> <8B09B96B-432C-4190-9DE0-DC2004AAFCC2@nlnetlabs.nl> <CC64461D-4F34-4367-AD9D-D42B2A476363@ripe.net> <75140927-0b8b-07ab-ad2e-952e32256df1@verizon.net> <24198.20355.168888.506246@oz.mt.att.com> <CACC_My-g7bU7FYHiy+3j=HfXBp4+ZEWA96aGOaptROtLg8CSUg@mail.gmail.com> <m2mu7to1jk.wl-randy@psg.com> <CACC_My9PwS7fSZD-50zCW8q2BtDMGbJA38SYfq+Efqzez_GMzQ@mail.gmail.com> <D3880B4C-BFAA-4113-A00F-86B241362B91@nlnetlabs.nl> <b029ffa1-903d-46c7-d37d-a6a8330c1bd4@ripe.net>
Organization: Open Netlabs
X-Mailer: Claws Mail 3.17.5 (GTK+ 2.24.32; x86_64-pc-linux-gnu)
MIME-Version: 1.0
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: <https://mailarchive.ietf.org/arch/msg/sidrops/WyB8G3165cm8YqG2RWGCr_Xe7VU>
Subject: Re: [Sidrops] what to do when the CRL is hosed?
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: Fri, 03 Apr 2020 08:32:58 -0000

Robert Kisteleki wrote:
> > However, this discussion is somewhat orthogonal to what RPs should
> > do in case they find issues with a MFT, CRL, or know that there are
> > objects that are missing. These problems exist regardless of the
> > transport.  
> I agree. Job pointed out a behavioural example from a tool, and we
> have evidence that the RP tools behave differently under different
> conditions. If, as Lukas wrote: "[I expect] all RP's to produce the
> same VRP sets, given the same input" is a desired goal, then we
> likely need a document specifying said behaviour.

Ideally, these would be a 6486-bis and 6487-bis with more detailed
instructions on validation. There’s already quite a number of
documents and it isn’t always clear which ones are important. I’d
prefer to have this in the document an implementer will definitely read.

I’ll be happy to help working on these bises.

Kind regards,
Martin