Re: [Sidrops] 6486bis: Failed Fetches

Stephen Kent <stkent@verizon.net> Sat, 05 September 2020 18:08 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 059113A0B9C for <sidrops@ietfa.amsl.com>; Sat, 5 Sep 2020 11:08:57 -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 zXWQP4YP1gr3 for <sidrops@ietfa.amsl.com>; Sat, 5 Sep 2020 11:08:55 -0700 (PDT)
Received: from sonic312-21.consmr.mail.bf2.yahoo.com (sonic312-21.consmr.mail.bf2.yahoo.com [74.6.128.83]) (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 9A53D3A0B9A for <sidrops@ietf.org>; Sat, 5 Sep 2020 11:08:55 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=verizon.net; s=a2048; t=1599329334; bh=AIkzhvKUuQ90GEcBp4Xt1TBmCLinFz+yvxsJUm8cafw=; h=From:Subject:To:Cc:References:Date:In-Reply-To:From:Subject; b=uFQYSHEq2P+3KukaquLUCDQ6sfioPoTr5hTYTFJLPHK/afhskOWz0hyd89LC8+MwcqSDEm99tCtORRmJTOhRqC3H0wLEYVAcoj/xwAYcjZDIkD7U9b2UHfH9gA5nE6HpOy7WrdBzBNPvjp1R1ehrEUhK9KWSvmPxQcppbwDkDpgGDK4cmBL7o5S79+s7Xp24i9RNeQC7PC5t6pA2S3b2pboUAvNFao9SMibvzVqcqOolzZhxaHKKzCH2DMnXtqUBFsA7FY6m8NGWrI47Qr6dlFSrj1Fm7gO0cNP7qVcDS9kkUacG2MiEyaMtKG+pZEOqI+JJ6ClhYqCW60d5USreug==
X-YMail-OSG: yQN9qD8VM1kL2RzwX2AJuDiv_QBb75LsxUWaBtImgGReuOrIZH5ZYV5KRbpevPJ 1vz19SjM18Gz3OJ54pYWF2VZwsP62Ncka2M7C_6LC0.4AvMlHddF0_qqv.sRFodeSDJIvEMUkTlG zm.cxHJ82TKIHXyyq8wAuImaZxgFsLZ2fjUy9FfN5dzrNk2EyR4jr05YfoQGzMkqRFjZ_NVkZPUY 81KPdjLekc1ODIcBV2niPgHiqwuKH6Vz6m0Pl3dYiao4TTswOMJUKT9yezcCax5IqnzNz8nfTvOE U6EHmZO4HRHDXgwxwIGQ.aQaY.1MyEYFQ.9rIaDdWWCRcObjeklydNPnuRwJ8BtBOs8h3z6EwpMh Rw8NP6kn8e8XbfeTp7n7a9PganD0V4Jo6ijmNv0Fj5X0mb30rXlqns6WdUCrJsUXWLtf1gttNz4E QggA96GvbAC6WGkjJGlbXjnkvcJbBpaEedS9C1POitX4dgOXytU8RfziEwNWhoIxkcf0slT9DVy6 im3faJbZvq7iXPbsUfKtNY8D7NUFEMFgEjWg9chQBFjL5A69B5O5HI8ScVAG6I68Ct63txLjRywS IVaSIWeMRdgx7NcM2.GDfNcynGy8NNxh6WJz3Jafhp7.nqgrilzey06EDEt4BvAc_iJ75DUvLfFv QjWm1mVJ0rfAxD51MpfQhSi_CsSzATvqIu6Nrhq2gb7p70LsGjqrs6vjp.kPatAQEJHJcV93ZA9G pXhzw1nCxdl6ClTdfWs9FJ6NvsurQOav8QpRkHI1ag2ZmenEabxFaXnxCTRLS99zp3o6VclF.6jh T7qkOOqkBp_BiVQEMA0aXJyIkJFul2i7Ca6anUMa7eP1vbI.pi5jvDwFyNFpZYNKIQF3PuNkS_pc vg_U881hsPv0subRxHP5ap08FjxQZFA9lPZe9zDj7JQeiFP55LyyN1rWpaVxLpGM.Q_F702ZcPU2 BXgSrUoQFrN02a5PlEIo9Tanx8oiDOAjSiL118eg5vMVj5YX82NFoMJhWV9pTDWyAggqx8H3b_WM xnHjko8Ef2RG9TJMHcHFxeix5AMPy1SUKh7pwqdcuwnIFoBWXEyun5S6Dczd04i_nHVP1r.n9Q.A dqW3iFXuInnh0EqkEeFlPx8YAuUVEEqKBreXgQEedCxb8wTiYoJrEug0dDSDtzDPGzeP0TvlM9Dn D3Plz_4.stn7TOYacNpd1AFOElLqP8fkgt8pJH_5z080z4lyV0kKSCpNKEQnLTH_mSFGjlyZQoW. Wa41nMtQBKIOfdQ81_nIe71rHPQeuJzjRuxh.VISIzd2zWMHyB.Om5KtZheP0ezLbPXLqArCOScP ccS1trToC0KltSPVdz3LRIxnClUkOG1YXNCZWcmhR8tyx1nwvVZleODQSjzqWiijLI10RUV9ihNO 8HnQPPrwo5Lc3lnBkCv7nRWiSRiXZ.zuw0LqZFgG0qO26PrU3Nz1mDsU.f9TV.IqEPVZ2ECdGYcZ a5ldk6qRWwMpcO3.BOSoGpqjPhUHVK5PCzOABIa886V9ysdAAaV3If3gn0IgrB6xFEv5vn2E0IM0 dUUECJRYjDprH_36zgKoF4u1RiKzhZch.51hanaU-
Received: from sonic.gate.mail.ne1.yahoo.com by sonic312.consmr.mail.bf2.yahoo.com with HTTP; Sat, 5 Sep 2020 18:08:54 +0000
Received: by smtp415.mail.bf1.yahoo.com (VZM Hermes SMTP Server) with ESMTPA ID 2b4bc99c3f870284ca36f0129e64e7f6; Sat, 05 Sep 2020 18:08:50 +0000 (UTC)
From: Stephen Kent <stkent@verizon.net>
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> <10b9622d-90b0-63e8-288e-858f88835284@verizon.net> <291655EE-2255-441B-B425-59BEE6DBE39F@nlnetlabs.nl>
Message-ID: <0c7ab898-4031-3613-1382-228ef598c478@verizon.net>
Date: Sat, 5 Sep 2020 14:08:49 -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: <291655EE-2255-441B-B425-59BEE6DBE39F@nlnetlabs.nl>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit
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/aGgNZ5q_qGkkNfZZhss-pemea80>
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, 05 Sep 2020 18:08:57 -0000

Tim,
> ...
> In short: Given that I expect that we are never come to a consensus other than the total reject-all-if-one-fails - I can live with this if we must, but don't let it come as a surprise.
Works for me.
>> ...
>> 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.
> So far none of the objects have seemed to need this flag.
If the goal is to define a very general scheme, then a flag may be 
necessary to accommodate objects not yet defined, since we cannot yet 
know whether a uniform response for all such objects will be 
appropriate. I agree that this need not be a binary flag, as in cert 
extensions. You suggested a three-value flag below, for example.
> ...
>> 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 it's flexible and extensible. I had not thought of this approach.
>
> But it is a lot of work, not just in RFCs, also in code. It also raises questions about how and when old PPs without the new objects can be deprecated. You can give operators more time to upgrade, but at some point plugs will probably be pulled? Maintaining multiple PPs indefinitely seems rather wasteful.
>
> I would like to hear what others have to say.. I have the feeling that ASPA is getting close, and I would really not like to see it delayed because of this.
It will take a while to complete another revision of the manifest doc, 
if we purse additional changes, and even longer before an RFC is 
approved and published. So ASPA will not be accommodated quickly. Also, 
as I noted in my reply to jay, a quick read of the ASPA doc didn't 
indicate how these new objects are validated using the RPKI.
> If we do go down this road then I think that we should also look at the manifest object itself, and let it convey which object (types) are critical (and while we are at it, we can specify types instead of using filename extensions). That way future object types could introduced more easily perhaps - this obviously needs more discussion but it could even allow for semantics like: 1) new object please test, don't use, 2) new objects, use if you can, 3) new objects, critical - fail if you don't understand.

One could combine the new SIA URI and a revised manifest, in which the 
manifest contains the per-object flag, rather than redefining the basic 
object format to accommodate the flag. That would reduce the number of 
RFCs that need to change. Good idea.

Your example bothers me a bit- it seems to argue for CA-directed 
processing flags, perhaps to accommodate experimentation with new object 
types. This sounds like adopting elements of the IRR DB model which 
didn't seem to be so great, IMHO.

Separately, I think we need to make GBR mandatory for all pub points. If 
the intent is to cause RPs to contact a CA/pub point maintainer when 
errors are encountered, then we need to be confident that RPs know who 
to contact and how.

Steve