Re: [sidr] No BGPSEC intradomain ?
Robert Raszuk <robert@raszuk.net> Tue, 10 April 2012 16:34 UTC
Return-Path: <robert@raszuk.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 D664C11E812A for <sidr@ietfa.amsl.com>; Tue, 10 Apr 2012 09:34:43 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level:
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599]
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 izTkwhIyy7D2 for <sidr@ietfa.amsl.com>; Tue, 10 Apr 2012 09:34:43 -0700 (PDT)
Received: from mail1310.opentransfer.com (mail1310.opentransfer.com [76.162.254.103]) by ietfa.amsl.com (Postfix) with ESMTP id AA0B111E8129 for <sidr@ietf.org>; Tue, 10 Apr 2012 09:34:42 -0700 (PDT)
Received: (qmail 21358 invoked by uid 399); 10 Apr 2012 16:34:42 -0000
Received: from unknown (HELO ?192.168.1.57?) (pbs:robert@raszuk.net@83.31.51.142) by mail1310.opentransfer.com with ESMTPM; 10 Apr 2012 16:34:42 -0000
X-Originating-IP: 83.31.51.142
Message-ID: <4F846121.2050408@raszuk.net>
Date: Tue, 10 Apr 2012 18:34:41 +0200
From: Robert Raszuk <robert@raszuk.net>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:11.0) Gecko/20120312 Thunderbird/11.0
MIME-Version: 1.0
To: sidr@ietf.org, "idr@ietf.org List" <idr@ietf.org>
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>
In-Reply-To: <0BD03B75-CA3A-4CBA-BBF4-E2100AFA64E4@kumari.net>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
Subject: Re: [sidr] No BGPSEC intradomain ?
X-BeenThere: sidr@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
Reply-To: robert@raszuk.net
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:34:44 -0000
Hi Warren, Many thx for your comment. It clarifies my question very well. So you are effectively confirming that as long as there is one ASBR, one RR or one confederation edge which does not yet speak BGPSEC anywhere in the UPDATE path the peer sending to him over ebgp or ibgp will convert BGP_SIGNED_PATH to AS_PATH/AS4_PATH attributes and from now on that path will remain unsigned. Likewise each RR/confed peer will need to convert BGP_SIGNED_PATH to set of AS_PATH/AS4_PATH attributes when sending to "legacy" BGP speakers. I do not know what is the rationale for recommendation of not sending mandatory BGP attributes any longer even if their content could be already contained with new BGP_SIGNED_PATH attribute. Anyhow my doubt has been answered and I stay by my opinion that not sending AS_PATH and AS4_PATH is a terrible idea. Perhaps one could depreciate it in 20 years when world is upgraded to BGPSEC, but recommending this in BGPSEC protocol draft now is IMHO not helpful for any even potential BGPSEC deployment model. Best regards, R. > 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 :-)))
- [sidr] draft-ietf-sidr-bgpsec-threats-02: Path sh… Shane Amante
- Re: [sidr] draft-ietf-sidr-bgpsec-threats-02: Pat… Stephen Kent
- Re: [sidr] draft-ietf-sidr-bgpsec-threats-02: Pat… Shane Amante
- Re: [sidr] draft-ietf-sidr-bgpsec-threats-02: Pat… Jakob Heitz
- Re: [sidr] draft-ietf-sidr-bgpsec-threats-02: Pat… Andrew Chi
- Re: [sidr] draft-ietf-sidr-bgpsec-threats-02: Pat… Shane Amante
- Re: [sidr] draft-ietf-sidr-bgpsec-threats-02: Pat… Andrew Chi
- Re: [sidr] draft-ietf-sidr-bgpsec-threats-02: Pat… Shane Amante
- Re: [sidr] draft-ietf-sidr-bgpsec-threats-02: Pat… Murphy, Sandra
- Re: [sidr] draft-ietf-sidr-bgpsec-threats-02: Pat… Andrew Chi
- Re: [sidr] draft-ietf-sidr-bgpsec-threats-02: Pat… Andrew Chi
- Re: [sidr] draft-ietf-sidr-bgpsec-threats-02: Pat… Sriram, Kotikalapudi
- Re: [sidr] draft-ietf-sidr-bgpsec-threats-02: Pat… Robert Raszuk
- Re: [sidr] draft-ietf-sidr-bgpsec-threats-02: Pat… Jakob Heitz
- Re: [sidr] draft-ietf-sidr-bgpsec-threats-02: Pat… Sriram, Kotikalapudi
- Re: [sidr] [Idr] draft-ietf-sidr-bgpsec-threats-0… Robert Raszuk
- Re: [sidr] [Idr] draft-ietf-sidr-bgpsec-threats-0… Murphy, Sandra
- Re: [sidr] [Idr] draft-ietf-sidr-bgpsec-threats-0… Robert Raszuk
- Re: [sidr] [Idr] draft-ietf-sidr-bgpsec-threats-0… Montgomery, Douglas
- Re: [sidr] [Idr] draft-ietf-sidr-bgpsec-threats-0… Robert Raszuk
- Re: [sidr] [Idr] draft-ietf-sidr-bgpsec-threats-0… Murphy, Sandra
- [sidr] No BGPSEC intradomain ? Robert Raszuk
- Re: [sidr] [Idr] draft-ietf-sidr-bgpsec-threats-0… Stephen Kent
- Re: [sidr] draft-ietf-sidr-bgpsec-threats-02: Pat… Stephen Kent
- Re: [sidr] draft-ietf-sidr-bgpsec-threats-02: Pat… Stephen Kent
- Re: [sidr] [Idr] No BGPSEC intradomain ? Christopher Morrow
- Re: [sidr] No BGPSEC intradomain ? Warren Kumari
- Re: [sidr] No BGPSEC intradomain ? Robert Raszuk
- Re: [sidr] [Idr] No BGPSEC intradomain ? Christopher Morrow
- Re: [sidr] [Idr] No BGPSEC intradomain ? Robert Raszuk
- Re: [sidr] [Idr] No BGPSEC intradomain ? Warren Kumari
- Re: [sidr] [Idr] No BGPSEC intradomain ? Montgomery, Douglas
- Re: [sidr] [Idr] No BGPSEC intradomain ? Christopher Morrow
- Re: [sidr] [Idr] No BGPSEC intradomain ? Robert Raszuk
- Re: [sidr] [Idr] No BGPSEC intradomain ? Robert Raszuk
- Re: [sidr] [Idr] No BGPSEC intradomain ? Jakob Heitz
- Re: [sidr] [Idr] No BGPSEC intradomain ? Christopher Morrow
- Re: [sidr] [Idr] No BGPSEC intradomain ? Christopher Morrow
- Re: [sidr] [Idr] No BGPSEC intradomain ? Christopher Morrow
- Re: [sidr] [Idr] No BGPSEC intradomain ? Jakob Heitz
- Re: [sidr] [Idr] No BGPSEC intradomain ? Randy Bush
- Re: [sidr] [Idr] No BGPSEC intradomain ? Randy Bush
- Re: [sidr] [Idr] No BGPSEC intradomain ? Robert Raszuk
- Re: [sidr] [Idr] No BGPSEC intradomain ? Paul Jakma
- [sidr] iBGP, BGPSEC and incremental deployment (w… Jeffrey Haas
- Re: [sidr] [Idr] No BGPSEC intradomain ? Christopher Morrow
- Re: [sidr] iBGP, BGPSEC and incremental deploymen… Jakob Heitz
- Re: [sidr] iBGP, BGPSEC and incremental deploymen… Christopher Morrow
- Re: [sidr] [Idr] No BGPSEC intradomain ? Brian Dickson
- Re: [sidr] iBGP, BGPSEC and incremental deploymen… Jeffrey Haas
- Re: [sidr] iBGP, BGPSEC and incremental deploymen… Jeffrey Haas
- Re: [sidr] iBGP, BGPSEC and incremental deploymen… Christopher Morrow
- Re: [sidr] [Idr] No BGPSEC intradomain ? George, Wes
- Re: [sidr] iBGP, BGPSEC and incremental deploymen… George, Wes
- Re: [sidr] [Idr] No BGPSEC intradomain ? George, Wes
- Re: [sidr] [Idr] No BGPSEC intradomain ? Robert Raszuk
- Re: [sidr] [Idr] No BGPSEC intradomain ? Jeffrey Haas
- Re: [sidr] iBGP, BGPSEC and incremental deploymen… Jeffrey Haas
- Re: [sidr] iBGP, BGPSEC and incremental deploymen… Christopher Morrow
- Re: [sidr] iBGP, BGPSEC and incremental deploymen… Jeffrey Haas
- Re: [sidr] [Idr] No BGPSEC intradomain ? George, Wes
- Re: [sidr] [Idr] No BGPSEC intradomain ? Jeffrey Haas
- Re: [sidr] [Idr] No BGPSEC intradomain ? Paul Jakma
- Re: [sidr] iBGP, BGPSEC and incremental deploymen… Jakob Heitz
- Re: [sidr] [Idr] iBGP, BGPSEC and incremental dep… Brian Dickson