Re: [sidr] Current document status && directionz

Rob Austein <sra@hactrn.net> Wed, 07 September 2016 16:34 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 01D8F12B3EF for <sidr@ietfa.amsl.com>; Wed, 7 Sep 2016 09:34:11 -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 kx8Egkz2Glzt for <sidr@ietfa.amsl.com>; Wed, 7 Sep 2016 09:34:09 -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 9362112B3B7 for <sidr@ietf.org>; Wed, 7 Sep 2016 09:34:09 -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 6336B3983B for <sidr@ietf.org>; Wed, 7 Sep 2016 16:34:08 +0000 (UTC)
Received: from minas-ithil.hactrn.net (localhost [IPv6:::1]) by minas-ithil.hactrn.net (Postfix) with ESMTP id F0AE2420ADDD for <sidr@ietf.org>; Wed, 7 Sep 2016 12:32:02 -0400 (EDT)
Date: Wed, 07 Sep 2016 12:32:02 -0400
From: Rob Austein <sra@hactrn.net>
To: sidr@ietf.org
In-Reply-To: <CAL9jLabwQQzigJF1=36dY7uWVcHSBKBmRC8DLd4pv1F1i0PZJg@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> <20160907040720.769594208DBB@minas-ithil.hactrn.net> <CAL9jLabwQQzigJF1=36dY7uWVcHSBKBmRC8DLd4pv1F1i0PZJg@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: <20160907163202.F0AE2420ADDD@minas-ithil.hactrn.net>
Archived-At: <https://mailarchive.ietf.org/arch/msg/sidr/-Xc3VKhpWcFE9TVCM0LQ9hA47g8>
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 16:34:11 -0000

At Wed, 7 Sep 2016 10:42:10 -0400, Christopher Morrow wrote:
...
> I think it means that since there is no single root coming 'soon',

Because they have chosen to neither create one nor work out their
issues with the obvious external candidate.  Politics.

> the RIR's are taking a step to move forward with rpki despite the
> 'no single root' existing. Ideally they would have a method to keep
> from being out of sync in their processing of
> requests/changes. Ideally that process would be outlined in the
> document here so we'd be able to say: "Ok, as the rpki lives on, how
> does X and Y and Z get done? what happens at X step 3 when Carlos
> decides to take a very long lunch? how does the process move along?
> what checks/balances are there?"

So they're proposing a half-assed alternative instead of doing what
they should be doing and promised us they would be doing.  Politics.

> That's the part that you're referring to as KC's comment, I think?

No, KC's comment was the observation that this is a cost transfer and
a technically bad one: it's the RIRs pushing problems onto RPs instead
of solving those problems, and technically bad because the RPs have no
sane grounds for deciding which RIR to believe when RIRs disagree.

> I don't disagree that running a CA is 'simple'... I think though
> that if the RIRs are in a position where there won't be a single
> root above them 'for a while' (it's been ~10 yrs at this point)

They could have a single root next week if they wanted one badly
enough.  (Lack of) action speaks louder than words.  Politics.

Well, unless the current generation of RIR CA implementations don't
support the client side of the provisioning ("up-down") protocol,
which would be interesting in view of their long-standing promise to
move towards a single root.  I have no data on this other than that
it's been at least five years since the last time I participated in an
up-down interoperability test with RIR CA software in the client role;
I have no idea whether the RIRs have tested this since that time.

> but they feel they need to move forward with something, is this
> direction acceptable? is it better to document that decision and
> it's gotchas than to not move forward at all? or to 'continue
> waiting for the single root' to arrive?

Each RIR separately claiming ownership of 0-4294967295,0.0.0.0/0,::0/0
is not progress towards anywhere we want to go.