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

Christopher Morrow <> Tue, 15 November 2011 03:07 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 0B8D71F0C98 for <>; Mon, 14 Nov 2011 19:07:05 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -103.543
X-Spam-Status: No, score=-103.543 tagged_above=-999 required=5 tests=[AWL=0.056, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id I3WTqO-ojYNs for <>; Mon, 14 Nov 2011 19:07:04 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id 525E71F0C92 for <>; Mon, 14 Nov 2011 19:07:04 -0800 (PST)
Received: by pzk5 with SMTP id 5so11528900pzk.9 for <>; Mon, 14 Nov 2011 19:07:04 -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=eah/UpdEXYy+NMfY/cCHMlPDPB3n20yJ9hG2VtjQulY=; b=uw63ALYKxdDiYRiGZ+cxT99w4zHfHsdtm6WSwXd5EGvehQW4roc6wcHK9CVDqgv5e3 Nrcan09y50lGjIi0bqmBF0o9E/7L8JwR9zHjLTm9x6OB3vCfQbndrSN2u3N/S/O/lmb2 gAY5rRVXM2lA/fw4Oh2VpYb+X8tw83sp/pWwc=
MIME-Version: 1.0
Received: by with SMTP id t2mr56237948pbt.73.1321326423849; Mon, 14 Nov 2011 19:07:03 -0800 (PST)
Received: by with HTTP; Mon, 14 Nov 2011 19:07:03 -0800 (PST)
In-Reply-To: <>
References: <> <> <>
Date: Mon, 14 Nov 2011 22:07:03 -0500
X-Google-Sender-Auth: LE919rvclnPaNz6YcgDdY7wEMkk
Message-ID: <>
From: Christopher Morrow <>
To: Danny McPherson <>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Cc: Rob Austein <>,
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 03:07:05 -0000

On Mon, Nov 14, 2011 at 7:02 PM, Danny McPherson <> wrote:
> On Nov 14, 2011, at 6:47 PM, Rob Austein wrote:
>> 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.

This is back to your (danny) point about: If someone[1] removes a
Resource Certification (ROA, for instance) and that resource is
actually critical[2] (or in use), all parties between the resource
(server) and the service-requestor (user) are bound to need to know
that the resource is still there, and valid. These parties all need to
populate their LTA (Local Trust Anchor) with the right certification

This seems like it will be messy, telling everyone via some
phone-tree, and potentially confusing.
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?


[1]: This is the nominal 'black helicopters' problem, also seen today
[2]: The netblock, for instance, for the .cx ccTLD (presuming that .cx
is doing/permitting-some-actions that a third party finds

b: I made up the example, and the 2 'black helicopter' examples are
certainly USA-centric, we could make up many more, but ... that's not
horribly relevant. The problem could also be triggered by someone
mistakenly missing their payment window to the RIR.