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

Danny McPherson <danny@tcb.net> Tue, 15 November 2011 00:02 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 4188911E8095 for <sidr@ietfa.amsl.com>; Mon, 14 Nov 2011 16:02:29 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.599
X-Spam-Level:
X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, 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 Xk1AmglAMzSz for <sidr@ietfa.amsl.com>; Mon, 14 Nov 2011 16:02:28 -0800 (PST)
Received: from dog.tcb.net (dog.tcb.net [64.78.150.133]) by ietfa.amsl.com (Postfix) with ESMTP id BB44811E8090 for <sidr@ietf.org>; Mon, 14 Nov 2011 16:02:28 -0800 (PST)
Received: by dog.tcb.net (Postfix, from userid 0) id 7C492268081; Mon, 14 Nov 2011 17:02:28 -0700 (MST)
Received: from dhcp-1267.meeting.ietf.org (dhcp-1267.meeting.ietf.org [130.129.18.103]) (authenticated-user smtp) (TLSv1/SSLv3 AES128-SHA 128/128) by dog.tcb.net with SMTP; Mon, 14 Nov 2011 17:02:27 -0700 (MST) (envelope-from danny@tcb.net)
Mime-Version: 1.0 (Apple Message framework v1084)
Content-Type: text/plain; charset="us-ascii"
From: Danny McPherson <danny@tcb.net>
In-Reply-To: <20111114234754.33CA96550DD@minas-ithil.hactrn.net>
Date: Mon, 14 Nov 2011 19:02:09 -0500
Content-Transfer-Encoding: 7bit
Message-Id: <87819BD9-1829-438C-A479-A315819943D0@tcb.net>
References: <80D9C12A-354E-4A90-8E97-946519E499D0@tcb.net> <20111114234754.33CA96550DD@minas-ithil.hactrn.net>
To: Rob Austein <sra@hactrn.net>
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, 15 Nov 2011 00:02:29 -0000

On Nov 14, 2011, at 6:47 PM, Rob Austein wrote:

> Danny,
> 
> For purposes of this discussion, a LTA is semantically equivalent to a
> collection of TAs plus a constraint list.  Since LTAs are also a more
> general mechanism (they can be shared by a group of like-minded folks
> more easily than a constraint list -- just create a TAL pointing at
> the LTA) and since LTAs have the nice property of keeping the raw
> constraint list out of the validator itself (thus keeping the
> validator that much simpler), my advice to anybody who thinks they
> need a constraint list would be to use a LTA.
> 
> We can discuss this further at the face to face meeting if you like,
> but that's the summary as I see it at the technical layer.

That'd be good, because I'm not comfortable with that as an RP.

> Layers 8+ are mostly out of scope for this list, so let me just say
> that I am really hoping that IANA and the RIRs will get their
> collective act together and issue a single TA before this becomes a
> serious problem.  They say that they intend to do so.  As somebody (KC
> Claffy?) said a few years ago, relying parties should not have to sort
> out this mess, that's what the industry pays the RIRs to do.  For the
> moment I'm willing to take the RIRs' word that they intend to do their
> job and just need a bit more time.  YMMV.

Until then (or even after in the event of a CA compromise), it's a 
technical issue and the capability for RPs to determine who holds 
what resources, or at least to constrain who they trust with what 
resources, and intersect that with the LTA 'federation' issue is very
much an operational issue.

-danny