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

Jakob Heitz <jakob.heitz@ericsson.com> Tue, 10 April 2012 21:51 UTC

Return-Path: <jakob.heitz@ericsson.com>
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 6F90111E80DF; Tue, 10 Apr 2012 14:51:36 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.599
X-Spam-Level:
X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
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 k31aGmiBXMZQ; Tue, 10 Apr 2012 14:51:35 -0700 (PDT)
Received: from imr4.ericy.com (imr4.ericy.com [198.24.6.9]) by ietfa.amsl.com (Postfix) with ESMTP id 8EB7811E80D2; Tue, 10 Apr 2012 14:51:35 -0700 (PDT)
Received: from eusaamw0711.eamcs.ericsson.se ([147.117.20.178]) by imr4.ericy.com (8.14.3/8.14.3/Debian-9.1ubuntu1) with ESMTP id q3ALpV3l009585; Tue, 10 Apr 2012 16:51:32 -0500
Received: from EUSAACMS0701.eamcs.ericsson.se ([169.254.1.55]) by eusaamw0711.eamcs.ericsson.se ([147.117.20.178]) with mapi; Tue, 10 Apr 2012 17:51:26 -0400
From: Jakob Heitz <jakob.heitz@ericsson.com>
To: Christopher Morrow <morrowc.lists@gmail.com>
Date: Tue, 10 Apr 2012 17:51:24 -0400
Thread-Topic: [Idr] [sidr] No BGPSEC intradomain ?
Thread-Index: Ac0XXpPBlalJJAgKTW6BRADxpxuq2gABNbSg
Message-ID: <7309FCBCAE981B43ABBE69B31C8D21391B3EE04140@EUSAACMS0701.eamcs.ericsson.se>
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> <7309FCBCAE981B43ABBE69B31C8D21391B3EE03F77@EUSAACMS0701.eamcs.ericsson.se> <CAL9jLaaOOTURBUQsMSW6HRwu+j9r3f6MKLYMoPvS4WXNt9jdgA@mail.gmail.com>
In-Reply-To: <CAL9jLaaOOTURBUQsMSW6HRwu+j9r3f6MKLYMoPvS4WXNt9jdgA@mail.gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: "idr@ietf.org List" <idr@ietf.org>, "sidr@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
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 21:51:37 -0000

On Tuesday, April 10, 2012 2:05 PM, Christopher Morrow <> wrote:

> On Tue, Apr 10, 2012 at 2:22 PM, Jakob Heitz
> <jakob.heitz@ericsson.com> wrote: 
>> On Tuesday, April 10, 2012 9:53 AM, Christopher Morrow <> wrote:
>> 
>>> 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)
>> 
>> I think it was along the lines of:
>> 2 AS paths will create the opportunity for an error if they differ
>> and we don't want to go around the error-handling block again.
>> 
>> I agree with Robert. Today, there are many tools that interact
>> with BGP messages. If the AS_PATH disappears, they will all break.
> 
> aspath doesn't disappear if I'm only speaking to a non-BGPSEC speaker.
> If the tools in question are updated to understand BGPSEC (and
> negotiate that capability with the bgp speaker) then ... they'd
> obviously have to know how to deal with this situation, right?
> 
> -chris

This will be a hurdle on the way to adoption.
I can see the network operator now: "My tools won't run. Let's
not turn BGPSEC on today".

The error-checking excuse looks real lame to me.

-- 
Jakob Heitz.