Re: [sidr] Current document status && directionz

"Roque Gagliano (rogaglia)" <> Wed, 07 September 2016 19:56 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id D537A12B1AB for <>; Wed, 7 Sep 2016 12:56:05 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -16.028
X-Spam-Status: No, score=-16.028 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.508, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (1024-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id zrm0hukFPTq4 for <>; Wed, 7 Sep 2016 12:56:03 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 435E212B358 for <>; Wed, 7 Sep 2016 12:56:03 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple;;; l=15886; q=dns/txt; s=iport; t=1473278163; x=1474487763; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=1akQg/zFiItq7P9n0Sp8SEpU1OpZ2YF2vWaBq8WEbsw=; b=gxVQ7RHJ1vDjYQVm0n+PuvR2h0zw/x9biSFKovX3x/MRxaovi+zU5EtI tK0N86CjJYv+rY6/qsiHWp8hIxkzynBvBkWfnmInsSqXNYRqC3223gC9C wqL/Bp63QexycnuWO02tlkH5gNebQZJhJDnbSubx/jWAbO1ivVked1X3y k=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-AV: E=Sophos;i="5.30,296,1470700800"; d="scan'208,217";a="320569662"
Received: from ([]) by with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 07 Sep 2016 19:56:02 +0000
Received: from ( []) by (8.14.5/8.14.5) with ESMTP id u87Ju18X021490 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Wed, 7 Sep 2016 19:56:02 GMT
Received: from ( by ( with Microsoft SMTP Server (TLS) id 15.0.1210.3; Wed, 7 Sep 2016 15:56:01 -0400
Received: from ([]) by ([]) with mapi id 15.00.1210.000; Wed, 7 Sep 2016 15:56:01 -0400
From: "Roque Gagliano (rogaglia)" <>
To: Andrew de la Haye <>, Christopher Morrow <>
Thread-Topic: [sidr] Current document status && directionz
Thread-Index: AQHSCUHbwDSafJV2ikaIhhAEiDU42Q==
Date: Wed, 07 Sep 2016 19:56:01 +0000
Message-ID: <>
References: <> <> <> <> <> <> <> <> <> <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-US
user-agent: Microsoft-MacOutlook/
x-ms-exchange-messagesentrepresentingtype: 1
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: []
Content-Type: multipart/alternative; boundary="_000_D3F638FF57F9Crogagliaciscocom_"
MIME-Version: 1.0
Archived-At: <>
Cc: "" <>
Subject: Re: [sidr] Current document status && directionz
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Secure Interdomain Routing <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 07 Sep 2016 19:56:06 -0000

Hi Andrew,

Taking into consideration your call for transparency, do you think the RIRs could add a section on the document where it is clearly stated what are the roadblocks to have a single root? I believe the document describes the problem and one technical feasible solution but not the full solution space. We need to understand that this is a decision from which we will most probably not turn back (we are basically deciding that there will never be a single root).

Finally, I can read in your email that you mention that this is a request from “the RIR folks”. Are you referring to RIR staff? The boards? The communities via a bottom-up process?

Best regards,

Roque Gagliano
Tail-f Solutions Architect Southern Europe
+41 76 449 8867

From: sidr <<>> on behalf of Andrew de la Haye <<>>
Date: Wednesday 7 September 2016 at 16:55
To: Christopher Morrow <<>>
Cc: "<>" <<>>
Subject: Re: [sidr] Current document status && directionz

On 07 Sep 2016, at 16:42, Christopher Morrow <<>> wrote:

On Wed, Sep 7, 2016 at 12:07 AM, Rob Austein <<>> 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.


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?


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


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


sidr mailing list<>

sidr mailing list<>