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

Stephen Kent <kent@bbn.com> Mon, 28 November 2011 22:13 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 C9DAA11E8125 for <sidr@ietfa.amsl.com>; Mon, 28 Nov 2011 14:13:13 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -104.999
X-Spam-Level:
X-Spam-Status: No, score=-104.999 tagged_above=-999 required=5 tests=[AWL=1.000, BAYES_00=-2.599, J_CHICKENPOX_22=0.6, 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 WXz-xW1KPi8h for <sidr@ietfa.amsl.com>; Mon, 28 Nov 2011 14:13:13 -0800 (PST)
Received: from smtp.bbn.com (smtp.bbn.com [128.33.0.80]) by ietfa.amsl.com (Postfix) with ESMTP id 510FA11E80A6 for <sidr@ietf.org>; Mon, 28 Nov 2011 14:13:13 -0800 (PST)
Received: from dhcp89-089-006.bbn.com ([128.89.89.6]:49201) by smtp.bbn.com with esmtp (Exim 4.74 (FreeBSD)) (envelope-from <kent@bbn.com>) id 1RV9Ro-0009w5-Ey; Mon, 28 Nov 2011 17:13:12 -0500
Mime-Version: 1.0
Message-Id: <p06240803caf95d6f5166@[128.89.89.6]>
In-Reply-To: <72E12AD7-CFAF-4FBD-8A98-F93038F7E8FB@tcb.net>
References: <80D9C12A-354E-4A90-8E97-946519E499D0@tcb.net> <p06240801cae79ccfa546@[172.20.1.65]> <72E12AD7-CFAF-4FBD-8A98-F93038F7E8FB@tcb.net>
Date: Mon, 28 Nov 2011 17:13:10 -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: Mon, 28 Nov 2011 22:13:13 -0000

At 10:09 PM -0500 11/21/11, Danny McPherson wrote:
>...
>  > I don't understand all of the words above.
>
>Apologies for the loose terminology here..  Try this..
>
>AS1 --- ISP1 (AS2) --- ISP2 (AS3) --- AS4
>
>In the case of LTA if these four parties wish to transact their 
>constraints files
>(or shared "non-putative" RPKI TAs) must be familiar and synchronized with
>each other via some out of band mechanism - i.e., they either have to:
>
>1) synchronize LTA contents across the set
>2) share a common non-putative TA that magically does this
>
>and in doing so, they likely would want to constrain what a TA is allowed to
>assert,  via a constraints file, as noted above?
>
>That is, LTA for the local AS doesn't fix the multi-AS/multi-administrator/RP
>issue, and so some synchronization or shared non-putative TA needs to be
>developed in they desire autonomy outside of the putative set. 
>
>Is that correct?

The original model for an LTA was, as the name suggests, local, hence 
just one AS.  However, it is easy to extend that model to encompass a 
set of AS'es under the same admin control. In that case, the set of 
ASes all agree to accept the
RPKI "view" managed by some entity in control (relative to the set of ASes).

In your example are all of the ASes independent? You say that they 
want to "transact their constraints file" but you didn't say why, nor 
what the relationships might be among the constraints file for each 
AS.

The LTA constraints, as currently defined, are expressed via a set of 
local processing flags, tags, and pointers (via SKIs) to extant certs 
(sections 3.2-3.4). All of these can be shared, but that doesn't say 
what each AS would do if the values of the flags or tags differ. 
Since I'm not sure what the trust model is here, I don't know if this 
is a problem. Also, if the blocks subsection has conflicting 
directions it's not clear what each AS should do.  (A union of the 
constraints would work cleanly, but only if the affected subtrees are 
disjoint. Other attempts at forming a union of constraints could 
break, depending on the details.)

Modulo the issue of constraint conflicts, each AS can maintain its 
own LTA, and perform the re-parenting and "perforation" as directed 
by the blocks subsection of the constraints.

Does that answer your question?

Steve