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 16: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 AD18721F8593; Wed, 11 Apr 2012 09:28:33 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -103.139
X-Spam-Level:
X-Spam-Status: No, score=-103.139 tagged_above=-999 required=5 tests=[AWL=-0.340, 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 6r7LTCFjecVF; Wed, 11 Apr 2012 09:28:33 -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 17C4E21F8547; Wed, 11 Apr 2012 09:28:33 -0700 (PDT)
Received: by obbtb4 with SMTP id tb4so1654283obb.31 for <multiple recipients>; Wed, 11 Apr 2012 09:28:32 -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; bh=N8UNhmj6U9DlOJtoltE8HaCjvzXuXR+prNCujyh5JBA=; b=M8Lnm72CXn/wZi12YnwBdAoliTXcXIGlDWJU4xgy0hucmu1TLkdzKz91Vdbdh21+gL iw6d/PA3DsQGpjdmouc4KtfL3K3vznJVCgnbWDB80UPjJWrCD3dVTOq/S5hIAX4nJlCw TGiTW4vf/i2mLtjHX3itQo2Yo+EML2KnMHrypRKr+8GvSrqZEqZNY+cleQHZKUKnX2+C Rq9l3EZtdCNj8G8T9t3FXaGtmpd4RdAaWZNC/VtmJQiQbrsHzG+lZ253sP7uI8aAjUAN 11BgwcbCeusG8EAjVwNu0DkoGSpjXGdiXld3OuxFfHL7s1bnpAlmVJ+mS5UCKSszWu10 F0pg==
MIME-Version: 1.0
Received: by 10.182.54.114 with SMTP id i18mr20797593obp.49.1334161712752; Wed, 11 Apr 2012 09:28:32 -0700 (PDT)
Sender: christopher.morrow@gmail.com
Received: by 10.182.153.34 with HTTP; Wed, 11 Apr 2012 09:28:32 -0700 (PDT)
In-Reply-To: <7309FCBCAE981B43ABBE69B31C8D21391B3EE934B5@EUSAACMS0701.eamcs.ericsson.se>
References: <D7A0423E5E193F40BE6E94126930C4930B96182E71@MBCLUSTER.xchange.nist.gov> <4F828D6D.10907@raszuk.net> <D7A0423E5E193F40BE6E94126930C4930B96C507DA@MBCLUSTER.xchange.nist.gov> <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>
Date: Wed, 11 Apr 2012 12:28:32 -0400
X-Google-Sender-Auth: yGCbaCBHjo8XcEXtaTjHEamy0Dg
Message-ID: <CAL9jLaZjXHBSXmuQ6p53o+0aPkfudTUm60xY2qTSbRu8+wLmMg@mail.gmail.com>
From: Christopher Morrow <morrowc.lists@gmail.com>
To: Jakob Heitz <jakob.heitz@ericsson.com>
Content-Type: text/plain; charset="ISO-8859-1"
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 16:28:33 -0000

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?

> IOW, the BGPSEC validity of an update does not necessarily
> prevent you from using the update if you have inside knowledge
> about AS path mucking. How you use the BGPSEC validity in
> your route selection is a private matter.

yes, which is, I think, nice.

v2.23.0 | Report a Bug | By Email