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

Christopher Morrow <> Wed, 26 February 2020 03:29 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 762BB3A0B3E for <>; Tue, 25 Feb 2020 19:29:06 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.098
X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id lwjWeXj5Kejn for <>; Tue, 25 Feb 2020 19:29:05 -0800 (PST)
Received: from ( [IPv6:2607:f8b0:4864:20::82a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 4032A3A0B3C for <>; Tue, 25 Feb 2020 19:29:05 -0800 (PST)
Received: by with SMTP id i23so1281593qtr.5 for <>; Tue, 25 Feb 2020 19:29:05 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=53fakRq5Wz1pKNCLiKlQPN7lI4zUxrYOA/QuJ9+KvCo=; b=Kwj3odIvR8gfYwpHDrW0d68LqTyc7b+gMa9/stpWXvgjt2NlBcMJFT7kkRRb9EcuW5 dToqVc1biPTai41daL7FDRumnGsk/3DcLc976IMty97qP9lsiMRiy2OaxbqtUDFhUW0L 2bHtvmNNRiIbCh3HUqDixIzcz8Rd1rR42/5Tki1wSRP5jqrgz5AcohfLaaYvMwwHVytt h0iTyRZd0WtgkQqsl/JeihtL7ln87suV1e5Sq+Ykk6OpSjJJCvGIh/kprCNpdB6CUOpc G1EeUu16fMkfR2sOmzQOqNv7tHq56bfhvjSsVwwF+35Rt2IfnV+OgDFgpbO7vl63k2tq xr5w==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=53fakRq5Wz1pKNCLiKlQPN7lI4zUxrYOA/QuJ9+KvCo=; b=oB8/KnxuD/yQJP+1DPoWHVJ1nL0GrzYAbeAI+sLQG4L3q/yVasU0N8bygfrdE8euHm 0UKOMI4aJhmroBTUNQFpc7ravaeqpjdbWYbYUBRViggpAzBoKZXizZ1YqT/v/o2aFdKy xg07CIBqLNFsMV9aqYIWXOU4bNg/88Fu3pg3ZHh7bGp59eaH0YsLNEQieZemb8urCkml 1OowB7mOflv+MuZddk9KoxahvFp4Gtr9WUTxfkOMG9DoriQ0r/YHRDmSci20Hqtq6LKT sPwfEHu3OXbIx7a5gIPVj9CTwlTRkibSUaVnAYjA61G+ARTt9mlYN2Vn6Kxxpm8UFUPY GgHw==
X-Gm-Message-State: APjAAAXigS7TSQoxNGdwjrv1uq4mbNFLI8wFaiWbvf2pORrAdSpcGuRV 9XgMaJnw53dsmtP4z5IR8XZbRarUP0MJA9xX2mk=
X-Google-Smtp-Source: APXvYqxGfkzujGGplXme+3eJpo8SknOXKn/2vMy2FC61rYIICEks9F20R1YJfOZai2QpKjcDiiObqKBnQY27m1e9cc4=
X-Received: by 2002:ac8:5457:: with SMTP id d23mr2437881qtq.93.1582687744059; Tue, 25 Feb 2020 19:29:04 -0800 (PST)
MIME-Version: 1.0
References: <> <> <> <> <>
In-Reply-To: <>
From: Christopher Morrow <>
Date: Tue, 25 Feb 2020 22:28:53 -0500
Message-ID: <>
To: George Michaelson <>
Cc: Stephen Kent <>, SIDR Operations WG <>
Content-Type: text/plain; charset="UTF-8"
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 03:29:07 -0000

On Tue, Feb 25, 2020 at 7:24 PM George Michaelson <> wrote:

> If you cannot see a CRL which you are told should exist, to assume the

This wasn't missing CRL, but an invalid one, right?
Does that change your mind on how you'd manage this sort of problem from
the (network) operations side of things?

> CRL doesn't matter feels extremely unwise. I may have mistakenly
> published entirely cryptographically valid things which do not now
> inform my intent, and I have tried to repudiate, and you cannot see
> that repudiation and now interpret states of routing in ways which do
> not reflect my true intent.

So, to bypass the CRL (in all cases) seems bad, sure.
To bypass it (or enable a bypass) in cases like this (clearly some mistake
let us get to this discussion) in order to keep routing packets 'properly' (ha!)
doesn't seem like a total disgrace.

If the CRL mistake is a the RIR publication point/top-of-tree it certainly
seems a bunch more important to fix the problem 'quickly', however, I'm
not sure 'quickly' is much more than the experienced 8hrs this time given
some default numbers in validator code bases, right?