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

Stephen Kent <stkent@verizon.net> Fri, 03 April 2020 15:06 UTC

Return-Path: <stkent@verizon.net>
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 75F793A1906 for <sidrops@ietfa.amsl.com>; Fri, 3 Apr 2020 08:06:41 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.101
X-Spam-Level:
X-Spam-Status: No, score=-2.101 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, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=verizon.net
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 yh5mWwWmHUMq for <sidrops@ietfa.amsl.com>; Fri, 3 Apr 2020 08:06:40 -0700 (PDT)
Received: from sonic308-2.consmr.mail.bf2.yahoo.com (sonic308-2.consmr.mail.bf2.yahoo.com [74.6.130.41]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 16B143A1901 for <sidrops@ietf.org>; Fri, 3 Apr 2020 08:06:38 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=verizon.net; s=a2048; t=1585926396; bh=UOxeFZZ2eUln/FyRynAxOyLGnzOuAvKEk4uwhBLmaMw=; h=Subject:To:References:From:Date:In-Reply-To:From:Subject; b=EvDDhu1ebq3k7iWPgl8VgTwvmhi9xjzKBKXTmqJ2LtEQSccwyLYbrSre8SrUYapNlaU1DmSkSQ6GOmtOjI+92E4vbJQA0slkMdDgQF7a/rKQe+8kiwi+AcwuudbY0+tYsLncR3Nx6/EfjwwwtjLVBephw4xA4LTTvla64SonLWnVVzyuhKn0MrgrdylOh/uSEkjYBb6Oet6z+jNHxEpoQJpJYeLkhy3jJlkseMbsefCEfg15FJBATaEz9hG/TtUMa+wWwFZ14jNirnnqXAslsGrbFdeOpQ35qKlM0++Y0xxVPv9Ptp3AmMkaxxok6QQijTwk7w18LptTR1MQlQAYFw==
X-YMail-OSG: miKBk7IVM1kXLfZSstuDECslSc7CtxlEz7fBxfFBjyzKm_X8yS1VPie4n20EwEP vSbqqJTdhbJegZLqktzDG9TEJUV67N8kCRMkXYPal8fAGa81R39jcOl3Zk9UJXn250SSbMzf9jMQ V9_FeEWwLFJUYRpXIR2Y.1T86sKvM23D1.OLB17k2wr3QqmgSYAJ81GY_93eb7wHPY52IHh4ednX jbdWhDKqzHQUlmZSkwguvozyt9_ldI4g4d7uyWqWUV.F3ZU7U0lLLqkuJFT4nxvhgXERH45kBAsh 6uClFKuL4UO1.PdTA_n.mtjUSyTpQuBZr6kAev8c.9KLqXsBzyucfohCgN7ktxKSyIv9kaongPoo .ySy7lk1iCbn75V90PnDPbVhB6aeK3cJukzEkH2gR92079dnrJTo2FzAQIjjQzHBKEAk2x7qwhRt m3H9T5oUXC6FKdPaBOjf.aNgSpfR2IKX04nXidKkDJhjbHpNGLZVgQV92TUnw8CHVZpMNpgeq8ol i3Yq4C_oTkJP.wiOC3kMfSUoIgkNz6lDg8k8ByNsYPBsngHKLzsdL3yVYDL19dGepShMjfCxKFVT 3AI2OyRfdWEu_T4VRNfiVx.VxFiP0wHmHu8cSivEiyi8uCZTcZR6X0ZO1a6seEGgmM7THkiSUzzs GSbDFzNUDPwALH49zoqOrXt1x4cqI_bm_alRp7rhpAUKkWJJzd04GqpFXj_HIOC6qufstNN0Y1Lh qQYRORwlDC9blclJoiZ.Vze9cZuq3hWbsJINK7QjVbKsVzNf1UxSvNFx8sAcuAocW9y_BeKMg71O xJn1g6ppuTIev51i8Vyb0g.0J1Xv_LcPKz8yPz0Fq5oSrKLZffEpA_LTmWHap4qgH3JqokWkKROI zzeH074mNSBDPTlwbz0JGFBsiWK3pXVmznB7Etoathx8sYPYuOW6c98iKH39y_UNtLcByVmd5bb4 xzkp5EPD0OfGvRx8vxB46YznQGN8giDjVDsP85az3gR5xZSy9tM4yrUM.u7f9zykDCcNMf1M_q0L 8vzJpIXmK2HBi5jNgGsG8_6d4NWruts7nv_xtppHqrwxh18485IJJWISN4bFAVYrp2nhZ0nA3DbW eTs8YEoipggULpk8_hqtkfa6Ry9yJ5_1uWL2OucRk6QMOkEeTujpoS.h1DQXvJVvu1YT23SM5wcE LA0Dyi3_0MA_HcLwE5ocSuyO.ByBKzPJEqg_1qUEG8FOAgf6RIMNUvebQC3E810D2DedhCuk8f8m dtEnVoDmnmX4AZ46sIiQ89N7tcikIUqqpf3mL1S5kNeaWP6zGr5iJOMTQAWS59oepSp0I5EjdLar yfpCCW6dmlxqvYSH.rb9yvliz.5fJL57pJWduWPC5RmOkEr0KPLMX2o9dPDEhqCQjkmvJ0oQ.FbO efppVKTmXpEDmOQujmbKStWjI6eQ6DMsRGiSjJblIxYUQc84-
Received: from sonic.gate.mail.ne1.yahoo.com by sonic308.consmr.mail.bf2.yahoo.com with HTTP; Fri, 3 Apr 2020 15:06:36 +0000
Received: by smtp412.mail.bf1.yahoo.com (Oath Hermes SMTP Server) with ESMTPA ID e6b5a31cd9e16e9a218aa38d90d0cad0; Fri, 03 Apr 2020 15:06:31 +0000 (UTC)
To: sidrops@ietf.org
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>
From: Stephen Kent <stkent@verizon.net>
Message-ID: <f1a9aab6-154c-5e27-7e70-9eb320eef422@verizon.net>
Date: Fri, 03 Apr 2020 11:06:30 -0400
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:68.0) Gecko/20100101 Thunderbird/68.6.0
MIME-Version: 1.0
In-Reply-To: <24198.20355.168888.506246@oz.mt.att.com>
Content-Type: text/plain; charset="utf-8"; format="flowed"
Content-Transfer-Encoding: 7bit
Content-Language: en-US
X-Mailer: WebService/1.1.15585 hermes Apache-HttpAsyncClient/4.1.4 (Java/11.0.6)
Archived-At: <https://mailarchive.ietf.org/arch/msg/sidrops/JzZqDO1nQcQb-BLcM2FeZP8-TkQ>
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 15:06:42 -0000

OJay,
> 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.
I often strive for pithy, but ...
> 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.

Thanks for the clarification. If the operator community can agree on a 
consistent way to deal with inconsistencies in downloaded pub point data 
I think that would be ideal.

I'll post some suggestions and an outline of the decision points, shortly.

Steve