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

Jeffrey Haas <jhaas@pfrc.org> Wed, 11 April 2012 19:48 UTC

Return-Path: <jhaas@slice.pfrc.org>
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 2A9BC11E80C6; Wed, 11 Apr 2012 12:48:10 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -101.278
X-Spam-Level:
X-Spam-Status: No, score=-101.278 tagged_above=-999 required=5 tests=[AWL=0.188, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, 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 n9J3mfEM2I1w; Wed, 11 Apr 2012 12:48:09 -0700 (PDT)
Received: from slice.pfrc.org (slice.pfrc.org [67.207.130.108]) by ietfa.amsl.com (Postfix) with ESMTP id B7F0C11E80B8; Wed, 11 Apr 2012 12:48:09 -0700 (PDT)
Received: by slice.pfrc.org (Postfix, from userid 1001) id 42F78170234; Wed, 11 Apr 2012 15:48:09 -0400 (EDT)
Date: Wed, 11 Apr 2012 15:48:09 -0400
From: Jeffrey Haas <jhaas@pfrc.org>
To: Christopher Morrow <morrowc.lists@gmail.com>
Message-ID: <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>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <CAL9jLaZjXHBSXmuQ6p53o+0aPkfudTUm60xY2qTSbRu8+wLmMg@mail.gmail.com>
User-Agent: Mutt/1.5.20 (2009-06-14)
Cc: "sidr@ietf.org" <sidr@ietf.org>, "idr@ietf.org List" <idr@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:48:10 -0000

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.

-- Jeff