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

"Carlos M. Martinez" <carlosm3011@gmail.com> Thu, 08 September 2016 14:39 UTC

Return-Path: <carlosm3011@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 AD16A12B1A0 for <sidr@ietfa.amsl.com>; Thu, 8 Sep 2016 07:39:40 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.75
X-Spam-Level:
X-Spam-Status: No, score=-1.75 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no 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 b_l5nExErDKD for <sidr@ietfa.amsl.com>; Thu, 8 Sep 2016 07:39:39 -0700 (PDT)
Received: from mail-ua0-x22c.google.com (mail-ua0-x22c.google.com [IPv6:2607:f8b0:400c:c08::22c]) (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 9C6FC12B28C for <sidr@ietf.org>; Thu, 8 Sep 2016 07:39:39 -0700 (PDT)
Received: by mail-ua0-x22c.google.com with SMTP id b7so42114734uab.3 for <sidr@ietf.org>; Thu, 08 Sep 2016 07:39:39 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:to:subject:date:message-id:mime-version; bh=MaVaZlvFtgHcARNU9U+TOcZVG6O2GCCB2wAsm1y2y0E=; b=0zx3NGQcuQusbPwQwanl0aTk4X85dYBYPj5Vxb4DkFxS7i9DEvjRpEhIHhzvDYa+Zu alfLMQrWhYIfvEZSbh4MIaTaIKZl3L3yJvwS+RsiOgT2SnZYO3WDSQCeUOTOVG3aM9P6 Y1iQXfAJYRSyBYzL/5o58fAsJQxEwunddzznb1PG+NnqffNCqMzU6ZbyxvOPGbe34wQD UKdJeNbyhgawQuDbkMoR4cy287Xts+hLnRo6sMhl8s5Rb/WBm8BIexFIprzBleeQ8sXq 2Bwm5/P4IufdZ4XMoExon2NpEA8MSkzDgfCLORCGBedwN5mAz192g4rgpuNKCOTAvcf5 aKrw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:to:subject:date:message-id:mime-version; bh=MaVaZlvFtgHcARNU9U+TOcZVG6O2GCCB2wAsm1y2y0E=; b=HeBjji/QFPFviIfiBtv8uMoKa87bXmzYk5aeGglijmpRhCNfC7zL1tLxmDJBEQc4Id ZS7eC7DoTC6blFkh15oiyHZ5PEwvh3wga+2RV1W0QtvGnztlrh5+O9akdsiVcI565GGb Mfl4ozWz6NBfs8KAIWdE9+4y0XxYOvIT6pef7g8/VuvO1IrGW1W2XYN5x0kYcdYFo/F6 WarFeftXB9AXABuHoOY276LPhm7bGsp1ieu/659oPqgUNbq7edQKPE1IJAacOXKwagzj rcTZY81YOwNS4i4FZjog8IHcmj5ySZ+GgN27nOqxqUkGSbaXzZw338rfkbrqxzwCBGkT ZE5Q==
X-Gm-Message-State: AE9vXwPo3x1xpHYVAqrn3PvBZVfqfq+1K+hfYdNCtB/RBreZAkwtG3YbPQ1oXFRmhy2fXA==
X-Received: by 10.159.53.33 with SMTP id o30mr11908353uao.106.1473345578629; Thu, 08 Sep 2016 07:39:38 -0700 (PDT)
Received: from [200.7.87.24] ([200.7.87.24]) by smtp.gmail.com with ESMTPSA id 105sm4821884uas.27.2016.09.08.07.39.37 for <sidr@ietf.org> (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 08 Sep 2016 07:39:37 -0700 (PDT)
From: "Carlos M. Martinez" <carlosm3011@gmail.com>
To: sidr <sidr@ietf.org>
Date: Thu, 08 Sep 2016 11:39:33 -0300
Message-ID: <85DF97DE-0EFD-4002-8EDE-83C3B6CB8E8F@gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; format=flowed
X-Mailer: MailMate (1.9.5r5260)
Archived-At: <https://mailarchive.ietf.org/arch/msg/sidr/t5jM0e3kNOyeLuaVJ672Xiy1QOU>
Subject: [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: Thu, 08 Sep 2016 14:39:41 -0000

Hello all

I'm going to provide the best answers I can to the questions that have 
been made in the mailing list. I'm spinning a new thread so we don't 
hijack the WG directionz one.

Intentionally I'm **not** going to answer any emails that invoke 
politics. Those who feel they need answers from that side of things know 
who you can refer to.

First of all, thanks for the feedback. To be honest, I am quite 
surprised that it took this long. This document was first presented in 
Buenos Aires, which was almost 5 months ago.

This decision to move to 0/0 is a solution born more of necessity than 
desire for the following reasons:

a. There exist political obstacles to a global trust anchor of 0/0 that 
are, at the moment and for the foreseeable future, insurmountable. This 
is regrettable, but also a reality and should not be denied.

b. Due to the above, there is an inconsistent model of trust anchors 
published by the RIRs. This solution does fix this problem, making the 
overall RPKI at least consistent.

c. The RPKI does not have a graceful mechanism for which to handle "ERX 
space" (networks managed by one RIR placed under the IANA allocation for 
another RIR). As inter-RIR transfers become more common place, the ERX 
space will become more fluid and a source of conflict. Management of ERX 
space is all the more difficult to manage under the RPKI as there is no 
make-before-break mechanism built-in to the RPKI nor does the RFC 6492 
protocol provide a mechanism for parent-to-child messaging with which to 
enable a make-before-break mechanism.

d. Given the fluidity of the ERX space mentioned above and the current 
validation algorithm, there is foreseeable fragility of the system that 
is solved by this solution. The IETF is working on changing the 
validation algorithm, but this change has been in progress for years and 
is still dependent on a timetable for publication of new ROAs by all CAs 
and installation of new software by all RPs.

e. Given that there is no global trust anchor and the RIRs each operate 
offline Trust Anchors for security, having just the resources actually 
assigned or allocated by the respective RIR, would require a trip to the 
datacenter for each inter-RIR transfer which will incur delays and 
result in resources showing up at two RIRs simultaneously, or none of 
the RIRs for some time as TA certificates are updated independently.

Thanks to all!

-Carlos