Re: [Sidrops] 6486bis: Failed Fetches

Stephen Kent <stkent@verizon.net> Sat, 29 August 2020 18:58 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 962413A0F21 for <sidrops@ietfa.amsl.com>; Sat, 29 Aug 2020 11:58:26 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.049
X-Spam-Level:
X-Spam-Status: No, score=-3.049 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, NICE_REPLY_A=-0.948, 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 e1VlzX328kji for <sidrops@ietfa.amsl.com>; Sat, 29 Aug 2020 11:58:25 -0700 (PDT)
Received: from sonic305-2.consmr.mail.bf2.yahoo.com (sonic305-2.consmr.mail.bf2.yahoo.com [74.6.133.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 182533A0F1E for <sidrops@ietf.org>; Sat, 29 Aug 2020 11:58:24 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=verizon.net; s=a2048; t=1598727503; bh=l0Ba2wp0yVrT3Z1pwiyDSPFZtNYjzz5lQCoLgLIA+hc=; h=Subject:To:Cc:References:From:Date:In-Reply-To:From:Subject; b=LebJobmdBinjqpcHGubC1/4mtwF1DjhwSVmsFX5PE3pOVEF7L5wlqYNFNQzkV5YLhhWF6YBkqMWm1+athopIqjI5WM6I+1YzxHzZ4Pn4qt1/zbvLMCBTEEr0S9Nb1wys+GFDTPJg/250eI+1TkFv+CCfZjHI2ZfzAknuqf5IyhcJmjN50HLvN5x7EFGM9Frn5hWMkgs+wN8ozIy6BdsZxrttEa3BH682cQLDA6wdInCA0k+KtXMpMVJw0A5tVjdps9W45OqmtvHU1on52K2Qi3nGSZhYyLrOrge8PfB+0TZFE5oHFvkP9+40lwOx2ymprsslBOTCqNSlVZEFxOx1fw==
X-YMail-OSG: a9fWxIMVM1kdDpKCS.144IH.WS3gfVfBlyJ_SfnSyC.TbcOusHxNYj1ED7apLMS gK73Eram31_Vc1_PcxCctsqmLgMN5hLqfHz9hs.gOBVxiqrn4ijyEs0bVB54FTWbmXtyzWa4DYqH WVbkmWhJ6Od_leT8xuK7L8aj0mYTiHSZzFQyEG6IGKxuPlfVey2t0kfQNOmFkgxCHu3_mcxCP5Z7 bpdhMKNwyH33ghgDa.Fb4UhuQ.F1xQoVBqTU7WEVlpq2.QAdKmAaSh3js3UleNQNB4JqDSMloiN3 Hl_uUf90EUK6sv53pdYQowAz5OQFluMWqS7t1T_xJFt4ZZfnk8znlYfQd7rB5wkNbOGiKcfwCuqc wOGLd_ZmgWXPeoEenLfEmiETrGahfnhzDr8sRY.LP2RG7q4Cr2V_fSW7HQbnqMe4nW6kvxFOSgZo 2uAizVbsTc1HE1Sqki2_nd4z9MSGl1efAsVV7MBs.xAfeDTvpEaUNXKAC5cDpm4hJ7JF.Vp5H23Q kcjQiyVI8I7QXTV.fxghO_vYk7y2A5HkzKsFY.Bg3f0SGLNIEfjeA_rENU_0KxbzC02YU5mC8JQM mzfq0HZ8aUA_axwOfUQow.yqz1LE7sAoAdiyrKmDAIBztqNHN2K1UEcfDyZcCnzg2L35OGqKXEk9 wJ6ti0l.xJRCLFPR6EkI5eBL_.0AI8kJhN.l5JXEC2kBW9VENDlCn99jQAwklnDD27cjSZJwpVG5 M6eSdVhOc7x1iQOzlK.k5LCCDQzMpHNet2d9sJOZ_Dt9hHmAFrv2W9mDoWaEYtQtRt0lVpxjet5Q 0t0ormg7PCUddh0U28fy5RhJHnQKKsPbMlhU.n.Co6gjaUMBFSxJZH1AzEA6ymT.EDVocfAQCuwF fcJc.IVaFUdQn9seQoXDWTi2d_U9Wh1DjHcjdkuOfuVtVcY4K.Qm7JYeZKnI.XzU91eyL2K9_wcg FAiUSe1udoYgWXfhxdv6.VGhqyhrms9YRscXy1.9wI3O_hrHVWdLKemdHk5b2OcFbcDu7ECG06Yl sbDoWcyk_1tcWaudp_3IEKMDiTa3_D17kv.wknK3qVt1aYONi5_WGZwj2aGdSgIqdfVzxylJHB4B 2WyI5b.J4Beqh7id.fv39MI1H09kjl4BF7iyX3BEDdPWI2WE0i6kwLmSbXHUwcxxiUjRjwpFKEUm QuAJc.OZlU7zAimbZa8UWQ66oPY9YOtNcH09vkV7FJYaSjTaNlpRgxKyev8lPowBsLTmJN.cdieh 9aCuuTUFi_k6szhdJlbFxk6ikkVKaWTuJRp5R9JbzV1Rol5NOO3id2l1h3OoXQSkNHS8et2vNZW0 12RXvqq0VTHS9qp91lRamaT82jviT_sPEiTm0CWHEoeb5K46pqrOgj.1FedV0zkxuNUJpuMUs6Cd zhaed0ZivCnS5PLPL_W20lmijjijYtHcOsGgZhxV0wnL6NV7iavCnbWI_CTv6UOqHmYjwjwKF_PE JeePPaSexRFv3ce4.Uq2gAmTYehW7lkW3EDogf9oY1r6pXxs36AATdscr8iPUx_1q3VGZvrRjG7G S.geO
Received: from sonic.gate.mail.ne1.yahoo.com by sonic305.consmr.mail.bf2.yahoo.com with HTTP; Sat, 29 Aug 2020 18:58:23 +0000
Received: by smtp403.mail.bf1.yahoo.com (VZM Hermes SMTP Server) with ESMTPA ID dbee226bae5a6fb06ec76084f40e19ea; Sat, 29 Aug 2020 18:58:18 +0000 (UTC)
To: Tim Bruijnzeels <tim@nlnetlabs.nl>
Cc: sidrops@ietf.org
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>
From: Stephen Kent <stkent@verizon.net>
Message-ID: <10b9622d-90b0-63e8-288e-858f88835284@verizon.net>
Date: Sat, 29 Aug 2020 14:58:17 -0400
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:68.0) Gecko/20100101 Thunderbird/68.12.0
MIME-Version: 1.0
In-Reply-To: <E8A259E6-869D-4D2C-87F0-87462B9731E2@nlnetlabs.nl>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit
Content-Language: en-US
X-Mailer: WebService/1.1.16565 mail.backend.jedi.jws.acl:role.jedi.acl.token.atz.jws.hermes.aol Apache-HttpAsyncClient/4.1.4 (Java/11.0.7)
Archived-At: <https://mailarchive.ietf.org/arch/msg/sidrops/vfnHtelKHJhWWdp8lJh5UJvBqaI>
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: Sat, 29 Aug 2020 18:58:27 -0000

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.
> I remember that many years ago I wrote code in the, then, RIPE NCC validator 2 to catch this issue. And only process publication points if the set was consistent. This was an allowed, but not mandated, interpretation of 6486.
>
> Note that with RRDP we have deltas. Solving this issues was one of its design goals. So, phasing out rsync could mitigate this.
> (yes, I realise now that the co-chairs asked me to re-submit the I-D for this, and I still need to do it)
I'm still waiting to see a clear, and hopefully concise, description of 
how an RP verifies that the pub point data acquired via RRDP is 
constrained in the hierarchic fashion imposed by the rsync directory 
model, but that's a separate issue.
> 2) resource changes
>
> If the parent removes any resources from the child before the child has had a chance to clean up objects then this will lead to invalid objects. Being strict that *all* objects must be valid will then lead to rejection of the CA's products. Even if it is only for a few hours.
>
> I believe that this issue could be greatly mitigated if RFC6492 would be extended with a notion to give children a warning about planned resource removals. The length of this warning time being a function of the contact frequency of child CAs and the depth of the CA hierarchy. But, if this frequency could also be stipulated - say SHOULD every 10 minutes? Then a warning time of just a few hours would already be plenty.
>
> However, this is a separate discussion. I do not suggest that we block progress on 6486bis for this. I am just saying that if strict checking for *all* objects is where the consensus goes then the WG must be aware of these consequences and accept them.
yes, this is a separate discussion.
> The current version of 6486 allows RPs to treat individual objects as 
> invalid. -bis is trying to change that to say that the whole set of 
> objects must be valid. This changes the consequences for the 
> deployment of new object types, so it is right to consider this now. 
6486 allows an RP to behave either way, e.g., to accept some but not all 
inconsistencies to to reject them. So, it's not quite accurate to 
suggest that RP software that operates in accordance with 6486 will 
treat individual objects as invalid- it might, or it might not.
> The most likely next object type would be the ASPA objects. I don't think that RPs should reject all ROAs because they do not yet understand ASPA. Given that object types in the RPKI get distinct file names, and RPKI signed objects get distinct OIDs I think it would be reasonable to say that RP software can ignore object *types* that it does not understand. I would still advocate then that the RPs do check for the presence and hashes of these objects as stipulated by the signed MFT, but not consider their content.
Allowing RPs to ignore object types they don't understand prevents a CA 
from being able to convey the notion that a new object type is important 
(to that CA). I don't think this is a good strategy. It means that RP 
behavior will be ambiguous relative to new object types.
> If we don't then the consequence will be that new object types only become deployable after a significant percentage of RP has been upgraded to version that understand the new type.
>
> Now, if all operators say that they are fine with this: let things go unknown for everyone who did not upgrade, and force them to do so.. sure. But it is right to consider this now and make a conscious choice. Oh and BTW.. for RPKI use cases where we only have VALID/INVALID but no NOT FOUND, such as BGPSec, this would be problematic.

If we want to have a consistent and flexible approach to accommodating 
new objects I suggest the strategy I mentioned earlier. Define an 
additional SIA URI that points to a pub point (and manifest) where we 
can introduce the next version of the signed object format, one that 
includes a critical flag, analogous to X.509v3 extensions. This allows 
each CA to decide which object types have to be processedĀ  by an RP in 
order for the whole pub point to be accepted vs. rejected. Note that 
this will require modifying a lot of RFCs, but it is a flexible, 
extensible approach to this issue.

I agree that even if we adopt the current 6486bis , for now, that a flag 
day is appropriate, and it shoudk be part of the document.

Steve