IETF Logo Mail Archive

Re: [sidr] On 0/0 at the 5 TAs - Some comments on the motivations

Andy Newton <andy@arin.net> Fri, 09 September 2016 13:29 UTC

Return-Path: <andy@arin.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 16D6A12B293 for <sidr@ietfa.amsl.com>; Fri, 9 Sep 2016 06:29:32 -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 EyEvzGZC57lY for <sidr@ietfa.amsl.com>; Fri, 9 Sep 2016 06:29:30 -0700 (PDT)
Received: from smtp2.arin.net (smtp2.arin.net [IPv6:2001:500:110:201::32]) by ietfa.amsl.com (Postfix) with ESMTP id 1768A12B270 for <sidr@ietf.org>; Fri, 9 Sep 2016 06:29:30 -0700 (PDT)
Received: by smtp2.arin.net (Postfix, from userid 323) id A8FE721367E; Fri, 9 Sep 2016 09:29:29 -0400 (EDT)
Received: from ashedge01.corp.arin.net (ashedge01.corp.arin.net [199.43.0.122]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp2.arin.net (Postfix) with ESMTP id D5DDD21367A; Fri, 9 Sep 2016 09:29:28 -0400 (EDT)
Received: from CAS02ASH.corp.arin.net (10.4.30.63) by ashedge01.corp.arin.net (199.43.0.122) with Microsoft SMTP Server (TLS) id 15.0.847.32; Fri, 9 Sep 2016 09:29:12 -0400
Received: from CAS01ASH.corp.arin.net (10.4.30.62) by CAS02ASH.corp.arin.net (10.4.30.63) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Fri, 9 Sep 2016 09:29:22 -0400
Received: from CAS01ASH.corp.arin.net ([fe80::4803:bd5b:dc93:20f6]) by CAS01ASH.corp.arin.net ([fe80::4803:bd5b:dc93:20f6%18]) with mapi id 15.00.1210.000; Fri, 9 Sep 2016 09:28:33 -0400
From: Andy Newton <andy@arin.net>
To: Sandra Murphy <sandy@tislabs.com>
Thread-Topic: [sidr] On 0/0 at the 5 TAs - Some comments on the motivations
Thread-Index: AQHSCd7iz9q7OVqIXEG9IZE3V/Sx3KBv/P+AgAAF2YCAAHrMgIAA7iIA
Date: Fri, 09 Sep 2016 13:28:32 +0000
Message-ID: <D4EFFBFB-452C-48B9-9CAF-7EEEEEDEB2E4@arin.net>
References: <85DF97DE-0EFD-4002-8EDE-83C3B6CB8E8F@gmail.com> <20160908153701.F0CA0420E4D8@minas-ithil.hactrn.net> <1839617E-8453-4A26-9A4A-7428EE887CF5@gmail.com> <D0405488-0530-4E44-B408-2C1E833B1722@tislabs.com>
In-Reply-To: <D0405488-0530-4E44-B408-2C1E833B1722@tislabs.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-ms-exchange-messagesentrepresentingtype: 1
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [10.1.26.79]
Content-Type: multipart/alternative; boundary="_000_D4EFFBFB452C48B99CAF7EEEEEDEB2E4arinnet_"
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/sidr/7ooeO0Ge9Qc5M2_YL2RYPI7rNuI>
Cc: Rob Austein <sra@hactrn.net>, sidr wg list <sidr@ietf.org>
Subject: Re: [sidr] On 0/0 at the 5 TAs - Some comments on the motivations
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: Fri, 09 Sep 2016 13:29:32 -0000

On Sep 8, 2016, at 7:17 PM, Sandra Murphy <sandy@tislabs.com<mailto:sandy@tislabs.com>> wrote:

speaking as a regular ol’ member:

On Sep 8, 2016, at 11:57 AM, Carlos M. Martinez <carlosm3011@gmail.com<mailto:carlosm3011@gmail.com>> wrote:

Hi Rob,

I’ll let each RIR answer for themselves. In our case (LACNIC), we don’t support up/down. We’ve had a very rough implementation of a ‘parent’ CA for a while, but since there is essentially no demand for it from our members, the project always gets down-prioritized.


For ARIN, we have code for both sides of the relationship tested against the Dragon software and some of the other RIRs. We allow for delegated CAs today in production, but the vast majority of network operators do not opt for it.

If the GTA was to gain any traction, we’d commit resources accordingly in order to support it from the ‘child’ side.

In short: it’s not the availability of up-down what has stalled the GTA.


This is the salient point.

If you had a client side implementation, then if a GTA did get established, you would be able to interact with the GTA for certification of your resources -- immediately.

Additionally, each RIR must establish and actively maintain a parent-child relationship with each other RIR.

-andy

v2.23.0 | Report a Bug | By Email