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

Jay Borkenhagen <jayb@braeburn.org> Thu, 02 April 2020 20:48 UTC

Return-Path: <jayb@oz.mt.att.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 641233A194C for <sidrops@ietfa.amsl.com>; Thu, 2 Apr 2020 13:48:26 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.648
X-Spam-Level:
X-Spam-Status: No, score=-1.648 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.25, SPF_HELO_NONE=0.001, SPF_NONE=0.001] autolearn=no 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 BAW1wtpr07v9 for <sidrops@ietfa.amsl.com>; Thu, 2 Apr 2020 13:48:25 -0700 (PDT)
Received: from hrabosky.cbbtier3.att.net (braeburn.org [12.0.1.25]) by ietfa.amsl.com (Postfix) with ESMTP id 1FC573A194D for <sidrops@ietf.org>; Thu, 2 Apr 2020 13:48:25 -0700 (PDT)
Received: from oz.mt.att.com (zoe.cbbtier3.att.net [12.0.1.45]) by hrabosky.cbbtier3.att.net (Postfix) with ESMTP id 46C592D7FE for <sidrops@ietf.org>; Thu, 2 Apr 2020 20:48:24 +0000 (UTC)
Received: by oz.mt.att.com (Postfix, from userid 1000) id 1B374A407C8; Thu, 2 Apr 2020 16:48:24 -0400 (EDT)
X-Mailer: emacs 24.3.1 (via feedmail 11-beta-1 I); VM 8.2.0b under 24.3.1 (x86_64-pc-linux-gnu)
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Message-ID: <24198.20355.168888.506246@oz.mt.att.com>
Date: Thu, 02 Apr 2020 16:48:03 -0400
From: Jay Borkenhagen <jayb@braeburn.org>
To: sidrops@ietf.org
In-Reply-To: <75140927-0b8b-07ab-ad2e-952e32256df1@verizon.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>
Reply-To: Jay Borkenhagen <jayb@braeburn.org>
X-GPG-Fingerprint: DDDB 542E D988 94D0 82D3 D198 7DED 6648 2308 D3C0
Archived-At: <https://mailarchive.ietf.org/arch/msg/sidrops/yrhm-HgnwnXRJPXgfAnPfYB13BE>
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: Thu, 02 Apr 2020 20:48:27 -0000

Hi,

Re-visiting an older message in preparation for the upcoming SIDROPS
virtual interim meeting.

On 23-March-2020, Stephen Kent writes:
 > I agree that more uniform processing is desirable, but in the routing 
 > system the notion of local policy seems to be ingrained, so ...

When I first saw this, I thought Steve was just making a pithy comment
about local policy and network operators.  But a friend thinks Steve
had not meant it as a joke at all, so let me take Steve's comment at
face value and respond:

As a network operator, yes, I expect to have the flexibility of
configuring my network using local policy.  But in the context of the
RPKI, we need to reach a point where all RFC-compliant RPs will
generate identical sets of VRPs when presented with the same input.
There will be reasons why I may prefer to operate one RP over another,
but the VRPs that a particular RP generates should never be one of
them.

No network operators want to specify any 'local policy' on their RP
instances to control under which conditions an RPKI object would be
accepted.  Some network operators in this WG have voiced strong
opinions about how such acceptance should be decided, but that's not
because they want the ability to exert local policy there.  Such
opinions are all toward the goal we share of all implementations
reliably creating a correct/consistent VRP set.


I encourage feedback from other network operators on this one simple
point.  Hopefully we all see this 'local policy' matter the same way,
and the WG can turn its attention to consistent handling of the corner
cases.

Thanks.
	
						Jay B.