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

Christopher Morrow <morrowc.lists@gmail.com> Thu, 12 April 2012 15:28 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 0D30021F867E; Thu, 12 Apr 2012 08:28:45 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -103.088
X-Spam-Level:
X-Spam-Status: No, score=-103.088 tagged_above=-999 required=5 tests=[AWL=-0.288, 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 M5RStd6tcy9l; Thu, 12 Apr 2012 08:28:44 -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 7EC9721F8671; Thu, 12 Apr 2012 08:28:44 -0700 (PDT)
Received: by obbtb4 with SMTP id tb4so3329695obb.31 for <multiple recipients>; Thu, 12 Apr 2012 08:28:44 -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=hr5zUVX4GZKT/9tTMUi5wSC8Q912tWbZRggxPRExLYM=; b=fwgjKJDIFkq2i8qTX48CHat6aBnGq8yUbahL5WKjORhx19PJz5dHZ9IOmOuTyJEePT vbrW15D2t1XnOq2ic6io6n8UdP0O2xR5FoZpsunc6oWdvTpZlcx7skS+dWHCUMIRYNId oC2LoaG2Ycm2VV0VHfovafitFiA9iCh6RH+7IWshQZbjgO4LtBlmmKgOYn3oZWKCJG/1 KOcIUFbje92HEvL0GNaB3GZa/0Qq+rn9baHDx6H9u3Qsm1XkJYKvAQNKmh/ZbGA7yBj1 gSgL4BsOdgVodLPPfHz3lGK9PyPRalGaQpKfhuCaYu3Jz7ph0rZeGC+xegVtmdrsbiz7 0Htw==
MIME-Version: 1.0
Received: by 10.182.52.104 with SMTP id s8mr3534355obo.59.1334244524079; Thu, 12 Apr 2012 08:28:44 -0700 (PDT)
Sender: christopher.morrow@gmail.com
Received: by 10.182.153.34 with HTTP; Thu, 12 Apr 2012 08:28:44 -0700 (PDT)
In-Reply-To: <20120412145258.GB9700@slice>
References: <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> <CAL9jLaaqcTtpTbjiRCCDWSRvqfZPAP3DB9Uv9h+eA8Uc9hOYRQ@mail.gmail.com> <20120412145258.GB9700@slice>
Date: Thu, 12 Apr 2012 11:28:44 -0400
X-Google-Sender-Auth: Sjm6YHY2tdr7taJbOTJ54y5oOc4
Message-ID: <CAL9jLaYRsr5mJMzk76wHrvGSN9hc04yWFoBBGCz99_eDPoRXng@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: Thu, 12 Apr 2012 15:28:45 -0000

On Thu, Apr 12, 2012 at 10:52 AM, Jeffrey Haas <jhaas@pfrc.org> wrote:
> On Wed, Apr 11, 2012 at 03:53:29PM -0400, Christopher Morrow wrote:
>> > 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.
>
> If you don't trust your own boxes to originate, I think you have a  bigger
> problem. :-)

yes... where's that box in $HOSTILE_COUNTRY ? are we SURE that no one
has tampered with it during the recent 'unscheduled power outage' ? :(
darned crapblarghistan and it's ongoing power grid problems!

> That said, there's little stopping you from using RPKI (perhaps with a local
> view) data to provide prefix sanity checking.  Internally the signature
> piece is probably excessive.

this is all from another frequent-poster to this list (the requirement
I mean)... I'm just parroting it back for the record. (though I do see
a valid case to sign on origination as well, and check internally)

you don't seem to disagree that the functionality could be there, so
... 'violent agreement'!

-chris