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

Danny McPherson <danny@tcb.net> Tue, 22 November 2011 03:10 UTC

Return-Path: <danny@tcb.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 839A621F84B4 for <sidr@ietfa.amsl.com>; Mon, 21 Nov 2011 19:10:06 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.469
X-Spam-Level:
X-Spam-Status: No, score=-102.469 tagged_above=-999 required=5 tests=[AWL=0.130, BAYES_00=-2.599, 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 GbfXnprRCwzf for <sidr@ietfa.amsl.com>; Mon, 21 Nov 2011 19:10:05 -0800 (PST)
Received: from dog.tcb.net (dog.tcb.net [64.78.150.133]) by ietfa.amsl.com (Postfix) with ESMTP id 0974F21F84B0 for <sidr@ietf.org>; Mon, 21 Nov 2011 19:10:03 -0800 (PST)
Received: by dog.tcb.net (Postfix, from userid 0) id C3071268063; Mon, 21 Nov 2011 20:10:02 -0700 (MST)
Received: from dul1dmcphers-m1.home (pool-98-118-240-226.clppva.fios.verizon.net [98.118.240.226]) (authenticated-user smtp) (TLSv1/SSLv3 AES128-SHA 128/128) by dog.tcb.net with SMTP; Mon, 21 Nov 2011 20:10:02 -0700 (MST) (envelope-from danny@tcb.net)
X-Avenger: version=0.7.8; receiver=dog.tcb.net; client-ip=98.118.240.226; client-port=64554; syn-fingerprint=65535:48:1:64:M1460,N,W3,N,N,T,S MacOS 10.4.8; data-bytes=0
Mime-Version: 1.0 (Apple Message framework v1084)
Content-Type: text/plain; charset=us-ascii
From: Danny McPherson <danny@tcb.net>
In-Reply-To: <p06240801cae79ccfa546@[172.20.1.65]>
Date: Mon, 21 Nov 2011 22:09:35 -0500
Content-Transfer-Encoding: quoted-printable
Message-Id: <72E12AD7-CFAF-4FBD-8A98-F93038F7E8FB@tcb.net>
References: <80D9C12A-354E-4A90-8E97-946519E499D0@tcb.net> <p06240801cae79ccfa546@[172.20.1.65]>
To: Stephen Kent <kent@bbn.com>
X-Mailer: Apple Mail (2.1084)
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, 22 Nov 2011 03:10:07 -0000

On Nov 16, 2011, at 2:50 AM, Stephen Kent wrote:
> 
>> Here's my primary question.  If I wanted to form a 'federation' of sorts for
>> resiliency would I have to use additional TALs in conjunction with my
>> LTA and paracertificate hierarchy?  If so, can an RP include some sort of
>> filter to constrain what a TA can assert as within their resource holdings?
> 
> not sure what a federation is, but, yes, an RP can constrain what a TA
> is allowed to assert, via a constraints file.

Ahh, this makes good sense.

>> That is, because for LTA to work every relying party in the transaction
>> path (i.e., source and destination networks, as well as intermediate RPs)
>> would need to override the putative [global] TA RPKI for every other
>> operators resources and generate a paracertificate hierarchy therein,
>> is that right?
> 
> 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?


>> And if that's the case, wouldn't it be simpler for RPs to be able to
>> associate resources with each trust anchor rather than trusting them to
>> convey to the RP what resources they are authoritative for?
> 
> LTA management allows this, but it becomes very complex to do well if there are too many data items to manage.

Yeah, that's what I'm mulling...

Thanks, 

-danny