Re: [sidr] Current document status && directionz

Christopher Morrow <morrowc.lists@gmail.com> Wed, 07 September 2016 14:42 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 CDEAF12B032 for <sidr@ietfa.amsl.com>; Wed, 7 Sep 2016 07:42:17 -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 C6WMkjctqsoE for <sidr@ietfa.amsl.com>; Wed, 7 Sep 2016 07:42:12 -0700 (PDT)
Received: from mail-qt0-x230.google.com (mail-qt0-x230.google.com [IPv6:2607:f8b0:400d:c0d::230]) (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 739BB12B0D1 for <sidr@ietf.org>; Wed, 7 Sep 2016 07:42:12 -0700 (PDT)
Received: by mail-qt0-x230.google.com with SMTP id 11so8321155qtc.0 for <sidr@ietf.org>; Wed, 07 Sep 2016 07:42:12 -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=mBgBCtLx4g3l8sM2MvkBSiMDcqHjtUJLMAs37rgfnfc=; b=GXW0vgVLva38j0PtlV9VBMBC/BcYsDzAMQ8IymAz4jlOfhvhBPC9ALoOUkRHBaekWi tFNP1ROIqqpoWcpVo8LqzktauzDeAdGs3iD7s+VgEnClmI5hHmkXjP6VxrgXEG27H1FV V2OBx1UHyfjBk1nEup5CIk3cRBIPpRyGPYLGhcenN+VaHvjoMKiVSbCdw8EwBr0Tl2Ls C00GTGuUMaYwVG6Dun/YJ5UOHezE6ymj1ssIVBZZCuD8DhK/djKafteyuFO0RVr6aVMh J78RsyHSanJ3Ghak7lLGhFw4Zc2/RiXK/x5EVkXzhzQVOhza3mZsI/B2DBQjhCsH/5kp XkgA==
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=mBgBCtLx4g3l8sM2MvkBSiMDcqHjtUJLMAs37rgfnfc=; b=UbqKI2JeuWlLGzUfxCn9LBUExDMkeloPJh82v55p187PTfON4Q42bL1rNJTsz2VxOK JODWxuvA11+wEie/AC18Ow17Aph+rsQse6Lj08xHb8TCLtI+uDGP3TW0EA4hVZRQOpqm LpYQm0YyXz037rbyoSJtcZCKtBVk79mcrYSvpbeyKhkxh2+4/UqZZ2XbLLzgjPHAKmE3 IgO7CSNUA4M0gD5rQkiI4hFWkUq529O+LSFkPZKstUECTgNzo+BeIiFgbFwQGboR62nc xFRiCC8wxk88InvI7dFRVFors/iOmpeWMfzitPdN+vs0WkPnZyISS2XpETEm3rZQ8dru +2Fw==
X-Gm-Message-State: AE9vXwPnLGgJVa6yFmY787e1P/6cnuYoA0sG7Qk0Cbia+/Hc2rU1MED4mZLc0SRIf0iivgWx1ZZLRW1cGyYwZg==
X-Received: by 10.200.55.215 with SMTP id e23mr23795323qtc.23.1473259331533; Wed, 07 Sep 2016 07:42:11 -0700 (PDT)
MIME-Version: 1.0
Sender: christopher.morrow@gmail.com
Received: by 10.140.85.116 with HTTP; Wed, 7 Sep 2016 07:42:10 -0700 (PDT)
In-Reply-To: <20160907040720.769594208DBB@minas-ithil.hactrn.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>
From: Christopher Morrow <morrowc.lists@gmail.com>
Date: Wed, 07 Sep 2016 10:42:10 -0400
X-Google-Sender-Auth: 174W8Ec-drg2PPfTkxOwXOO4I1g
Message-ID: <CAL9jLabwQQzigJF1=36dY7uWVcHSBKBmRC8DLd4pv1F1i0PZJg@mail.gmail.com>
To: Rob Austein <sra@hactrn.net>
Content-Type: multipart/alternative; boundary="001a11471b9c1e6577053bebeb93"
Archived-At: <https://mailarchive.ietf.org/arch/msg/sidr/0XI9TmJdAwKp0cTrf98zR6sWxUY>
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 14:42:18 -0000

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?


> 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
>