Re: [sidr] Origin Ops, TALs and Local TAs

Stephen Kent <kent@bbn.com> Tue, 29 November 2011 16:27 UTC

Return-Path: <kent@bbn.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 D81A821F8C47 for <sidr@ietfa.amsl.com>; Tue, 29 Nov 2011 08:27:19 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -106.066
X-Spam-Level:
X-Spam-Status: No, score=-106.066 tagged_above=-999 required=5 tests=[AWL=0.533, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UR6aX8Ddw-yS for <sidr@ietfa.amsl.com>; Tue, 29 Nov 2011 08:27:19 -0800 (PST)
Received: from smtp.bbn.com (smtp.bbn.com [128.33.0.80]) by ietfa.amsl.com (Postfix) with ESMTP id 620E021F8C3A for <sidr@ietf.org>; Tue, 29 Nov 2011 08:27:19 -0800 (PST)
Received: from dhcp89-089-006.bbn.com ([128.89.89.6]:49165) by smtp.bbn.com with esmtp (Exim 4.74 (FreeBSD)) (envelope-from <kent@bbn.com>) id 1RVQWb-000KHW-OD; Tue, 29 Nov 2011 11:27:17 -0500
Mime-Version: 1.0
Message-Id: <p06240807cafab43091fd@[128.89.89.6]>
In-Reply-To: <60D433F0-D9E5-428E-8A79-47EE5E1CECFE@tcb.net>
References: <80D9C12A-354E-4A90-8E97-946519E499D0@tcb.net> <p06240801cae79ccfa546@172.20.1.65> <72E12AD7-CFAF-4FBD-8A98-F93038F7E8FB@tcb.net> <p06240803caf95d6f5166@128.89.89.6> <CAL9jLaZ7ccqD6gkyy1Rd2gdqwf3=C28D77Y1YSb2eMRGn8OGoQ@mail.gmail.com> <p06240801cafaa8c5e519@128.89.89.6> <CAL9jLabQgB-Fd1LQV0J0q2zqGYjodVAyOHTS7rh6hosigqiiiw@mail.gmail.com> <60D433F0-D9E5-428E-8A79-47EE5E1CECFE@tcb.net>
Date: Tue, 29 Nov 2011 11:18:06 -0500
To: Danny McPherson <danny@tcb.net>
From: Stephen Kent <kent@bbn.com>
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
Cc: sidr@ietf.org
Subject: Re: [sidr] Origin Ops, TALs and Local TAs
X-BeenThere: sidr@ietf.org
X-Mailman-Version: 2.1.12
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: <http://www.ietf.org/mail-archive/web/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: Tue, 29 Nov 2011 16:27:20 -0000

At 10:49 AM -0500 11/29/11, Danny McPherson wrote:
>On Nov 29, 2011, at 10:36 AM, Christopher Morrow wrote:
>
>>  I think this last bit gets at danny's concern (after the 'but every
>>  asn in the path has to agree that the root is wrong' bit)... lots more
>>  complexity here is not helpful :(
>
>Yes.
>
>-danny

The characterization above is not quite right, but close :-).

The fundamental notion of LTA is that each RP is the "root." That's a 
good model
for PKIs in general, not just the RPKI, as it allows an RP to accept 
putative roots and impose constraints on them.  (This is the opposite 
of the browser model.) But, as in most of life, TANSTAAFL. The 3779 
extensions that help
ensure that a misbehaving CA is limited in the extent of the damage 
it can inflict on the rest of the RPKI also makes it more complex to 
use the generic LTA model.

It is accurate  to say then when an RP wants to adopt a different view of the
RPKI then there is more work involved. Hierarchies are often adopted because
they make it easier to organize and to distribute a workload. So, 
there is a tradeoff, intrinsically, when an RP wants to pick and 
choose data from a hierarchy.  If a set of ASes want to let some 
third party do all of this for them, then they could use the LTA 
mechanisms to do that, in a trivial fashion. But, that approach give 
up all local control, and so it has its own downside.

Steve