Re: [Sidrops] 6486bis: Failed Fetches

Di Ma <madi@zdns.cn> Sun, 30 August 2020 04:49 UTC

Return-Path: <madi@zdns.cn>
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 787F03A1430 for <sidrops@ietfa.amsl.com>; Sat, 29 Aug 2020 21:49:08 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level:
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham 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 mITx4swEedfF for <sidrops@ietfa.amsl.com>; Sat, 29 Aug 2020 21:49:05 -0700 (PDT)
Received: from smtpbgau1.qq.com (smtpbgau1.qq.com [54.206.16.166]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 217643A142E for <sidrops@ietf.org>; Sat, 29 Aug 2020 21:49:02 -0700 (PDT)
X-QQ-mid: bizesmtp11t1598762935t2mvfpuq
Received: from [192.168.3.24] (unknown [223.21.254.18]) by esmtp6.qq.com (ESMTP) with id ; Sun, 30 Aug 2020 12:48:52 +0800 (CST)
X-QQ-SSF: 00400000002000X0Z000000A0000000
X-QQ-FEAT: 2Jv068wAOjb5VLoLeohB/axnXO9hfTwstcp3S19/IsIYO6lrIzumsA0MrbZFi MSG0y4IHvEbLm4692fRC0q1p8zKX/DpTSfGIsArMUVQt9BVVxfO0CgcCxmeqzHY3XcFCaCB IrqCtDqECN+ZNKJ/SwlquDWdK4pCVGSCKFF2eHcJrOPSSdgtylXQQuwRYcLMSFa/0icRnpg 51tYDWNokEnhAQ4Qha9FEtmhGLk0Z6V1ihhL3XVN9cBgtceSoMW2fz7XsvUlTFgrpjgczdX B4azb0cPTbhALpU/Hye3VNg/VycRk/pX8G3Ital2jwIh2SgDKKKse/CsGqKa+UmEnxR/mXj DNvn+EvR2VHRI7dsS6IKQS4soCju63R5jAUikwu
X-QQ-GoodBg: 2
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.1\))
From: Di Ma <madi@zdns.cn>
In-Reply-To: <10b9622d-90b0-63e8-288e-858f88835284@verizon.net>
Date: Sun, 30 Aug 2020 12:48:51 +0800
Cc: SIDR Operations WG <sidrops@ietf.org>
Content-Transfer-Encoding: quoted-printable
Message-Id: <DFCBFDAB-F6F9-482D-B5A4-BB69742BB619@zdns.cn>
References: <20200817163134.29aa1a6b@glaurung.nlnetlabs.nl> <c1a8fffb-9106-d08e-4254-44ddf1a0115a@verizon.net> <20200818083659.1922a98c@grisu.home.partim.org> <6cebcc89-3e07-8a85-3813-b4ae9887d119@verizon.net> <20200826122539.52493813@glaurung.nlnetlabs.nl> <b71c9c88-fb10-b037-d06a-910711e51e04@verizon.net> <cf7030be-adc4-dde4-7eda-516339fd6c91@verizon.net> <E8A259E6-869D-4D2C-87F0-87462B9731E2@nlnetlabs.nl> <10b9622d-90b0-63e8-288e-858f88835284@verizon.net>
To: Stephen Kent <stkent=40verizon.net@dmarc.ietf.org>, Tim Bruijnzeels <tim@nlnetlabs.nl>
X-Mailer: Apple Mail (2.3608.120.23.2.1)
X-QQ-SENDSIZE: 520
Feedback-ID: bizesmtp:zdns.cn:qybgforeign:qybgforeign7
X-QQ-Bgrelay: 1
Archived-At: <https://mailarchive.ietf.org/arch/msg/sidrops/QsR2tpQwBYr8JdyKWx2vr7Yrh2s>
Subject: Re: [Sidrops] 6486bis: Failed Fetches
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: Sun, 30 Aug 2020 04:49:09 -0000


> 2020年8月30日 02:58,Stephen Kent <stkent=40verizon.net@dmarc.ietf.org> 写道:
> 
> Tim,
>> Hi,
>> I agree that a correctly functioning CA will produce a sound set of objects. Also it is highly unlikely that a CA will just publish an expired ROA. The much more likely scenario is that a CA is unable to make or publish updates and the MFT and CRL go stale, and the MFT EE expires, way before any ROA or issued cert would.
> I agree that these seem to be the more likely error modes, but there also was a discussion of encountering more than one CRL, for example.
>> That being said there are scenarios beyond the control of a CA that can lead to invalid objects:
>> 
>> 1) rsync
>> 
>> If the RP does rsync only, they may get an inconsistent data set. Transactions are not supported here. They just get an old MFT and new CRL or vice versa, or they may get a new MFT but not the new object, etc. This is a race condition that happens infrequently when RPs fetch during publication. It is rare, but it does happen.
> I agree that this may happen, even if one publishes all of the objects in a new directory and the  switches the pointer. But, in that case, the RP should consider this a failed fetch and retry. I believe that's what the RPSTIR software did (does?), so it's not a fatal error.


Yes. RPSTIR2 does do so, retrying.

It is difficult for an RP to determine if it is a rollover or a mistake when it sees new MFT and old signed objects coexist in the repository in question.

If it is a mistake, RP is supposed to consider those old objects invalid as per 6486bis.

But if it is during rollover, RPSTIR2 now has to keep retrying until things are seems ok. 

IMHO, I suggest it is the CA that does make-before-break by setting up a new publication point with new MFT and new objects, keeping old ones still valid. Once the new publication is all ready to service, CA replaces old SIA with new one. This is what I can see by far a  compromise to solve this issue.

Di