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 :-)))