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

Warren Kumari <warren@kumari.net> Tue, 10 April 2012 17:37 UTC

Return-Path: <warren@kumari.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 7C37221F866D; Tue, 10 Apr 2012 10:37:38 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -106.599
X-Spam-Level:
X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, 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 3pktSovE8s6J; Tue, 10 Apr 2012 10:37:38 -0700 (PDT)
Received: from vimes.kumari.net (vimes.kumari.net [198.186.192.250]) by ietfa.amsl.com (Postfix) with ESMTP id E499221F866B; Tue, 10 Apr 2012 10:37:37 -0700 (PDT)
Received: from dhcp-172-19-119-246.cbf.corp.google.com (unknown [64.13.52.115]) by vimes.kumari.net (Postfix) with ESMTPSA id AB4391B402FA; Tue, 10 Apr 2012 13:37:36 -0400 (EDT)
Mime-Version: 1.0 (Apple Message framework v1084)
Content-Type: text/plain; charset=us-ascii
From: Warren Kumari <warren@kumari.net>
In-Reply-To: <CAL9jLaYF-MW1cJ2n28BiV1mi+tpPS2ECKB2UxhFMQ=NXxbihCg@mail.gmail.com>
Date: Tue, 10 Apr 2012 13:37:34 -0400
Content-Transfer-Encoding: quoted-printable
Message-Id: <D7CF4F8F-AF93-43F2-BC0D-26E072307B4F@kumari.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> <CAL9jLaYF-MW1cJ2n28BiV1mi+tpPS2ECKB2UxhFMQ=NXxbihCg@mail.gmail.com>
To: Christopher Morrow <morrowc.lists@gmail.com>
X-Mailer: Apple Mail (2.1084)
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 17:37:38 -0000

On Apr 10, 2012, at 12:52 PM, 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 that sone of the biggest issues to keep in mind with carrying the "same" data in two places is what to do when you suddenly discover that they are not actually the same?

There has been much good work in IDR to better handle bugs / implementations issues, and these considerations probably had much to do with this...

For example, I'm a BGPSEC speaker. In the BGPSEC bits I see:

AS1 AS2 AS3 AS4 AS5  All this checks out, the magic crypto says all is happy, etc.
but, in the AS_PATH I see:
AS1 AS 100 AS17 AS6

What do I do here? Do I a: drop the update or b: ignore the issue or c: reset the session or d: prefer the singed or unsigned or e: nasal demons?  
Someone who's opinion I really respect once said: Never test for an error condition you don't know how to handle.

This idea extends this by simply not allowing the error condition to occur.

You have all of the information to recreate the AS_PATH / AS4_PATH when you leave a BGPSEC domain, and because it is only in one place, you sidestep all sorts of weird error corner cases...

W


> 
>> 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
> _______________________________________________
> sidr mailing list
> sidr@ietf.org
> https://www.ietf.org/mailman/listinfo/sidr
>