IETF Logo Mail Archive

Re: [sidr] iBGP, BGPSEC and incremental deployment (was No BGPSEC intradomain ?)

Christopher Morrow <morrowc.lists@gmail.com> Wed, 11 April 2012 19: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 AFE7311E80E8; Wed, 11 Apr 2012 12:53:37 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -103.099
X-Spam-Level:
X-Spam-Status: No, score=-103.099 tagged_above=-999 required=5 tests=[AWL=-0.299, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, SARE_SUB_RAND_LETTRS4=0.799, 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 nJ4KazCy2Nmy; Wed, 11 Apr 2012 12:53:36 -0700 (PDT)
Received: from mail-ob0-f172.google.com (mail-ob0-f172.google.com [209.85.214.172]) by ietfa.amsl.com (Postfix) with ESMTP id A59D111E80DB; Wed, 11 Apr 2012 12:53:33 -0700 (PDT)
Received: by obbtb4 with SMTP id tb4so1889345obb.31 for <multiple recipients>; Wed, 11 Apr 2012 12:53:29 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; 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=Z9X+ISKgcZEcinaxXemvKeEcjS20OX6a4Iat8jE8fiM=; b=wtuvnjVePlNbEMjl1PtNB9OYGfn1EsUBWXMIiZSFvgRIcr7ZcJ4Tfvrmpz4MKkbfRH BPNSuKmBulA0bOjmmJ6H2d2LGEaCCr/drRIwJlrelV1i4m9YSHWHM0qxwwmAvCFwRk8u kWvsCoLnLsIpCf68FxxaEiAT5nbaS65aiWtwXMQtfqxz+Egv9MCu4FWndDR8dvRjAUZL ystCn70mDBO5CHADl0128Lz2KhRkTheyUiZ0KVxpL2C2WfLUTObEnva3WaXVs3neFGkE dvXoidmqLQHjFM5Gm4rtdDriZk+O++EtYDUN0BLTkkcr8RDp/66C1a/0fQUqt8wWFVB9 FzfQ==
MIME-Version: 1.0
Received: by 10.182.52.104 with SMTP id s8mr21500861obo.59.1334174009075; Wed, 11 Apr 2012 12:53:29 -0700 (PDT)
Sender: christopher.morrow@gmail.com
Received: by 10.182.153.34 with HTTP; Wed, 11 Apr 2012 12:53:29 -0700 (PDT)
In-Reply-To: <20120411194809.GE1283@slice>
References: <4F830E75.70606@raszuk.net> <24B20D14B2CD29478C8D5D6E9CBB29F60F6F1533@Hermes.columbia.ads.sparta.com> <4F832F5E.9030903@raszuk.net> <0BD03B75-CA3A-4CBA-BBF4-E2100AFA64E4@kumari.net> <4F846121.2050408@raszuk.net> <CAL9jLaYF-MW1cJ2n28BiV1mi+tpPS2ECKB2UxhFMQ=NXxbihCg@mail.gmail.com> <D7CF4F8F-AF93-43F2-BC0D-26E072307B4F@kumari.net> <20120411142053.GA1283@slice> <7309FCBCAE981B43ABBE69B31C8D21391B3EE934B5@EUSAACMS0701.eamcs.ericsson.se> <CAL9jLaZjXHBSXmuQ6p53o+0aPkfudTUm60xY2qTSbRu8+wLmMg@mail.gmail.com> <20120411194809.GE1283@slice>
Date: Wed, 11 Apr 2012 15:53:29 -0400
X-Google-Sender-Auth: -o3XdKshdP1Mca-PvcfhsWqipzw
Message-ID: <CAL9jLaaqcTtpTbjiRCCDWSRvqfZPAP3DB9Uv9h+eA8Uc9hOYRQ@mail.gmail.com>
From: Christopher Morrow <morrowc.lists@gmail.com>
To: Jeffrey Haas <jhaas@pfrc.org>
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: quoted-printable
Cc: "idr@ietf.org List" <idr@ietf.org>, "sidr@ietf.org" <sidr@ietf.org>
Subject: Re: [sidr] iBGP, BGPSEC and incremental deployment (was No BGPSEC intradomain ?)
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: Wed, 11 Apr 2012 19:53:37 -0000

On Wed, Apr 11, 2012 at 3:48 PM, Jeffrey Haas <jhaas@pfrc.org> wrote:
> On Wed, Apr 11, 2012 at 12:28:32PM -0400, Christopher Morrow wrote:
>> On Wed, Apr 11, 2012 at 12:17 PM, Jakob Heitz <jakob.heitz@ericsson.com> wrote:
>> > Confeds are out of scope.
>>
>> how are confeds out of scope?
>> if you want path validation for ibgp/originated-by-you routes and the
>> originating router is in one of the confed sub-ases you have that
>> router sign with the confed-external/public asn, no? I'm fairly
>> certain we planned to support this sort of activity... though I could
>> be missing the part which is out-of-scope?
>
> Functionally, confed segments are stripped prior to the global AS being
> added to the path.  The box performing this function is the one that needs
> to amend the BGPSEC signature, not some box in the middle of the
> confederation.

I suppose you could re-sign... the case I was thinking of was
attempting to validate inside your domain a prefix supposedly
originated by an iBGP speaker inside your domain.

v2.23.0 | Report a Bug | By Email