Re: [sidr] Current document status && directionz

Christopher Morrow <morrowc.lists@gmail.com> Wed, 07 September 2016 16:04 UTC

Return-Path: <christopher.morrow@gmail.com>
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 E733E12B397 for <sidr@ietfa.amsl.com>; Wed, 7 Sep 2016 09:04:25 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.699
X-Spam-Level:
X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
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 1XAQCUjJTbaU for <sidr@ietfa.amsl.com>; Wed, 7 Sep 2016 09:04:23 -0700 (PDT)
Received: from mail-qt0-x22d.google.com (mail-qt0-x22d.google.com [IPv6:2607:f8b0:400d:c0d::22d]) (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 B46B112B384 for <sidr@ietf.org>; Wed, 7 Sep 2016 09:04:22 -0700 (PDT)
Received: by mail-qt0-x22d.google.com with SMTP id 11so9659894qtc.0 for <sidr@ietf.org>; Wed, 07 Sep 2016 09:04:22 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=ZNj3QyIR0pfhYMU/WpGEJg4Ug71pqLuWR0+fdGoFDuM=; b=wLZS1y1sUjFiOcDsx6DtRs2YxZKla8c0hT5TH0rNG++rHiPpx/Ym8QkR7qZt0boXyc 53W2Oit8Dvn9isQAc8SDoxN6+SHqkQqSHPZHewmhu02GwzO8vC3oifNoLmcS7Ut3bJPB ZxJggznu7iLCWMdm5oWPM64z5a/78aVotJ1ZrNQjjsb+xQknHgpH/CNB/eknnICu6Wdz rq7thxBT01oPVtq9lZplpybNrFS1QPPHfLPyqdtwl3VCNSIlg5oDMTfMaEe7f6vyjImv eD9/3BYo/RLp+I1kgqfZCJzR71/5d0uGWfuaTStpPapkDfAGmf+DbgzEvHn/fMWvf/Ig AqYw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=ZNj3QyIR0pfhYMU/WpGEJg4Ug71pqLuWR0+fdGoFDuM=; b=DO+yVwl1CeLHsiEC3JAfxRagST8K25ne/2iK65VYdXslVnFs3z08fzBRFPPVhZatvh w4f8WeIl4ZHMgPIVDs62wIATxaHKOP07H7dKdZvxYBAbYwGGKjgU45ci4cBKh8VPm3/n MkIDdwjU9ClHB7/aSm0fP0JvHlgHuBuYTm1nCEhtXk80Hfu6XTU+2GTOsrfU0GBH+hAK WkabTTTfWbMw0sf5wOiCtbWejocV8R6OENVAbvOK13wlOdpUjjSYNf858Np+jDAZBP/8 GGVDV3OSCJtUsLipV8gaxnRM8naCpl7mvsVHFUt9k1zqmWMGbYCJkb/Yf4plfTgP/Wiz r7UA==
X-Gm-Message-State: AE9vXwPhliBgGORjPfz3Hl67U5OFkgbIBfGE1KhuHkTqZdTOteaDpqOkmKRCy1woYdckTpi02qVcp7tselhn4A==
X-Received: by 10.200.38.241 with SMTP id 46mr19622208qtp.135.1473264261728; Wed, 07 Sep 2016 09:04:21 -0700 (PDT)
MIME-Version: 1.0
Sender: christopher.morrow@gmail.com
Received: by 10.140.85.116 with HTTP; Wed, 7 Sep 2016 09:04:21 -0700 (PDT)
In-Reply-To: <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> <BBA42462-C8AF-4C78-973B-3C475A9970D6@ripe.net>
From: Christopher Morrow <morrowc.lists@gmail.com>
Date: Wed, 7 Sep 2016 12:04:21 -0400
X-Google-Sender-Auth: AN9k0tXIh74Q2lDcZ6kYUqRxDJ0
Message-ID: <CAL9jLaZ5tPtg0D1gWvURv=CXRdzWud5C+FWv4WUHeW6v2BLzvw@mail.gmail.com>
To: Andrew de la Haye <andrewh@ripe.net>
Content-Type: multipart/alternative; boundary=001a113feba2fb540c053bed1040
Archived-At: <https://mailarchive.ietf.org/arch/msg/sidr/zWPOAouS_OxMiwGa6C5bWVSBCLo>
Cc: "sidr@ietf.org" <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 16:04:26 -0000

On Wed, Sep 7, 2016 at 10:55 AM, Andrew de la Haye <andrewh@ripe.net> wrote:

>
> 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> 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
>
>
ok, I'm glad I ddin't mis-interpret... now I'll wait on stephen/rob to pipe
back up :)
Maybe this doesn't go through a routing-area group as a document, maybe
this should really be in the ops-area group that comes out of SIDR?

Or maybe there's pushback that says: "Hey, I hear what you all in the rir
want, but it's not cool, please please let's dive back into the politics
stream and see how we get movement on what we all (probably?) want: a
single root for this system."

i'm just fishing for direction.


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