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

Christopher Morrow <> Tue, 15 November 2011 05:22 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id AE02811E81CB for <>; Mon, 14 Nov 2011 21:22:29 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -103.545
X-Spam-Status: No, score=-103.545 tagged_above=-999 required=5 tests=[AWL=0.054, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 4WkYlw5nIvkp for <>; Mon, 14 Nov 2011 21:22:28 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id BCC0E11E8073 for <>; Mon, 14 Nov 2011 21:22:28 -0800 (PST)
Received: by iaeo4 with SMTP id o4so10370262iae.31 for <>; Mon, 14 Nov 2011 21:22:28 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=yKa8h4JhAFMFKGbgX5/uxlfggI65en4h2kHEyOhY0no=; b=TaX3Hj9bW1EumsrpLrjhda6MX4kTkoQkBTPnXZkh5gtFxrTEOlSiK0gS9+gobJQqKu LL9VKfNALdaW8W67BbTu8CVM/20/X1rcHI9tyas0rWceyoGs9JrbxtC4pug4hEsHJpBf nhJV7U20bGVEjZmdAML27Z8lLmyp8BUgm/bbU=
MIME-Version: 1.0
Received: by with SMTP id 17mr6012319ibu.31.1321334548331; Mon, 14 Nov 2011 21:22:28 -0800 (PST)
Received: by with HTTP; Mon, 14 Nov 2011 21:22:28 -0800 (PST)
In-Reply-To: <>
References: <> <> <> <> <>
Date: Tue, 15 Nov 2011 00:22:28 -0500
X-Google-Sender-Auth: kRiQCTxF4FRDpCkPvKsXHo3Dg0w
Message-ID: <>
From: Christopher Morrow <>
To: Danny McPherson <>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Cc: sidr wg list <>
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, 15 Nov 2011 05:22:29 -0000

On Mon, Nov 14, 2011 at 10:57 PM, Danny McPherson <> wrote:
> On Nov 14, 2011, at 10:07 PM, Christopher Morrow wrote:
>> On top of that if the resource is then re-certified (to the same or
>> different end entity) how do the intermediate parties know which is
>> the 'right' thing to do?
> Agreed..  It's critical to highlight that LTA doesn't fix anything here
> unless this is accommodated by all parties in the transaction path.

in one sense, LTA is meant to certify resources local to the ASN (or
set of ASNs which use the LTA, of course). It could be to cerify
'blackhole' routes, or RFC1918-like space.

in another it's been bent for the 'stop the black-helicopters' problem
(or the less controversal: 'Joe forgot to pay ARIN' case). So far your
comments, I think, are about this use-case.

> Furthermore, because CAs can be compromised (as we've seen with
> many CAs whose @day_job IS security), and today anyone in your TAL

also, we ought to be clear that the 'CA' is really one 'CA' at the
root, we hope. which is both good and bad...

> list can assert authority for any resources (as many are currently doing
> currently), without the ability to filter this or scope it in some manner it
> could be really problematic.

agreed, can we only have one root CA please? :) Having more than 1 is
just asinine. (imho)