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

Christopher Morrow <morrowc.lists@gmail.com> Tue, 10 April 2012 16:53 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 464F621F8661; Tue, 10 Apr 2012 09:53:03 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -103.599
X-Spam-Level:
X-Spam-Status: No, score=-103.599 tagged_above=-999 required=5 tests=[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 LqodVhTnhPuP; Tue, 10 Apr 2012 09:53:01 -0700 (PDT)
Received: from mail-yw0-f52.google.com (mail-yw0-f52.google.com [209.85.213.52]) by ietfa.amsl.com (Postfix) with ESMTP id 920E821F8684; Tue, 10 Apr 2012 09:52:59 -0700 (PDT)
Received: by yhpp61 with SMTP id p61so2388946yhp.25 for <multiple recipients>; Tue, 10 Apr 2012 09:52:57 -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=UduqRddfpLr69NErUcQy3z7+FsvHQAP3D4UEUAkJ7YY=; b=wTbczWO+zQKLMaEq3YGz6ZiKYqVKP/SsWTqVBq7lWWJad6Wzz/ED6c2nVC3/FdFFUV p0zX9IGbWnDRTY403Af3Z2TTX38HyQeXMcFthHMHB+G8FtvqFlXD/ks4sn/Rauqi0Ykd WxvMLnc138JwJOE12FEQ1zdPN7LhlNjpYtRLWIC87x5di1vLGvECY5L1yH2AJjjXdsgg Pkz6TZMH/MSZNoNrwbJODLJ3cYu1esps5oyGszb0XCHM8ogkNRWM5xoHsYO/8GFuRuHD gkNGBllAa44Os1DqjAHWOiC/69nlDDjbiie8mO+xnqGXKwbUH+H0sJRaLNuvc7OYYxgd r3cg==
MIME-Version: 1.0
Received: by 10.60.24.201 with SMTP id w9mr16750567oef.49.1334076777708; Tue, 10 Apr 2012 09:52:57 -0700 (PDT)
Sender: christopher.morrow@gmail.com
Received: by 10.182.153.34 with HTTP; Tue, 10 Apr 2012 09:52:57 -0700 (PDT)
In-Reply-To: <4F846121.2050408@raszuk.net>
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>
Date: Tue, 10 Apr 2012 12:52:57 -0400
X-Google-Sender-Auth: GgUjAXP7ezF2eMb3pb8xanU6NFo
Message-ID: <CAL9jLaYF-MW1cJ2n28BiV1mi+tpPS2ECKB2UxhFMQ=NXxbihCg@mail.gmail.com>
From: Christopher Morrow <morrowc.lists@gmail.com>
To: robert@raszuk.net
Content-Type: text/plain; charset=ISO-8859-1
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
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:53:04 -0000

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