Re: [sidr] various

Brian Dickson <brian.peter.dickson@gmail.com> Sun, 13 November 2011 01:29 UTC

Return-Path: <brian.peter.dickson@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 4C7D521F8ABE for <sidr@ietfa.amsl.com>; Sat, 12 Nov 2011 17:29:51 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.55
X-Spam-Level:
X-Spam-Status: No, score=-3.55 tagged_above=-999 required=5 tests=[AWL=0.049, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1]
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 6IHZBnwUCDdp for <sidr@ietfa.amsl.com>; Sat, 12 Nov 2011 17:29:50 -0800 (PST)
Received: from mail-bw0-f44.google.com (mail-bw0-f44.google.com [209.85.214.44]) by ietfa.amsl.com (Postfix) with ESMTP id 2C56F21F8541 for <sidr@ietf.org>; Sat, 12 Nov 2011 17:29:50 -0800 (PST)
Received: by bkbzv15 with SMTP id zv15so5637100bkb.31 for <sidr@ietf.org>; Sat, 12 Nov 2011 17:29:49 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=we5yp9NwbKtw7aPKCslXn9Lk4tpAhODVjchCk0Qmtz0=; b=gkxsjTL8weuYzNywJaD/OlWSY/33QYIP7SuNzN8Mwh0YheyHjxKmWz0v6KflPKcjXe uXOLrtMcxqdFgAfJJ74iAP7w2uxBEsjufz0k03u69aT+c+D4ERa6427gSghPeNjPKb1+ sCRo4DP62A89dRuIh5Mb/DBduFOAdEK01sfu4=
MIME-Version: 1.0
Received: by 10.205.119.207 with SMTP id fv15mr13805959bkc.100.1321147789178; Sat, 12 Nov 2011 17:29:49 -0800 (PST)
Received: by 10.223.54.15 with HTTP; Sat, 12 Nov 2011 17:29:49 -0800 (PST)
In-Reply-To: <DCC302FAA9FE5F4BBA4DCAD4656937791451B2CD7F@PRVPEXVS03.corp.twcable.com>
References: <20111031193803.30761.81234.idtracker@ietfa.amsl.com> <4EB02586.5010101@bbn.com> <DCC302FAA9FE5F4BBA4DCAD4656937791451B2CC8D@PRVPEXVS03.corp.twcable.com> <m2ehxef1ob.wl%randy@psg.com> <DCC302FAA9FE5F4BBA4DCAD4656937791451B2CCDA@PRVPEXVS03.corp.twcable.com> <m2aa81g7hp.wl%randy@psg.com> <DCC302FAA9FE5F4BBA4DCAD4656937791451B2CCE5@PRVPEXVS03.corp.twcable.com> <m2d3cxei0p.wl%randy@psg.com> <DCC302FAA9FE5F4BBA4DCAD4656937791451B2CCE9@PRVPEXVS03.corp.twcable.com> <m24ny9e6bv.wl%randy@psg.com> <DCC302FAA9FE5F4BBA4DCAD4656937791451B2CD7F@PRVPEXVS03.corp.twcable.com>
Date: Sat, 12 Nov 2011 20:29:49 -0500
Message-ID: <CAH1iCio+BsTK9nqKx_c26NH_cOLVAfczxreX4zAZ7yJOFnswLg@mail.gmail.com>
From: Brian Dickson <brian.peter.dickson@gmail.com>
To: "George, Wes" <wesley.george@twcable.com>
Content-Type: text/plain; charset="ISO-8859-1"
Cc: sidr wg list <sidr@ietf.org>
Subject: Re: [sidr] various
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: Sun, 13 Nov 2011 01:29:51 -0000

On Sat, Nov 12, 2011 at 7:45 PM, George, Wes <wesley.george@twcable.com> wrote:
>> From: Randy Bush [mailto:randy@psg.com]
>> Sent: Saturday, November 12, 2011 9:58 AM
>> To: George, Wes
>> Cc: sidr wg list
>> Subject: Re: various
>>
>> > Do you or do you not agree that on the transition between private ASN
>> > and public, if remove-private is configured, any signatures
>> containing
>> > private ASN must be removed even if the eBGP peer is BGPSec capable?
>>
>> with the statement as is, if it is a private asn or a public asn, it is
>> not signing.
>
> [WEG] sigh. Let me try one more time.
> This question is not about confederations so "the statement" is not applicable.
> Think just bog-standard, vanilla eBGP, with two BGPSec speakers, one of whom is using a private ASN, announcing routes that must be carried to the DFZ. Make more sense now as to why I'm making the distinction between private and public ASN?

Should we presume in your example, that the sequence is:

private -> public -> public

I.e. that there is no public ASN before the private ASN, and the route
is originated by the private AS?

I think the answer is something along the lines of, the private AS
announces with its private AS as the origin,
and the upstream public AS has its own trust anchor for assigning its
instances of private AS ROA records.

The public AS, to the outside world, appears to be the real
originator, so the original signature is stripped completely,
and a new signature block created using the public AS's "real" ROA
info and signed as if it really was originated.

Everything works beyond that.

There really cannot be a transitive 1918->non-1918 signature path,
because there cannot be 1918 ROAs with global significance, because of
the AS's non-uniqueness.

BGPsec from the announcer, transitively, can only be done with a
public ASN. 4-byte ASNs are available now, expect demand to increase
with BGPsec, IMHO.

Brian