Re: [sidr] Current document status && directionz

Andrew de la Haye <andrewh@ripe.net> Wed, 07 September 2016 14:55 UTC

Return-Path: <andrewh@ripe.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 02EF212B018 for <sidr@ietfa.amsl.com>; Wed, 7 Sep 2016 07:55:44 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.407
X-Spam-Level:
X-Spam-Status: No, score=-3.407 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-1.508] 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 9NZIO_-CS2oA for <sidr@ietfa.amsl.com>; Wed, 7 Sep 2016 07:55:41 -0700 (PDT)
Received: from mahimahi.ripe.net (mahimahi.ripe.net [IPv6:2001:67c:2e8:11::c100:1372]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 487CB12B01A for <sidr@ietf.org>; Wed, 7 Sep 2016 07:55:41 -0700 (PDT)
Received: from nene.ripe.net ([193.0.23.10]) by mahimahi.ripe.net with esmtps (TLSv1.2:DHE-RSA-AES256-GCM-SHA384:256) (Exim 4.84) (envelope-from <andrewh@ripe.net>) id 1bheGH-0005It-OC; Wed, 07 Sep 2016 16:55:39 +0200
Received: from sslvpn.ripe.net ([193.0.20.230] helo=vpn-254.ripe.net) by nene.ripe.net with esmtps (TLSv1:AES256-SHA:256) (Exim 4.72) (envelope-from <andrewh@ripe.net>) id 1bheGH-0007Yp-Ik; Wed, 07 Sep 2016 16:55:37 +0200
Content-Type: multipart/signed; boundary="Apple-Mail=_A9B010DF-EA63-43F5-BA2B-71C9324EF1AC"; protocol="application/pkcs7-signature"; micalg=sha1
Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\))
From: Andrew de la Haye <andrewh@ripe.net>
In-Reply-To: <CAL9jLabwQQzigJF1=36dY7uWVcHSBKBmRC8DLd4pv1F1i0PZJg@mail.gmail.com>
Date: Wed, 7 Sep 2016 16:55:37 +0200
Message-Id: <BBA42462-C8AF-4C78-973B-3C475A9970D6@ripe.net>
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>
To: Christopher Morrow <morrowc.lists@gmail.com>
X-Mailer: Apple Mail (2.3124)
X-ACL-Warn: Delaying message
X-RIPE-Spam-Level: ---------
X-RIPE-Spam-Report: Spam Total Points: -9.1 points pts rule name description ---- ---------------------- ------------------------------------ -7.5 ALL_TRUSTED Passed through trusted hosts only via SMTP -1.1 RP_MATCHES_RCVD Envelope sender domain matches handover relay domain 0.0 HTML_MESSAGE BODY: HTML included in message -0.5 BAYES_05 BODY: Bayes spam probability is 1 to 5% [score: 0.0144]
X-RIPE-Signature: e27d87b2fb08ebd3914ba33c5d0e271be24b13a2b165e8158867823db13fc5e1
Archived-At: <https://mailarchive.ietf.org/arch/msg/sidr/WH01Jn1j4FODaAqVfQuTtwx1yDQ>
Cc: sidr@ietf.org
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 14:58:14 -0000

> On 07 Sep 2016, at 16:42, Christopher Morrow <morrowc.lists@gmail.com> wrote:
> 
> 
> 
> On Wed, Sep 7, 2016 at 12:07 AM, Rob Austein <sra@hactrn.net <mailto:sra@hactrn.net>> wrote:
> 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?"
> 
> 
> totally agree/understand.
>  
> > 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.
> 
> 
> yes, sorry I was trying to not point fingers at particular people/things :(
>  
> 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.
> 
> 
> ok
>  
> 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.
> 
> 
> I think it means that since there is no single root coming 'soon', 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?"
> 
> That's the part that you're referring to as KC's comment, I think?
>  
> 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.
> 
> 
> 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) 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?

Chris,

fully agree, the intent is to provide unity and transparency on how the RIRs handle their respective trust anchors at this stage

Andrew 


>  
> Which brings us back to bad technical decisions and political reasons.
> Sorry.
> 
> yup.
>  
> 
> _______________________________________________
> sidr mailing list
> sidr@ietf.org <mailto:sidr@ietf.org>
> https://www.ietf.org/mailman/listinfo/sidr <https://www.ietf.org/mailman/listinfo/sidr>
> 
> _______________________________________________
> sidr mailing list
> sidr@ietf.org
> https://www.ietf.org/mailman/listinfo/sidr