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
- [sidr] Origin Ops, TALs and Local TAs Danny McPherson
- Re: [sidr] Origin Ops, TALs and Local TAs Rob Austein
- Re: [sidr] Origin Ops, TALs and Local TAs Danny McPherson
- Re: [sidr] Origin Ops, TALs and Local TAs Christopher Morrow
- Re: [sidr] Origin Ops, TALs and Local TAs Danny McPherson
- Re: [sidr] Origin Ops, TALs and Local TAs Christopher Morrow
- Re: [sidr] Origin Ops, TALs and Local TAs Stephen Kent
- Re: [sidr] Origin Ops, TALs and Local TAs Danny McPherson
- Re: [sidr] Origin Ops, TALs and Local TAs Stephen Kent
- Re: [sidr] Origin Ops, TALs and Local TAs Christopher Morrow
- Re: [sidr] Origin Ops, TALs and Local TAs Stephen Kent
- Re: [sidr] Origin Ops, TALs and Local TAs Christopher Morrow
- Re: [sidr] Origin Ops, TALs and Local TAs Danny McPherson
- Re: [sidr] Origin Ops, TALs and Local TAs Stephen Kent