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

Christopher Morrow <morrowc.lists@gmail.com> Tue, 29 November 2011 00:53 UTC

Return-Path: <christopher.morrow@gmail.com>
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 52C721F0C58 for <sidr@ietfa.amsl.com>; Mon, 28 Nov 2011 16:53:16 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.999
X-Spam-Level:
X-Spam-Status: No, score=-102.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_22=0.6, RCVD_IN_DNSWL_LOW=-1, 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 2IaLgy8P16oY for <sidr@ietfa.amsl.com>; Mon, 28 Nov 2011 16:53:15 -0800 (PST)
Received: from mail-iy0-f172.google.com (mail-iy0-f172.google.com [209.85.210.172]) by ietfa.amsl.com (Postfix) with ESMTP id BB10D1F0C46 for <sidr@ietf.org>; Mon, 28 Nov 2011 16:53:15 -0800 (PST)
Received: by iaeo4 with SMTP id o4so11634472iae.31 for <sidr@ietf.org>; Mon, 28 Nov 2011 16:53:15 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; 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=0UZZZZG4qc2MRQk/SL2oT42xP6U6PnOPQkvnLs8DCfc=; b=HXHXwTCOjCU2QEKLZMt4tgWNZvliBvhz6vQk3hkolGFt89rwD0nZnNGB/gCcLpsV/R 42CMQYEGHWjsnXLS/V4bEN6kzIEsi2AwuG+LOjhJrjoAgquxXdCeY4ngSUBsS9I5j9dP 4OM17go3lLJ0qJ4cTp/0WTPvhhMbU8vntWWos=
MIME-Version: 1.0
Received: by 10.50.88.199 with SMTP id bi7mr52579689igb.45.1322527995394; Mon, 28 Nov 2011 16:53:15 -0800 (PST)
Sender: christopher.morrow@gmail.com
Received: by 10.231.207.78 with HTTP; Mon, 28 Nov 2011 16:53:15 -0800 (PST)
In-Reply-To: <p06240803caf95d6f5166@128.89.89.6>
References: <80D9C12A-354E-4A90-8E97-946519E499D0@tcb.net> <p06240801cae79ccfa546@172.20.1.65> <72E12AD7-CFAF-4FBD-8A98-F93038F7E8FB@tcb.net> <p06240803caf95d6f5166@128.89.89.6>
Date: Mon, 28 Nov 2011 19:53:15 -0500
X-Google-Sender-Auth: G9RnBPOYhlKwxct8khy7_FgzxEA
Message-ID: <CAL9jLaZ7ccqD6gkyy1Rd2gdqwf3=C28D77Y1YSb2eMRGn8OGoQ@mail.gmail.com>
From: Christopher Morrow <morrowc.lists@gmail.com>
To: Stephen Kent <kent@bbn.com>
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: quoted-printable
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, 29 Nov 2011 00:53:16 -0000

On Mon, Nov 28, 2011 at 5:13 PM, Stephen Kent <kent@bbn.com> wrote:
> At 10:09 PM -0500 11/21/11, Danny McPherson wrote:
>>
>> ...
>>  > 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?
>
> The original model for an LTA was, as the name suggests, local, hence just
> one AS.  However, it is easy to extend that model to encompass a set of
> AS'es under the same admin control. In that case, the set of ASes all agree
> to accept the
> RPKI "view" managed by some entity in control (relative to the set of ASes).
>
> In your example are all of the ASes independent? You say that they want to
> "transact their constraints file" but you didn't say why, nor what the
> relationships might be among the constraints file for each AS.

I think danny's example (as explained off-line in taipei) was something like:

  o 3 cooperating ASNs (say: 701, 7018, 2914)
  o one customer on either side of the 3 ASNs (a-widget-maker &&
a-widget-user/customer)
  o All have RPKI + BGPSEC deployed
  o the 'blackhelicopters of forgotten payment' arrive at ARIN's
doorstep and remove the Registration data for a-root/24.

  For a-widget-customer to still access a-widget-maker all of the
intermediate ASN's (and a-widget-customer even) will have to enter
into their LTA's some bogus/temporary certificate data... Or, I
suppose, they could just wing it on 'not validated' but still the only
prefix-in-town?

I think Danny's proposing some federation of LTAs under distributed
control where these folks all agree that "a-widget-maker/24 is still
a-ok by us!".

-chris