Re: [sidr] Current document status && directionz

Rob Austein <sra@hactrn.net> Wed, 07 September 2016 04:09 UTC

Return-Path: <sra@hactrn.net>
X-Original-To: sidr@ietfa.amsl.com
Delivered-To: sidr@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E61D012B2ED for <sidr@ietfa.amsl.com>; Tue, 6 Sep 2016 21:09:24 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.409
X-Spam-Level:
X-Spam-Status: No, score=-3.409 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-1.508, SPF_PASS=-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 Edujr-oLaSXb for <sidr@ietfa.amsl.com>; Tue, 6 Sep 2016 21:09:23 -0700 (PDT)
Received: from adrilankha.hactrn.net (adrilankha.hactrn.net [147.28.0.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9F87D127078 for <sidr@ietf.org>; Tue, 6 Sep 2016 21:09:23 -0700 (PDT)
Received: from minas-ithil.hactrn.net (c-73-47-197-23.hsd1.ma.comcast.net [73.47.197.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "nargothrond.hactrn.net", Issuer "Grunchweather Associates" (not verified)) by adrilankha.hactrn.net (Postfix) with ESMTPS id 0ED4B39818 for <sidr@ietf.org>; Wed, 7 Sep 2016 04:09:23 +0000 (UTC)
Received: from minas-ithil.hactrn.net (localhost [IPv6:::1]) by minas-ithil.hactrn.net (Postfix) with ESMTP id 769594208DBB for <sidr@ietf.org>; Wed, 7 Sep 2016 00:07:20 -0400 (EDT)
Date: Wed, 07 Sep 2016 00:07:20 -0400
From: Rob Austein <sra@hactrn.net>
To: sidr@ietf.org
In-Reply-To: <CAL9jLaYLJ2_1Dj9BtpQBa+Ta+BrGdvNpHHfFgrRxQ6SVo-6RXw@mail.gmail.com>
References: <yj9ooa46aumt.wl%morrowc@ops-netman.net> <AAE3F119-98A3-4618-BBFB-76F921316BD1@gmail.com> <349cb6ac-f4fe-29e5-b01f-3223b14e47de@gmail.com> <m2shteszs3.wl-randy@psg.com> <0a66024b-5cae-1abb-dc53-b11c1e35cdeb@bbn.com> <20160906220000.F1005420823A@minas-ithil.hactrn.net> <CAL9jLaYLJ2_1Dj9BtpQBa+Ta+BrGdvNpHHfFgrRxQ6SVo-6RXw@mail.gmail.com>
User-Agent: Wanderlust/2.15.5 (Almost Unreal) Emacs/22.3 Mule/5.0 (SAKAKI)
MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka")
Content-Type: text/plain; charset=US-ASCII
Message-Id: <20160907040720.769594208DBB@minas-ithil.hactrn.net>
Archived-At: <https://mailarchive.ietf.org/arch/msg/sidr/JvPbNkJJXcImR3822SP8mVeJstY>
Subject: Re: [sidr] Current document status && directionz
X-BeenThere: sidr@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Secure Interdomain Routing <sidr.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/sidr>, <mailto:sidr-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/sidr/>
List-Post: <mailto:sidr@ietf.org>
List-Help: <mailto:sidr-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/sidr>, <mailto:sidr-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 07 Sep 2016 04:09:25 -0000

At Tue, 6 Sep 2016 22:48:07 -0400, Christopher Morrow wrote:
> 
> (note, I do not care for this message about politics)

Understood, with the caveat that since it's the politics which are
pushing the wrong technical solution here, any technical discussion
will loop back to politics as soon as one asks "why?"

> we're here because, I think, from the top down to the RIR there isn't a
> hierarchy being created, right? the RIR folk are saying: "Ok, you all want
> this thing, but upstairs hasn't created the root, so we're going to do the
> best we can with making a root each that allows us to xfer between RIRs.
> This is how it's being done, so you have some docs about the mechanics
> involved and can build/guide from there"
> 
> is that not the case? (again, I don't care about the politics)

I'm ignoring "upstairs", because that is also political.

Stripped of the politics, we're having this conversation because the
RIRs are proposing to operate five roots instead of one, with each
root allowed to claim ownership over the known universe, because
actually coordinating with each other is Too Hard.  Or maybe it's more
than five, some of the RIRs have extra roots just for fun, but let's
take it as given for now that they'll collapse back down to five.

The problem with multiple global RPKI roots, as KC Claffy put it
rather neatly many years ago, is that it pushes responsibility for
fixing RIR coordination mistakes (which the RIRs apparently believe
are a serious issue, as evidenced by the draft under discussion) onto
the relying parties rather than forcing the RIRs to fix those issues
on the CA side.  This is technically broken.

Generating a single RPKI root is not hard.  It can be done by a cron
job.  I ran one for years, for experimental purposes, entirely from
data already available to the RIRs.  The only real issue is which
database to believe when they disagree -- which is exactly the problem
the RIRs are trying to push onto the RPs with this document.

Which brings us back to bad technical decisions and political reasons.
Sorry.