IETF Logo Mail Archive

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

Christopher Morrow <morrowc.lists@gmail.com> Tue, 10 April 2012 21:05 UTC

Return-Path: <christopher.morrow@gmail.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 587DB11E8154; Tue, 10 Apr 2012 14:05:07 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -103.499
X-Spam-Level:
X-Spam-Status: No, score=-103.499 tagged_above=-999 required=5 tests=[AWL=0.100, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, 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 zJ6T9ysqvlqr; Tue, 10 Apr 2012 14:05:06 -0700 (PDT)
Received: from mail-ob0-f172.google.com (mail-ob0-f172.google.com [209.85.214.172]) by ietfa.amsl.com (Postfix) with ESMTP id 4F46111E814B; Tue, 10 Apr 2012 14:05:01 -0700 (PDT)
Received: by obbtb4 with SMTP id tb4so300604obb.31 for <multiple recipients>; Tue, 10 Apr 2012 14:05:01 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=pc3SLTC8lbIAIiJBVG86JKWNtWQoMima21Vve0j5x68=; b=DlaUX5A7Q+eA/90XIrSxQ1UqZoCH3YW+YCV336AAmbPvpFHmb3Qq4ImC6NTenoSqkq u5EbDOOCSlH3LVK6+0xi4j9vGuPoo1RF9M1Jv4jTMVRK5eHevDw9/BdaMdTPFhKVd8Jy IjcQ5/VaA8nuEuqvLJsJI4AaCxAZEnVTFmnGAQ+sYzn8wiG8WEZKa5GkSqHVrLNk/BsR HdLc6jjPMryuxe+y0dSegUUzE29puoHQUvDezkz95knf1Sz7v47i9XSko+ygGns89Pgq TvfOvQX61i2q0wcImpuNyq397CS0q0IqjpuibHPsHCCOax3BP5uAWUH9h5LGELy4t00R fAEQ==
MIME-Version: 1.0
Received: by 10.182.159.41 with SMTP id wz9mr17995065obb.69.1334091900958; Tue, 10 Apr 2012 14:05:00 -0700 (PDT)
Sender: christopher.morrow@gmail.com
Received: by 10.182.153.34 with HTTP; Tue, 10 Apr 2012 14:05:00 -0700 (PDT)
In-Reply-To: <7309FCBCAE981B43ABBE69B31C8D21391B3EE03F77@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>
Date: Tue, 10 Apr 2012 17:05:00 -0400
X-Google-Sender-Auth: RkJR20gO2KACrvNk4MCNaJqaQPQ
Message-ID: <CAL9jLaaOOTURBUQsMSW6HRwu+j9r3f6MKLYMoPvS4WXNt9jdgA@mail.gmail.com>
From: Christopher Morrow <morrowc.lists@gmail.com>
To: Jakob Heitz <jakob.heitz@ericsson.com>
Content-Type: text/plain; charset="ISO-8859-1"
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:05:07 -0000

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

v2.23.0 | Report a Bug | By Email