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

Jeffrey Haas <jhaas@pfrc.org> Wed, 11 April 2012 19:52 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 52E7711E8075; Wed, 11 Apr 2012 12:52:47 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -101.315
X-Spam-Level:
X-Spam-Status: No, score=-101.315 tagged_above=-999 required=5 tests=[AWL=0.151, 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 hbqubd5z2X6Z; Wed, 11 Apr 2012 12:52:46 -0700 (PDT)
Received: from slice.pfrc.org (slice.pfrc.org [67.207.130.108]) by ietfa.amsl.com (Postfix) with ESMTP id BA67521F8458; Wed, 11 Apr 2012 12:52:45 -0700 (PDT)
Received: by slice.pfrc.org (Postfix, from userid 1001) id 857461703E4; Wed, 11 Apr 2012 15:52:45 -0400 (EDT)
Date: Wed, 11 Apr 2012 15:52:45 -0400
From: Jeffrey Haas <jhaas@pfrc.org>
To: Jakob Heitz <jakob.heitz@ericsson.com>
Message-ID: <20120411195245.GF1283@slice>
References: <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>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <7309FCBCAE981B43ABBE69B31C8D21391B3EE934B5@EUSAACMS0701.eamcs.ericsson.se>
User-Agent: Mutt/1.5.20 (2009-06-14)
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:52:48 -0000

On Wed, Apr 11, 2012 at 12:17:40PM -0400, Jakob Heitz wrote:
> Confeds are out of scope.
> 
> VPN address families are out of scope.

Meaning that the AS_PATH has to be present.  No?

(I suspect you mean yes.  That's the matter at hand.)

> If the BGPSEC path does not match the AS_PATH, the update
> is invalid.

You mean a 1:1 match of ASes including prepend counts?  If so, that's at
least an opinion. :-)

> The validity of an update is used as an input to route selection.
> If you have been replace/override/removing ASNs, you are free to
> use that information in route selection too.

That depends on path validity.  If you require that the AS_PATH and the
signature are identical (or potentially accommodate transparent ASes of
length 0), you can't do a number of those things without rendering the route
invalid.  Again, deployment issues.

> 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.

In general, I agree.  The particulars have consequences.

-- Jeff