Re: [Sidrops] 6486bis: Failed Fetches

Jay Borkenhagen <jayb@braeburn.org> Wed, 02 September 2020 18:34 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 97F823A0CC0 for <sidrops@ietfa.amsl.com>; Wed, 2 Sep 2020 11:34:00 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.649
X-Spam-Level:
X-Spam-Status: No, score=-1.649 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.249, 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 BOTvDRhy_qtA for <sidrops@ietfa.amsl.com>; Wed, 2 Sep 2020 11:33:59 -0700 (PDT)
Received: from hrabosky.cbbtier3.att.net (braeburn.org [12.0.1.25]) by ietfa.amsl.com (Postfix) with ESMTP id 9C27C3A0CBE for <sidrops@ietf.org>; Wed, 2 Sep 2020 11:33:59 -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 268202C607 for <sidrops@ietf.org>; Wed, 2 Sep 2020 18:33:59 +0000 (UTC)
Received: by oz.mt.att.com (Postfix, from userid 1000) id EFAF25640A3A; Wed, 2 Sep 2020 14:33:58 -0400 (EDT)
X-Mailer: emacs 25.2.2 (via feedmail 11-beta-1 I); VM 8.2.0b under 25.2.2 (x86_64-pc-linux-gnu)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID: <24399.58769.547600.368430@oz.mt.att.com>
Date: Wed, 2 Sep 2020 14:33:53 -0400
From: Jay Borkenhagen <jayb@braeburn.org>
To: sidrops@ietf.org
In-Reply-To: <4d77e33d-25bb-03a7-7a7e-1535bb2e1f18@verizon.net>
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> <24393.25181.84151.476185@oz.mt.att.com> <4d77e33d-25bb-03a7-7a7e-1535bb2e1f18@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/R01LYGsNgdy6hK9WpWc6bIt77fE>
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: Wed, 02 Sep 2020 18:34:01 -0000

Steve,

Stephen Kent writes:
 > The crux of the issue is whether it is preferable to reject all objects 
 > at a pub point if an error is detected (until the error is rectified), 
 > and thus potentially treat many more routes as having an unknown 
 > verification status, or to accept bits and pieces of data from a pub 
 > point with the potential that some routes will be treated as valid, even 
 > if they are invalid. To me, that is a value judgement to be made by 
 > network operators, not by developers of RP software. [...]

No, there is a bit more to it than that.

I want my network's routers and those of all other networks to be fed
with VRPs that represent all the verified and legitimate published
origin-ASN intentions of verified, legitimate IP number resource
holders.

Clearly the challenge there is in determining "verified" and
"legitimate."  In creating the rules (to be documented in
standards-track RFCs) for those determinations, I would like the input
of all SIDROPS participants to be valued, including the input of the
RPKI designers, the CA- and RP-implementers, the RIRs, and the network
operators.

To my point: if RP-implementers feel that the "bits and pieces of
data" (to use your words) should be considered to best make those
determinations, such input should be welcomed; conversely, if
RP-implementers feel that strict publication rules and accompanying
strict handling of retrieved records together create the best way to
make those determinations, we all should listen to what they have to
say.

 > Experience with X.509 cert extensions suggests that the approach I noted 
 > is preferable. Saying that older RPs can ignore objects they don't 
 > understand introduces ambiguity in RP behavior, which is precisely the 
 > concern that motivated the effort to generate 6486bis.

Ambiguity is bad in any technical endeavor where precision is needed.
And we're here discussing this now because there was ambiguity in
rfc6486 (not assigning blame -- I missed it, too).  But I don't see
how it follows that if/when ASPA (for example) is standardized, that
older RPs should be required to throw away all records retrieved from
PPs whose MFTs now cite ASPA records.

Thanks.

						Jay B.