[sidr] Origin Ops, TALs and Local TAs

Danny McPherson <danny@tcb.net> Mon, 14 November 2011 21:38 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 34DC821F8D12 for <sidr@ietfa.amsl.com>; Mon, 14 Nov 2011 13:38:49 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.576
X-Spam-Level:
X-Spam-Status: No, score=-102.576 tagged_above=-999 required=5 tests=[AWL=0.023, 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 nwQdZHLDypq0 for <sidr@ietfa.amsl.com>; Mon, 14 Nov 2011 13:38:48 -0800 (PST)
Received: from dog.tcb.net (dog.tcb.net [64.78.150.133]) by ietfa.amsl.com (Postfix) with ESMTP id E288421F8D4A for <sidr@ietf.org>; Mon, 14 Nov 2011 13:38:47 -0800 (PST)
Received: by dog.tcb.net (Postfix, from userid 0) id E95FB268081; Mon, 14 Nov 2011 14:38:44 -0700 (MST)
Received: from [172.16.6.19] (122.147.35.3 [122.147.35.3]) (authenticated-user smtp) (TLSv1/SSLv3 AES128-SHA 128/128) by dog.tcb.net with SMTP; for sidr@ietf.org; Mon, 14 Nov 2011 14:38:44 -0700 (MST) (envelope-from danny@tcb.net)
X-Avenger: version=0.7.8; receiver=dog.tcb.net; client-ip=122.147.35.3; client-port=21250; syn-fingerprint=65535:44:1:64:M1460,N,W3,N,N,T,S MacOS 10.4.8; data-bytes=0
From: Danny McPherson <danny@tcb.net>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Date: Mon, 14 Nov 2011 16:38:42 -0500
Message-Id: <80D9C12A-354E-4A90-8E97-946519E499D0@tcb.net>
To: sidr wg list <sidr@ietf.org>
Mime-Version: 1.0 (Apple Message framework v1084)
X-Mailer: Apple Mail (2.1084)
Subject: [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, 14 Nov 2011 21:38:49 -0000

Rob/Steve, et al., 
Relative to the SIDR Origin Ops draft and local trust anchor (LTA) 
configuration, I'm trying to understand how one would actualize 
trust anchor locators (TALs) and LTAs in a deployment scenario and 
was hoping you could help me here.

I think it's probably safe to assume everyone is going to have a 
"Constraints" file for some things.  

Because the TALs don't actually specify the list of resources covered by 
the referenced self-signed CA certificates the relying party must consult 
each trust anchor (e.g., RIR) to determine the INR extension(s) within this 
certificate, and the onus is on the RP to resolve conflicts, is this correct?
  
For example, currently, in the experimental pilot RPKI system many of the 
INRs are asserting 0.0.0.0/0 and 0::/0, which opens the opportunity for 
conflicts that must be resolved by the RP, when they likely have no real
capability to do this (hence the IAB statement on this topic).

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?

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?

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?

Does this question make sense, or is this problem solved elsewhere?

Thanks, 

-danny