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

Job Snijders <> Tue, 24 March 2020 16:09 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 4A8D33A0C92 for <>; Tue, 24 Mar 2020 09:09:49 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id uYYb-6GPlQja for <>; Tue, 24 Mar 2020 09:09:47 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 0CF713A0D45 for <>; Tue, 24 Mar 2020 09:09:41 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTPSA id 17261EE013C; Tue, 24 Mar 2020 16:09:41 +0000 (UTC)
Received: from compute3.internal (compute3.nyi.internal []) by mailauth.nyi.internal (Postfix) with ESMTP id 937E827C0058; Tue, 24 Mar 2020 12:09:39 -0400 (EDT)
Received: from imap1 ([]) by compute3.internal (MEProxy); Tue, 24 Mar 2020 12:09:39 -0400
X-ME-Sender: <xms:wzB6XtZNBxmuaTSKtw9qXkjC4l7elCjgc_yyPIcdC36EPH7p53E2sA>
X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedugedrudehuddgheegucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurhepofgfggfkjghffffhvffutgfgsehtqhertderreejnecuhfhrohhmpedflfho sgcuufhnihhjuggvrhhsfdcuoehjohgssehnthhtrdhnvghtqeenucevlhhushhtvghruf hiiigvpedtnecurfgrrhgrmhepmhgrihhlfhhrohhmpehjohgsodhmvghsmhhtphgruhht hhhpvghrshhonhgrlhhithihqddutdegjeeludehkeegqddvfeeffeekfedvtddqjhhosg eppehnthhtrdhnvghtsehsohgsohhrnhhoshhtrdhnvght
X-ME-Proxy: <xmx:wzB6Xjm4b3mqeD5xp3ogrSE5ubNe99VEIOz0-bw0G4hE40uN6AXaaA> <xmx:wzB6XmIDE9eqU-5QHe9nrv-SrZ4z6f2_R82iPZyICEsbqd2nXOT1Aw> <xmx:wzB6XtLGL3wdm_V4tF-lvSjARZMeo8HdxQmpX45Re5J-8laNMzJ2Ig> <xmx:wzB6Xl1yKudM9KKcxu6zMlxanf-CIDSMyDnZq0PF7J4DGzeNj9Fpeungvlg>
Received: by mailuser.nyi.internal (Postfix, from userid 501) id 16585C200A4; Tue, 24 Mar 2020 12:09:39 -0400 (EDT)
X-Mailer: Webmail Interface
User-Agent: Cyrus-JMAP/3.1.7-1021-g152deaf-fmstable-20200319v1
Mime-Version: 1.0
Message-Id: <>
In-Reply-To: <>
References: <> <> <> <> <> <> <> <> <> <> <> <>
Date: Tue, 24 Mar 2020 17:08:29 +0100
From: Job Snijders <>
To: Oleg Muravskiy <>
Cc: SIDR Operations WG <>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
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: Tue, 24 Mar 2020 16:10:07 -0000

Dear Oleg,

On Tue, Mar 24, 2020, at 16:36, Oleg Muravskiy wrote:
> Your examples so far have showed that continuing with incomplete set of 
> ROAs after a withhold/manipulation on ROA objects might create 
> dangerous situation.
> Are there scenarios where withholding / making invalid a certificate, 
> for example, leads to a similar danger?
> I wonder if this is specific to ROA objects only, and whether we should 
> treat them differently. If it is, then we could “ignore” all published 
> ROAs at the specific publication point, but continue validation to 
> child certificates and their sub-trees.

Good question. My intuition is that it is not entirely relevant what the file type is. My examples are indeed all ROA and CRL specific as the consequences are easier to demonstrate using the real Internet BGP tables in examples.

Treating ROAs differently than other types of files referenced in manifests may lead to pain somewhere down the road when it is discovered that these problems in fact didn't just apply to only ROAs or CRLs. If there happens to be a file type (now or in the future) where proceeding to extract data from subtrees is a safe choice to make, I think /that/ should be be the exception after it has proven to be a safe choice to do so.

The RPKI data does not lend itself for some kind of Solomon-Reed error correction. Manifests allow us to discover that /something/ is missing, but we have no idea /what/ is missing. If we don't know /what/ is missing, all bets are off. It is hard for me to imagine a scenario where the publication point's own ROAs are hosed but it'll still be safe to continue attempting to extract data from non-ROA objects from child certs / sub trees.

Should at some point there be 'business rule' interdependencies between various object types that may exist in the RPKI, and exceptions were made for ROAs but not for other file types - I suspect the complexity of the decision tree will become insurmountable.

Kind regards,