Re: [sidr] [Idr] No BGPSEC intradomain ?

Robert Raszuk <robert@raszuk.net> Tue, 10 April 2012 17:00 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 D203011E8102 for <sidr@ietfa.amsl.com>; Tue, 10 Apr 2012 10:00:39 -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 lcUtESGrAsVj for <sidr@ietfa.amsl.com>; Tue, 10 Apr 2012 10:00:39 -0700 (PDT)
Received: from mail1310.opentransfer.com (mail1310.opentransfer.com [76.162.254.103]) by ietfa.amsl.com (Postfix) with ESMTP id 1701A11E80F3 for <sidr@ietf.org>; Tue, 10 Apr 2012 10:00:39 -0700 (PDT)
Received: (qmail 31084 invoked by uid 399); 10 Apr 2012 17:00:38 -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 17:00:38 -0000
X-Originating-IP: 83.31.51.142
Message-ID: <4F846736.2060604@raszuk.net>
Date: Tue, 10 Apr 2012 19:00:38 +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: Christopher Morrow <morrowc.lists@gmail.com>
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>
In-Reply-To: <CAL9jLaYF-MW1cJ2n28BiV1mi+tpPS2ECKB2UxhFMQ=NXxbihCg@mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Cc: "idr@ietf.org List" <idr@ietf.org>, sidr@ietf.org
Subject: Re: [sidr] [Idr] 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 17:00:40 -0000

 > So... we can send the data along, but in the case of BGPSEC speakers
 > the data isn't used (it's replicated in the BGPSEC_SIGNED_PATH).

So far I have always heard that BGPSEC is just providing the hint to the 
operator and does not change how BGP works.

Here you are saying that now AS_PATH length should be calculated from 
completely different (and optional) attribute.

You are also saying that now multipath code which computes which path 
are eligible to be multipath needs to look/parse/decrypt totally 
different attribute.

All BGP monitoring tools need to be upgraded to now understand BGPSEC 
attribute too. And surprise .. here BMP will not convert it like it will 
to "legacy" speakers.

You may think that if we stuff all "data" in the new attribute and drop 
the other one everything else will work. This may be so in theory, but 
it is clearly not a case in practice.

Regards,
R.


> On Tue, Apr 10, 2012 at 12:34 PM, Robert Raszuk<robert@raszuk.net>  wrote:
>> Anyhow my doubt has been answered and I stay by my opinion that not sending
>> AS_PATH and AS4_PATH is a terrible idea.
>
> So... we can send the data along, but in the case of BGPSEC speakers
> the data isn't used (it's replicated in the BGPSEC_SIGNED_PATH).
> Carrying extra bits isn't actually helpful is it? (the implementers
> drove the design decision here I believe)
>
>> 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.
>
> is it helpful for the folks that write bgp code though? "Hey, you will
> need to re-synthesize the as-path at sec->non-sec boundaries. you need
> to also create sec-path at none->sec boundaries."
>
> -chris
>
>