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

Danny McPherson <> Tue, 22 November 2011 03:10 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 839A621F84B4 for <>; Mon, 21 Nov 2011 19:10:06 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -102.469
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 ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id GbfXnprRCwzf for <>; Mon, 21 Nov 2011 19:10:05 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id 0974F21F84B0 for <>; Mon, 21 Nov 2011 19:10:03 -0800 (PST)
Received: by (Postfix, from userid 0) id C3071268063; Mon, 21 Nov 2011 20:10:02 -0700 (MST)
Received: from dul1dmcphers-m1.home ( []) (authenticated-user smtp) (TLSv1/SSLv3 AES128-SHA 128/128) by with SMTP; Mon, 21 Nov 2011 20:10:02 -0700 (MST) (envelope-from
X-Avenger: version=0.7.8;; client-ip=; 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 <>
In-Reply-To: <p06240801cae79ccfa546@[]>
Date: Mon, 21 Nov 2011 22:09:35 -0500
Content-Transfer-Encoding: quoted-printable
Message-Id: <>
References: <> <p06240801cae79ccfa546@[]>
To: Stephen Kent <>
X-Mailer: Apple Mail (2.1084)
Subject: Re: [sidr] Origin Ops, TALs and Local TAs
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Secure Interdomain Routing <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-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...