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

Job Snijders <> Wed, 26 February 2020 02:25 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id DE6643A09CA for <>; Tue, 25 Feb 2020 18:25:40 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.648
X-Spam-Status: No, score=-1.648 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.25, 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 ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id TSVuTkFnVOPY for <>; Tue, 25 Feb 2020 18:25:39 -0800 (PST)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 7D23E3A0972 for <>; Tue, 25 Feb 2020 18:25:39 -0800 (PST)
Received: by with SMTP id p18so1024844wre.9 for <>; Tue, 25 Feb 2020 18:25:38 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to; bh=kS5y3qwsHU/vTQ6DeWCPbNZv+BMFlb8j2JOnfgAB1BA=; b=C5YJeGfpeSRTQKQ2FVlSESPrldi1uX7xzRcUoKHAU62JM33+nkP8o/9rZLl/EE/oLn BFCe0WNHEHSFWiyOjt7lF5rMto0XT86BJ7aGy1k2Ghk3O860RQcdHAa73N6WLp7283xV aDTUi85mm/SznsrSXc4W6DNEbTpcndc2r3ZmhGQ/nNk9rMszVV9v4iuGQCYnFdFB1xNV P+Q9GVv/ldouUgfV96pmkAxngFhnUVjlmYd3zjncxyFcgDgNQ1RRbPvq/ZazgOVqF990 cxcRK5qkiSGeK5Qx6sWmjkyYyDCT1PaDryLt6nKr/NYcB1DxIKvR55GpcPxRkakCVtaH suCA==
X-Gm-Message-State: APjAAAVAY+N6M/3FZ7tL9Nqs3obGu1G5gVzl2v3dJSXRWSJkzvNgNf+0 +9z7RiTgJA05eGIHMfyHQAM4zUi8YpI=
X-Google-Smtp-Source: APXvYqzyyuYlDCwqTwpIVDDEfukdUokrKu24HbwdA1opKU/pSHyHQ0cC1UN00d/U4ViLH221trB0yQ==
X-Received: by 2002:a5d:4b82:: with SMTP id b2mr2310501wrt.102.1582683937271; Tue, 25 Feb 2020 18:25:37 -0800 (PST)
Received: from ( []) by with ESMTPSA id u62sm858244wmu.17.2020. (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 25 Feb 2020 18:25:36 -0800 (PST)
Received: from localhost ( [local]) by (OpenSMTPD) with ESMTPA id 5deeaba0; Wed, 26 Feb 2020 02:25:35 +0000 (UTC)
Date: Wed, 26 Feb 2020 02:25:35 +0000
From: Job Snijders <>
To: Louis Poinsignon <>
Message-ID: <>
References: <> <> <> <> <>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <>
X-Clacks-Overhead: GNU Terry Pratchett
Archived-At: <>
Subject: Re: [Sidrops] what to do when the CRL is hosed?
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: A list for the SIDR Operations WG <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 26 Feb 2020 02:25:41 -0000

Dear Louis, group,

On Tue, Feb 25, 2020 at 06:02:05PM -0800, Louis Poinsignon wrote:
> My opinion on an operational standpoint.
> I don't think I'd like having our routers suddenly reprocessing the million
> routes associated with 78000 ROAs leaving us with an increased surface of
> attack and potential reroutings. 

It differs from BGP implementation to BGP implementation whether a
milion routes in their concept of the RIBs need to be reprocessed, or
only the routes covered by the (now invalid) ROAs / VRP removal. I
believe there are high performant BGP/ROV implementations out there.

> The outage lasted 8 hours as well.  Even with a replayed certificate,
> I don't believe the impact would be as critical. And it would leave
> traces.  If the impact of a mistake is more punitive than a proper
> misuse, it's bad.
> While I believe Job is right on the discrepancy between validators, I agree
> with the point of Martin on the added complexity.

The only punitive effect I observe is towards the CA operators (a small
group, appears not too often to make mistakes), but at the same time
there are continuous benefits going to the relying parties (a large
group, the internet). I see opportunity for a movement to motivate CA
operators to the strictest possible interpretation of how their RPKI CA
& publication process works and how the data distributed will be

> Even though browsers and RPKI are different, I think we can learn from
> the experience. Which is to get away from CRLs.

I agree this is worthwhile exploring.

Kind regards,