Re: [sidr] No BGPSEC intradomain ?

Warren Kumari <warren@kumari.net> Tue, 10 April 2012 16:07 UTC

Return-Path: <warren@kumari.net>
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 AF9A721F85FD; Tue, 10 Apr 2012 09:07:09 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -106.599
X-Spam-Level:
X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, 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 3pZ1IskKCj52; Tue, 10 Apr 2012 09:07:08 -0700 (PDT)
Received: from vimes.kumari.net (vimes.kumari.net [198.186.192.250]) by ietfa.amsl.com (Postfix) with ESMTP id C27E621F85F9; Tue, 10 Apr 2012 09:07:08 -0700 (PDT)
Received: from dhcp-172-19-119-246.cbf.corp.google.com (unknown [64.13.52.115]) by vimes.kumari.net (Postfix) with ESMTPSA id CFF9A1B40018; Tue, 10 Apr 2012 12:07:07 -0400 (EDT)
Mime-Version: 1.0 (Apple Message framework v1084)
Content-Type: text/plain; charset=us-ascii
From: Warren Kumari <warren@kumari.net>
In-Reply-To: <4F832F5E.9030903@raszuk.net>
Date: Tue, 10 Apr 2012 12:07:06 -0400
Content-Transfer-Encoding: quoted-printable
Message-Id: <0BD03B75-CA3A-4CBA-BBF4-E2100AFA64E4@kumari.net>
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>
To: "sidr@ietf.org list" <sidr@ietf.org>
X-Mailer: Apple Mail (2.1084)
Cc: "idr@ietf.org List" <idr@ietf.org>
Subject: Re: [sidr] 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: Tue, 10 Apr 2012 16:07:09 -0000

On Apr 9, 2012, at 2:50 PM, Robert Raszuk wrote:

> Hi,
> 
>> And intradomain BGP speakers do not use bgpsec (ebgp sessions only).
> 
> I do not understand. How a BGP Update will transit via an AS where each router is a real BGP speaker and where as some proposed BGP mandatory AS_PATH attribute is not present ?


I must admit I'm having a hard time parsing the question. I'll take a stab though... This answer may be unrelated to what you are asking...

When an update leaves a BGPSEC speaker destined for a "legacy" speaker the BGPSEC bits are removed

> 
> Are you assuming each AS today is BGP Free with full mesh of MPLS/IP tunnel ASBR to ASBR as transport ? Even in this case ASBRs are connected directly or indirectly (RRs) via IBGP.

Nope, not assuming that at all. The devices on the edge of the AS (those that do eBGP) need to speak BGPSEC, and if the AS is small, they will probably be in a full mesh. If the AS is not small (or has planned ahead :-)) they will talk to a RR or be part of a confed. If they talk through a RR (or set of RRs), these should also speak BGPSEC. If you prefer the confed flavor of scaling, well, the devices on the edge of the confed are kinda like eBGP speakers, and inside the confed they all mesh (or talk through a RR (see previous :-)))

> 
> As you proposing to remove AS_PATH selection criteria from best path for updates which come over IBGP ?

Goodness, no....


> What happens if you need to compare paths received over EBGP and IBGP on a given BGP speaker ?
> 
> Many thx,
> R.
> 

P.S: Crossposting left in, as it seems like that is what was wanted, but....

> _______________________________________________
> sidr mailing list
> sidr@ietf.org
> https://www.ietf.org/mailman/listinfo/sidr
>