Re: [sidr] Burstiness of BGP updates

Brian Dickson <brian.peter.dickson@gmail.com> Wed, 16 November 2011 05:56 UTC

Return-Path: <brian.peter.dickson@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 72E601F0D1C for <sidr@ietfa.amsl.com>; Tue, 15 Nov 2011 21:56:26 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.483
X-Spam-Level:
X-Spam-Status: No, score=-3.483 tagged_above=-999 required=5 tests=[AWL=0.116, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1]
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 d-xVak8BY1VR for <sidr@ietfa.amsl.com>; Tue, 15 Nov 2011 21:56:25 -0800 (PST)
Received: from mail-bw0-f44.google.com (mail-bw0-f44.google.com [209.85.214.44]) by ietfa.amsl.com (Postfix) with ESMTP id 66EB01F0D1A for <sidr@ietf.org>; Tue, 15 Nov 2011 21:56:25 -0800 (PST)
Received: by bkbzv15 with SMTP id zv15so147361bkb.31 for <sidr@ietf.org>; Tue, 15 Nov 2011 21:56:24 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=UZpRVjdhcPEy5WhqsVOFNuFefuOggU02/SxstTMmRkQ=; b=SbXWlyMzJ34yNJ73K336fzrlEGYEmu05qHRDF8X2V4irkcHvzED7SUA4iLeDS6hAhL 0ti/84AUaOd11YqQ9rTeiBqmcziHWxdsKQH6hIH3tAEKgHTgxLLDlIslvh+qFddmQUWC cdoZUL9NdXgnJFVjdZLd/u76FU5JEl4ewpwFs=
MIME-Version: 1.0
Received: by 10.205.138.17 with SMTP id iq17mr19563703bkc.118.1321422984394; Tue, 15 Nov 2011 21:56:24 -0800 (PST)
Received: by 10.223.54.15 with HTTP; Tue, 15 Nov 2011 21:56:24 -0800 (PST)
In-Reply-To: <CAL9jLaZ+m=P37X+Q3sf5r=RmdDniA+XSYMbQFF8_PZyCq2WtUQ@mail.gmail.com>
References: <D7A0423E5E193F40BE6E94126930C49308E9E35567@MBCLUSTER.xchange.nist.gov> <7309FCBCAE981B43ABBE69B31C8D21391A45A1F85D@EUSAACMS0701.eamcs.ericsson.se> <m2fwhqeq5i.wl%randy@psg.com> <CCE759E6-BEA6-433B-957A-6559C67BAD52@ericsson.com> <DCC302FAA9FE5F4BBA4DCAD4656937791452387941@PRVPEXVS03.corp.twcable.com> <7309FCBCAE981B43ABBE69B31C8D21391A45A1FE9F@EUSAACMS0701.eamcs.ericsson.se> <DCC302FAA9FE5F4BBA4DCAD4656937791452387978@PRVPEXVS03.corp.twcable.com> <7309FCBCAE981B43ABBE69B31C8D21391A45A1FEC8@EUSAACMS0701.eamcs.ericsson.se> <4EC3125D.4000309@riw.us> <7309FCBCAE981B43ABBE69B31C8D21391A45A2061F@EUSAACMS0701.eamcs.ericsson.se> <4EC329C6.4090600@riw.us> <7309FCBCAE981B43ABBE69B31C8D21391A45A2062E@EUSAACMS0701.eamcs.ericsson.se> <CAH1iCiqFq7reoMrCBAUOk-PdmZDYoed+ii37xQbgX0nopNgDEw@mail.gmail.com> <CAL9jLaZ+m=P37X+Q3sf5r=RmdDniA+XSYMbQFF8_PZyCq2WtUQ@mail.gmail.com>
Date: Wed, 16 Nov 2011 00:56:24 -0500
Message-ID: <CAH1iCiq38ViGN_UWr9+AGuOhfvzgbedRk0esrjmk4B6L_Tk+8g@mail.gmail.com>
From: Brian Dickson <brian.peter.dickson@gmail.com>
To: Christopher Morrow <morrowc.lists@gmail.com>
Content-Type: text/plain; charset=ISO-8859-1
Cc: "sidr@ietf.org" <sidr@ietf.org>
Subject: Re: [sidr] Burstiness of BGP updates
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: Wed, 16 Nov 2011 05:56:26 -0000

On Wed, Nov 16, 2011 at 12:35 AM, Christopher Morrow
<morrowc.lists@gmail.com> wrote:
> On Wed, Nov 16, 2011 at 12:29 AM, Brian Dickson
>> Does this illustrate the importance of not only validating origins,
>> but also only using signed prefixes if you are participating in
>> BGPsec?
>
> sure, but if your customer forgets to pay a bill, calls you up and
> (post proper 'this is the customer' authentication) says: "Hey, srsly,
> I forgot, checks in the mail to ARIN, can you accept our route pls?"

I was using "only" in contrast to Jakob, who was suggesting having the same
prefix and as-path, both signed and unsigned, be used, and in fact the
unsigned used prior to validating the signatures.

Basically, if you have BGPsec enabled with a given peer, you might get
a combination of signed and unsigned from that peer - but for a given prefix,
you MUST only get one or the other. Invalid-sig != unsigned.

Accepting unsigned as a "fast" short-cut is insane, frankly.

Signed prefix processing actually needs to "block" until the signature
result is received.
On a per-prefix basis, of course.

This is why having your cache very close is important, as are any
possible implementation
optimizations or design considerations that improve signature
processing/capacity/timeliness.

> you may be willing to do same, you may also be willing to do this in
> the case of internal services routes that you don't actually want
> externally visible.

Sure - and locally significant signatures/trust-anchors are very
important for just such an occasion.
(For any convenient value of "local", it should be noted. City, zip
code, province, continent, building, whatever.)

>
> re-announcement is 'harder' since it's not clear if NTT is supposed to
> be passing cogent aol's routes or not, is it?

Agreed - I can't be specific on exactly when, but expect me to present something
"real soon now" on a nuts-and-bolts level of how to do this. Maybe a
month, maybe two.

Brian